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.
