Now I have an idea for a novell Prolog core, called Novacore.
What should it be able to do? A few features from JavaScript:

a) Renaming Module Import
The have even renaming module import. For example one
can do in JavaScript:

const emitter = require('events');

But is there a Prolog system that has a renaming module import?
Like for example this here:

:- use_module(events as emitter).

b) Polyfills
In JavaScript new functionality can be added to old versions
via so called polyfills. On the module/class level, this requires
that you can do code injections, later mixins.

Although Prolog would be in a good position here, since for
example it has multifile predicates. But does this work for a
module system of a Prolog system? And how would a polyfill

exactly be done?

I tried this in Ciao Prolog playground, but there seems a couple
of other problems:

:- use_module(library(lists)).

lists:subtract([], _, R) :- !,
R = [].
lists:subtract([E|T], D, R) :- !,
( memberchk(E, D)
-> lists:subtract(T, D, R)
; R = [E|R1],
lists:subtract(T, D, R1)
).

I get quite a funny bouquet of errors:

ERROR: (lns 6-11) Predicate memberchk/2 undefined in source
ERROR: (lns 6-11) Bad module qualification of subtract/3,
predicate not imported from module lists
ERROR: (lns 6-11) Bad module qualification of subtract/3,
predicate not imported from module lists
ERROR: Aborted module compilation

If I am not totally mistaken the subtract/3 mixing works in SWI-Prolog
and in Jekejeke Prolog. Have to try again. But there could be issues
with reconsult, in general it makes a few things more complicated

concerning the Prolog system tooling. But frankly I didn’t use it so
often, there were a few use cases though.

So what would be the benefit of Novacore? It would solve
some of the bottlenecks in Prolog systems. Somebody wrote:

"Surely if SWI-Prolog is the outlier I’m happy to change that,
considering that the impact is most likely low."

How can you do **widescale change** and semantic confluence
without waiting for every Prolog system, even without waiting
for SWI-Prolog? Thats what Polyfills do in JavaScript. But I don’t

know how popular they are right now. In the past there
was Babel, and it is still there:

Babel is a JavaScript compiler
Use next generation JavaScript, today.
https://babeljs.io/

Logtalk is kind of the Prolog Babel, with the difference that
Logtalk doesn’t do existing Prolog system module system
injection. But the Bable toolchain consists of more than only

Polyfills, some are similar to Logtalk again (codemods):

- Transform syntax
- Polyfill features that are missing in your target environment
(through a third-party polyfill such as core-js)
^- Source code transformations (codemods)
- And more!

To some extend there is also a third option besides the alternative
of if-then-else conditional Prolog compilation. You could also
use goal_expansion/2 to do some things.

Mostowski Collapse schrieb am Mittwoch, 17. August 2022 um 14:18:25 UTC+2:
> Now I have an idea for a novell Prolog core, called Novacore.
> What should it be able to do? A few features from JavaScript:
>
> a) Renaming Module Import
> The have even renaming module import. For example one
> can do in JavaScript:
>
> const emitter = require('events');
>
> But is there a Prolog system that has a renaming module import?
> Like for example this here:
>
> :- use_module(events as emitter).
>
> b) Polyfills
> In JavaScript new functionality can be added to old versions
> via so called polyfills. On the module/class level, this requires
> that you can do code injections, later mixins.
>
> Although Prolog would be in a good position here, since for
> example it has multifile predicates. But does this work for a
> module system of a Prolog system? And how would a polyfill
>
> exactly be done?
>
> I tried this in Ciao Prolog playground, but there seems a couple
> of other problems:
>
> :- use_module(library(lists)).
>
> lists:subtract([], _, R) :- !,
> R = [].
> lists:subtract([E|T], D, R) :- !,
> ( memberchk(E, D)
> -> lists:subtract(T, D, R)
> ; R = [E|R1],
> lists:subtract(T, D, R1)
> ).
>
> I get quite a funny bouquet of errors:
>
> ERROR: (lns 6-11) Predicate memberchk/2 undefined in source
> ERROR: (lns 6-11) Bad module qualification of subtract/3,
> predicate not imported from module lists
> ERROR: (lns 6-11) Bad module qualification of subtract/3,
> predicate not imported from module lists
> ERROR: Aborted module compilation
>
> If I am not totally mistaken the subtract/3 mixing works in SWI-Prolog
> and in Jekejeke Prolog. Have to try again. But there could be issues
> with reconsult, in general it makes a few things more complicated
>
> concerning the Prolog system tooling. But frankly I didn’t use it so
> often, there were a few use cases though.

In as far the pure modules by Ciao Prolog are a good exercise.
Now imagine a pure+common module, which uses totally different
library than Ciao does currently have as a status quo. No changes

needed to the libraries that Ciao Prolog has, only a common context,
where the name space looks different and some common libraries
are provided. So the Ciao Prolog system would see the current

status quo of Ciao, and the user would see the common. Would this
be possible, such a Chimera Prolog? Or can Ciao Prolog remove
built-ins (for pure) but not add built-ins (for pure+common)?

