Wanna know whats the Cancer of Prolog?

Try this:

fizzbuzz :-
foreach(between(1, 100, X), print_item(X)).

print_item(X) :-
( 0 is X mod 15
-> print('FizzBuzz')
; 0 is X mod 3
-> print('Fizz')
; 0 is X mod 5
-> print('Buzz')
; print(X)
),
nl.

https://rosettacode.org/wiki/FizzBuzz#Prolog

And then try this in (Ciao Prolog Playground or search their documentation):

?- foreach(member(X, [1,2,3]), print(X)).
{ERROR: No handle found for thrown exception
error(existence_error(procedure,'user:foreach'/2),'user:foreach'/2)}

LoL

What does your Prolog float/1 and your Prolog (**)/2 do?
Does it do the right thing, or some nonsense?

Here are some results:

/* Jekejeke Prolog 1.5.4 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 551.

/* Trealla Prolog 2.2.5 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 12750.

/* Scryer Prolog 0.9.0 */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10 =\= float(N^10)), C).
C = 500254.

/* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
?- aggregate_all(count, (between(1,1000000,N),
float(N)**10.0 =\= float(N**10)), C).
C = 585342.

Maybe one needs also look into float/1, not only (**)/2 ?
Especially float/1 of a bigint, I guess smallint could be ok.

I did more testing:

/* Jekejeke Prolog, JDK 19 */
C = 551.

/* Dogelog Player, Python (CPython and PyPy) */
C = 1991.

/* Dogelog Player, JavaScript (FireFox) */
C = 1991.

/* Jekejeke Prolog, JDK 1.8 */
C = 15586.

/* Dogelog Player, JavaScript (Chrome and NodeJS) */
C = 97722.

Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> What does your Prolog float/1 and your Prolog (**)/2 do?
> Does it do the right thing, or some nonsense?
>
> Here are some results:
>
> /* Jekejeke Prolog 1.5.4 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 551.
>
> /* Trealla Prolog 2.2.5 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 12750.
>
> /* Scryer Prolog 0.9.0 */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10 =\= float(N^10)), C).
> C = 500254.
>
> /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> ?- aggregate_all(count, (between(1,1000000,N),
> float(N)**10.0 =\= float(N**10)), C).
> C = 585342.

The differences can be explained that the different host
languages have different runtime systems, with different
intrinsic Math.pow(double, double) implementations, that

is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
was all tested on the same hardware, so they possibly use
soft implementation of the pow intrinsic. Or maybe some

use hard implementation delegating to FPU, and I might
even see differences on different hardward. Will check with
a different hardware as welll. Give me some time. Since I

have Ryzen and Intel here, maybe will see a difference.

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> Maybe one needs also look into float/1, not only (**)/2 ?
> Especially float/1 of a bigint, I guess smallint could be ok.
>
> I did more testing:
>
> /* Jekejeke Prolog, JDK 19 */
> C = 551.
>
> /* Dogelog Player, Python (CPython and PyPy) */
> C = 1991.
>
> /* Dogelog Player, JavaScript (FireFox) */
> C = 1991.
>
> /* Jekejeke Prolog, JDK 1.8 */
> C = 15586.
>
> /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> C = 97722.
> Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > What does your Prolog float/1 and your Prolog (**)/2 do?
> > Does it do the right thing, or some nonsense?
> >
> > Here are some results:
> >
> > /* Jekejeke Prolog 1.5.4 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 551.
> >
> > /* Trealla Prolog 2.2.5 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 12750.
> >
> > /* Scryer Prolog 0.9.0 */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10 =\= float(N^10)), C).
> > C = 500254.
> >
> > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > ?- aggregate_all(count, (between(1,1000000,N),
> > float(N)**10.0 =\= float(N**10)), C).
> > C = 585342.

Yes there is also a hardware dependency, and these figures
are no joke, i.e. that one figure is permutation of the other figure,
thats some random accident. I get the following result:

/* Jekejeke Prolog, JDK 1.8, Ryzen, 5 4500U */
C = 15586.

/* Jekejeke Prolog, JDK 1.8, Intel, i5-1135G7 */
C = 15856.

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:23:25 UTC+2:
> The differences can be explained that the different host
> languages have different runtime systems, with different
> intrinsic Math.pow(double, double) implementations, that
>
> is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
> was all tested on the same hardware, so they possibly use
> soft implementation of the pow intrinsic. Or maybe some
>
> use hard implementation delegating to FPU, and I might
> even see differences on different hardward. Will check with
> a different hardware as welll. Give me some time. Since I
>
> have Ryzen and Intel here, maybe will see a difference.
> Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> > Maybe one needs also look into float/1, not only (**)/2 ?
> > Especially float/1 of a bigint, I guess smallint could be ok.
> >
> > I did more testing:
> >
> > /* Jekejeke Prolog, JDK 19 */
> > C = 551.
> >
> > /* Dogelog Player, Python (CPython and PyPy) */
> > C = 1991.
> >
> > /* Dogelog Player, JavaScript (FireFox) */
> > C = 1991.
> >
> > /* Jekejeke Prolog, JDK 1.8 */
> > C = 15586.
> >
> > /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> > C = 97722.
> > Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > > What does your Prolog float/1 and your Prolog (**)/2 do?
> > > Does it do the right thing, or some nonsense?
> > >
> > > Here are some results:
> > >
> > > /* Jekejeke Prolog 1.5.4 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 551.
> > >
> > > /* Trealla Prolog 2.2.5 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 12750.
> > >
> > > /* Scryer Prolog 0.9.0 */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10 =\= float(N^10)), C).
> > > C = 500254.
> > >
> > > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > float(N)**10.0 =\= float(N**10)), C).
> > > C = 585342.

