Java Floating Point Points?

[sminervini.prism]

mailto:core-libs-dev at openjdk.java.net

Andrew Haley said, and we reply:

1) Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.

While I don't like re-submitting this article, certainly not on this forum,
there has always been this article:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

The age of this article does not matter. It is as bearing to action in 2022
as it was then.

-Even without recombiling floating point or StrictMath code, of course it could
be changed, and compatibly. Runtime or compile time switches could be introduced.
Key words could be introduced that may apply at many different levels. Maybe
even annotations could be used for the compiler, which can already apply at
any point that floating point arithmetic and StrictMath methods and fields
may occur. Whevever there is a code space, there could be an annotation
or a keyword. At the class or interface or static block level. At the
variable, data, field and method level. Even at the main method,
Thread level, Runnable or Future level, or even further.

2) Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.

-There could be dual mode floating point correction, implemented inside
Java at any level you could like. Dual mode couldn't be incompatible
with anything.

3) You must read and fully understand this before you go any further. It
will require a lot of study:

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

> May the Java Community Process reconsider the present floating point
> operations and method calls situation, based on an imperfect
> standard and improper workaround, and provide corrected, defaulting
> or specifying-compatible waya for Java floating point arithmetic and
> Calculator class method results to always cohere in their ranges,
> without denormal and pronormal inclusion?

In a word, no. That possibility is so unlikely that it is not worthy
of consideration.

-IEEE 754 has a blind spot, an oversight error. It says nothing about
operation values that straddle the range of the arithmetic or method result,
partway in, partway out. BigInteger, BigDecimal, or the big-math library
at https://github.com/eobermuhlner/big-math are only temporary responses
that are two large in memory than needed, and too slow. The article included
as part of 3) doesn't even mention SSE, the presence of end of range
carrying additional bits.

Speed at the expense of accurary, ie. providing
a rapid falsehood, is a logic error that can compromise the entire enterprise
of computer software itself. What is required is the inclusion of SSE
additional registers and their use; just a little bit of extra registry
space to handle range end carries if they occur.

We wish to appeal to reason on this subject, if not the odds! A mechanical
clock is really amazing because it is complex, and because all the pieces whizz
around together at amazing speed, but because it maintains those earlier two
properties while maintaining accurate time. The clock loses usefulness,
and even any usefulness, if the accurate time can't be set or maintained,
at the rate it needs to operate at.

The fact that more registers are referred to, to uphold float and double, has not been
enough of a speed compromise to prevent 128 bit numbers elsewhere.
Besides, the emptiness of extra bits past the range limit of float and double
could be optimised and controlled by one flag bit.

Is there someone else involved in core-libs-dev at openjdk.java.net, or the JCP,
who can give a more particular response to this issue via the points raised here,
and engender change to the attitudes to floating point arithmetic and
floating point elementary functions, so that release versions of Java SE and
OpenJDK can include FP error correction in this Java domain?

Sergio Minervini
S.M.

Sent with [ProtonMail](https://protonmail.com/) secure email.