Mostowski Collapse schrieb am Mittwoch, 17. August 2022 um 15:37:18 UTC+2:
> So what would be the benefit of Novacore? It would solve
> some of the bottlenecks in Prolog systems. Somebody wrote:
>
> "Surely if SWI-Prolog is the outlier I’m happy to change that,
> considering that the impact is most likely low."
>
> How can you do **widescale change** and semantic confluence
> without waiting for every Prolog system, even without waiting
> for SWI-Prolog? Thats what Polyfills do in JavaScript. But I don’t
>
> know how popular they are right now. In the past there
> was Babel, and it is still there:
>
> Babel is a JavaScript compiler
> Use next generation JavaScript, today.
> https://babeljs.io/
>
> Logtalk is kind of the Prolog Babel, with the difference that
> Logtalk doesn’t do existing Prolog system module system
> injection. But the Bable toolchain consists of more than only
>
> Polyfills, some are similar to Logtalk again (codemods):
>
> - Transform syntax
> - Polyfill features that are missing in your target environment
> (through a third-party polyfill such as core-js)
> ^- Source code transformations (codemods)
> - And more!
>
> To some extend there is also a third option besides the alternative
> of if-then-else conditional Prolog compilation. You could also
> use goal_expansion/2 to do some things.
> Mostowski Collapse schrieb am Mittwoch, 17. August 2022 um 14:18:25 UTC+2:
> > Now I have an idea for a novell Prolog core, called Novacore.
> > What should it be able to do? A few features from JavaScript:
> >
> > a) Renaming Module Import
> > The have even renaming module import. For example one
> > can do in JavaScript:
> >
> > const emitter = require('events');
> >
> > But is there a Prolog system that has a renaming module import?
> > Like for example this here:
> >
> > :- use_module(events as emitter).
> >
> > b) Polyfills
> > In JavaScript new functionality can be added to old versions
> > via so called polyfills. On the module/class level, this requires
> > that you can do code injections, later mixins.
> >
> > Although Prolog would be in a good position here, since for
> > example it has multifile predicates. But does this work for a
> > module system of a Prolog system? And how would a polyfill
> >
> > exactly be done?
> >
> > I tried this in Ciao Prolog playground, but there seems a couple
> > of other problems:
> >
> > :- use_module(library(lists)).
> >
> > lists:subtract([], _, R) :- !,
> > R = [].
> > lists:subtract([E|T], D, R) :- !,
> > ( memberchk(E, D)
> > -> lists:subtract(T, D, R)
> > ; R = [E|R1],
> > lists:subtract(T, D, R1)
> > ).
> >
> > I get quite a funny bouquet of errors:
> >
> > ERROR: (lns 6-11) Predicate memberchk/2 undefined in source
> > ERROR: (lns 6-11) Bad module qualification of subtract/3,
> > predicate not imported from module lists
> > ERROR: (lns 6-11) Bad module qualification of subtract/3,
> > predicate not imported from module lists
> > ERROR: Aborted module compilation
> >
> > If I am not totally mistaken the subtract/3 mixing works in SWI-Prolog
> > and in Jekejeke Prolog. Have to try again. But there could be issues
> > with reconsult, in general it makes a few things more complicated
> >
> > concerning the Prolog system tooling. But frankly I didn’t use it so
> > often, there were a few use cases though.

Since I have already a prototype running, but it needs a little
bit more preparation, here is a new term coined. We have
already the new term Novacore, and now comes the following:

One could pursue a new approach, based on a Novacore
with what could be coined Liblets. A Liblet would be kind of package,
that would switch in what is normally more cohesively connected

inside a Prolog system. But the Prolog systems that would aim at
supporting Novacore and Liblets, would need some refactoring
and deossification. So that the Prolog system specific Liblet

becomes switchable. One way to do it, is to have the Prolog
system depend on an internal Liblet not visible to the outside, so
that the switchable Liblets become possible. One could then

experiment with a least common multiple (LCM) Liblet in
each Prolog system that has a Novacore. The LCM Liblet
would be the fusion of various Liblets or even a totally different

setup concerning the name space of this LCM Liblet and the
content of this LCM Liblet. LCM Liblet would be the new name
for Common Prolog. Why is a Novacore needed, and not the

ISO core standard suitable. Various reasons, a) intollerant syntax of
some ISO core implementations, b) other intollerant features of some
ISO core implementations, that prohibit Liblets modelled after or

directly loaded from existing more tollerant Prolog systems.

Was refactoring Dogelog Player. It has now a couple
of libraries, making use of the new system_url to fetch them.

- library(compat): New idea of a library, has things like tab/1.
- library(sequence): Reduced library(adanced/sequence) from formerly Jekejeke Prolog.
- library(aggregate): Reduced library(adanced/aggregate) from formerly Jekejeke Prolog.
- library(lists): Like library(basic/lists) from formerly Jekejeke Prolog.

library(sequence) and library(aggregate) are implemented via
the new change_arg/3 in Dogelog Player, unlike Jekejeke Prolog
which uses some Java pivot datastructure.

The new system_url to fetch does not change Dogelog Player
performance. Dogelog Player is still not an extremly fast
Prolog system, it might beat Tau Prolog but otherwise it has

rather modest performance. But change_arg/3 gives nice
performance. Its the better solution than bb_put/2 and bb_get/2,
which is module local, and BTW will not work in multi-threading,

if it has SICStus semantics it is for "blackboard" communication
between multiple threads. The bb_ stands for "blackboard". So its
not thread-local. What is Scryer Prolog thinking?

Anyway, here some performance:

/* Scryer Prolog "v0.9.0-175-g6b8e6204" */
?- use_module(library(iso_ext)).
true.
?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
% CPU time: 4.719s
true.

/* Dogelog Player 1.0.2, nodejs */
?- ensure_loaded(library(sequence)).
true.
?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
% Wall 1763 ms, gc 4 ms, 6250971 lips
true.

/* SWI-Prolog, 8.5.14 */
?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
% 5,002,004 inferences, 0.484 CPU in 0.473 seconds (102% CPU, 10326718 Lips)
true.

The implementation goes:

bb_put(Key, Value) :-
( atom(Key) ->
'$store_global_var'(Key, Value)
; type_error(atom, Key, bb_put/2)
).

And then bb_put/2 is used in Scryer Prologs call_nth/2.
How do you want to use this in a multi-threaded Prolog system?

