<!-- 
RSS generated by JIRA (4.4#649-r158309) at Sat May 25 03:17:46 CDT 2013

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary add field=key&field=summary to the URL of your request.
For example:
http://dev.clojure.org/jira/si/jira.issueviews:issue-xml/LOGIC-112/LOGIC-112.xml?field=key&field=summary
-->
<rss version="0.92" >
<channel>
    <title>Clojure JIRA</title>
    <link>http://dev.clojure.org/jira</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>4.4</version>
        <build-number>649</build-number>
        <build-date>25-07-2011</build-date>
    </build-info>

<item>
            <title>[LOGIC-112] Incorrect results with tabled resolution</title>
                <link>http://dev.clojure.org/jira/browse/LOGIC-112</link>
                <project id="10020" key="LOGIC">core.logic</project>
                        <description>&lt;p&gt;We (authors of damp.qwal and damp.ekeko) are trying to track the cause of some indeterminism with respect to the solutions to a path query over a control flow graph.  To this end, we wrote a small test case that mimics the qwal part of the query. This test case works under core.logic 0.7.5, but exhibits incorrect behavior in the latest release.&lt;/p&gt;

&lt;p&gt;The test case illustrates two problems:&lt;br/&gt;
First, the solutions to two logically equivalent path queries return differ. The query that uses predicate test-2 returns the correct amount of solutions (4 nodes encountered on the single path through a graph).&lt;br/&gt;
The query that uses predicate test-1 returns just 2 nodes.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;damp.tabling-test&amp;gt; (test-1)
(:baz :quux)
damp.tabling-test&amp;gt; (test-2)
(:foo :bar :baz :quux)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;Both queries skip an arbitrary number of nodes (using patho), capture a node to obtain a solution (through unification), and skip an arbitrary number of nodes.&lt;br/&gt;
The predicates only differ in the last step: either this is achieved by including &apos;patho&apos; as the last element in the last that is passed to solve-goals, or by calling &apos;patho&apos; separately after the call to solve-goals. Logic-wise, both queries should be equivalent. Note that omitting &apos;tabled&apos; from the definition of &apos;patho&apos; causes the tests to behave as expected.&lt;/p&gt;

&lt;p&gt;Second, we encountered a minor issue concerning the number of results returned by the faulty query. This &lt;em&gt;sometimes&lt;/em&gt; changes when the file is recompiled.&lt;/p&gt;

&lt;div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;&gt;&lt;div class=&quot;codeContent panelContent&quot;&gt;
&lt;pre class=&quot;code-java&quot;&gt;damp.tabling-test&amp;gt; (test-1)
(:quux)
;;recompile
damp.tabling-test&amp;gt; (test-1)
(:baz :quux)&lt;/pre&gt;
&lt;/div&gt;&lt;/div&gt;

&lt;p&gt;More comments can be found in the code for the test case that is attached.&lt;/p&gt;</description>
                <environment>org.clojure/clojure &amp;quot;1.3.0&amp;quot;&lt;br/&gt;
org.clojure/core.logic &amp;quot;0.8.0-rc2&amp;quot;</environment>
            <key id="15991">LOGIC-112</key>
            <summary>Incorrect results with tabled resolution</summary>
                <type id="1" iconUrl="http://dev.clojure.org/jira/images/icons/bug.gif">Defect</type>
                                <priority id="3" iconUrl="http://dev.clojure.org/jira/images/icons/priority_major.gif">Major</priority>
                    <status id="5" iconUrl="http://dev.clojure.org/jira/images/icons/status_resolved.gif">Resolved</status>
                    <resolution id="1">Completed</resolution>
                                <assignee username="dnolen">David Nolen</assignee>
                                <reporter username="resteven">Reinout Stevens</reporter>
                        <labels>
                    </labels>
                <created>Tue, 5 Feb 2013 09:30:04 -0600</created>
                <updated>Wed, 13 Mar 2013 08:51:19 -0500</updated>
                    <resolved>Wed, 13 Mar 2013 08:51:19 -0500</resolved>
                                                                    <due></due>
                    <votes>0</votes>
                        <watches>2</watches>
                        <comments>
                    <comment id="30591" author="dnolen" created="Wed, 13 Feb 2013 15:10:23 -0600"  >&lt;p&gt;Ok, I&apos;ve confirmed the issue. Will look into it.&lt;/p&gt;</comment>
                    <comment id="30725" author="dnolen" created="Mon, 11 Mar 2013 08:37:54 -0500"  >&lt;p&gt;I believe I have found the issue as well as the source of the nondeterminism. When we switched to sets away from lists for the cache I didn&apos;t fully think through the implications. The nondeterminism arises from the use of sets. We actually want a hybrid cache datatype that works like a list but can efficiently check for the existence of a cached answer w/o scanning the list.&lt;/p&gt;</comment>
                    <comment id="30756" author="dnolen" created="Wed, 13 Mar 2013 08:51:19 -0500"  >&lt;p&gt;fixed, &lt;a href=&quot;http://github.com/clojure/core.logic/commit/53cbfca4b7062e09d7c7ff43fccec70e46d36ea1&quot;&gt;http://github.com/clojure/core.logic/commit/53cbfca4b7062e09d7c7ff43fccec70e46d36ea1&lt;/a&gt;&lt;/p&gt;</comment>
                </comments>
                    <attachments>
                    <attachment id="11836" name="tabling-test.clj" size="3988" author="resteven" created="Tue, 5 Feb 2013 09:30:04 -0600" />
                </attachments>
            <subtasks>
        </subtasks>
                <customfields>
                                                                                            <customfield id="customfield_10010" key="com.pyxis.greenhopper.jira:gh-global-rank">
                <customfieldname>Global Rank</customfieldname>
                <customfieldvalues>
                    
                </customfieldvalues>
            </customfield>
                                            <customfield id="customfield_10000" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                <customfieldname>Patch</customfieldname>
                <customfieldvalues>
                        <customfieldvalue key="10000">None</customfieldvalue>

                </customfieldvalues>
            </customfield>
                                                                                        </customfields>
    </item>
</channel>
</rss>