>> May the Java Community Process reconsider the present floating point >> operations [...]?
Over the past several weeks, this community has unanimously replied to your concerns with a clear: "No thanks, for the next decades we aren't interested in changing the current semantics of floating-point arithmetic in Java." The good news for you: you don't need to spend even more of your time on this mailing list, trying to convince this reluctant community. From: core-libs-dev <core-libs-dev-r...@openjdk.java.net> on behalf of sminervini.prism <sminervini.pr...@protonmail.com> Date: Monday, 02 May 2022 at 08:58 To: core-libs-dev@openjdk.java.net <core-libs-dev@openjdk.java.net> Subject: OpenJDK or SE Java Floating Point Options? To core-libs-dev, and Glavo, this inner nature of C++, simply means that the floating point equation can be altered in the decimal direction; the beginning of value degredation could be altered in the equation to be entirely outside number type's the range. C++'s "apparent floating point" and SSE, and SSE descendents, are still a solution to look for which I suggest to OpenJDK and JCP. It is still the case that I and others need Java floating point and StrictMath (the key double type calculator class) to be repaired of their denormal and pronormal errors and the circumstances creating such. Such repair is possible, using an SSE oriented approach, while maintaining the current ranges of float and double. Their ranges seem to be: float: from 1.40129846432481707e-45 to 3.40282346638528860e+38 (positive or negative). double: from 4.94065645841246544e-324d to 1.79769313486231570e+308d (positive or negative). As I attempted to submit in my previous message to core-libs-dev, IEEE 754 is silent on pertinent matters around floating point arithmetic, mainly certain end facts concluding binary and decimal use in computer software; the need to have range objectivity. The proper precedent to draw from is not a standard with a small "blind spot", due to reciprocal exponential terms alone, but the phenomenon which simply states that both information and behaviour can be encoded into a computer, so that such a machine will behave by means of that information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans. Range any decimal mathematics, including floating point, should be for humans, and binary mathematics is for computers. Therefore, for any decimal result to have proper meaning, it must be entirely correct within its (rational, truncated) range. The most meaningfull thing to do, while creating the least number of language disturbances, is to utilise additional (SEE and similar) registers, with appropriate sub-java (implementation) code, to use all registry space, including the extra space if needed, to produce range accurate Java results via improved operational logic. It is known that having a little more registry space past the number (result range) limit, for use and consideration, is the only range, base-10 perfect way to go. It is certainly better than the available class approaches, which waste memory, speed, and lack important and appropriate auxiliary use options. It is also the case that asymptotic number generation from the floating point equation that Java uses can be offset to occur outside of the end point of the decimal values range end. May the Java Community Process reconsider the present floating point operations and method calls situation, based on an imperfect standard and improper operation improper and workarounds, and provide corrected, defaulting or specified compatible ways for Java floating point arithmetic and Calculator class method results to always cohere in their ranges, without denormal and pronormal inclusions whatsoever?
