That mixing floats and rational numbers can be a challenge
recently surfaced for SWI-Prolog, where their floats also
have NaN and Infinity. On the other hand I do not have these

two constants, and my own takes in the form of a simple
library(arithmetic/ratio), that does some overloading of the
existing basic arithmetic operators and comparison,

seems not to be fit at all. If I download an old version
interpreter_1.5.1.jar I get these results:

?- 1229999999999999878 rdiv 123 =:= 1.0E16.
fail.
?- X is (1 rdiv 2)+0.0.
Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.
?- X is (1 rdiv 2)*1.0.
Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.

Such cases were deliberatively left open. But I think these
gaps can be closed towards a ISO core standard backward
compatibility. Keeping in mind that integers are also rational

numbers, and therefore all the coercion of integer to float,
that is already found in the ISO core standard should translate
to a coercion of rational number to float.

Here is a prototype of such coercion, already
working for the next release of formerly Jekejeke Prolog.
I now have running these examples:

?- 1229999999999999878 rdiv 123 =:= 1.0E16.
true.
?- X is (1 rdiv 2)+0.0.
X = 0.5.
?- X is (1 rdiv 2)*1.0.
X = 0.5.

And a few further examples:

?- X is 1 rdiv 3.
X = 1#3.
?- X is 1 rdiv 3.0.
X = 0.3333333333333333.
?- X is 3^(-1).
X = 1#3.
?- X is 3.0^(-1).
X = 0.3333333333333333.

The value of 3^(-1) and 1 rdiv 3.0 differ from what SWI-Prolog
delivers in its default setting. The above values result from
consulting use_module(library(arithmetic/ratio)) in my system.

Mostowski Collapse schrieb am Sonntag, 22. Januar 2023 um 14:00:40 UTC+1:
> That mixing floats and rational numbers can be a challenge
> recently surfaced for SWI-Prolog, where their floats also
> have NaN and Infinity. On the other hand I do not have these
>
> two constants, and my own takes in the form of a simple
> library(arithmetic/ratio), that does some overloading of the
> existing basic arithmetic operators and comparison,
>
> seems not to be fit at all. If I download an old version
> interpreter_1.5.1.jar I get these results:
>
> ?- 1229999999999999878 rdiv 123 =:= 1.0E16.
> fail.
> ?- X is (1 rdiv 2)+0.0.
> Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.
> ?- X is (1 rdiv 2)*1.0.
> Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.
>
> Such cases were deliberatively left open. But I think these
> gaps can be closed towards a ISO core standard backward
> compatibility. Keeping in mind that integers are also rational
>
> numbers, and therefore all the coercion of integer to float,
> that is already found in the ISO core standard should translate
> to a coercion of rational number to float.

I think 3^(-1) and 3.0^(-1) is save to have a new value in my system,
since without consulting library(arithmetic/ratio), I get the following
two values:

/* without library(arithmetic/ratio) */
?- X is 3^(-1).
Error: Argument should be positive or 0, found -1.
?- X is 3.0^(-1).
Error: Argument should be positive or 0, found -1.

So only the library(arithmetic/ratio)) opens (^)/2 to negative
exponents. On the other hand without the library(arithmetic/ratio),
the operator (^)/2 already covered floating point numbers:

/* without library(arithmetic/ratio) */
?- X is 3^2.
X = 9.
?- X is 3.0^2.
X = 9.0.

So challenge was to make (^)/2 more exact and at the
same time also support floating point numbers. The
examples 3^(-1) and 1 rdiv 3.0 with the currious results

that differ with SWI-Prolog reflect a different design
decision. Basically we have now this identity in our
system, for both rational number arguments and

floating point value arguments:

X^(-1) =:= 1 rdiv X

Mostowski Collapse schrieb am Sonntag, 22. Januar 2023 um 14:08:03 UTC+1:
> Here is a prototype of such coercion, already
> working for the next release of formerly Jekejeke Prolog.
> I now have running these examples:
> ?- 1229999999999999878 rdiv 123 =:= 1.0E16.
> true.
> ?- X is (1 rdiv 2)+0.0.
> X = 0.5.
> ?- X is (1 rdiv 2)*1.0.
> X = 0.5.
>
> And a few further examples:
>
> ?- X is 1 rdiv 3.
> X = 1#3.
> ?- X is 1 rdiv 3.0.
> X = 0.3333333333333333.
> ?- X is 3^(-1).
> X = 1#3.
> ?- X is 3.0^(-1).
> X = 0.3333333333333333.
>
> The value of 3^(-1) and 1 rdiv 3.0 differ from what SWI-Prolog
> delivers in its default setting. The above values result from
> consulting use_module(library(arithmetic/ratio)) in my system.
> Mostowski Collapse schrieb am Sonntag, 22. Januar 2023 um 14:00:40 UTC+1:
> > That mixing floats and rational numbers can be a challenge
> > recently surfaced for SWI-Prolog, where their floats also
> > have NaN and Infinity. On the other hand I do not have these
> >
> > two constants, and my own takes in the form of a simple
> > library(arithmetic/ratio), that does some overloading of the
> > existing basic arithmetic operators and comparison,
> >
> > seems not to be fit at all. If I download an old version
> > interpreter_1.5.1.jar I get these results:
> >
> > ?- 1229999999999999878 rdiv 123 =:= 1.0E16.
> > fail.
> > ?- X is (1 rdiv 2)+0.0.
> > Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.
> > ?- X is (1 rdiv 2)*1.0.
> > Fehler: Argument sollte Ganzzahl sein, gefunden 1.0.
> >
> > Such cases were deliberatively left open. But I think these
> > gaps can be closed towards a ISO core standard backward
> > compatibility. Keeping in mind that integers are also rational
> >
> > numbers, and therefore all the coercion of integer to float,
> > that is already found in the ISO core standard should translate
> > to a coercion of rational number to float.

Somehow I regret my fingerpointing to 0/0 as nan.
Now there are some new problems, in SWI-Prolog:

?- X is max(nan, 1.0).
X = 1.0.

In JavaScript:

console.log(Math.max(0/0, 1.0));
> NaN

In Python:

>>> max(float('nan'),1.0)
nan

I guess the later two languages adhere to some approaches
of mathematical logic to partial functions, i.e. the rule that

functions that have at least one NaN argument, should
return NaN. But this is my personal speculation.

There is a strange effect, that NaN make the less than
or equal not anymore being a total order, i.e. it is
not anymore assured that X =< Y or Y =< X:

/* SWI-Prolog 9.1.2 */
?- nan =< 1.0.
false.

?- 1.0 =< nan.
false.

Did ROK ever write about that? Exact comparison would
gain transitivity. But continuation values, especially the value
NaN, destroys totality.

Mostowski Collapse schrieb am Dienstag, 24. Januar 2023 um 02:30:38 UTC+1:
> Somehow I regret my fingerpointing to 0/0 as nan.
> Now there are some new problems, in SWI-Prolog:
>
> ?- X is max(nan, 1.0).
> X = 1.0.
>
> In JavaScript:
>
> console.log(Math.max(0/0, 1.0));
> > NaN
>
> In Python:
>
> >>> max(float('nan'),1.0)
> nan
>
> I guess the later two languages adhere to some approaches
> of mathematical logic to partial functions, i.e. the rule that
>
> functions that have at least one NaN argument, should
> return NaN. But this is my personal speculation.