Some progress was reported for SWI-Prolog:

/* Ubuntu AMD3950X, gcc-11 */
C = 807
/* Apple M1, AppleClang 13.1 */
C = 1225
/* Windows, MinGW 11.2 */
C = 508689

Maybe MinGW suffers from:

- Theory: You know something, but it doesn’t work.
- Practice: Something works, but you don’t know why.
- Programming: Combine theory and practice: Nothing works, and we don’t know why!

Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:41:01 UTC+2:
> Yes there is also a hardware dependency, and these figures
> are no joke, i.e. that one figure is permutation of the other figure,
> thats some random accident. I get the following result:
>
> /* Jekejeke Prolog, JDK 1.8, Ryzen, 5 4500U */
> C = 15586.
>
> /* Jekejeke Prolog, JDK 1.8, Intel, i5-1135G7 */
> C = 15856.
> Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:23:25 UTC+2:
> > The differences can be explained that the different host
> > languages have different runtime systems, with different
> > intrinsic Math.pow(double, double) implementations, that
> >
> > is used for (**)/2 in Jekejeke Prolog and Dogelog Player, it
> > was all tested on the same hardware, so they possibly use
> > soft implementation of the pow intrinsic. Or maybe some
> >
> > use hard implementation delegating to FPU, and I might
> > even see differences on different hardward. Will check with
> > a different hardware as welll. Give me some time. Since I
> >
> > have Ryzen and Intel here, maybe will see a difference.
> > Mostowski Collapse schrieb am Donnerstag, 22. September 2022 um 15:13:46 UTC+2:
> > > Maybe one needs also look into float/1, not only (**)/2 ?
> > > Especially float/1 of a bigint, I guess smallint could be ok.
> > >
> > > I did more testing:
> > >
> > > /* Jekejeke Prolog, JDK 19 */
> > > C = 551.
> > >
> > > /* Dogelog Player, Python (CPython and PyPy) */
> > > C = 1991.
> > >
> > > /* Dogelog Player, JavaScript (FireFox) */
> > > C = 1991.
> > >
> > > /* Jekejeke Prolog, JDK 1.8 */
> > > C = 15586.
> > >
> > > /* Dogelog Player, JavaScript (Chrome and NodeJS) */
> > > C = 97722.
> > > Mostowski Collapse schrieb am Mittwoch, 21. September 2022 um 19:42:38 UTC+2:
> > > > What does your Prolog float/1 and your Prolog (**)/2 do?
> > > > Does it do the right thing, or some nonsense?
> > > >
> > > > Here are some results:
> > > >
> > > > /* Jekejeke Prolog 1.5.4 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 551.
> > > >
> > > > /* Trealla Prolog 2.2.5 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 12750.
> > > >
> > > > /* Scryer Prolog 0.9.0 */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10 =\= float(N^10)), C).
> > > > C = 500254.
> > > >
> > > > /* SWI-Prolog 8.5.17, doesn't have (^)/2, the (**)/2 behaves like it for integer arguments */
> > > > ?- aggregate_all(count, (between(1,1000000,N),
> > > > float(N)**10.0 =\= float(N**10)), C).
> > > > C = 585342.

Will a change to float/1 also affect (/)/2. In the past I had high
regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
ECLiPSe Prolog has degraded. But there is now the issue, suppose

there is a new SWI-Prolog version with a new float/1 compatible
with (**)/2, do the results still hold?

?- aggregate_all(count, (between(1,1000000,N),
(123456789*123456789*N)/123456789 =\= float(123456789*N)), C).

/* SWI-Prolog 8.5.17 */
C = 0

/* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
C = 72226

/* ECLiPSe Prolog 7.0.61 */
C = 494175

And of course there is the question of timing. SWI-Prolog, the
version 8.5.17 I have available, is rather behind, possibly rather
an issue of (/)/2, but could be an issue of both (/)/2

and float/1 in the future:

?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
=\= float(123456789*N), fail; true)).

/* SWI-Prolog 8.5.17 */
% 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)

/* Jekejeke Prolog 1.5.4, JDK 19 */
% Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)