LMAO!

Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 11:59:37 UTC+2:
> Was refactoring Dogelog Player. It has now a couple
> of libraries, making use of the new system_url to fetch them.
>
> - library(compat): New idea of a library, has things like tab/1.
> - library(sequence): Reduced library(adanced/sequence) from formerly Jekejeke Prolog.
> - library(aggregate): Reduced library(adanced/aggregate) from formerly Jekejeke Prolog.
> - library(lists): Like library(basic/lists) from formerly Jekejeke Prolog.
>
> library(sequence) and library(aggregate) are implemented via
> the new change_arg/3 in Dogelog Player, unlike Jekejeke Prolog
> which uses some Java pivot datastructure.
>
> The new system_url to fetch does not change Dogelog Player
> performance. Dogelog Player is still not an extremly fast
> Prolog system, it might beat Tau Prolog but otherwise it has
>
> rather modest performance. But change_arg/3 gives nice
> performance. Its the better solution than bb_put/2 and bb_get/2,
> which is module local, and BTW will not work in multi-threading,
>
> if it has SICStus semantics it is for "blackboard" communication
> between multiple threads. The bb_ stands for "blackboard". So its
> not thread-local. What is Scryer Prolog thinking?
>
> Anyway, here some performance:
>
> /* Scryer Prolog "v0.9.0-175-g6b8e6204" */
> ?- use_module(library(iso_ext)).
> true.
> ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> % CPU time: 4.719s
> true.
>
> /* Dogelog Player 1.0.2, nodejs */
> ?- ensure_loaded(library(sequence)).
> true.
> ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> % Wall 1763 ms, gc 4 ms, 6250971 lips
> true.
>
> /* SWI-Prolog, 8.5.14 */
> ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> % 5,002,004 inferences, 0.484 CPU in 0.473 seconds (102% CPU, 10326718 Lips)
> true.

I guess the SWI-Prolog implementation of call_nth/2 can
be used with multi-threading. So does the formerly Jekejeke
Prolog implementation, can be used with multi-threading

as well. Performance for formerly Jekejeke Prolog with
JDK 1.8, even bettern than that for SWI-Prolog:

?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
% Threads 359 ms, GC 6 ms, Up 372 ms (Current 08/31/22 12:07:16)
true.

Cannot test Ciao Prolog since it doesn't have call_nth/2.
Same for ECLiPSe Prolog, I don't find a predicate that goes
exactly by the name call_nth/2,

maybe there is a substitute?

Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 12:04:36 UTC+2:
> The implementation goes:
>
> bb_put(Key, Value) :-
> ( atom(Key) ->
> '$store_global_var'(Key, Value)
> ; type_error(atom, Key, bb_put/2)
> ).
>
> And then bb_put/2 is used in Scryer Prologs call_nth/2.
> How do you want to use this in a multi-threaded Prolog system?
>
> LMAO!
> Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 11:59:37 UTC+2:
> > Was refactoring Dogelog Player. It has now a couple
> > of libraries, making use of the new system_url to fetch them.
> >
> > - library(compat): New idea of a library, has things like tab/1.
> > - library(sequence): Reduced library(adanced/sequence) from formerly Jekejeke Prolog.
> > - library(aggregate): Reduced library(adanced/aggregate) from formerly Jekejeke Prolog.
> > - library(lists): Like library(basic/lists) from formerly Jekejeke Prolog.
> >
> > library(sequence) and library(aggregate) are implemented via
> > the new change_arg/3 in Dogelog Player, unlike Jekejeke Prolog
> > which uses some Java pivot datastructure.
> >
> > The new system_url to fetch does not change Dogelog Player
> > performance. Dogelog Player is still not an extremly fast
> > Prolog system, it might beat Tau Prolog but otherwise it has
> >
> > rather modest performance. But change_arg/3 gives nice
> > performance. Its the better solution than bb_put/2 and bb_get/2,
> > which is module local, and BTW will not work in multi-threading,
> >
> > if it has SICStus semantics it is for "blackboard" communication
> > between multiple threads. The bb_ stands for "blackboard". So its
> > not thread-local. What is Scryer Prolog thinking?
> >
> > Anyway, here some performance:
> >
> > /* Scryer Prolog "v0.9.0-175-g6b8e6204" */
> > ?- use_module(library(iso_ext)).
> > true.
> > ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> > % CPU time: 4.719s
> > true.
> >
> > /* Dogelog Player 1.0.2, nodejs */
> > ?- ensure_loaded(library(sequence)).
> > true.
> > ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> > % Wall 1763 ms, gc 4 ms, 6250971 lips
> > true.
> >
> > /* SWI-Prolog, 8.5.14 */
> > ?- time((call_nth((between(1,1000,_),call_nth(between(1,1000,_),_)),_), fail; true)).
> > % 5,002,004 inferences, 0.484 CPU in 0.473 seconds (102% CPU, 10326718 Lips)
> > true.

End-users have really problems with embeding
Prolog into HTML pages by themself. For example
an simple advice as follows from Tau Prolog:

get_by_id(writeme, WriteMe),
open(WriteMe, write, Stream),
set_output(Stream),
...
write(Formula)

doesn't work, when the stream does a
innerHTML += for the writeme element. What
would then be needed is:

get_by_id(writeme, WriteMe),
open(WriteMe, write, Stream),
set_output(Stream),
...
term_atom(Formula, FormulaAtom),
xml_ecape(FormulaAtom, FormulaEscaped),
write(FormulaEscaped)

I guess xml_escape/2 exists already since
1990's when the world's first web server, was
developed and implemented by Berners-Lee

on a NeXTcube computer. But its even
worse, does Tau Prolog have a term_atom/2?

So a Code Playground where you can
simply do the following, as currently
available from dogelog.js:

<script type="application/x-dogelog">
... Dogelog Player code goes here ...
</script>

