Dear Corretto,
This email is in regards to https://github.com/corretto/corretto-18/issues/15, which is closed at this time.
I/we are not in a position to just leave this particular subject where last left,
and we don't want the discussion or apprehension of this subject to remain closed.
As we tried to describe on the beginning of our thread at https://github.com/corretto/corretto-18/issues/15 ,
Java floating point denormal and pronormal values, from arithmetic and StrictMath function calls, in terms
of range accuracy, don't correspond to decimal or binary mathematics. Because they are not one or the other,
they don't correspond to anything. IEEE 754, for these reasons, is incomplete, and trying to justify Java's present
state due to IEEE 754 is a non sequitar, as is, more importantly, the present floating point state of OpenJDK,
and Corretto, at least right now.
-If just to start, how could correcting Java's default floating point behaviour possibly break compatibility? What on earth
could correcting the present, strange, erroneous and inconsistent behaviour of Java floating point as it is now,
possibly break compatibility with? We can't really see or think of one example, certainly one that is good for Java,
and not a lower level language. Forgive our naïveté, but are there really any such real useful examples, such,
at all, pertinent to a Java space, needing floating point errors without their base 10 range correction?!?!
-Even this is not the main thrust of our request. Our request submission to Coretto still is for the sake of the
implementation and release of a Coretto Java patch to itself. A patch can be included or omitted, installed
or not, still allowing compatibility. But even with the inclusion of a patch, various switches or options
for the runtime could be involved, to enable a changed floating point arithmetic or StrictMath,
yet still allowing compatability, either totally, or in some desired partial or co-integral manner,
which could still succeed in being previously compatible, if one pauses to think. :)
We can't exactly allow for this discussion to be just halted, because we in fact are beginning to NEED
corrected OpenJDK floating point arithmetic, and an equivalent corrected StrictMath, because of the
2D graphics and 3D visual graphics work we are now planning. The present workarounds are too slow,
and waste too much memory. We need continuous float and double range accuracy and the other facilities
of those earlier types. As will a large number of programmers or companies out there, who haven't come
forward, or persisted.
Can those involved at Corretto reconsider this matter, and implement and release a base 10 floating point
arithmetic and StrictMath correction or mode varying patch for Corretto Java, for present and future versions,
for its JDK and JRE, on all offered Correto platforms, now and into the future?
AWS OFFICIALUpdated 10 months ago
The issue of floating point errors has been raised repeatedly, before, with the JCP.
Because of this, I am trying to approach Corretto Java to do what they alone could do, which is to implement floating point correction inside one of their patches for their Corretto Java. Can what I am submitting still be considered and taken on board? Why exactly can't Corretto issue a patch, at least, that differs from the spec, particularly in a bug area, and an incomplete area in the set of Java standards, a "blind spot"? Particularly since a patch can always be seen as optional, anyway?