Now turning my attention to (/)/2. SWI-Prolog wants me
to use set_prolog_flag(iso, true), to get the semantics
of the ISO core standard, page 116.

But the fuzzer still finds the needle in the haystack.
Using more bits to the numerator, and I find:

/* Jekejeke Prolog 1.5.5 */
?- X is -15915286457581575168 / -238455449856.
X = 6.674322800000001E7.

/* SWI-Prolog 8.5.18 */
?- current_prolog_flag(iso, X).
X = true.

?- X is -15915286457581575168 / -238455449856.
X = 66743227.99999999.

Now I have test cases so nasty, even Ciao Prolog and
SICStus Prolog are stumbling. Interestingly Ciao Prolog
and SICStus Prolog stumble at the exact same test cases.

/* Ciao Prolog 1.22.0 */
?- case4(N, P, Q, Y), Z is P/Q, Y =\= Z.
N = 3,
P = -138732791312937296168,
Q = 70775453,
Y = -1960182315087.9346,
Z = -1960182315087.9343 ? ;
no

/* SICStus Prolog 4.7.1 */
?- case4(N, P, Q, Y), Z is P/Q, Y =\= Z.
N = 3,
P = -138732791312937296168,
Q = 70775453,
Y = -1960182315087.9346,
Z = -1960182315087.9343 ? ;
no

Mostowski Collapse schrieb am Freitag, 14. Oktober 2022 um 10:41:45 UTC+2:
> Now turning my attention to (/)/2. SWI-Prolog wants me
> to use set_prolog_flag(iso, true), to get the semantics
> of the ISO core standard, page 116.
>
> But the fuzzer still finds the needle in the haystack.
> Using more bits to the numerator, and I find:
> /* Jekejeke Prolog 1.5.5 */
> ?- X is -15915286457581575168 / -238455449856.
> X = 6.674322800000001E7.
>
> /* SWI-Prolog 8.5.18 */
> ?- current_prolog_flag(iso, X).
> X = true.
>
> ?- X is -15915286457581575168 / -238455449856.
> X = 66743227.99999999.

Last chapter of the testing campaign. Testing (**)/2 now.

BTW, this is a little cringe what the fuzzer found for Dogelog
Player on Python. One can try Python 3.11 and will get:

Python 3.11.0rc1 (main, Aug 8 2022, 11:30:54)
>>> 396** -1
0.002525252525252525
>>> 1/396
0.0025252525252525255

Same test case that makes SICStus Prolog tumbling. Such
surprises lower the pain of testing, make it rather addictive.

Mostowski Collapse schrieb am Freitag, 14. Oktober 2022 um 10:43:32 UTC+2:
> Now I have test cases so nasty, even Ciao Prolog and
> SICStus Prolog are stumbling. Interestingly Ciao Prolog
> and SICStus Prolog stumble at the exact same test cases.
> /* Ciao Prolog 1.22.0 */
> ?- case4(N, P, Q, Y), Z is P/Q, Y =\= Z.
> N = 3,
> P = -138732791312937296168,
> Q = 70775453,
> Y = -1960182315087.9346,
> Z = -1960182315087.9343 ? ;
> no
>
> /* SICStus Prolog 4.7.1 */
> ?- case4(N, P, Q, Y), Z is P/Q, Y =\= Z.
> N = 3,
> P = -138732791312937296168,
> Q = 70775453,
> Y = -1960182315087.9346,
> Z = -1960182315087.9343 ? ;
> no
> Mostowski Collapse schrieb am Freitag, 14. Oktober 2022 um 10:41:45 UTC+2:
> > Now turning my attention to (/)/2. SWI-Prolog wants me
> > to use set_prolog_flag(iso, true), to get the semantics
> > of the ISO core standard, page 116.
> >
> > But the fuzzer still finds the needle in the haystack.
> > Using more bits to the numerator, and I find:
> > /* Jekejeke Prolog 1.5.5 */
> > ?- X is -15915286457581575168 / -238455449856.
> > X = 6.674322800000001E7.
> >
> > /* SWI-Prolog 8.5.18 */
> > ?- current_prolog_flag(iso, X).
> > X = true.
> >
> > ?- X is -15915286457581575168 / -238455449856.
> > X = 66743227.99999999.

Next challenge, how to keep my comparison matrice
small. There are so many JavaScript platforms, nodeJS,
browsers, and WTF they differ:

/* Chrome Windows Nok */
?- X is 1889**29.
X = 1.0250068783051206E95.

/* FireFox Windows Ok */
?- X is 1889**29.
X = 1.0250068783051207E95.

Whats the Novacore bigint versus float mantra? The difference
between the two notions “less precise and more speed” versus
“more precise and less speed” can be maybe capture as follows:

- Less Precise and More Speed: Even if the arguments are bigint, and
have potentially more than 52 bit mantissa, they are always first
converted to float. So that the operation is only performed with 52
bit arguments, allow for faster processing.

- More Precise and Less Speed: If the arguments are bigint or if
the arguments are rational numbers or arbitrary floats, all bits are
taken into account. So that the operation is performed with more bits
than only 52 bits, resulting in slower processing.

Theoretically in the intersection, when the arguments are already
52 bit mantissa, there should be no difference in speed and also
no difference in accuracy, except if the second mode is