Is much simpler. Thanks to the Novacore,
if I have time, I will maybe provide also:

<script type="application/x-swi">
... SWI-Prolog code goes here ...
</script>
<script type="application/x-ciao">
... Ciao Prolog code goes here ...
</script>

And if in 100 years from now, the stubborn
Prolog community has decided on some PEPs,
could maybe even do:

<script type="application/x-prolog">
... Prolog code goes here ...
</script>

Mostowski Collapse schrieb am Mittwoch, 31. August 2022 um 19:18:28 UTC+2:
> End-users have really problems with embeding
> Prolog into HTML pages by themself. For example
> an simple advice as follows from Tau Prolog:
>
> get_by_id(writeme, WriteMe),
> open(WriteMe, write, Stream),
> set_output(Stream),
> ...
> write(Formula)
>
> doesn't work, when the stream does a
> innerHTML += for the writeme element. What
> would then be needed is:
>
> get_by_id(writeme, WriteMe),
> open(WriteMe, write, Stream),
> set_output(Stream),
> ...
> term_atom(Formula, FormulaAtom),
> xml_ecape(FormulaAtom, FormulaEscaped),
> write(FormulaEscaped)
>
> I guess xml_escape/2 exists already since
> 1990's when the world's first web server, was
> developed and implemented by Berners-Lee
>
> on a NeXTcube computer. But its even
> worse, does Tau Prolog have a term_atom/2?

I would like to have nice test cases for Novacore.
For sure floats would be part of Novacore. SWI-Prolog
publish its new release 8.5.18. And it says it does now

do to_nearest rouding more consequently. What does
that mean? Wiki tells me there are at least two “to nearest”:

- Round to nearest, ties to even – rounds to the nearest value;
if the number falls midway, it is rounded to the nearest value
with an even least significant digit.

- Round to nearest, ties away from zero (or ties to away) – rounds
to the nearest value; if the number falls midway, it is rounded to
the nearest value above (for positive numbers) or below (for negative numbers).

https://en.wikipedia.org/wiki/IEEE_754#Roundings_to_nearest 1

But then in Java BigDecimal there are even 3 “to nearest”,
HALF_EVEN, HALF_UP and HALF_DOWN.

I guess the to_nearest should be HALF_EVEN. Was
lazy making manual test cases, so used a fuzzer.
The fuzzer test cases might not be that good, especially

for HALF_EVEN, since they might not pick up the border
cases, but nevertheless its a first start. Might do more
test cases. The test cases are simply:

fuzzer :-
L is -(1<<100),
H is (1<<100)+1,
between(1, 100, N),
random(L, H, X),
Y is float(X),
write(case(N, X, Y)), write('.'), nl,
fail.
fuzzer.

My Prolog systems, formerly Jekejeke Prolog and
Dogelog Player on its various target platforms, all
pass these test cases.

Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:06:09 UTC+2:
> I would like to have nice test cases for Novacore.
> For sure floats would be part of Novacore. SWI-Prolog
> publish its new release 8.5.18. And it says it does now
>
> do to_nearest rouding more consequently. What does
> that mean? Wiki tells me there are at least two “to nearest”:
>
> - Round to nearest, ties to even – rounds to the nearest value;
> if the number falls midway, it is rounded to the nearest value
> with an even least significant digit.
>
> - Round to nearest, ties away from zero (or ties to away) – rounds
> to the nearest value; if the number falls midway, it is rounded to
> the nearest value above (for positive numbers) or below (for negative numbers).
>
> https://en.wikipedia.org/wiki/IEEE_754#Roundings_to_nearest 1
>
> But then in Java BigDecimal there are even 3 “to nearest”,
> HALF_EVEN, HALF_UP and HALF_DOWN.

Here are some very first results for other Prolog systems:

/* SWI-Prolog 8.5.18 (Windows and WASM) Ok */
?- case(N, X, Y), Y =\= float(X).
false.

/* Trealla Prolog 2.4.3 Ok */
?- case(N, X, Y), Y =\= float(X).
false.

/* Scryer Prolog 0.9.0 Nok */
?- case(N, X, Y), Y =\= float(X).
N = 1, X = -572504891324561953821040518484, Y = -5.7250489132456196e29
; N = 3, X = 884996183305110611102854483978, Y = 8.849961833051106e29
; N = 4, X = 1251939306673717603656775488197, Y = 1.2519393066737177e30
Etc..

So somehow these test cases already do their job!

Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:12:39 UTC+2:
> I guess the to_nearest should be HALF_EVEN. Was
> lazy making manual test cases, so used a fuzzer.
> The fuzzer test cases might not be that good, especially
>
> for HALF_EVEN, since they might not pick up the border
> cases, but nevertheless its a first start. Might do more
> test cases. The test cases are simply:
>
> fuzzer :-
> L is -(1<<100),
> H is (1<<100)+1,
> between(1, 100, N),
> random(L, H, X),
> Y is float(X),
> write(case(N, X, Y)), write('.'), nl,
> fail.
> fuzzer.
>
> My Prolog systems, formerly Jekejeke Prolog and
> Dogelog Player on its various target platforms, all
> pass these test cases.
> Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:06:09 UTC+2:
> > I would like to have nice test cases for Novacore.
> > For sure floats would be part of Novacore. SWI-Prolog
> > publish its new release 8.5.18. And it says it does now
> >
> > do to_nearest rouding more consequently. What does
> > that mean? Wiki tells me there are at least two “to nearest”:
> >
> > - Round to nearest, ties to even – rounds to the nearest value;
> > if the number falls midway, it is rounded to the nearest value
> > with an even least significant digit.
> >
> > - Round to nearest, ties away from zero (or ties to away) – rounds
> > to the nearest value; if the number falls midway, it is rounded to
> > the nearest value above (for positive numbers) or below (for negative numbers).
> >
> > https://en.wikipedia.org/wiki/IEEE_754#Roundings_to_nearest 1
> >
> > But then in Java BigDecimal there are even 3 “to nearest”,
> > HALF_EVEN, HALF_UP and HALF_DOWN.

