Dear Corretto,
We have been encountering brickwall problems trying to interact with Oracle, the JCP and the OpenJDK in terms of Java floating point, since they are refusing to interact with us, discuss, or be persuaded. This leaves no options at all, in a necessary and obligate sitation.
From what we have gathered, both ourselves and more widely, IEEE 754 has a blind spot in it. An incompletion where either right or wrong can creep in. This is towards the right hand side of float or double arithmetic and StrictMath method calls, where you can have a straddling value for the last decimal place. At that point there is presently room for confusion between the decimal and the binary; the decimal, which the human and further logic, mathematics or software needs, and the binary, which is converterted to and away from, that the computer needs to perform operations on.
Since binary is for computers, and decimal is for humans, the most important root fact anyway, dealing with both of them means that you should deal with them one at a time, or convert them, entirely, one to the other. This is exactly what Java floating point does not do. It deliberately confuses the two, at the wrong time, with denormals and pronormals, at the last unit place in float and double decimal numbers, leading to what is accurately referred to as a 'floating point errors', even though no Java exception objects are thrown at the time.
When the Java switch statement was enhanced, so that programmers could immediately switch via a String, and could also coelesce switch options using the -> operator, there was no split in Java because of an incompatability. The fact that people had cause to learn something different and new about switch was no problem either. The two compatability options, one of which was a technical enhancement, only improved the circumstances for everyone; the programmers, users and vendors.
The BigInteger, BigDecimal, https://github.com/eobermuhlner big-math workarounds waste too much memory too much speed, both. The superior approach for floating point types, aside from problems with Arbitrary Precision on their own, is to just plain correct floating point errors by means of SSE hardware in the CPU floating point unit, the Maths Co-Processor, which almost all PCS have these days, at the point of 2022; in fact they have successors past SSE, since SSE itself is all the way up to version 4.2.
The thing with a patch is that it is not the main stream, the primary product. People have the specific option to include one or not. Who could want or need a denormal or pronormal value, exactedly? Any speed difference between accurate or innacurate is negligible because of SSE and similar anyway. Why should all ubiquity Java Developers have no broader choice about how they react about an incomplete, therefore incorrect and flawed standard, and implementation? Present workarounds are only that, workarounds; while within float and double ranges, these workarounds are even slower and larger in RAM than needs be. A patch can leave the writing or reading or exchange of float and double between Java code spaces exactly the same, or enhanced, providing complete choice between two Java floating point operation modes.
Most importantly, what should happen about floating point error correction should Oracle, OpenJDK, JCP et al, the ideal points for improvement on FP errors, never listen, and persist in leaving these errors and program operations problem intact? Surely it would be better for a downstream vendor to offer a patch for the problem, which is lower, even really no risk and apart from their mainstream OpenJDK and Open JRE, than this error problem remain ongoing and neglected in place, with its present crazy consequences, forever.
If these are the needs and the circumstances, Corretto should still consider a special Floating Point patch for Corretto Java, despites everything so far?
AWS OFFICIALUpdated 2 years ago