also required to return more bits. So we also have for the
first mode the result is **always** required to be only a float.
Then there is mostlikely always a speed difference, and the

first mode is always faster and less accurate.

Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> Whats the Novacore bigint versus float mantra? The difference
> between the two notions “less precise and more speed” versus
> “more precise and less speed” can be maybe capture as follows:
>
> - Less Precise and More Speed: Even if the arguments are bigint, and
> have potentially more than 52 bit mantissa, they are always first
> converted to float. So that the operation is only performed with 52
> bit arguments, allow for faster processing.
>
> - More Precise and Less Speed: If the arguments are bigint or if
> the arguments are rational numbers or arbitrary floats, all bits are
> taken into account. So that the operation is performed with more bits
> than only 52 bits, resulting in slower processing.

Ok did some performance measurement. Basically used this harness.
Was reusing the test data, that was used for accuracy testing, so its
based on the same cases.p file:

% swi_perf
swi_perf :-
write('case, swi: '), time((between(1,20000,_),
case(_, X, Y), Y =\= float(X), fail; true)),
write('case2, swi: '), time((between(1,20000,_),
case2(_, X, Y), Y =\= float(X), fail; true)),
write('case3, swi: '), time((between(1,20000,_),
case3(_, X, Y), Y =\= float(X), fail; true)),
write('case4, swi: '), time((between(1,20000,_),
case4(_, P, Q, Y), Y =\= P/Q, fail; true)),
write('case5, swi: '), time((between(1,20000,_),
case5(_, P, Q, Y), Y =\= P/Q, fail; true)),
write('case6, swi: '), time((between(1,20000,_),
case6(_, P, Q, Y), Y =\= P**Q, fail; true)).

Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> Whats the Novacore bigint versus float mantra? The difference
> between the two notions “less precise and more speed” versus
> “more precise and less speed” can be maybe capture as follows:
>
> - Less Precise and More Speed: Even if the arguments are bigint, and
> have potentially more than 52 bit mantissa, they are always first
> converted to float. So that the operation is only performed with 52
> bit arguments, allow for faster processing.
>
> - More Precise and Less Speed: If the arguments are bigint or if
> the arguments are rational numbers or arbitrary floats, all bits are
> taken into account. So that the operation is performed with more bits
> than only 52 bits, resulting in slower processing.

Woa! My Jekejeke Prolog (was using JDK 1.8) is quite a number cruncher,
on the other hand Dogelog Player (was using nodeJS) is lacking behind.
Inbetween the result of Prolog systems that I tested, results in milliseconds.

System case case2 case3 case4 case5 case6
jekejeke 270 266 255 305 361 539
ciao 344 343 343 386 386 544
eclipse 414 388 396 518 541 939
trealla 553 547 549 569 565 605
swi 989 941 979 528 532 861
scryer 889 857 872 1177 1188 1147
sicstus 1087 1083 1104 1221 1218 1226
dogelog 1171 1163 1171 1241 1300 1330

Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:51:45 UTC+2:
> Ok did some performance measurement. Basically used this harness.
> Was reusing the test data, that was used for accuracy testing, so its
> based on the same cases.p file:
>
> % swi_perf
> swi_perf :-
> write('case, swi: '), time((between(1,20000,_),
> case(_, X, Y), Y =\= float(X), fail; true)),
> write('case2, swi: '), time((between(1,20000,_),
> case2(_, X, Y), Y =\= float(X), fail; true)),
> write('case3, swi: '), time((between(1,20000,_),
> case3(_, X, Y), Y =\= float(X), fail; true)),
> write('case4, swi: '), time((between(1,20000,_),
> case4(_, P, Q, Y), Y =\= P/Q, fail; true)),
> write('case5, swi: '), time((between(1,20000,_),
> case5(_, P, Q, Y), Y =\= P/Q, fail; true)),
> write('case6, swi: '), time((between(1,20000,_),
> case6(_, P, Q, Y), Y =\= P**Q, fail; true)).
> Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> > Whats the Novacore bigint versus float mantra? The difference
> > between the two notions “less precise and more speed” versus
> > “more precise and less speed” can be maybe capture as follows:
> >
> > - Less Precise and More Speed: Even if the arguments are bigint, and
> > have potentially more than 52 bit mantissa, they are always first
> > converted to float. So that the operation is only performed with 52
> > bit arguments, allow for faster processing.
> >
> > - More Precise and Less Speed: If the arguments are bigint or if
> > the arguments are rational numbers or arbitrary floats, all bits are
> > taken into account. So that the operation is performed with more bits
> > than only 52 bits, resulting in slower processing.

Code inspection sometimes helps find defects:

/* Jekejeke Prolog Ok */
?- X is (2^53+1)*2^64+1, Y is float(X).
X = 166153499473114502559719956244594689, Y = 1.6615349947311452E35.

/* SWI-Prolog 8.5.20 Ok */
?- X is float(166153499473114502559719956244594689).
X = 1.6615349947311452e+35.

/* Ciao Prolog Nok */
?- X is float(166153499473114502559719956244594689).
X = 1.661534994731145e35 ?