/* Jekejeke Prolog 1.5.4, JDK 1.8 */
% Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> Will a change to float/1 also affect (/)/2. In the past I had high
> regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> ECLiPSe Prolog has degraded. But there is now the issue, suppose
>
> there is a new SWI-Prolog version with a new float/1 compatible
> with (**)/2, do the results still hold?
>
> ?- aggregate_all(count, (between(1,1000000,N),
> (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
>
> /* SWI-Prolog 8.5.17 */
> C = 0
>
> /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> C = 72226
>
> /* ECLiPSe Prolog 7.0.61 */
> C = 494175

Its also lacking behind on Unix, via WSL2 on the same machine,
but this is not yet a version with some new float/1:

/* SWI-Prolog 8.4.2 */
% 2,000,001 inferences, 0.543 CPU in 0.543 seconds (100% CPU, 3685380 Lips)
JDK 1.8 does it in 261 ms. But I use a different (/)/2 algorithm.
Actually one could also introduce two float division algorithms, similar
to two power raise functions (**)/2 and (^)/2:

- Fast but less precise (/)/2: Calling X is A/B will use a less precise algorithm,
like for example float(A)/float(B). The benefit would be more speedier,
disadvantage less precision. The error is not that bad, see above in the
example I get only 72226 faults. Same idea could be applied to (**)/2.

- Slow but more precise (rdiv)/2 and float/1 combo: Call X is float(A rdiv B) will
use a more precise algorithm, for example divmod/4 and extra shifting
based as in mpq_get_d_nearest . The benefit would be more precise,
disadvantage less speed. Same idea could be appled to (^)/2.

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:11:35 UTC+2:
> And of course there is the question of timing. SWI-Prolog, the
> version 8.5.17 I have available, is rather behind, possibly rather
> an issue of (/)/2, but could be an issue of both (/)/2
>
> and float/1 in the future:
>
> ?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
> =\= float(123456789*N), fail; true)).
>
> /* SWI-Prolog 8.5.17 */
> % 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)
>
> /* Jekejeke Prolog 1.5.4, JDK 19 */
> % Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)
>
> /* Jekejeke Prolog 1.5.4, JDK 1.8 */
> % Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)
> Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> > Will a change to float/1 also affect (/)/2. In the past I had high
> > regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> > ECLiPSe Prolog has degraded. But there is now the issue, suppose
> >
> > there is a new SWI-Prolog version with a new float/1 compatible
> > with (**)/2, do the results still hold?
> >
> > ?- aggregate_all(count, (between(1,1000000,N),
> > (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
> >
> > /* SWI-Prolog 8.5.17 */
> > C = 0
> >
> > /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> > C = 72226
> >
> > /* ECLiPSe Prolog 7.0.61 */
> > C = 494175

I also tested Trealla Prolog and Scryer Prolog, here precision:

/* Trealla Prolog 2.2.6 */
C = 72226

/* Scryer Prolog 0.9.0 */
C = 494423

Here the time measurements, Trealla Prolog nearly as fast as JDK 1.8:

/* Trealla Prolog 2.2.6 */
% Time elapsed 0.293s

/* Scryer Prolog 0.9.0 */
% % CPU time: 1.559s

Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 17:55:23 UTC+2:
> Its also lacking behind on Unix, via WSL2 on the same machine,
> but this is not yet a version with some new float/1:
>
> /* SWI-Prolog 8.4.2 */
> % 2,000,001 inferences, 0.543 CPU in 0.543 seconds (100% CPU, 3685380 Lips)
> JDK 1.8 does it in 261 ms. But I use a different (/)/2 algorithm.
> Actually one could also introduce two float division algorithms, similar
> to two power raise functions (**)/2 and (^)/2:
>
> - Fast but less precise (/)/2: Calling X is A/B will use a less precise algorithm,
> like for example float(A)/float(B). The benefit would be more speedier,
> disadvantage less precision. The error is not that bad, see above in the
> example I get only 72226 faults. Same idea could be applied to (**)/2.
>
> - Slow but more precise (rdiv)/2 and float/1 combo: Call X is float(A rdiv B) will
> use a more precise algorithm, for example divmod/4 and extra shifting
> based as in mpq_get_d_nearest . The benefit would be more precise,
> disadvantage less speed. Same idea could be appled to (^)/2.
> Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:11:35 UTC+2:
> > And of course there is the question of timing. SWI-Prolog, the
> > version 8.5.17 I have available, is rather behind, possibly rather
> > an issue of (/)/2, but could be an issue of both (/)/2
> >
> > and float/1 in the future:
> >
> > ?- time((between(1,1000000,N), (123456789*123456789*N)/123456789
> > =\= float(123456789*N), fail; true)).
> >
> > /* SWI-Prolog 8.5.17 */
> > % 2,000,002 inferences, 1.297 CPU in 1.285 seconds (101% CPU, 1542170 Lips)
> >
> > /* Jekejeke Prolog 1.5.4, JDK 19 */
> > % Threads 328 ms, GC 3 ms, Up 333 ms (Current 09/25/22 16:01:26)
> >
> > /* Jekejeke Prolog 1.5.4, JDK 1.8 */
> > % Threads 250 ms, GC 3 ms, Up 261 ms (Current 09/25/22 16:05:51)
> > Mostowski Collapse schrieb am Sonntag, 25. September 2022 um 16:10:14 UTC+2:
> > > Will a change to float/1 also affect (/)/2. In the past I had high
> > > regard of ECLiPSe Prolog (/)/2. Actually now I have the feeling
> > > ECLiPSe Prolog has degraded. But there is now the issue, suppose
> > >
> > > there is a new SWI-Prolog version with a new float/1 compatible
> > > with (**)/2, do the results still hold?
> > >
> > > ?- aggregate_all(count, (between(1,1000000,N),
> > > (123456789*123456789*N)/123456789 =\= float(123456789*N)), C).
> > >
> > > /* SWI-Prolog 8.5.17 */
> > > C = 0
> > >
> > > /* Jekejeke Prolog 1.5.4, both JDK 1.8 and JDK 19 */
> > > C = 72226
> > >
> > > /* ECLiPSe Prolog 7.0.61 */
> > > C = 494175

One more question. Do SWI-Prolog have a smallint
fast path for A/B, or does it always detour over
some kind of mpq_get_d_nearest?

The advantage of float(A)/float(B) is, it is already
a smallint fastpath for A and B smallint. That
is a smallint fastpath, seen that this has count C=0:

?- between(1,1000000,N), (33*33*N)/33
=\= float(33*N).

Some results concerning timing:

/* SWI-Prolog 8.5.17, Windows */
% 2,000,003 inferences, 0.297 CPU in 0.290 seconds (102% CPU, 6736852 Lips)

/* SWI-Prolog 8.4.2, Unix WSL2 */
% 2,000,003 inferences, 0.337 CPU in 0.337 seconds (100% CPU, 5929587 Lips)

/* Jekejeke Prolog 1.5.4, JDK 19 */
% Threads 297 ms, GC 3 ms, Up 290 ms (Current 09/25/22 18:38:00)

/* Jekejeke Prolog 1.5.4, JDK 1.8 */
% Threads 188 ms, GC 2 ms, Up 186 ms (Current 09/25/22 18:39:33)

Smalint fastpath results for (/)/2 and for other Prolog
systems, only the timing, otherwise they all agree C=0:

/* Trealla Prolog 2.2.6 */
% Time elapsed 0.151s

/* ECLiPSe Prolog 7.0.61 */
% Yes (0.75s cpu)

/* Ciao Playground 1.21.0 */
% Wall time 784.0 ms

/* Scryer Prolog 0.9.0 */
% CPU time: 1.314s

The only good result is by Trealla Prolog.

Mostowski Collapse schrieb:
> One more question. Do SWI-Prolog have a smallint
> fast path for A/B, or does it always detour over
> some kind of mpq_get_d_nearest?
>
> The advantage of float(A)/float(B) is, it is already
> a smallint fastpath for A and B smallint. That
> is a smallint fastpath, seen that this has count C=0:
>
> ?- between(1,1000000,N), (33*33*N)/33
> =\= float(33*N).
>
> Some results concerning timing:
>
> /* SWI-Prolog 8.5.17, Windows */
> % 2,000,003 inferences, 0.297 CPU in 0.290 seconds (102% CPU, 6736852 Lips)
>
> /* SWI-Prolog 8.4.2, Unix WSL2 */
> % 2,000,003 inferences, 0.337 CPU in 0.337 seconds (100% CPU, 5929587 Lips)
>
> /* Jekejeke Prolog 1.5.4, JDK 19 */
> % Threads 297 ms, GC 3 ms, Up 290 ms (Current 09/25/22 18:38:00)
>
> /* Jekejeke Prolog 1.5.4, JDK 1.8 */
> % Threads 188 ms, GC 2 ms, Up 186 ms (Current 09/25/22 18:39:33)

Here is a 100% pure Prolog implementation of HALF_EVEN, without
any materialization, it assumes that the current float/1 does only mpz_get_d:

float_half_even(X,Y) :-
(getbit(X, msb(X)-53) =:= 0;
getbit(X, msb(X)-52) =:= 0, msb(X)-53 =:= lsb(X)), !, Y is float(X).
float_half_even(X,Y) :-
Y is nexttoward(float(X), 1E300).

Was using 1E300 for infinity, is there something else that would work?
float_half_even/2 is just a translation of the following into Prolog:

public double doubleValue() {
https://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/math/BigInteger.java#l3871

Here some test whether it agrees with BigInteger.
doubleValue(), first testing the old version of
SWI-Prolog, where float is mpz_get_d:

/* SWI-Prolog 8.5.17 */
?- between(1,10,N), X is 10^20+N*2^13,
float_half_even(X,Y), write(Y), nl, fail; true.
1.0e+20
1.0000000000000002e+20
1.0000000000000003e+20
1.0000000000000003e+20
1.0000000000000003e+20
1.0000000000000005e+20
1.0000000000000007e+20
1.0000000000000007e+20
1.0000000000000007e+20
1.0000000000000008e+20

Comparing with a Prolog system that calls
BigInteger.doubleValue():

/* Jekejeke Prolog 1.5.4 */
?- between(1,10,N), X is 10^20+N*2^13,
Y is float(X), write(Y), nl, fail; true.
1.0E20
1.0000000000000002E20
1.0000000000000003E20
1.0000000000000003E20
1.0000000000000003E20
1.0000000000000005E20
1.0000000000000007E20
1.0000000000000007E20
1.0000000000000007E20
1.0000000000000008E20

Yeah, they agree! Riddle solved, the misterious
veil of the secret souce behind an ultrafast
float/1 for bigint has been lifted.

Mostowski Collapse wrote:
> Here is a 100% pure Prolog implementation of HALF_EVEN, without
> any materialization, it assumes that the current float/1 does only mpz_get_d:
>
> float_half_even(X,Y) :-
> (getbit(X, msb(X)-53) =:= 0;
> getbit(X, msb(X)-52) =:= 0, msb(X)-53 =:= lsb(X)), !, Y is float(X).
> float_half_even(X,Y) :-
> Y is nexttoward(float(X), 1E300).
>
> Was using 1E300 for infinity, is there something else that would work?
> float_half_even/2 is just a translation of the following into Prolog:
>
> public double doubleValue() {
> https://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/math/BigInteger.java#l3871
>

Quite some disagreement concerning (**)/2:

/* Ciao Playground 1.21.0 */
?- Z is 51**10.
Z = 119042423827613000.0 ?

/* ECLiPSe Prolog 7.0.61 */
?- X is 51**10.
X = 1.1904242382761301e+17

Guess which one corresponds to HALF_EVEN ?

Whats also funny when a Prolog system disagrees internally:

/* SWI-Prolog 8.5.17, Windows 10 */
?- X is 51^10, Z is float(X), Y is nexttoward(Z, 1E300).
X = 119042423827613001,
Z = 1.1904242382761301e+17,
Y = 1.1904242382761302e+17.

?- Z is float(51^10), Y is nexttoward(Z, 1E300).
Z = 1.19042423827613e+17,
Y = 1.1904242382761301e+17.

The above "bug" makes it hard for me to test float_half_even/2.

Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:33:22 UTC+2:
> Quite some disagreement concerning (**)/2:
> /* Ciao Playground 1.21.0 */
> ?- Z is 51**10.
> Z = 119042423827613000.0 ?
> /* ECLiPSe Prolog 7.0.61 */
> ?- X is 51**10.
> X = 1.1904242382761301e+17
>
> Guess which one corresponds to HALF_EVEN ?

If I do nothing, I cannot make mistakes. Could be
the motto that Ciao Prolog doesn't support (^)/2
as an evaluable predicate.

But among those Prolog systems that take the
risk (clap clap!!) and support (^)/2 the situation
is a little immature, I find:

Scryer Prolog and Trealla Prolog, they both do wrong
float/1 rounding (1.19042423827613e+17
instead 1.1904242382761301E17):

/* Scryer Prolog 0.9.0 */
?- X is 51^10, Z is float(X).
X = 119042423827613001, Z = 1.19042423827613e17.
?- Z is float(51^10).
Z = 1.19042423827613e17.

But Trealla Prolog has a problem with (^)/2, wrong
result of bigint pow() (i.e. 119042423827613008 instead
119042423827613001):

/* Trealla Prolog 2.2.10 */
?- X is 51^10, Z is float(X).
X = 119042423827613008, Z = 1.19042423827613e+17.
?- Z is float(51^10).
Z = 1.19042423827613e+17.

Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:34:44 UTC+2:
> Whats also funny when a Prolog system disagrees internally:
>
> /* SWI-Prolog 8.5.17, Windows 10 */
> ?- X is 51^10, Z is float(X), Y is nexttoward(Z, 1E300).
> X = 119042423827613001,
> Z = 1.1904242382761301e+17,
> Y = 1.1904242382761302e+17.
>
> ?- Z is float(51^10), Y is nexttoward(Z, 1E300).
> Z = 1.19042423827613e+17,
> Y = 1.1904242382761301e+17.
>
> The above "bug" makes it hard for me to test float_half_even/2.
> Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:33:22 UTC+2:
> > Quite some disagreement concerning (**)/2:
> > /* Ciao Playground 1.21.0 */
> > ?- Z is 51**10.
> > Z = 119042423827613000.0 ?
> > /* ECLiPSe Prolog 7.0.61 */
> > ?- X is 51**10.
> > X = 1.1904242382761301e+17
> >
> > Guess which one corresponds to HALF_EVEN ?

To judge that ECLiPSe Prolog is correct, one
needs to think in binary representation. We find,
using a precise float to bigint conversion:

?- X is integer(1.1904242382761301E17).
X = 119042423827613008.

?- X is integer(1.19042423827613E17).
X = 119042423827612992.

Now which one is closer?

?- X is 119042423827613001-119042423827613008.
X = -7.

?- X is 119042423827613001-119042423827612992.
X = 9.

So 1.1904242382761301E17 is the correct float.

Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:33:22 UTC+2:
> Quite some disagreement concerning (**)/2:
> /* Ciao Playground 1.21.0 */
> ?- Z is 51**10.
> Z = 119042423827613000.0 ?
> /* ECLiPSe Prolog 7.0.61 */
> ?- X is 51**10.
> X = 1.1904242382761301e+17
>
> Guess which one corresponds to HALF_EVEN ?

Be careful, integer/1 isn't in the ISO core standard, thats
my take in one system to make it a precise conversion from
float to bigint. Maybe not reproducable in other Prolog systems.

It works also in Dogelog player:

/* Dogelog Player, JavaScript */
?- X is integer(1.1904242382761301E17).
X = 119042423827613008.
?- X is integer(1.19042423827613E17).
X = 119042423827612992.

/* Dogelog Player, Python */
?- X is integer(1.1904242382761301E17).
X = 119042423827613008.
?- X is integer(1.19042423827613E17).
X = 119042423827612992.

Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:56:30 UTC+2:
> To judge that ECLiPSe Prolog is correct, one
> needs to think in binary representation. We find,
> using a precise float to bigint conversion:
>
> ?- X is integer(1.1904242382761301E17).
> X = 119042423827613008.
>
> ?- X is integer(1.19042423827613E17).
> X = 119042423827612992.
>
> Now which one is closer?
>
> ?- X is 119042423827613001-119042423827613008.
> X = -7.
>
> ?- X is 119042423827613001-119042423827612992.
> X = 9.
>
> So 1.1904242382761301E17 is the correct float.
> Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:33:22 UTC+2:
> > Quite some disagreement concerning (**)/2:
> > /* Ciao Playground 1.21.0 */
> > ?- Z is 51**10.
> > Z = 119042423827613000.0 ?
> > /* ECLiPSe Prolog 7.0.61 */
> > ?- X is 51**10.
> > X = 1.1904242382761301e+17
> >
> > Guess which one corresponds to HALF_EVEN ?

Warning, possibly this ticket can be closed. Its not necessarily
a display problem. For example many Math.pow(double,double)
implementations cannot do the problem correctly.

They cannot or do not round to the theoretical optimum, they
have inherently a higher error than only one Unit in the last place (ULP).
So a certain error is to expect. You see this here:

/* Dogelog Player, JavaScript */
?- X is 51**10.
X = 1.19042423827613E17.

?- X is float(51^10).
X = 119042423827613010.0.

In the above the (**)/2 is Math.pow(double,double) and the
(^)/2 is exact bigint exponentiation. I took the pair (51,10)
from a list of pairs where (**)/2 and (^)/2 often disagree

based on Math.pow(double,double) typically being weak.

Mostowski Collapse schrieb am Mittwoch, 28. September 2022 um 12:33:22 UTC+2:
> Quite some disagreement concerning (**)/2:
> /* Ciao Playground 1.21.0 */
> ?- Z is 51**10.
> Z = 119042423827613000.0 ?
> /* ECLiPSe Prolog 7.0.61 */
> ?- X is 51**10.
> X = 1.1904242382761301e+17
>
> Guess which one corresponds to HALF_EVEN ?

Even SWI-Prolog has still some brakes somewhere in its
bigint/smallint implementation, or its a problem of the
ZIP compilation, its WAM architecture? At least on the

Windows platform I find this astonishing result:

/* Jekejeke Prolog 1.5.5, JDK 1.8 */
?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
% Threads 1,172 ms, GC 15 ms, Up 1,201 ms (Current 01/04/23 06:10:28)
true.

/* SWI-Prolog 9.1.0 */
܀?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
% 7,000,000 inferences, 1.813 CPU in 1.816 seconds (100% CPU, 3862069 Lips)
true.

SWI-Prolog is 50% slower. What was the Prolog code
of the test cases? Its my latest rat_rationalize/3, written
such that there is no dependency on rational numbers,

working with pairs and avoiding a call to rational/1.
So its a test case that any ISO core standard Prolog should
be able to run. Will possibly test more Prolog systems.

% rat_rationalize(+Number, +Pair, -Pair)
:- public rat_rationalize/3.
rat_rationalize(F, (V,W), T) :-
divmod(V, W, D, U),
rat_iter((W,U), (D,1), (1,0), F, T).

% rat_iter(+Pair, +Pair, +Pair, +Number, -Pair)
:- private rat_iter/5.
rat_iter(_, (M,N), _, Y, X) :- M/N =:= Y, !, X = (M,N).
rat_iter((_,0), X, _, _, X) :- !.
rat_iter((V,W), (M,N), (P,Q), Y, X) :-
divmod(V, W, D, U),
R is D*M+P,
S is D*N+Q,
rat_iter((W,U), (R,S), (M,N), Y, X).

Mostowski Collapse schrieb am Montag, 2. Januar 2023 um 19:51:51 UTC+1:
> Never trust a paper, that you didn't fake yourself.
>
> Example:
>
> Table 3. SWOT Analysis
> Strengths (Section 4.1)
> sophisticated tools: analyzers, partial evaluators, parallelizers, ...
> https://arxiv.org/pdf/2201.10816.pdf
>
> Looking at SWI-Prolog and how rationalize/1 is
> wiggled into C code, we are probably still
> in the stone age of Prolog, and the above SWOT
>
> analysis is incorrect or too optimistic. This wont
> probably improve in 2023, even Scryer Prolog
> doesn't have a partial evaluator of some sort.
>
> It also begs the question, if your pure Prolog
> executes quickly in your Prolog system, why
> go into C code? Isn't this a sign that your Prolog
>
> system is weak? Better have a faster Prolog system
> and don't rely on tooling and or foreign code.

Woa! Jekejeke Prolog JDK 1.8 Windows still beats by
an itch Trealla Prolog and also Scryer Prolog. And
Jekejeke Prolog 1.5.5 has evolved, it has now also a

quadruple precision data type. But this doesn't seem
to slow down the core and its arithmetical unit of
Jekejeke Prolog. But I have streamlined a little bit

divmod/4 and friends. In previous version I also
supported float arguments, but I reverted it back
to only accept integer. On the WSL2 Platform I get:

/* Trealla Prolog 2.7.15 */
?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
% Time elapsed 1.29s
rue.

/* Scryer Prolog 0.9.1 */
?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
% CPU time: 1.365s
true.

Scryer Prolog would be possibly faster if it had divmod/4.
I needed to bootstrap it as follows. The bootstrapping was
not necessary for Trealla Prolog, since it has adopted divmod/4.

/* Needed for Scryer Prolog */
divmod(A, B, D, M) :-
D is A div B,
M is A - D*B.

Mostowski Collapse schrieb am Mittwoch, 4. Januar 2023 um 06:17:33 UTC+1:
> Even SWI-Prolog has still some brakes somewhere in its
> bigint/smallint implementation, or its a problem of the
> ZIP compilation, its WAM architecture? At least on the
>
> Windows platform I find this astonishing result:
>
> /* Jekejeke Prolog 1.5.5, JDK 1.8 */
> ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> % Threads 1,172 ms, GC 15 ms, Up 1,201 ms (Current 01/04/23 06:10:28)
> true.
>
> /* SWI-Prolog 9.1.0 */
> ܀?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> % 7,000,000 inferences, 1.813 CPU in 1.816 seconds (100% CPU, 3862069 Lips)
> true.
>
> SWI-Prolog is 50% slower. What was the Prolog code
> of the test cases? Its my latest rat_rationalize/3, written
> such that there is no dependency on rational numbers,
>
> working with pairs and avoiding a call to rational/1.
> So its a test case that any ISO core standard Prolog should
> be able to run. Will possibly test more Prolog systems.
>
> % rat_rationalize(+Number, +Pair, -Pair)
> :- public rat_rationalize/3.
> rat_rationalize(F, (V,W), T) :-
> divmod(V, W, D, U),
> rat_iter((W,U), (D,1), (1,0), F, T).
>
> % rat_iter(+Pair, +Pair, +Pair, +Number, -Pair)
> :- private rat_iter/5.
> rat_iter(_, (M,N), _, Y, X) :- M/N =:= Y, !, X = (M,N).
> rat_iter((_,0), X, _, _, X) :- !.
> rat_iter((V,W), (M,N), (P,Q), Y, X) :-
> divmod(V, W, D, U),
> R is D*M+P,
> S is D*N+Q,
> rat_iter((W,U), (R,S), (M,N), Y, X).
> Mostowski Collapse schrieb am Montag, 2. Januar 2023 um 19:51:51 UTC+1:
> > Never trust a paper, that you didn't fake yourself.
> >
> > Example:
> >
> > Table 3. SWOT Analysis
> > Strengths (Section 4.1)
> > sophisticated tools: analyzers, partial evaluators, parallelizers, ...
> > https://arxiv.org/pdf/2201.10816.pdf
> >
> > Looking at SWI-Prolog and how rationalize/1 is
> > wiggled into C code, we are probably still
> > in the stone age of Prolog, and the above SWOT
> >
> > analysis is incorrect or too optimistic. This wont
> > probably improve in 2023, even Scryer Prolog
> > doesn't have a partial evaluator of some sort.
> >
> > It also begs the question, if your pure Prolog
> > executes quickly in your Prolog system, why
> > go into C code? Isn't this a sign that your Prolog
> >
> > system is weak? Better have a faster Prolog system
> > and don't rely on tooling and or foreign code.

And here the speedy ones. ca. 5 times speedier than
Jekejeke Prolog! Amazing Prolog systems indeed:

/* Ciao Prolog 1.22.0 */
?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
% 0.250524 seconds

/* ECLiPSe Prolog 7.1.12 */
?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
(7074237752028440,2251799813685248), _), fail; true)).
0.224643099994864 sec

Mostowski Collapse schrieb am Mittwoch, 4. Januar 2023 um 06:37:01 UTC+1:
> Woa! Jekejeke Prolog JDK 1.8 Windows still beats by
> an itch Trealla Prolog and also Scryer Prolog. And
> Jekejeke Prolog 1.5.5 has evolved, it has now also a
>
> quadruple precision data type. But this doesn't seem
> to slow down the core and its arithmetical unit of
> Jekejeke Prolog. But I have streamlined a little bit
>
> divmod/4 and friends. In previous version I also
> supported float arguments, but I reverted it back
> to only accept integer. On the WSL2 Platform I get:
>
> /* Trealla Prolog 2.7.15 */
> ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> % Time elapsed 1.29s
> rue.
>
> /* Scryer Prolog 0.9.1 */
> ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> % CPU time: 1.365s
> true.
>
> Scryer Prolog would be possibly faster if it had divmod/4.
> I needed to bootstrap it as follows. The bootstrapping was
> not necessary for Trealla Prolog, since it has adopted divmod/4.
>
> /* Needed for Scryer Prolog */
> divmod(A, B, D, M) :-
> D is A div B,
> M is A - D*B.
> Mostowski Collapse schrieb am Mittwoch, 4. Januar 2023 um 06:17:33 UTC+1:
> > Even SWI-Prolog has still some brakes somewhere in its
> > bigint/smallint implementation, or its a problem of the
> > ZIP compilation, its WAM architecture? At least on the
> >
> > Windows platform I find this astonishing result:
> >
> > /* Jekejeke Prolog 1.5.5, JDK 1.8 */
> > ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> > (7074237752028440,2251799813685248), _), fail; true)).
> > % Threads 1,172 ms, GC 15 ms, Up 1,201 ms (Current 01/04/23 06:10:28)
> > true.
> >
> > /* SWI-Prolog 9.1.0 */
> > ܀?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> > (7074237752028440,2251799813685248), _), fail; true)).
> > % 7,000,000 inferences, 1.813 CPU in 1.816 seconds (100% CPU, 3862069 Lips)
> > true.
> >
> > SWI-Prolog is 50% slower. What was the Prolog code
> > of the test cases? Its my latest rat_rationalize/3, written
> > such that there is no dependency on rational numbers,
> >
> > working with pairs and avoiding a call to rational/1.
> > So its a test case that any ISO core standard Prolog should
> > be able to run. Will possibly test more Prolog systems.
> >
> > % rat_rationalize(+Number, +Pair, -Pair)
> > :- public rat_rationalize/3.
> > rat_rationalize(F, (V,W), T) :-
> > divmod(V, W, D, U),
> > rat_iter((W,U), (D,1), (1,0), F, T).
> >
> > % rat_iter(+Pair, +Pair, +Pair, +Number, -Pair)
> > :- private rat_iter/5.
> > rat_iter(_, (M,N), _, Y, X) :- M/N =:= Y, !, X = (M,N).
> > rat_iter((_,0), X, _, _, X) :- !.
> > rat_iter((V,W), (M,N), (P,Q), Y, X) :-
> > divmod(V, W, D, U),
> > R is D*M+P,
> > S is D*N+Q,
> > rat_iter((W,U), (R,S), (M,N), Y, X).
> > Mostowski Collapse schrieb am Montag, 2. Januar 2023 um 19:51:51 UTC+1:
> > > Never trust a paper, that you didn't fake yourself.
> > >
> > > Example:
> > >
> > > Table 3. SWOT Analysis
> > > Strengths (Section 4.1)
> > > sophisticated tools: analyzers, partial evaluators, parallelizers, ....
> > > https://arxiv.org/pdf/2201.10816.pdf
> > >
> > > Looking at SWI-Prolog and how rationalize/1 is
> > > wiggled into C code, we are probably still
> > > in the stone age of Prolog, and the above SWOT
> > >
> > > analysis is incorrect or too optimistic. This wont
> > > probably improve in 2023, even Scryer Prolog
> > > doesn't have a partial evaluator of some sort.
> > >
> > > It also begs the question, if your pure Prolog
> > > executes quickly in your Prolog system, why
> > > go into C code? Isn't this a sign that your Prolog
> > >
> > > system is weak? Better have a faster Prolog system
> > > and don't rely on tooling and or foreign code.

