Menu ▾ ▴

#257 A question on recursive query

wrong answer
open
nobody
None
5
2022-12-15
2022-12-06
chi
No

Hi,

I have the following program:

:- table huxq/1.

fwzn(15).
fwzn(-25).
fwzn(11).
fwzn(5).
qzsg(-34, 2).
qzsg(4, 41).

huxq(A) :- qzsg(4, A).
huxq(A) :- huxq(B), qzsg(A, A), huxq(A), not fwzn(A).
huxq(A) :- fwzn(A), not huxq(A).

I execute it in XSB with command: 

xsb --noprompt --quietload --nobanner --nofeedback -e "[example], huxq(A), writeln([A]), fail. halt."

Then I get the result:

[5]
[11]
[-25]
[15]
[41]

But I compute the result manually, I find the result should only be 41. The result of the first rule is 41, the result of the second rule is empty, the result of the third rule is 41. I don't know why there are five facts in the result.
If I remove huxq(B) in the second rule, I can get the result 41. But huxq(B) should have no influence on the final result.
Could you please help me to see what I did wrong?

Related

Bugs: #257

Discussion

  • Michael Kifer

    Michael Kifer - 2022-12-06



    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <style id="bidiui-paragraph-margins" type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>


    probably you are not paying attention and are ignoring compiler warnings.


    ++Warning[XSB]: [Compiler]  Singleton variable B in a clause of huxq/1


    We have very little time for answering these questions, especially of the kind that could be avoided.



    On 12/5/22 9:26 PM, chi wrote:
    ---

