Format of floating point numbers

[ltratt]

AFAIK, SOM doesn't specify how floating point numbers should be converted to strings, so there is almost certainly inconsistency across implementations. To my surprise, printing floating point numbers turns out to be an active area of research, with the recent best algorithm appearing only in 2018. yksom uses an implementation of Ryū to print out floating point numbers and it is subtly different than java-som. Consider the program:

        (1.1 + 1) println.
        (1.1 + 1.2) println.
        (1.1 + (1 << 30)) println.
        (1.1 + (1 << 60)) println.
        (1 + 1.1) println.
        (-1 - 1.1) println.
        (-1 - -1.1) println.
        (-1 * -1.1) println.
        (10 / 1.3) println.
        (10 / 0.3) println.
        (10 / 0.2) println.

java-som prints:

2.1
2.3
1.0737418251E9
1.15292150460684698E18
2.1
-2.1
0.10000000000000009
1.1
7
33
50

whereas yksom prints:

2.1
2.3
1073741825.1
1.152921504606847e18
2.1
-2.1
0.10000000000000009
1.1
7
33
50

i.e. 1.0737418251E9 -> 1073741825.1.

There are C and Java implementations of Ryū, so it is probably feasible to specify that's how floating point numbers should be printed? I admit this is a small issue in the grand scheme of things, at most, but it does make it harder to test multiple SOM variants.

[smarr]

I fear, it doesn't really end there.
Given that floating point operations have rounding errors, there can be differences between an interpreted execution and a compiled and optimized execution. Not sure whether Java permits such transformations, but I would assume that somewhere out there, some compiler optimized floating point operations resulting in rounding differences.

[ltratt]

Isn't it sufficient to say that floating point operations in SOM must be IEE 754 compatible?

[smarr]

I guess, one could say that optimizations are only allowed if they are identities according to the IEEE-754 standard.

But that would seem to preclude things such as
"Automatically improving accuracy for floating point expressions"
https://dl.acm.org/citation.cfm?id=2737959

I guess, it would be nice if accuracy is never worse than when following IEEE-754.

[ltratt]

If I understand that paper correctly, it doesn't change IEEE-754, it just reorders source-level expressions so that they're less subject to rounding (which is something experienced programmers do anyway, to some extent). So I think IEEE-754 is still a reasonable spec to adhere to?