#257 A question on recursive query

[chi]

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?

[Michael Kifer]

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <style id="user-content-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]

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]

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/

[chi]

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]

'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/

[chi]

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