More results:

/* Ciao Prolog 1.22.0 (WSL and WASM) Ok */
?- case(N, X, Y), Y =\= float(X).
no

/* ECLiPSe Prolog 7.0.61 Nok */
?- case(N, X, Y), Y =\= float(X).
N = 1
X = -572504891324561953821040518484
Y = -5.7250489132456196e+29
Etc..

Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:13:46 UTC+2:
> Here are some very first results for other Prolog systems:
>
> /* SWI-Prolog 8.5.18 (Windows and WASM) Ok */
> ?- case(N, X, Y), Y =\= float(X).
> false.
>
> /* Trealla Prolog 2.4.3 Ok */
> ?- case(N, X, Y), Y =\= float(X).
> false.
>
> /* Scryer Prolog 0.9.0 Nok */
> ?- case(N, X, Y), Y =\= float(X).
> N = 1, X = -572504891324561953821040518484, Y = -5.7250489132456196e29
> ; N = 3, X = 884996183305110611102854483978, Y = 8.849961833051106e29
> ; N = 4, X = 1251939306673717603656775488197, Y = 1.2519393066737177e30
> Etc..
>
> So somehow these test cases already do their job!
> Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:12:39 UTC+2:
> > I guess the to_nearest should be HALF_EVEN. Was
> > lazy making manual test cases, so used a fuzzer.
> > The fuzzer test cases might not be that good, especially
> >
> > for HALF_EVEN, since they might not pick up the border
> > cases, but nevertheless its a first start. Might do more
> > test cases. The test cases are simply:
> >
> > fuzzer :-
> > L is -(1<<100),
> > H is (1<<100)+1,
> > between(1, 100, N),
> > random(L, H, X),
> > Y is float(X),
> > write(case(N, X, Y)), write('.'), nl,
> > fail.
> > fuzzer.
> >
> > My Prolog systems, formerly Jekejeke Prolog and
> > Dogelog Player on its various target platforms, all
> > pass these test cases.
> > Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 01:06:09 UTC+2:
> > > I would like to have nice test cases for Novacore.
> > > For sure floats would be part of Novacore. SWI-Prolog
> > > publish its new release 8.5.18. And it says it does now
> > >
> > > do to_nearest rouding more consequently. What does
> > > that mean? Wiki tells me there are at least two “to nearest”:
> > >
> > > - Round to nearest, ties to even – rounds to the nearest value;
> > > if the number falls midway, it is rounded to the nearest value
> > > with an even least significant digit.
> > >
> > > - Round to nearest, ties away from zero (or ties to away) – rounds
> > > to the nearest value; if the number falls midway, it is rounded to
> > > the nearest value above (for positive numbers) or below (for negative numbers).
> > >
> > > https://en.wikipedia.org/wiki/IEEE_754#Roundings_to_nearest 1
> > >
> > > But then in Java BigDecimal there are even 3 “to nearest”,
> > > HALF_EVEN, HALF_UP and HALF_DOWN.

Here is a better fuzzer, it has a higher mean lsb/1 value,
and therefore mostlikely tests more HALF_EVEN:

?- aggregate_all(sum(N), (case(_,X,_), N is lsb(abs(X))), S), A is S/100.
S = 94,
A = 0.94.

?- aggregate_all(sum(N), (case2(_,X,_), N is lsb(abs(X))), S), A is S/100.
S = 5050,
A = 50.5.

The fiuzzer reads as follows:

fuzzer2 :-
between(1, 100, N),
L is -(1<<N),
H is (1<<N)+1,
random(L, H, X),
Z is X<<(100-N),
Y is float(Z),
write(case2(N, Z, Y)), write('.'), nl,
fail.
fuzzer2.

It indeed trip wires the newest SWI-Prolog:

/* SWI-Prolog 8.5.18 Nok */
?- case2(N, X, Y), Z is float(X), Y =\= Z.
N = 56,
X = -1190359501396335678156200476672,
Y = -1.1903595013963357e+30,
Z = -1.1903595013963356e+30 ;
false.

The test case is ok in all my systems, like formerly
Jekejeke Prolog and Dogelog Player. The test
case is also ok here:

/* Trealla Prolog 2.4.3 Ok */
?- case2(N, X, Y), Y =\= float(X).
false.

/* Ciao Prolog 1.22.0 Ok */
?- case2(N, X, Y), Y =\= float(X).
no

Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 08:57:43 UTC+2:
> Here is a better fuzzer, it has a higher mean lsb/1 value,
> and therefore mostlikely tests more HALF_EVEN:
>
> ?- aggregate_all(sum(N), (case(_,X,_), N is lsb(abs(X))), S), A is S/100.
> S = 94,
> A = 0.94.
>
> ?- aggregate_all(sum(N), (case2(_,X,_), N is lsb(abs(X))), S), A is S/100.
> S = 5050,
> A = 50.5.
>
> The fiuzzer reads as follows:
>
> fuzzer2 :-
> between(1, 100, N),
> L is -(1<<N),
> H is (1<<N)+1,
> random(L, H, X),
> Z is X<<(100-N),
> Y is float(Z),
> write(case2(N, Z, Y)), write('.'), nl,
> fail.
> fuzzer2.

There are much more tripwires, and its not
related to negative bigints per se:

