Re: The Reasoned Schemer chpt 4: "Please pass the aspirin"
On Sunday, 25 February 2018 17:46:26 UTC, Calvin Sauer wrote: > > I'm currently struggling with the same question. Did you ever happen to > reach a satisfying conclusion? > https://groups.google.com/forum/#!topic/minikanren/JCKJV7k7lGU -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: The Reasoned Schemer chpt 4: "Please pass the aspirin"
I'm currently struggling with the same question. Did you ever happen to reach a satisfying conclusion? On Saturday, May 25, 2013 at 1:21:08 PM UTC-4, Brian Craft wrote: > > Wondering if anyone can give me some pointers with this, as I dive into > logic programming. Or point me to a more appropriate forum, if this is the > wrong one. I know a lot of you have been trying out core.logic. > > It was all going well until chapter four. The story so far: introduce some > simple function, like cdr, then develop a logic programming equivalent, > repeat. Then in chapter four we get the second commandment, and the > equivalent functions stop being equivalent. Instead, they generate > meaningless results, like 4.18, where the value of z is irrelevant to > whether the equivalent function (mem) would succeed, since the target > pattern appears earlier in the list, but memo outputs an infinite number of > the target pattern. Or they generate incorrect results, like 4.31, where > some of the patterns do not satisfy the equivalent function (rember), like > (a b _.0 d e): z can't be removed unless it unifies with y, in which case > y would have been removed, not z. The chapter concludes by highlighting > this issue with "surprise", a simple example which generates solutions that > don't satisfy the constraints. > > I was hoping, at that point, for insights into accurately translating > functions into their logic programming equivalents, however the chapter > ends with "Please pass the aspirin", and the book continues with more > "second commandment" examples that also produce unhelpful results. > > So, I'm a bit baffled about the point of this exercise. Why is it useful > to have a second commandment that converts functions into logic programming > functions that are superficially similar, but fundamentally different, > producing solutions that are irrelevant or incorrect for the original > function? Is there some different technique that would allow one to > generate correct solutions with logic programming? > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
The Reasoned Schemer chpt 4: Please pass the aspirin
Wondering if anyone can give me some pointers with this, as I dive into logic programming. Or point me to a more appropriate forum, if this is the wrong one. I know a lot of you have been trying out core.logic. It was all going well until chapter four. The story so far: introduce some simple function, like cdr, then develop a logic programming equivalent, repeat. Then in chapter four we get the second commandment, and the equivalent functions stop being equivalent. Instead, they generate meaningless results, like 4.18, where the value of z is irrelevant to whether the equivalent function (mem) would succeed, since the target pattern appears earlier in the list, but memo outputs an infinite number of the target pattern. Or they generate incorrect results, like 4.31, where some of the patterns do not satisfy the equivalent function (rember), like (a b _.0 d e): z can't be removed unless it unifies with y, in which case y would have been removed, not z. The chapter concludes by highlighting this issue with surprise, a simple example which generates solutions that don't satisfy the constraints. I was hoping, at that point, for insights into accurately translating functions into their logic programming equivalents, however the chapter ends with Please pass the aspirin, and the book continues with more second commandment examples that also produce unhelpful results. So, I'm a bit baffled about the point of this exercise. Why is it useful to have a second commandment that converts functions into logic programming functions that are superficially similar, but fundamentally different, producing solutions that are irrelevant or incorrect for the original function? Is there some different technique that would allow one to generate correct solutions with logic programming? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The Reasoned Schemer chpt 4: Please pass the aspirin
Hi Brian, You should post your question to the miniKanren Google group. minikan...@googlegroups.com -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com On Sat May 25 10:21 , Brian Craft wrote: Wondering if anyone can give me some pointers with this, as I dive into logic programming. Or point me to a more appropriate forum, if this is the wrong one. I know a lot of you have been trying out core.logic. It was all going well until chapter four. The story so far: introduce some simple function, like cdr, then develop a logic programming equivalent, repeat. Then in chapter four we get the second commandment, and the equivalent functions stop being equivalent. Instead, they generate meaningless results, like 4.18, where the value of z is irrelevant to whether the equivalent function (mem) would succeed, since the target pattern appears earlier in the list, but memo outputs an infinite number of the target pattern. Or they generate incorrect results, like 4.31, where some of the patterns do not satisfy the equivalent function (rember), like (a b _.0 d e): z can't be removed unless it unifies with y, in which case y would have been removed, not z. The chapter concludes by highlighting this issue with surprise, a simple example which generates solutions that don't satisfy the constraints. I was hoping, at that point, for insights into accurately translating functions into their logic programming equivalents, however the chapter ends with Please pass the aspirin, and the book continues with more second commandment examples that also produce unhelpful results. So, I'm a bit baffled about the point of this exercise. Why is it useful to have a second commandment that converts functions into logic programming functions that are superficially similar, but fundamentally different, producing solutions that are irrelevant or incorrect for the original function? Is there some different technique that would allow one to generate correct solutions with logic programming? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The Reasoned Schemer chpt 4: Please pass the aspirin
+1 On Sat, May 25, 2013 at 8:12 PM, Austin Haas aus...@pettomato.com wrote: Hi Brian, You should post your question to the miniKanren Google group. minikan...@googlegroups.com -austin -- Austin Haas Pet Tomato, Inc. http://pettomato.com On Sat May 25 10:21 , Brian Craft wrote: Wondering if anyone can give me some pointers with this, as I dive into logic programming. Or point me to a more appropriate forum, if this is the wrong one. I know a lot of you have been trying out core.logic. It was all going well until chapter four. The story so far: introduce some simple function, like cdr, then develop a logic programming equivalent, repeat. Then in chapter four we get the second commandment, and the equivalent functions stop being equivalent. Instead, they generate meaningless results, like 4.18, where the value of z is irrelevant to whether the equivalent function (mem) would succeed, since the target pattern appears earlier in the list, but memo outputs an infinite number of the target pattern. Or they generate incorrect results, like 4.31, where some of the patterns do not satisfy the equivalent function (rember), like (a b _.0 d e): z can't be removed unless it unifies with y, in which case y would have been removed, not z. The chapter concludes by highlighting this issue with surprise, a simple example which generates solutions that don't satisfy the constraints. I was hoping, at that point, for insights into accurately translating functions into their logic programming equivalents, however the chapter ends with Please pass the aspirin, and the book continues with more second commandment examples that also produce unhelpful results. So, I'm a bit baffled about the point of this exercise. Why is it useful to have a second commandment that converts functions into logic programming functions that are superficially similar, but fundamentally different, producing solutions that are irrelevant or incorrect for the original function? Is there some different technique that would allow one to generate correct solutions with logic programming? -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Clojure group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups Clojure group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