Pitty my fuzzer didn't find it. But I guess I will manually add it.

Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:52:41 UTC+2:
> Woa! My Jekejeke Prolog (was using JDK 1.8) is quite a number cruncher,
> on the other hand Dogelog Player (was using nodeJS) is lacking behind.
> Inbetween the result of Prolog systems that I tested, results in milliseconds.
>
> System case case2 case3 case4 case5 case6
> jekejeke 270 266 255 305 361 539
> ciao 344 343 343 386 386 544
> eclipse 414 388 396 518 541 939
> trealla 553 547 549 569 565 605
> swi 989 941 979 528 532 861
> scryer 889 857 872 1177 1188 1147
> sicstus 1087 1083 1104 1221 1218 1226
> dogelog 1171 1163 1171 1241 1300 1330
> Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:51:45 UTC+2:
> > Ok did some performance measurement. Basically used this harness.
> > Was reusing the test data, that was used for accuracy testing, so its
> > based on the same cases.p file:
> >
> > % swi_perf
> > swi_perf :-
> > write('case, swi: '), time((between(1,20000,_),
> > case(_, X, Y), Y =\= float(X), fail; true)),
> > write('case2, swi: '), time((between(1,20000,_),
> > case2(_, X, Y), Y =\= float(X), fail; true)),
> > write('case3, swi: '), time((between(1,20000,_),
> > case3(_, X, Y), Y =\= float(X), fail; true)),
> > write('case4, swi: '), time((between(1,20000,_),
> > case4(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > write('case5, swi: '), time((between(1,20000,_),
> > case5(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > write('case6, swi: '), time((between(1,20000,_),
> > case6(_, P, Q, Y), Y =\= P**Q, fail; true)).
> > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> > > Whats the Novacore bigint versus float mantra? The difference
> > > between the two notions “less precise and more speed” versus
> > > “more precise and less speed” can be maybe capture as follows:
> > >
> > > - Less Precise and More Speed: Even if the arguments are bigint, and
> > > have potentially more than 52 bit mantissa, they are always first
> > > converted to float. So that the operation is only performed with 52
> > > bit arguments, allow for faster processing.
> > >
> > > - More Precise and Less Speed: If the arguments are bigint or if
> > > the arguments are rational numbers or arbitrary floats, all bits are
> > > taken into account. So that the operation is performed with more bits
> > > than only 52 bits, resulting in slower processing.

Explanation of the defect:

Mostly based on code from Torbjorn Granlund, Johan Andersson,
and Mats Carlsson (Ref: Knuth vol. 2 sec. 4.3.1)

flt64_t bn_to_float(bignum_t *bn) {
while (i > 1) {
f = f*norm2 + u;
https://github.com/ciao -lang/ciao/blob/master/core/engine/eng_bignum.c#L1043

I think a defect could be if HALF_EVEN prematurely
rounds down the value of f, and then later a value of u,
would indicate that this rounding down was not legit,

but float addition cannot help it.

Mostowski Collapse schrieb am Donnerstag, 20. Oktober 2022 um 03:55:47 UTC+2:
> Code inspection sometimes helps find defects:
>
> /* Jekejeke Prolog Ok */
> ?- X is (2^53+1)*2^64+1, Y is float(X).
> X = 166153499473114502559719956244594689, Y = 1.6615349947311452E35.
>
> /* SWI-Prolog 8.5.20 Ok */
> ?- X is float(166153499473114502559719956244594689).
> X = 1.6615349947311452e+35.
>
> /* Ciao Prolog Nok */
> ?- X is float(166153499473114502559719956244594689).
> X = 1.661534994731145e35 ?
>
> Pitty my fuzzer didn't find it. But I guess I will manually add it.
> Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:52:41 UTC+2:
> > Woa! My Jekejeke Prolog (was using JDK 1.8) is quite a number cruncher,
> > on the other hand Dogelog Player (was using nodeJS) is lacking behind.
> > Inbetween the result of Prolog systems that I tested, results in milliseconds.
> >
> > System case case2 case3 case4 case5 case6
> > jekejeke 270 266 255 305 361 539
> > ciao 344 343 343 386 386 544
> > eclipse 414 388 396 518 541 939
> > trealla 553 547 549 569 565 605
> > swi 989 941 979 528 532 861
> > scryer 889 857 872 1177 1188 1147
> > sicstus 1087 1083 1104 1221 1218 1226
> > dogelog 1171 1163 1171 1241 1300 1330
> > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:51:45 UTC+2:
> > > Ok did some performance measurement. Basically used this harness.
> > > Was reusing the test data, that was used for accuracy testing, so its
> > > based on the same cases.p file:
> > >
> > > % swi_perf
> > > swi_perf :-
> > > write('case, swi: '), time((between(1,20000,_),
> > > case(_, X, Y), Y =\= float(X), fail; true)),
> > > write('case2, swi: '), time((between(1,20000,_),
> > > case2(_, X, Y), Y =\= float(X), fail; true)),
> > > write('case3, swi: '), time((between(1,20000,_),
> > > case3(_, X, Y), Y =\= float(X), fail; true)),
> > > write('case4, swi: '), time((between(1,20000,_),
> > > case4(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > > write('case5, swi: '), time((between(1,20000,_),
> > > case5(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > > write('case6, swi: '), time((between(1,20000,_),
> > > case6(_, P, Q, Y), Y =\= P**Q, fail; true)).
> > > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> > > > Whats the Novacore bigint versus float mantra? The difference
> > > > between the two notions “less precise and more speed” versus
> > > > “more precise and less speed” can be maybe capture as follows:
> > > >
> > > > - Less Precise and More Speed: Even if the arguments are bigint, and
> > > > have potentially more than 52 bit mantissa, they are always first
> > > > converted to float. So that the operation is only performed with 52
> > > > bit arguments, allow for faster processing.
> > > >
> > > > - More Precise and Less Speed: If the arguments are bigint or if
> > > > the arguments are rational numbers or arbitrary floats, all bits are
> > > > taken into account. So that the operation is performed with more bits
> > > > than only 52 bits, resulting in slower processing.

I added some hand picked test cases, from the
Ciao Prolog blooper, including some negative bigints.
Interestingly other Prolog systems are also pray to the

same blooper. In total I found that 3 Prolog systems have
this blooper, whereas Trealla only for 50%. Here are now
the number of failures from the new test cases:

% case3, trealla: 5
% case3, ciao: 10
% case3, sicstus: 10

Mostowski Collapse schrieb am Donnerstag, 20. Oktober 2022 um 03:58:38 UTC+2:
> Explanation of the defect:
>
> Mostly based on code from Torbjorn Granlund, Johan Andersson,
> and Mats Carlsson (Ref: Knuth vol. 2 sec. 4.3.1)
>
> flt64_t bn_to_float(bignum_t *bn) {
> while (i > 1) {
> f = f*norm2 + u;
> https://github.com/ciao -lang/ciao/blob/master/core/engine/eng_bignum.c#L1043
>
> I think a defect could be if HALF_EVEN prematurely
> rounds down the value of f, and then later a value of u,
> would indicate that this rounding down was not legit,
>
> but float addition cannot help it.
> Mostowski Collapse schrieb am Donnerstag, 20. Oktober 2022 um 03:55:47 UTC+2:
> > Code inspection sometimes helps find defects:
> >
> > /* Jekejeke Prolog Ok */
> > ?- X is (2^53+1)*2^64+1, Y is float(X).
> > X = 166153499473114502559719956244594689, Y = 1.6615349947311452E35..
> >
> > /* SWI-Prolog 8.5.20 Ok */
> > ?- X is float(166153499473114502559719956244594689).
> > X = 1.6615349947311452e+35.
> >
> > /* Ciao Prolog Nok */
> > ?- X is float(166153499473114502559719956244594689).
> > X = 1.661534994731145e35 ?
> >
> > Pitty my fuzzer didn't find it. But I guess I will manually add it.
> > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:52:41 UTC+2:
> > > Woa! My Jekejeke Prolog (was using JDK 1.8) is quite a number cruncher,
> > > on the other hand Dogelog Player (was using nodeJS) is lacking behind..
> > > Inbetween the result of Prolog systems that I tested, results in milliseconds.
> > >
> > > System case case2 case3 case4 case5 case6
> > > jekejeke 270 266 255 305 361 539
> > > ciao 344 343 343 386 386 544
> > > eclipse 414 388 396 518 541 939
> > > trealla 553 547 549 569 565 605
> > > swi 989 941 979 528 532 861
> > > scryer 889 857 872 1177 1188 1147
> > > sicstus 1087 1083 1104 1221 1218 1226
> > > dogelog 1171 1163 1171 1241 1300 1330
> > > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:51:45 UTC+2:
> > > > Ok did some performance measurement. Basically used this harness.
> > > > Was reusing the test data, that was used for accuracy testing, so its
> > > > based on the same cases.p file:
> > > >
> > > > % swi_perf
> > > > swi_perf :-
> > > > write('case, swi: '), time((between(1,20000,_),
> > > > case(_, X, Y), Y =\= float(X), fail; true)),
> > > > write('case2, swi: '), time((between(1,20000,_),
> > > > case2(_, X, Y), Y =\= float(X), fail; true)),
> > > > write('case3, swi: '), time((between(1,20000,_),
> > > > case3(_, X, Y), Y =\= float(X), fail; true)),
> > > > write('case4, swi: '), time((between(1,20000,_),
> > > > case4(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > > > write('case5, swi: '), time((between(1,20000,_),
> > > > case5(_, P, Q, Y), Y =\= P/Q, fail; true)),
> > > > write('case6, swi: '), time((between(1,20000,_),
> > > > case6(_, P, Q, Y), Y =\= P**Q, fail; true)).
> > > > Mostowski Collapse schrieb am Mittwoch, 19. Oktober 2022 um 16:42:37 UTC+2:
> > > > > Whats the Novacore bigint versus float mantra? The difference
> > > > > between the two notions “less precise and more speed” versus
> > > > > “more precise and less speed” can be maybe capture as follows:
> > > > >
> > > > > - Less Precise and More Speed: Even if the arguments are bigint, and
> > > > > have potentially more than 52 bit mantissa, they are always first
> > > > > converted to float. So that the operation is only performed with 52
> > > > > bit arguments, allow for faster processing.
> > > > >
> > > > > - More Precise and Less Speed: If the arguments are bigint or if
> > > > > the arguments are rational numbers or arbitrary floats, all bits are
> > > > > taken into account. So that the operation is performed with more bits
> > > > > than only 52 bits, resulting in slower processing.

Woa! My testing campaign has not yet ended. Now I
found a test case, where the Unix platform also fails.
Was increasing the bits in the case6/3 fuzzer:

pow2(B, E, X) :- E < 0, integer(E), !, X is 1/(B^(-E)).
pow2(B, E, X) :- X is B^E.

?- current_prolog_flag(iso, X).
X = false.

/* SWI-Prolog 8.5.20 WLS2 Nok */
?- repeat, L is -(1<<15), H is (1<<15)+1,
M is -(1<<3), J is (1<<3)+1, random(L, H, P),
random(M, J, Q), pow2(P, Q, A), B is P**Q, A=\=B.
P = -18573,
Q = -7,
A = -1.3116730299820406e-30,
B = -1.3116730299820408e-30 .

I have SWIPL on Unix platform only since weekend,
could not do this testing beforehand, so I guess I
need to update case6/3 test cases,

because they showed Unix platform completely
passing, which seems to be wrong. I used in the old
fuzzer 12 bits + 6 bits, the above uses 15 bits + 3 bits,

and new nasty test cases pop up. Its a test case where
JDK 19 non-strict also fails. Cool! I couldn’t believe that
it is that good. It was too good to be true.

So its also not that good!

/* Jekejeke Prolog 1.5.5, JDK 19 non-strict Nok */
?- X is -18573** -7.
X = -1.3116730299820408E-30.

Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 14:56:11 UTC+2:
> Woa! My testing campaign has not yet ended. Now I
> found a test case, where the Unix platform also fails.
> Was increasing the bits in the case6/3 fuzzer:
>
> pow2(B, E, X) :- E < 0, integer(E), !, X is 1/(B^(-E)).
> pow2(B, E, X) :- X is B^E.
>
> ?- current_prolog_flag(iso, X).
> X = false.
>
> /* SWI-Prolog 8.5.20 WLS2 Nok */
> ?- repeat, L is -(1<<15), H is (1<<15)+1,
> M is -(1<<3), J is (1<<3)+1, random(L, H, P),
> random(M, J, Q), pow2(P, Q, A), B is P**Q, A=\=B.
> P = -18573,
> Q = -7,
> A = -1.3116730299820406e-30,
> B = -1.3116730299820408e-30 .

Nope the JDK 19 is correct here. Bug in long division?

/* SWI-Prolog 8.5.20 WSL2 */
?- current_prolog_flag(iso, X).
X = false.

?- X is 1/(18573^7).
X = 1.3116730299820406e-30.

?- X is float(1 rdiv (18573^7)).
X = 1.3116730299820408e-30.

the Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 14:59:11 UTC+2:
> I have SWIPL on Unix platform only since weekend,
> could not do this testing beforehand, so I guess I
> need to update case6/3 test cases,
>
> because they showed Unix platform completely
> passing, which seems to be wrong. I used in the old
> fuzzer 12 bits + 6 bits, the above uses 15 bits + 3 bits,
>
> and new nasty test cases pop up. Its a test case where
> JDK 19 non-strict also fails. Cool! I couldn’t believe that
> it is that good. It was too good to be true.
>
> So its also not that good!
>
> /* Jekejeke Prolog 1.5.5, JDK 19 non-strict Nok */
> ?- X is -18573** -7.
> X = -1.3116730299820408E-30.
> Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 14:56:11 UTC+2:
> > Woa! My testing campaign has not yet ended. Now I
> > found a test case, where the Unix platform also fails.
> > Was increasing the bits in the case6/3 fuzzer:
> >
> > pow2(B, E, X) :- E < 0, integer(E), !, X is 1/(B^(-E)).
> > pow2(B, E, X) :- X is B^E.
> >
> > ?- current_prolog_flag(iso, X).
> > X = false.
> >
> > /* SWI-Prolog 8.5.20 WLS2 Nok */
> > ?- repeat, L is -(1<<15), H is (1<<15)+1,
> > M is -(1<<3), J is (1<<3)+1, random(L, H, P),
> > random(M, J, Q), pow2(P, Q, A), B is P**Q, A=\=B.
> > P = -18573,
> > Q = -7,
> > A = -1.3116730299820406e-30,
> > B = -1.3116730299820408e-30 .

Enhanced test cases, new viewpoint. Now WASM is
the more accurate platform, both for SWI and Ciao.
JDK 19 is still ultra accurate. But I cant say that it

is always correctly rounded. For non-integer arguments
I found a faulty example for (**)/2, but the below test
cases only test integer arguments of (**)/2:

System (=:=)/2 (/)/2 (**)/2 Total Variant
jekejeke 0 0 0 0 JDK 19
dogelog 0 0 2 2 PyPy
swi 0 0 4 4 WASM
sicstus 10 0 2 12 Windows
trealla 5 0 11 16 WSL2
ciao 10 0 10 20 WASM
scryer 33 46 11 90 WSL2
eclipse 33 45 68 146 Windows

Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 17:36:46 UTC+2:
> Nope the JDK 19 is correct here. Bug in long division?
>
> /* SWI-Prolog 8.5.20 WSL2 */
> ?- current_prolog_flag(iso, X).
> X = false.
> ?- X is 1/(18573^7).
> X = 1.3116730299820406e-30.
>
> ?- X is float(1 rdiv (18573^7)).
> X = 1.3116730299820408e-30.
> the Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 14:59:11 UTC+2:
> > I have SWIPL on Unix platform only since weekend,
> > could not do this testing beforehand, so I guess I
> > need to update case6/3 test cases,
> >
> > because they showed Unix platform completely
> > passing, which seems to be wrong. I used in the old
> > fuzzer 12 bits + 6 bits, the above uses 15 bits + 3 bits,
> >
> > and new nasty test cases pop up. Its a test case where
> > JDK 19 non-strict also fails. Cool! I couldn’t believe that
> > it is that good. It was too good to be true.
> >
> > So its also not that good!
> >
> > /* Jekejeke Prolog 1.5.5, JDK 19 non-strict Nok */
> > ?- X is -18573** -7.
> > X = -1.3116730299820408E-30.
> > Mostowski Collapse schrieb am Dienstag, 25. Oktober 2022 um 14:56:11 UTC+2:
> > > Woa! My testing campaign has not yet ended. Now I
> > > found a test case, where the Unix platform also fails.
> > > Was increasing the bits in the case6/3 fuzzer:
> > >
> > > pow2(B, E, X) :- E < 0, integer(E), !, X is 1/(B^(-E)).
> > > pow2(B, E, X) :- X is B^E.
> > >
> > > ?- current_prolog_flag(iso, X).
> > > X = false.
> > >
> > > /* SWI-Prolog 8.5.20 WLS2 Nok */
> > > ?- repeat, L is -(1<<15), H is (1<<15)+1,
> > > M is -(1<<3), J is (1<<3)+1, random(L, H, P),
> > > random(M, J, Q), pow2(P, Q, A), B is P**Q, A=\=B.
> > > P = -18573,
> > > Q = -7,
> > > A = -1.3116730299820406e-30,
> > > B = -1.3116730299820408e-30 .

Here is a trick to force Python compatibility mode, I guess
works for SWI-Prolog 8.5.20 which has improved rational
number rounding? Thats the incorrectly rounded result:

/* incorrectly rounded of the real number quotient */
?- X is 1267650600228229401496703205376 /
762385119722780192080867194597.
X = 1.662743103759914.
Now do switch on Python compatibility mode, and
watch the result getting correctly rounded:

/* Use this combo for Python compatibility:
prefer_rationals=true,
max_rational_size=0,
max_rational_size_action=float */
?- set_prolog_flag(prefer_rationals, true).
true.

?- set_prolog_flag(max_rational_size, 0).
true.

?- set_prolog_flag(max_rational_size_action, float).
true.

/* Correctly rounded of the real number quotient, via
detour over rational numbers, which are correctly
rounded since release 8.5.20 of SWI-Prolog? */
?- X is 1267650600228229401496703205376 /
762385119722780192080867194597.
X = 1.6627431037599143.

BTW the real number quotient is this real number:

1267650600228229401496703205376 /
762385119722780192080867194597 =
1.66274310375991431383116365048...

Was using microsoft calculator desk accessory. But
maybe should do more testing of this new Python
mode trick. Nasty test cases might lure everywhere.

Mostowski Collapse schrieb am Mittwoch, 26. Oktober 2022 um 16:01:01 UTC+2:
> Here is a trick to force Python compatibility mode, I guess
> works for SWI-Prolog 8.5.20 which has improved rational
> number rounding? Thats the incorrectly rounded result:
>
> /* incorrectly rounded of the real number quotient */
> ?- X is 1267650600228229401496703205376 /
> 762385119722780192080867194597.
> X = 1.662743103759914.
> Now do switch on Python compatibility mode, and
> watch the result getting correctly rounded:
>
> /* Use this combo for Python compatibility:
> prefer_rationals=true,
> max_rational_size=0,
> max_rational_size_action=float */
> ?- set_prolog_flag(prefer_rationals, true).
> true.
>
> ?- set_prolog_flag(max_rational_size, 0).
> true.
>
> ?- set_prolog_flag(max_rational_size_action, float).
> true.
>
> /* Correctly rounded of the real number quotient, via
> detour over rational numbers, which are correctly
> rounded since release 8.5.20 of SWI-Prolog? */
> ?- X is 1267650600228229401496703205376 /
> 762385119722780192080867194597.
> X = 1.6627431037599143.

My latest take on msb/2, in case a Prolog system
doesn't have this built-in. Some hi lo search:

% msb(+Integer, -Integer)
msb(0, N) :- !, N = -1.
msb(X, N) :-
msb(X, 1, N).

% msb(+Integer, +Integer, -Integer)
msb(X, H, N) :-
X < (1<<H), !,
L is H>>1,
msb(X, L, H, N).
msb(X, H, N) :-
J is H<<1,
msb(X, J, N).

% msb(+Integer, +Integer, +Integer, -Integer)
msb(_, L, H, N) :- L+1 =:= H, !,
N = L.
msb(X, L, H, N) :- M is (L+H) >> 1,
X < (1<<M), !,
msb(X, L, M, N).
msb(X, L, H, N) :- M is (L+H) >> 1,
msb(X, M, H, N).

But it is not a replacement for the real thing.
An msb/1 evaluable function still performs better.

So when will all Prolog system have these basic
evaluable functions and predicates?

msb/1: Return most significant bit of an integer
lsb/1: Return least significant bit of an integer
testbit/2: Succeed if bit of integer is set, otherwise fail.
divmod/4: Succeed with div and mod.

Scryer Prolog doesn't have these built-ins. So emulating
them makes it utterly slow. Using the hi lo approach for msb:

/* Scryer Prolog 0.9.1 WSL2 */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% CPU time: 4.240s
% CPU time: 5.621s
% CPU time: 7.718s
% true.

But it seems that bigints are not that fast, with ECLiPSe Prolog
which does not have these built-ins the hi lo isn't that bad:

/* ECLiPSe Prolog 7.1.12 Windows */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time_eclipse((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
0.904113500000676 sec
1.78132879998884 sec
1.56477859998995 sec

The best is always SWI-Prolog. It picks up trends and provides
functionallity so that the end-user can profit:

/* SWI-Prolog 8.5.20 Windows GMP */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% 8,699,603 inferences, 0.875 CPU in 0.879 seconds (100% CPU, 9942403 Lips)
% 7,952,250 inferences, 1.047 CPU in 1.064 seconds (98% CPU, 7596179 Lips)
% 3,771,657 inferences, 0.656 CPU in 0.673 seconds (97% CPU, 5747287 Lips)
true.

Whats wrong with the other Prolog systems, such as Scryer
Prolog and ECLiPSe Prolog that don't provide these built-ins?

Are they in a comatose sleeping beauty sleep?

Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:21:11 UTC+1:
> My latest take on msb/2, in case a Prolog system
> doesn't have this built-in. Some hi lo search:
>
> % msb(+Integer, -Integer)
> msb(0, N) :- !, N = -1.
> msb(X, N) :-
> msb(X, 1, N).
>
> % msb(+Integer, +Integer, -Integer)
> msb(X, H, N) :-
> X < (1<<H), !,
> L is H>>1,
> msb(X, L, H, N).
> msb(X, H, N) :-
> J is H<<1,
> msb(X, J, N).
>
> % msb(+Integer, +Integer, +Integer, -Integer)
> msb(_, L, H, N) :- L+1 =:= H, !,
> N = L.
> msb(X, L, H, N) :- M is (L+H) >> 1,
> X < (1<<M), !,
> msb(X, L, M, N).
> msb(X, L, H, N) :- M is (L+H) >> 1,
> msb(X, M, H, N).
>
> But it is not a replacement for the real thing.
> An msb/1 evaluable function still performs better.

The best I can do for Dogelog Player, concerning
msb/1 and the JavaScript platform. Just imagine
the speed if JavaScript would have a real msb/1
or bitlength/1, so that we don't need this nonsense?

function bigint_msb(alpha) {
alpha = alpha.toString(16);
return 31 - Math.clz32(hexvalue(alpha.codePointAt(0))) + (alpha.length - 1)*4;
}

This is a known problem that bigint has no msb/1 or
bitlength/1 in JavaScript as of now. Nevertheless I now
easily beat Scryer Prolog even with Dogelog Player.
Comparing to the hi lo search msb I get these results:

/* Dogelog Player 1.0.3 Windows nodeJS */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% Wall 4136 ms, gc 10 ms, 2539128 lips
% Wall 4346 ms, gc 104 ms, 2219962 lips
% Wall 3876 ms, gc 88 ms, 1180529 lips
true.

Also unlike Scryer Prolog, for larger bigints, i.e. 8192
the timing doesn't go up, it rather goes down. Probably some
alternative bigint multiplication methods etc.. kick in for
larger bigints, and they are missing in Scryer Prolog for

the Rust based bigints? They are still in its fancy? Also
Scryer Prolog would fare better if it had a native msb/1.

Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:31:28 UTC+1:
> Scryer Prolog doesn't have these built-ins. So emulating
> them makes it utterly slow. Using the hi lo approach for msb:
>
> /* Scryer Prolog 0.9.1 WSL2 */
> ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> % CPU time: 4.240s
> % CPU time: 5.621s
> % CPU time: 7.718s
> % true.

The effect that computation gets faster for larger bigint
is also seen for Python, when I use the PyPy interpreter.
I guess it has also to do with the effort needed to

promote a smallint to a bigint, either before an operation
or after an operation. Another speculation would be, that
the bigint operations slow down the frequency of my

Dogelog Player garbage collection, since this frequency
is not yet adaptive. But the larger bit test case even
beats Scryer Prolog, now beaten by Python/PyPy:
/* Dogelog Player 1.0.3 Windows PyPy */
?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
% Wall 18696 ms, gc 799 ms, 561771 lips
% Wall 12737 ms, gc 730 ms, 757550 lips
% Wall 7126 ms, gc 339 ms, 642182 lips
true.

The 7126 ms (Dogelog Player on PyPy) compared to the
7.718s (Scryer Prolog) is ca. 10% faster. I never though
that Dogelog Prolog on the Python platform could do

that, since Python is rather annonyingly slow.

Mostowski Collapse schrieb am Donnerstag, 17. November 2022 um 15:08:51 UTC+1:
> The best I can do for Dogelog Player, concerning
> msb/1 and the JavaScript platform. Just imagine
> the speed if JavaScript would have a real msb/1
> or bitlength/1, so that we don't need this nonsense?
>
> function bigint_msb(alpha) {
> alpha = alpha.toString(16);
> return 31 - Math.clz32(hexvalue(alpha.codePointAt(0))) + (alpha.length - 1)*4;
> }
>
> This is a known problem that bigint has no msb/1 or
> bitlength/1 in JavaScript as of now. Nevertheless I now
> easily beat Scryer Prolog even with Dogelog Player.
> Comparing to the hi lo search msb I get these results:
>
> /* Dogelog Player 1.0.3 Windows nodeJS */
> ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> % Wall 4136 ms, gc 10 ms, 2539128 lips
> % Wall 4346 ms, gc 104 ms, 2219962 lips
> % Wall 3876 ms, gc 88 ms, 1180529 lips
> true.
>
> Also unlike Scryer Prolog, for larger bigints, i.e. 8192
> the timing doesn't go up, it rather goes down. Probably some
> alternative bigint multiplication methods etc.. kick in for
> larger bigints, and they are missing in Scryer Prolog for
>
> the Rust based bigints? They are still in its fancy? Also
> Scryer Prolog would fare better if it had a native msb/1.
> Mostowski Collapse schrieb am Montag, 14. November 2022 um 23:31:28 UTC+1:
> > Scryer Prolog doesn't have these built-ins. So emulating
> > them makes it utterly slow. Using the hi lo approach for msb:
> >
> > /* Scryer Prolog 0.9.1 WSL2 */
> > ?- member((N,K),[(53,2600),(1024,150),(8192,9)]),
> > time((between(1,K,_), mp_pi(N, _), fail; true)), fail; true.
> > % CPU time: 4.240s
> > % CPU time: 5.621s
> > % CPU time: 7.718s
> > % true.

I guess its time to talk about DOM APIs inside Prolog,
and making them mature and portable. I am planning
to adopt the Tau Prolog DOM API.

But I have two DOM APIs in mind:

- Stateless DOM API: Basically Tau Prolog is a stateless
DOM API. All API calls have all the necessary parameters,
there is nothing implicit right?

- Statefull DOM API: On the other hand so far, in Dogelog
Player, I have used a statefull DOM API. With a notion
of cursor, you can imagine Turtle graphics, only the Turtle

is not a Turtle with location and orientation, but a node
somewhere in a DOM tree.

My plan is to give the Statefull DOM API a new try, but
bootstrapping it from the a Stateless DOM API. Eh voila
I am already banging my head:

DOM API: How get last child efficiently?
https://github.com/tau-prolog/tau-prolog/issues/340

Ha Ha ChatGPT is trolling me. You can search last_child
in Tau Prolog current GitHub, not a single find.

https://github.com/tau-prolog/tau-prolog/search?q=last_child

Or try this:

:- use_module(library(dom)).
?- last_child(foo, bar).
uncaught exception: error(existence_error(procedure,last_child/2),top_level/0)

Nevertheless ChatGPT halucinates something perfectly plausible:

Q: How get DOM last child in Tau Prolog programming language.

A: In Tau Prolog, you can use the built-in predicate
"last_child/2" to get the last child of a DOM element.

The predicate takes two arguments:

The DOM element for which you want to get
the last child (the parent element)
A variable that will be bound to the last child element

Example usage:

Copy code
last_child(parent_element, LastChild),
You have to unify the parent element with a variable
that has been initialized as a DOM element .

Please note that my knowledge cut off on Tau-Prolog is
from 2021 and this predicates could be deprecated or
changed so I recommend to check in the documentation
of the library you're using or check the version of
Tau-Prolog you're working with.

LoL

Mostowski Collapse schrieb am Mittwoch, 11. Januar 2023 um 21:45:30 UTC+1:
> I guess its time to talk about DOM APIs inside Prolog,
> and making them mature and portable. I am planning
> to adopt the Tau Prolog DOM API.
>
> But I have two DOM APIs in mind:
>
> - Stateless DOM API: Basically Tau Prolog is a stateless
> DOM API. All API calls have all the necessary parameters,
> there is nothing implicit right?
>
> - Statefull DOM API: On the other hand so far, in Dogelog
> Player, I have used a statefull DOM API. With a notion
> of cursor, you can imagine Turtle graphics, only the Turtle
>
> is not a Turtle with location and orientation, but a node
> somewhere in a DOM tree.
>
> My plan is to give the Statefull DOM API a new try, but
> bootstrapping it from the a Stateless DOM API. Eh voila
> I am already banging my head:
>
> DOM API: How get last child efficiently?
> https://github.com/tau-prolog/tau-prolog/issues/340

Looks like Ciao Prolog Playground totally
forgot about some library(dom)? Nada?

Is it more harder to make library(dom) for
a WASM based Prolog than a JavaScript based

Prolog? What about SWI-Prolog WASM?

An other can of worms format/2, related to DOM generation.
The Prolog community could standardisize it voluntarily
without the need of the ISO body. Just have a common place,

where somebody puts up a kind of specification document.
Something like a format/2 Prolog Enhancement Proposals (PEP).
Why look into format/2 ? Because Tau Prolog suggests funny stuff:

add_item(Item, Count) :-
...
format(Stream, "~a (~d)", [Item, Count]),
...

Web development with Tau Prolog - Riazaa
https://biblioteca.sistedes.es/submissions/descargas/2022/PROLE/2022-PROLE-006.pdf

Mostlikely the above is not a very optimal idea, since
there are so many other issues in DOM text generation,
like XML Escape or URL Encoding. But nevertheless

worth investigating as a means for DOM text generation.