/* SWI-Prolog 8.5.18 */
?- case3(N, X, Y), Y =\= float(X).
N = 12,
X = 548500250785140154065267720192,
Y = 5.485002507851401e+29 ;
N = 37,
X = 503487689179869862254742601728,
Y = 5.034876891798698e+29 ;
N = 44,
X = -828141981914306499269539921920,
Y = -8.281419819143066e+29 ;
N = 69,
X = -124851129191269336172294307840,
Y = -1.2485112919126934e+29 ;
N = 95,
X = 594779305038924597107611402240,
Y = 5.9477930503892456e+29 ;
false.

Interesting? Thats probably some material fur
further analysis. Need to reactivate my SWI-Prolog
based float_half_even/2. If you analyse the

float_half_even/2 you could find the execution
paths that these examples are using and whether
there is something in common. But this only works

if your system uses fast path float/1, if it uses
a rational number based bigint to float conversion,
the analysis possibly not so helpful. Although a

rational number based float conversion might
show some denominator in the form 2^k, for
some k, and yet all its logic could be translated

to getbit/1, lsb/1, etc..

Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 08:59:43 UTC+2:
> It indeed trip wires the newest SWI-Prolog:
>
> /* SWI-Prolog 8.5.18 Nok */
> ?- case2(N, X, Y), Z is float(X), Y =\= Z.
> N = 56,
> X = -1190359501396335678156200476672,
> Y = -1.1903595013963357e+30,
> Z = -1.1903595013963356e+30 ;
> false.
>
> The test case is ok in all my systems, like formerly
> Jekejeke Prolog and Dogelog Player. The test
> case is also ok here:
> /* Trealla Prolog 2.4.3 Ok */
> ?- case2(N, X, Y), Y =\= float(X).
> false.
>
> /* Ciao Prolog 1.22.0 Ok */
> ?- case2(N, X, Y), Y =\= float(X).
> no
> Mostowski Collapse schrieb am Montag, 10. Oktober 2022 um 08:57:43 UTC+2:
> > Here is a better fuzzer, it has a higher mean lsb/1 value,
> > and therefore mostlikely tests more HALF_EVEN:
> >
> > ?- aggregate_all(sum(N), (case(_,X,_), N is lsb(abs(X))), S), A is S/100.
> > S = 94,
> > A = 0.94.
> >
> > ?- aggregate_all(sum(N), (case2(_,X,_), N is lsb(abs(X))), S), A is S/100.
> > S = 5050,
> > A = 50.5.
> >
> > The fiuzzer reads as follows:
> >
> > fuzzer2 :-
> > between(1, 100, N),
> > L is -(1<<N),
> > H is (1<<N)+1,
> > random(L, H, X),
> > Z is X<<(100-N),
> > Y is float(Z),
> > write(case2(N, Z, Y)), write('.'), nl,
> > fail.
> > fuzzer2.

Some suspicion about the random number skewing.
Mostlikely #define MAX_URANDOMM_ITER is too low. See
here what GMP does. And it then falls back to low quality result:

if (count == 0)
/* Too many iterations; return result mod n == result - n */
mpn_sub_n (rp, rp, np, size);
https://salsa.debian.org/science-team/gmp/-/blob/master/mpz/urandomm.c

Note that the example interval [0…2^n+1) is a very nasty non power
of 2 interval. That I was using a nasty interval was rather not planned,
when writing the fuzzer, just some accident.

In my implementation I have no MAX_URANDOMM_ITER limit.
My suspiciion, therefore it generates a better probability shaping
on my side, which can be even measured,

already for 100 bits? Is this the reason? Or its some other bug
in mpz_urandomm() caused by the last limb cmp juggling?

I didn’t test the random/1 evaluable function in Trealla and Cliao yet.
Cannot run the same test case in Trealla Prolog or Ciao Prolog,
too much stuff missing:

- Trealla Prolog: Didn’t find bigint random.

- Ciao Prolog: Found some random, with an incompatible
protocol to SWI-Prolog, different meaning of the parameters,
but there is so much other stuff missing, like
msb/1, aggregate_all/3, etc…

Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 19:46:58 UTC+2:
> Some suspicion about the random number skewing.
> Mostlikely #define MAX_URANDOMM_ITER is too low. See
> here what GMP does. And it then falls back to low quality result:
>
> if (count == 0)
> /* Too many iterations; return result mod n == result - n */
> mpn_sub_n (rp, rp, np, size);
> https://salsa.debian.org/science-team/gmp/-/blob/master/mpz/urandomm.c
>
> Note that the example interval [0…2^n+1) is a very nasty non power
> of 2 interval. That I was using a nasty interval was rather not planned,
> when writing the fuzzer, just some accident.
>
> In my implementation I have no MAX_URANDOMM_ITER limit.
> My suspiciion, therefore it generates a better probability shaping
> on my side, which can be even measured,
>
> already for 100 bits? Is this the reason? Or its some other bug
> in mpz_urandomm() caused by the last limb cmp juggling?

On Ciao Prolog its:
random(0,M,...)

On SWI-Prolog its:
random(0,M+1,...)

Should there be a discussion about random/3, its protocoll?
I don’t know, what are the plans of Ciao Prolog and SWI-Prolog?
I don’t know? Is there a road map? I don’t know.

Recently SWI-Prolog deprecated random/3 and introduced
random_between/3 with a different protocoll. Maybe this can
point the way forward? I am more interested about the

