Float enhancements stalled?

Prolog Improvements Forum - PIPS General discussions
1

Hi,

Somehow this link is broken ( Not Found ):

0106.0 Float enhancements Draft
https://prolog-lang.org/ImprovementsForum/0106-floats-enhancements.html

Also there is no consensus between ECLiPSe and SWI in realization:

/* Version 7.1beta #13 (x86_64_nt) */
[eclipse 5]: X is min(1.5NaN, 3).
X = 3.0
Yes (0.00s cpu)
[eclipse 6]: X is min(3, 1.5NaN).
X = 1.5NaN
Yes (0.00s cpu)

/* SWI-Prolog (threaded, 64 bits, version 10.1.1) */
?- X is min(1.5NaN, 3).
X = 1.5NaN.
?- X is min(3, 1.5NaN).
X = 1.5NaN.

Mostlikely SWI uses IEEE minimum. While ECLiPSe uses (a < b ? a : b).

Bye

P.S.: I am planning a kind of IEEE minNum behaviour:

/* Dogelog Player 2.2.1 */
?- X is min(0rNaN, 3).
X = 3.
?- X is min(3, 0rNaN).
X = 3.

Note that there is no coercion of 3 into 3.0.

2

The story is rather complicated. See f(max/2)

3

Yes, sorry, it doesn’t exist yet. I had started working on a draft based on my 2009 proposal, but it requires more work than anticipated, owing to interim developments (standard updates IEEE 754-2019 / ISO/IEC 60559:2020 and ISO/IEC 10967-1:2012, and the SWI implementation of various features).

ECLiPSe behaviour here is undesirable, the min/max operations should commute.

As for returning NaN (“NaN contagion”) or 3 (“treat NaN as missing data”), this has been the subject of standardisation discussions. Note that minNum/maxNum functions were removed from the IEEE standard in 2019 (background, Julia discussion), and replaced by minimumNumber/maximumNumber which do propagate NaN. minimum/maximum (which propagate NaN) and minimumNumber/maximumNumber (which return the non-NaN).

For the Prolog functions, I’d support the “NaN contagion” behaviour (as SWI does), to make min/max/2 fully consistent with the other arithmetic functions. Of course there are applications where the “treat NaN as missing data” semantics is useful, but this should be done by different predicates, not regular arithmetic evaluation.

4

Actually the suffix “Number” in the name indicate that they don’t
propagate NaN unless both arguments are NaN, the ones that
propagate NaN are still “minimum” and “maximum” without “Number”

suffix. See IEEE754_ver2019.pdf, you can choose at least between:

9.6 Minimum and maximum operations
sourceFormat minimum(source, source)
sourceFormat minimumNumber(source, source)
sourceFormat maximum(source, source)
sourceFormat maximumNumber(source, source)

I have tried to track my design choice so far and got:

The built-in (=\=)/2 now implements not quiet IEEE 754-2019 §5.6.1.
The built-ins (=:=)/2, (<)/2, etc. now implement quiet IEEE 754-2019 §5.6.1.
The built-ins (@<)/2, etc. now implement quiet ordered IEEE 754-2019 §5.6.1.
The built-in (-)/2 now implements NaN propagation IEEE 754-2019 §6.2.3.
The built-ins min/3 and max/3 now implement number IEEE 754-2019 §9.6.

I didn’t touch arithmetic functions or trigonometric functions yet,
they still bark on special values. Only tried to have a clean cut
solution for ordering releated stuff, that uses special values, which

has less coverage in the ECLiPSe document, and albeit arbitrary
choices were made, some choices are inspired by what is found in
other languages such as JavaScript, Python and Java, other choices

are inspired to have a natural order, disagreeing with SWI and ECLiPSe:

/* Version 7.1beta #13 (x86_64_nt) */
[eclipse 1]: ?- sort([0, 0.0, 1.5NaN, -1.0Inf, 1.0Inf], X).
X = [1.5NaN, -1.0Inf, 0.0, 1.0Inf, 0]

/* SWI-Prolog (threaded, 64 bits, version 10.1.1) */
?- sort([0, 0.0, 1.5NaN, -1.0Inf, 1.0Inf], X).
X = [1.5NaN, -1.0Inf, 0.0, 0, 1.0Inf].

/* Dogelog Player 2.2.1 */
?- sort([0, 0.0, 0rNaN, -0rInf, 0rInf], X).
X = [-0rInf, 0.0, 0, 0rInf, 0rNaN].

One can still see ISO core standard typical things, like 0 \== 0.0.
That NaN is bigger than 0.0 in total order comes from IEEE 754-2019 §5.6.1.
SWI Prolog adopts finite float and integer ordered together surrounded

by special values, while ECLiPSe Prolog does not do that.

5

Thanks, I’ve corrected my post!