** [bugs:#257] A question on recursive query**

**Status:** open
**Group:** wrong answer
**Created:** Tue Dec 06, 2022 02:26 AM UTC by chi
**Last Updated:** Tue Dec 06, 2022 02:26 AM UTC
**Owner:** nobody


Hi,

I have the following program:


    :- table huxq/1.

fwzn(15).
fwzn(-25).
fwzn(11).
fwzn(5).
qzsg(-34, 2).
qzsg(4, 41).

huxq(A) :- qzsg(4, A).
huxq(A) :- huxq(B), qzsg(A, A), huxq(A), not fwzn(A).
huxq(A) :- fwzn(A), not huxq(A).

    


I execute it in XSB with command: 


    xsb --noprompt --quietload --nobanner --nofeedback -e "[example], huxq(A), writeln([A]), fail. halt."

    


Then I get the result:


    [5]
[11]
[-25]
[15]
[41]

    


But I compute the result manually, I find the result should only be 41. The result of the first rule is 41, the result of the second rule is empty, the result of the third rule is 41. I don't know why there are five facts in the result.
If I remove huxq(B) in the second rule, I can get the result 41. But huxq(B) should have no influence on the final result. 
Could you please help me to see what I did wrong?


---

Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/xsb/bugs/257/>



To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>

     

  • chi

    chi - 2022-12-14

    Hi,

    I am very sorry to disturb you!

    But I found that this problem also occurs in programs without any warnings. Consider the following program:

    :- table jbuh/1.

jbuh(19).
jbuh(-23).
jbuh(0).
jbuh(-23).
jbuh(6).
nlwd(-2).
nlwd(-20).
nlwd(8).
nlwd(29).
nlwd(23).

pfeg(A, A) :- nlwd(A).
jbuh(A) :- nlwd(A), not jbuh(A).
jbuh(B) :- pfeg(B, C), jbuh(C).

    I execute it with the command:

    /tmp/xsb-code/XSB/bin/xsb --noprompt --quietload --nobanner --nofeedback -e "[example], jbuh(A), writeln([A]), fail. halt."

    Then I get the results:

    [0]
[6]
[8]
[19]
[23]
[29]
[-23]
[-20]
[-2]

    But I executed the two rules for jbuh separately and they both only had the following results:

    [6]
[0]
[-23]
[19]

    So their union should not have 9 tuples, right?

     

    • Michael Kifer

      Michael Kifer - 2022-12-14

      well, you are not paying attention here too :-)

      With tabled predicates you should use tnot, if you want well-founded
      semantics. Then 5 of these will be undefined.

      But you will not see that some are undefined with writeln. To filter out
      the undefined ones, read the manual.

      The simplest way to see that is to use the XSB command line interface.

      First debug your query there and only then do other things, like the -e
      option and whatever.

      --

      --- michael

      On 12/14/22 7:24 AM, chi wrote:

      Hi,

      I am very sorry to disturb you!

      But I found that this problem also occurs in programs without any
      warnings. Consider the following program:

      |:- table jbuh/1. jbuh(19). jbuh(-23). jbuh(0). jbuh(-23). jbuh(6).
      nlwd(-2). nlwd(-20). nlwd(8). nlwd(29). nlwd(23). pfeg(A, A) :-
      nlwd(A). jbuh(A) :- nlwd(A), not jbuh(A). jbuh(B) :- pfeg(B, C), jbuh(C). |

      I execute it with the command:

      |/tmp/xsb-code/XSB/bin/xsb--noprompt --quietload --nobanner
      --nofeedback -e "[example], jbuh(A), writeln([A]), fail. halt." |

      Then I get the results:

      |[0][6][8][19][23][29][-23][-20][-2]|

      But I executed the two rules for jbuh separately and they both only
      had the following results:

      |[6][0][-23][19]|

      So their union should not have 9 tuples, right?

      [bugs:#257] https://sourceforge.net/p/xsb/bugs/257/ A question on
      recursive query

      Status: open
      Group: wrong answer
      Created: Tue Dec 06, 2022 02:26 AM UTC by chi
      Last Updated: Tue Dec 06, 2022 02:26 AM UTC
      Owner: nobody

      Hi,

      I have the following program:

      |:- table huxq/1. fwzn(15). fwzn(-25). fwzn(11). fwzn(5). qzsg(-34,
      2). qzsg(4, 41). huxq(A) :- qzsg(4, A). huxq(A) :- huxq(B), qzsg(A,
      A), huxq(A), not fwzn(A). huxq(A) :- fwzn(A), not huxq(A). |

      I execute it in XSB with command:

      |xsb--noprompt --quietload --nobanner --nofeedback -e "[example],
      huxq(A), writeln([A]), fail. halt." |

      Then I get the result:

      |[5][11][-25][15][41]|

      But I compute the result manually, I find the result should only be
      41. The result of the first rule is 41, the result of the second rule
      is empty, the result of the third rule is 41. I don't know why there
      are five facts in the result.
      If I remove huxq(B) in the second rule, I can get the result 41. But
      huxq(B) should have no influence on the final result.
      Could you please help me to see what I did wrong?

      Sent from sourceforge.net because you indicated interest in
      https://sourceforge.net/p/xsb/bugs/257/
      https://sourceforge.net/p/xsb/bugs/257/

      To unsubscribe from further messages, please visit
      https://sourceforge.net/auth/subscriptions/
      https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #257

  • chi

    chi - 2022-12-15

    Hi Michael,

    Thank you very much for your patient answer! I tried with "tnot" and get the correct result.

    But I'd like to ask if this indicates a small bug on "not", or if this incorrect usage should be reported by grammar checker. Because for this example, executing the two rules separately and executing them together should have the same result, right?

    Best,
    Chi

     

    • Michael Kifer

      Michael Kifer - 2022-12-15

      'not' is the usual prolog negation as failure synonymous with +. It doesn't have logical semantics.
      In some cases a warning could be issued if 'not' is applied to a tabled predicate but in general it's hard to detect. I don't know why partial detection wasn't adopted.

      Dec 14, 2022 22:04:25 chi cztest@users.sourceforge.net:

      Hi Michael,

      Thank you very much for your patient answer! I tried with "tnot" and get the correct result.

      But I'd like to ask if this indicates a small bug on "not", or if this incorrect usage should be reported by grammar checker. Because for this example, executing the two rules separately and executing them together should have the same result, right?

      Best,
      Chi

      [bugs:#257][https://sourceforge.net/p/xsb/bugs/257/] A question on recursive query

      Status: open
      Group: wrong answer
      Created: Tue Dec 06, 2022 02:26 AM UTC by chi
      Last Updated: Wed Dec 14, 2022 12:24 PM UTC
      Owner: nobody

      Hi,

      I have the following program:

      *:- table huxq/1.

      fwzn(15).
      fwzn(-25).
      fwzn(11).
      fwzn(5).
      qzsg(-34, 2).
      qzsg(4, 41).

      huxq(A) :- qzsg(4, A).
      huxq(A) :- huxq(B), qzsg(A, A), huxq(A), not fwzn(A).
      huxq(A) :- fwzn(A), not huxq(A). * I execute it in XSB with command:

      *xsb --noprompt --quietload --nobanner --nofeedback -e "[example], huxq(A), writeln([A]), fail. halt." * Then I get the result:

      *[5]
      [11]
      [-25]
      [15]
      [41] * But I compute the result manually, I find the result should only be 41. The result of the first rule is 41, the result of the second rule is empty, the result of the third rule is 41. I don't know why there are five facts in the result.
      If I remove huxq(B) in the second rule, I can get the result 41. But huxq(B) should have no influence on the final result.
      Could you please help me to see what I did wrong?

      Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/xsb/bugs/257/

      To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

       

      Related

      Bugs: #257

      alternate

  • chi

    chi - 2022-12-15

    I got it. Thank you very much for your answer.

     

Log in to post a comment.