OK this is informative :) The bug in your program is helping me find a bug in core.logic :)
David On Thu, Mar 6, 2014 at 6:20 PM, Mauro Lopes <[email protected]> wrote: > When you asked what result I expected, I have answered regarding my whole > program, and I think this has created this confusion. I should have focused > on the gist only. Sorry for that. > > Considering this, I think the correct answer is the one with 5 results in > the set. I think all five of them satisfy the constraints. Do you think (1 > 0 0 1) does not satisfy? > > > On Thursday, March 6, 2014, Mauro Lopes <[email protected]> wrote: > >> Well, I've just noticed that the version we are using has some clauses >> removed. See the last clause of solve-row in >> >> >> http://github.com/maurolopes/nonogramsolver/blob/master/src/nonogramsolver/core.clj >> >> The idea is that, whenever a var becomes 0, the sum of all the remaining >> vars have to be equal to the sum of the remaining numbers. So, in (1 0 0 >> 1), when the second var becomes zero, the sum of the last two must be equal >> to 0, which is not the case. >> Also, I suspect there is some error in my code, since in this case there >> should be no 1 followed by 0. >> Sorry for the confusion. When reporting the problem to the list, I >> removed all the clauses I could to make the example minimal, hoping it >> would make debugging easier. The only problem is that it made the expected >> results no longer the same. But the problem still exists. >> >> >> On Thu, Mar 6, 2014 at 2:43 PM, David Nolen <[email protected]>wrote: >> >> Ok but what logic disallows the results that you don't think should be in >> there? I'm assuming something in your program prevents (1 0 0 1)? >> >> David >> >> >> On Thu, Mar 6, 2014 at 11:56 AM, Mauro Lopes <[email protected]>wrote: >> >> Actually what I desire to get as a result is only the first three >> solutions: >> >> #{(0 1 1 0) (1 1 0 0) (0 0 1 1)} >> >> I noticed that, in order to get this solution, I can just replace >> >> ([[] vars]) >> >> with >> >> ([[] vars] >> (l/everyg #(l/== % 0) vars)) >> >> and it seems to work fine for my program, and I agree that this change is >> necessary for it to work as intended. >> >> Anyway, without this change, what I really think it should return is: >> >> #{(0 1 1 0) (1 1 0 0) (0 0 1 1) (1 1 1 0) (1 1 0 1) (1 1 1 1) (0 1 1 1)} >> >> So, in my opinion, both of the solutions (4 or 5 results) are incorrect, >> core.logic is adding a few extra results and missing others. >> >> >> On Thu, Mar 6, 2014 at 11:34 AM, David Nolen <[email protected]>wrote: >> >> Thanks I can confirm. I'm assuming the case where you get 5 results in >> the set is simply not correct? >> >> David >> >> >> On Wed, Mar 5, 2014 at 10:33 PM, Mauro Lopes <[email protected]>wrote: >> >> Sure. I have added fd/in for all vars involved in fd operations and the >> problem persists. I uploaded the new code to JIRA. See if it helps. >> Thanks. >> >> Regards, >> >> Mauro >> >> >> On Wednesday, March 5, 2014 12:18:23 PM UTC-3, David Nolen wrote: >> >> So I took a closer look at this and noticed that you're not using fd/in >> in all the locations where you create fresh vars and then apply finite >> domain operation on them. This is not correct. >> >> Can you fix your code and then let us know if the problem continues to >> persist? >> >> Thanks, >> David >> >> >> On Sat, Feb 22, 2014 at 7:48 PM, Mauro Lopes <[email protected]> wrote: >> >> Done. Ticket is at http://dev.clojure.org/jira/browse/LOGIC-156 >> Thanks, David. >> >> On Saturday, February 22, 2014 9:01:54 PM UTC-3, David Nolen wrote: >> >> Sounds like a bug, please file a bug in JIRA with this code and I will >> take a look. Thanks! >> >> David >> >> >> On Sat, Feb 22, 2014 at 5:53 PM, Mauro Lopes <[email protected]> wrote: >> >> Hello everyone, >> >> I am new to core.logic but have been using it for the past few days >> (version 0.8.7). >> I have found a behavior that seems strange to me. I have written a search >> (run*) that does not always return the same set of results if I run it a >> few times wit >> >> -- > You received this message because you are subscribed to the Google Groups > "minikanren" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/minikanren. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "minikanren" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/minikanren. For more options, visit https://groups.google.com/d/optout.
