Re: [PPL-devel] Arithmetic evaluation bug in the CVS HEAD version of XSB
Paul Broome wrote:
As I'm sure you know, the is/2 predicate is nonlogical. This difference is also in previous versions of XSB. In this instance, there is a simple alternate:
[broome@localhost bin]$ ./xsb-bits64 [xsb_configuration loaded] [sysinitrc loaded]
XSB Version 3.1 (Incognito) of August 10, 2007 [x86_64-unknown-linux-gnu; mode: optimal; engine: slg-wam; gc: indirection; scheduling: local]
| ?- [user]. [Compiling user] side_step_term_as_arithmetic_argument_bug(Term,N) :- call(N is Term). end_of_file. [user compiled, cpu time used: 0.0090 seconds] [user loaded]
| ?- side_step_term_as_arithmetic_argument_bug(1+1+1,N).
N = 3;
no | ?- End XSB (cputime 0.02 secs, elapsetime 74.23 secs)
I hope this helps.
Dear Paul,
thanks for the workaround. However, I don't understand how the fact that the is/2 predicate is nonlogical matters. Do you agree with me that the behavior I indicated witnesses a (big) XSB bug? All the best,
Roberto
This is a longstanding bug with XSB's compiler. I tried fixing it 4-5 years ago, but my fix caused problems with some optimizations that XSB performs with arithmetic expressions, so the fix was never adopted.
But you're right -- it is a big (though localized) bug and we should fix it. Do you have a work-around for the immediate future?
Terry
On Sun, 23 Sep 2007, Roberto Bagnara wrote:
Paul Broome wrote:
As I'm sure you know, the is/2 predicate is nonlogical. This difference is also in previous versions of XSB. In this instance, there is a simple alternate:
[broome@localhost bin]$ ./xsb-bits64 [xsb_configuration loaded] [sysinitrc loaded]
XSB Version 3.1 (Incognito) of August 10, 2007 [x86_64-unknown-linux-gnu; mode: optimal; engine: slg-wam; gc: indirection; scheduling: local]
| ?- [user]. [Compiling user] side_step_term_as_arithmetic_argument_bug(Term,N) :- call(N is Term). end_of_file. [user compiled, cpu time used: 0.0090 seconds] [user loaded]
| ?- side_step_term_as_arithmetic_argument_bug(1+1+1,N).
N = 3;
no | ?- End XSB (cputime 0.02 secs, elapsetime 74.23 secs)
I hope this helps.
Dear Paul,
thanks for the workaround. However, I don't understand how the fact that the is/2 predicate is nonlogical matters. Do you agree with me that the behavior I indicated witnesses a (big) XSB bug? All the best,
Roberto-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Xsb-development mailing list Xsb-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xsb-development
Terrance Swift wrote:
This is a longstanding bug with XSB's compiler. I tried fixing it 4-5 years ago, but my fix caused problems with some optimizations that XSB performs with arithmetic expressions, so the fix was never adopted.
But you're right -- it is a big (though localized) bug and we should fix it. Do you have a work-around for the immediate future?
Yes, I have one. But I look forward to get rid of it. Thanks,
Roberto
We'll handle it one way or another (though I'm interested in Bart's further comments.)
BTW, Some other changes that should be coming into CVS within the next couple of weeks from either David or me (if all goes as planned):
-- Multi-threaded XASP -- ISO Private thread queues and thread_signal/2 -- call_cleanup/2 -- Guaranteed interrupt handling before cuts and before disjunctions within a clause (this may not include disjuntions set up when backing through trie_asserted code, however).
Terry
On Sun, 23 Sep 2007, Roberto Bagnara wrote:
Terrance Swift wrote:
This is a longstanding bug with XSB's compiler. I tried fixing it 4-5 years ago, but my fix caused problems with some optimizations that XSB performs with arithmetic expressions, so the fix was never adopted.
But you're right -- it is a big (though localized) bug and we should fix it. Do you have a work-around for the immediate future?
Yes, I have one. But I look forward to get rid of it. Thanks,
Roberto-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Xsb-development mailing list Xsb-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xsb-development
-- call_cleanup/2
In WG17, there was an attempt to propose call_cleanup/2 for the standard - the specification was rather incomplete to say the least. I am looking forward to seeing XSB's :-) And also to how you implemented it (which might be looking forward twice to the same thing actually).
Cheers
Bart Demoen
On 2007/09/23, at 20:35, Bart Demoen wrote:
-- call_cleanup/2
In WG17, there was an attempt to propose call_cleanup/2 for the standard - the specification was rather incomplete to say the least.
Correction: there *IS* a proposal for adding call_cleanup/2 to the ISO standard. It's in the core revision DRAFT proposal and yes, its specification needs work. This draft has not discussed in the latest ISO WG 17 meeting (at ICLP'07) but contributions are welcome. The following Prolog compilers implement a version of this predicate: SICStus Prolog, SWI-Prolog, YAP, Qu-Prolog, and B-Prolog (there might be others). Terry: having done some work on implementing this predicate on YAP and B-Prolog, I will be happy to collaborate with you on the XSB implementation.
All the best,
Paulo
----------------------------------------------------------------- Paulo Jorge Lopes de Moura Dep. of Computer Science, University of Beira Interior 6201-001 Covilhã, Portugal
Office 4.3 Ext. 3257 Phone: +351 275319891 Fax: +351 275319899 Email: mailto:pmoura@di.ubi.pt
Home page: http://www.di.ubi.pt/~pmoura Research: http://logtalk.org/ -----------------------------------------------------------------
having done some work on implementing this predicate on YAP and B-Prolog
As I pointed out earlier: the one in Yap is/was buggy (wrt any intended specification). Has it been corrected in the mean time ?
Cheers
Bart
On 2007/09/24, at 10:01, Bart Demoen wrote:
having done some work on implementing this predicate on YAP and B-Prolog
As I pointed out earlier: the one in Yap is/was buggy (wrt any intended specification). Has it been corrected in the mean time ?
Not yet. Hope to do some work on it before YAP 5.1.3 is released. I will keep you posted.
Cheers,
Paulo
----------------------------------------------------------------- Paulo Jorge Lopes de Moura Dep. of Computer Science, University of Beira Interior 6201-001 Covilhã, Portugal
Office 4.3 Ext. 3257 Phone: +351 275319891 Fax: +351 275319899 Email: mailto:pmoura@di.ubi.pt
Home page: http://www.di.ubi.pt/~pmoura Research: http://logtalk.org/ -----------------------------------------------------------------
Roberto, I agree with your sentiments and have suffered similar frustrations. It indeed illustrates a significant departure from the expected result and will be a surprise to most new users. Then again, I would say that all logic programming systems are hindered in many ways by the underlying operating systems. XSB has other value. Best wishes - Paul
Roberto Bagnara wrote:
Paul Broome wrote:
As I'm sure you know, the is/2 predicate is nonlogical. This difference is also in previous versions of XSB. In this instance, there is a simple alternate:
[broome@localhost bin]$ ./xsb-bits64 [xsb_configuration loaded] [sysinitrc loaded]
XSB Version 3.1 (Incognito) of August 10, 2007 [x86_64-unknown-linux-gnu; mode: optimal; engine: slg-wam; gc: indirection; scheduling: local]
| ?- [user]. [Compiling user] side_step_term_as_arithmetic_argument_bug(Term,N) :- call(N is Term). end_of_file. [user compiled, cpu time used: 0.0090 seconds] [user loaded]
| ?- side_step_term_as_arithmetic_argument_bug(1+1+1,N).
N = 3;
no | ?- End XSB (cputime 0.02 secs, elapsetime 74.23 secs)
I hope this helps.
Dear Paul,
thanks for the workaround. However, I don't understand how the fact that the is/2 predicate is nonlogical matters. Do you agree with me that the behavior I indicated witnesses a (big) XSB bug? All the best,
Roberto
Do you agree with me that the behavior I indicated witnesses a (big) XSB bug?
It is more of an inconsistency than a bug: XSB has chosen not to evaluate variables on the right side of is/2 - Quintus used to do the same. Long ago, I didn't understand that there are good reasons for this choice. Now I think that Prolog would be better of without this feature.
Terry, why does the following not work as a fix in the compiler ? At compile time, replace X is Y by
(number(Y) -> X = Y ; throw(appropriate error) ) That would give consistent behaviour, no ? Even though not ISO. You don't have to do such a thing for </2 (and friends) because of the rest of XSB's compilation schema for arithmetic ... which has its more important problems of course:
| ?- -2147483648 < 2147483647 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
no | ?- -2147483648 < 1 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
yes | ?- -2 < 2147483647 .
no
All the above in XSB Version 3.0.1 (Sagres) of August 7, 2006
Cheers
Bart Demoen
On Sun, 23 Sep 2007, Bart Demoen wrote:
Do you agree with me that the behavior I indicated witnesses a (big) XSB bug?
It is more of an inconsistency than a bug: XSB has chosen not to evaluate variables on the right side of is/2 - Quintus used to do the same. Long ago, I didn't understand that there are good reasons for this choice. Now I think that Prolog would be better of without this feature.
I'm interested in why you think this (especially as this is what we do anyway :-)
Terry, why does the following not work as a fix in the compiler ? At compile time, replace X is Y by
(number(Y) -> X = Y ; throw(appropriate error) ) That would give consistent behaviour, no ? Even though not ISO. You don't have to do such a thing for </2 (and friends) because of the rest of XSB's compilation schema for arithmetic ... which has its more important problems of course:
This may be a good solution if we decide not to go the ISO way.
| ?- -2147483648 < 2147483647 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
no | ?- -2147483648 < 1 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
yes | ?- -2 < 2147483647 .
no
All the above in XSB Version 3.0.1 (Sagres) of August 7, 2006
Unfortunately, it is still the same in 3.1 (unless you use 64-bit compilation).
Terry
I'm interested in why you think this (especially as this is what we do anyway :-)
A bunch of small reasons:
- how much time goes into explaining to new users of Prolog this particular feature of Prolog ? just too much to be worth its while
- lot's of existing code has the form:
loop(0) :- !. loop(N) :- M is N - 1, loop(M).
also in libraries. Try to explain to users that ?- loop(0). finishes (quickly) but that ?- loop(1-1). loops.
- try giving a type to predicates that use ISO arithmetic - you must cater for the arithmetic expressions; suddenly, lists that were supposed to have only numbers, are typed as list of arit_expression and this propagates in places you don't want
- I find it inconsistent that some builtins but not all, accept besides numbers also arithmetic expressions (similar for library predicates); why is ?- length([1,2,3],1+2). in SWI an error, but succeeds in Yap ? Why did ISO decide to flag ?- functor(foo(1),_,2-1). as an error ? How about ?- put(97+1). ? Not ISO I know, but Yap and SICStus (3.*) are fine with it, while SWI (5.6.39) says Type error.
- how much time goes into maintaining besides a compilation schema for arithmetic, also an interpreter ? just too much to be worthwhile
Unfortunately, it is still the same in 3.1 (unless you use 64-bit compilation).
But I would then just use larger numbers and have the same problems, right ?
Cheers
Bart Demoen
Friends,
Sorry I'm a latecomer to this party, but I do have one comment:
Terrance Swift writes:
| ?- -2147483648 < 2147483647 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
no | ?- -2147483648 < 1 .
++Error[XSB]: [Runtime/C] Overflow in integer, returning MAX_INT
yes
I recently did some work on integer overflow in the tokenizer. Previously, it was pretty bad in XSB. I tried to make it less bad. The above is one problem I punted. -2147483648, the smallest 32-bit integer, is flagged incorrectly as overflow, as shown here. The problem is that it's not easy in the XSB tokenizer to determine when processing an integer whether it is positive or negative; they essentially are all initially treated as positive. So since 2147483648 *is* an overflow, I took the easy way out and flagged it an error even in the case in which it would be turned negative, and so be OK. That was my laziness. (Bart, do you have a practical example in which it was critical to have that one, rather special, negative integer? :-).
Now:
| ?- -2 < 2147483647 .
no
This is quite troubling. I will look into it.
-David
(Bart, do you have a practical example in which it was critical to have that one, rather special, negative integer? :-).
Of course, oodles of them :-)
I was just trying to cook up examples that give unexpected behaviour. I had started from a predicate a/2:
a(X,Y) :- X < Y .
and did queries like ?- a(large_neg_int,large_pos_int), e.g:
| ?- a(-2147483647,3).
no
for instance.
What I later pasted in my mail was some sort of abbreviation of some of the queries. I didn't even notice it was showing some different weird behaviour. I now realize that toplevel queries of </2 can behave differently from compiled goals. The problem with compiled </2 is that XSB compiles X < Y to X-Y < 0 (or something like that - when there is (undetected ?) overflow in the -/2, things go wrong.
Cheers
Bart Demoen
Bart Demoen writes:
What I later pasted in my mail was some sort of abbreviation of some of the queries. I didn't even notice it was showing some different weird behaviour. I now realize that toplevel queries of </2 can behave differently from compiled goals. The problem with compiled </2 is that XSB compiles X < Y to X-Y < 0 (or something like that - when there is (undetected ?) overflow in the -/2, things go wrong.
Ah yes. Thanks for that insight. Hmmm, looks like we should first detect overflow, and then figure out how to change the compiler to not use difference to compile comparisons.
-David
Bart Demoen wrote:
Terry, why does the following not work as a fix in the compiler ? At compile time, replace X is Y by
(number(Y) -> X = Y ; throw(appropriate error) ) That would give consistent behaviour, no ? Even though not ISO.
Please, do strive for standard conformance in any aspect of the system. Going the other way around brings nowhere. Just my 2 cents. Cheers,
Roberto
participants (6)
-
Bart Demoen -
David Warren -
Paul Broome -
Paulo Moura -
Roberto Bagnara -
Terrance Swift