How many lines of codes are they, Ciao and ECLiPSe?
Any papers about that? Are they giants? See also

Weird Landscape of Compilers - Graydon, 2019
http://venge.net/graydon/talks/CompilerTalk-2019.pdf

Mostowski Collapse schrieb am Mittwoch, 4. Januar 2023 um 06:50:16 UTC+1:
> And here the speedy ones. ca. 5 times speedier than
> Jekejeke Prolog! Amazing Prolog systems indeed:
>
> /* Ciao Prolog 1.22.0 */
> ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> % 0.250524 seconds
>
> /* ECLiPSe Prolog 7.1.12 */
> ?- time((between(1,100000,_), rat_rationalize(3.141592653589793,
> (7074237752028440,2251799813685248), _), fail; true)).
> 0.224643099994864 sec

Now I found a nice test case for format/[2,3]:

/* SWI-Prolog 9.1.2 */
?- E = sin(pi/6), R is E, format(
'Evaluating ~w gives ~4f rounded to 4 digits', [E,R]), nl.
Evaluating sin(pi/6) gives 0.5000 rounded to 4 digits
E = sin(pi/6),
R = 0.49999999999999994.

Which Scryer Prolog fails:

/* Scryer Prolog v0.9.1-61-g84583da5 */
?- E = sin(pi/6), R is E, format(
"Evaluating ~w gives ~4f rounded to 4 digits", [E,R]), nl.
Evaluating sin(pi/6) gives 0.4999 rounded to 4 digits
E = sin(pi/6), R = 0.49999999999999994.

See also this Tau Prolog ticket:

format/2 doesn't work as expected
https://github.com/tau-prolog/tau-prolog/issues/341