skewness here, and not the protcoll of some random API.
Skewed shouldn’t mean screwed. Its quite possible that a
skewed random generator can be fixed.

Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 19:48:05 UTC+2:
> I didn’t test the random/1 evaluable function in Trealla and Cliao yet.
> Cannot run the same test case in Trealla Prolog or Ciao Prolog,
> too much stuff missing:
>
> - Trealla Prolog: Didn’t find bigint random.
>
> - Ciao Prolog: Found some random, with an incompatible
> protocol to SWI-Prolog, different meaning of the parameters,
> but there is so much other stuff missing, like
> msb/1, aggregate_all/3, etc…
> Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 19:46:58 UTC+2:
> > Some suspicion about the random number skewing.
> > Mostlikely #define MAX_URANDOMM_ITER is too low. See
> > here what GMP does. And it then falls back to low quality result:
> >
> > if (count == 0)
> > /* Too many iterations; return result mod n == result - n */
> > mpn_sub_n (rp, rp, np, size);
> > https://salsa.debian.org/science-team/gmp/-/blob/master/mpz/urandomm.c
> >
> > Note that the example interval [0…2^n+1) is a very nasty non power
> > of 2 interval. That I was using a nasty interval was rather not planned,
> > when writing the fuzzer, just some accident.
> >
> > In my implementation I have no MAX_URANDOMM_ITER limit.
> > My suspiciion, therefore it generates a better probability shaping
> > on my side, which can be even measured,
> >
> > already for 100 bits? Is this the reason? Or its some other bug
> > in mpz_urandomm() caused by the last limb cmp juggling?

So maybe the requirement is eclectic? A non skewed
random ganerator for bigints. Often power of 2 is only
required or smallint is enough.

Ha Ha, a Casino website could be interested that their
random generators are not skewed. Or maybe they even
go for a particular skewed random generator?

What if the users of the Casino website figure out the
skewing and play accordingly? I am thinking of games
like roulette or card games. So its in their own interest?

Legitimacy & Regulation of the RNG
There are a number of independent companies which specialise in iGaming testing.
https://www.casinoguardian.co.uk/casino-guide/random-number-generator/

Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 22:22:29 UTC+2:
> On Ciao Prolog its:
> random(0,M,...)
>
> On SWI-Prolog its:
> random(0,M+1,...)
>
> Should there be a discussion about random/3, its protocoll?
> I don’t know, what are the plans of Ciao Prolog and SWI-Prolog?
> I don’t know? Is there a road map? I don’t know.
>
> Recently SWI-Prolog deprecated random/3 and introduced
> random_between/3 with a different protocoll. Maybe this can
> point the way forward? I am more interested about the
>
> skewness here, and not the protcoll of some random API.
> Skewed shouldn’t mean screwed. Its quite possible that a
> skewed random generator can be fixed.
> Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 19:48:05 UTC+2:
> > I didn’t test the random/1 evaluable function in Trealla and Cliao yet.
> > Cannot run the same test case in Trealla Prolog or Ciao Prolog,
> > too much stuff missing:
> >
> > - Trealla Prolog: Didn’t find bigint random.
> >
> > - Ciao Prolog: Found some random, with an incompatible
> > protocol to SWI-Prolog, different meaning of the parameters,
> > but there is so much other stuff missing, like
> > msb/1, aggregate_all/3, etc…
> > Mostowski Collapse schrieb am Mittwoch, 12. Oktober 2022 um 19:46:58 UTC+2:
> > > Some suspicion about the random number skewing.
> > > Mostlikely #define MAX_URANDOMM_ITER is too low. See
> > > here what GMP does. And it then falls back to low quality result:
> > >
> > > if (count == 0)
> > > /* Too many iterations; return result mod n == result - n */
> > > mpn_sub_n (rp, rp, np, size);
> > > https://salsa.debian.org/science-team/gmp/-/blob/master/mpz/urandomm.c
> > >
> > > Note that the example interval [0…2^n+1) is a very nasty non power
> > > of 2 interval. That I was using a nasty interval was rather not planned,
> > > when writing the fuzzer, just some accident.
> > >
> > > In my implementation I have no MAX_URANDOMM_ITER limit.
> > > My suspiciion, therefore it generates a better probability shaping
> > > on my side, which can be even measured,
> > >
> > > already for 100 bits? Is this the reason? Or its some other bug
> > > in mpz_urandomm() caused by the last limb cmp juggling?

2 out of 3 Prolog system cannot generate uniform random
bigints? Don't know yet, have to dig deeper. Strange that
the below result has always 100.0:

The error in Ciao Prolog is much larger than in SWI-Prolog,
i.e. the distance to the expected value. Was using this query,
taking into account the different random/3 protocoll, and

manually compensating for the missing aggregate_all/3
and msb/1 evaluable function:

$ ciaosh
Ciao 1.22.0 (2022-09-28 21:20:35 +0200) [LINUXx86_64]
?- use_module(library(between)).

?- ['aggregate.p'].

?- E is (1<<100), M is (1<<101), K is (1<<20),
between(1,10,_), aggregate_all(sum(X),
(between(1,K,_), random(0,M,X)), S),
H is abs(S-E*K), msb(H,J), N is J-20, write(N), nl, fail; true.
100.0
100.0
100.0
100.0
100.0
100.0
100.0
100.0
100.0
100.0

And this helper code (file aggregate.p):

:- use_module(library(numlists)).
:- use_module(library(random)).

aggregate_all(sum(X), G, S) :-
findall(X, G, L),
sum_list(L, S).

msb(X, Y) :- Y is log(X)/log(2).

Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 14:53:46 UTC+2:
> So maybe the requirement is eclectic? A non skewed
> random ganerator for bigints. Often power of 2 is only
> required or smallint is enough.
>
> Ha Ha, a Casino website could be interested that their
> random generators are not skewed. Or maybe they even
> go for a particular skewed random generator?
>
> What if the users of the Casino website figure out the
> skewing and play accordingly? I am thinking of games
> like roulette or card games. So its in their own interest?
>
> Legitimacy & Regulation of the RNG
> There are a number of independent companies which specialise in iGaming testing.
> https://www.casinoguardian.co.uk/casino-guide/random-number-generator/

Does the C floating point API have HALF_EVEN default?
Maybe, maybe not. Is there a test case to figure out
what rounding a system, Prolog or not, does, for its

floating point numbers, independent of some bigint
conversion issues? Was trying the folllowing test and got
some surprise. There was first quite some agreement:

/* SWI-Prolog 8.5.18 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.65723957508125e+29.

/* Ciao Prolog 1.22.0 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.65723957508125e29 ?

/* Trealla Prolog 2.4.3 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.65723957508125e+29.

/* Jekejeke Prolog 1.5.5 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.65723957508125E29.

But then suddently:

/* Scryer Prolog 0.9.0 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.657239575081248e29.

/* ECLiPSe Prolog 7.0.61 */
?- X is 665723957508124892951320985600.0+26388279066624.0.
X = 6.6572395750812482e+29

?- X is 6.6572395750812482e+29-6.65723957508125E29.
X = -140737488355328.0.

Maybe this also explains the divergence in bigint to float conversion.
Maybe they have by accident a misconfigured FPU? Some init call
to the runtime system missing? Or a cheap floating point library?

But one is WSL2 and the other Windows!

Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:16:02 UTC+2:
> Does the C floating point API have HALF_EVEN default?
> Maybe, maybe not. Is there a test case to figure out
> what rounding a system, Prolog or not, does, for its
>
> floating point numbers, independent of some bigint
> conversion issues? Was trying the folllowing test and got
> some surprise. There was first quite some agreement:
>
> /* SWI-Prolog 8.5.18 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.65723957508125e+29.
>
> /* Ciao Prolog 1.22.0 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.65723957508125e29 ?
>
> /* Trealla Prolog 2.4.3 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.65723957508125e+29.
>
> /* Jekejeke Prolog 1.5.5 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.65723957508125E29.

Have to dig deeper, could be a parsing problem.
For the first summand, I get:

/* SWI-Prolog */
?- X is 665723957508124892951320985600.0.
X = 6.65723957508125e+29.

/* ECLiPSe Prolog */
X is 665723957508124892951320985600.0.
X = 6.6572395750812482e+29

I am not yet at a test case, which would give me
some information about rounding.

Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:18:04 UTC+2:
> But then suddently:
>
> /* Scryer Prolog 0.9.0 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.657239575081248e29.
>
> /* ECLiPSe Prolog 7.0.61 */
> ?- X is 665723957508124892951320985600.0+26388279066624.0.
> X = 6.6572395750812482e+29
>
> ?- X is 6.6572395750812482e+29-6.65723957508125E29.
> X = -140737488355328.0.
>
> Maybe this also explains the divergence in bigint to float conversion.
> Maybe they have by accident a misconfigured FPU? Some init call
> to the runtime system missing? Or a cheap floating point library?
>
> But one is WSL2 and the other Windows!
> Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:16:02 UTC+2:
> > Does the C floating point API have HALF_EVEN default?
> > Maybe, maybe not. Is there a test case to figure out
> > what rounding a system, Prolog or not, does, for its
> >
> > floating point numbers, independent of some bigint
> > conversion issues? Was trying the folllowing test and got
> > some surprise. There was first quite some agreement:
> >
> > /* SWI-Prolog 8.5.18 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.65723957508125e+29.
> >
> > /* Ciao Prolog 1.22.0 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.65723957508125e29 ?
> >
> > /* Trealla Prolog 2.4.3 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.65723957508125e+29.
> >
> > /* Jekejeke Prolog 1.5.5 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.65723957508125E29.

Looks like my system belongs to the 2 system that
cannot generate good random numbers? I guess the
system with a smaller value is possible the less good

random generator, because some periodicity was hit.
Java uses a Lehmer algorithm which has a very short
period and uses very few bits in its state. On the other

hand the Twister uses quite some bits I guess, and has
a much larger periodicity. Twister would be therefore the
better randum number generator.

Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:36:51 UTC+2:
> Have to dig deeper, could be a parsing problem.
> For the first summand, I get:
>
> /* SWI-Prolog */
> ?- X is 665723957508124892951320985600.0.
> X = 6.65723957508125e+29.
>
> /* ECLiPSe Prolog */
> X is 665723957508124892951320985600.0.
> X = 6.6572395750812482e+29
>
> I am not yet at a test case, which would give me
> some information about rounding.
> Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:18:04 UTC+2:
> > But then suddently:
> >
> > /* Scryer Prolog 0.9.0 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.657239575081248e29.
> >
> > /* ECLiPSe Prolog 7.0.61 */
> > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > X = 6.6572395750812482e+29
> >
> > ?- X is 6.6572395750812482e+29-6.65723957508125E29.
> > X = -140737488355328.0.
> >
> > Maybe this also explains the divergence in bigint to float conversion.
> > Maybe they have by accident a misconfigured FPU? Some init call
> > to the runtime system missing? Or a cheap floating point library?
> >
> > But one is WSL2 and the other Windows!
> > Mostowski Collapse schrieb am Donnerstag, 13. Oktober 2022 um 20:16:02 UTC+2:
> > > Does the C floating point API have HALF_EVEN default?
> > > Maybe, maybe not. Is there a test case to figure out
> > > what rounding a system, Prolog or not, does, for its
> > >
> > > floating point numbers, independent of some bigint
> > > conversion issues? Was trying the folllowing test and got
> > > some surprise. There was first quite some agreement:
> > >
> > > /* SWI-Prolog 8.5.18 */
> > > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > > X = 6.65723957508125e+29.
> > >
> > > /* Ciao Prolog 1.22.0 */
> > > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > > X = 6.65723957508125e29 ?
> > >
> > > /* Trealla Prolog 2.4.3 */
> > > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > > X = 6.65723957508125e+29.
> > >
> > > /* Jekejeke Prolog 1.5.5 */
> > > ?- X is 665723957508124892951320985600.0+26388279066624.0.
> > > X = 6.65723957508125E29.