To core-libs-dev, and Glavo, given this inner nature of C++, which I had not seen, I do renege those code snippets.
It is still the case that I and others need Java floating point and StrictMath (the key double type calculator class) to be repaired. It has been made clear to us by a number of publicly available sources, irrespective of their age, from their date of publication and going forwards, that with registry additions already present in Java relevant hardware, being SSE and beyond, that repair can and must be wrought for Java float and double numeric types utilised in both Java SE and OpenJDK's runtime environments. This includes their present ranges, whenever arithmetic operations at all or certain method calls involving them are made, where the results manage to straddle the edge of those ranges. 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 decimal arithmetic, mainly certain end facts concluding that binary and decimal use in computer software need to have objectivity. The proper precedent to draw from is not a standard with a small "blind spot", but the phenomenon which simply states that both information and behaviour can be encoded into a computer, so that such a machine can behave by means of that information rapidly, consistently, and usefully (therefore meaningfully), to the advantage of humans. Range complete decimal mathematics is for humans, and binary mathematics is for computers. Therefore, for a decimal result to have proper meaning, it must be entirely correct within its (rational, truncated) range. The most efficient and only meaningful thing to do is to utilise additional (SEE and similar) registers, with appropriate sub-java 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. In recent times, it has been the case that there are upstream and downstream vendors of the OpenJDK. Discussions with them have proven impossible, since all of them only agree to conform and derive from whatever the OpenJDK and the JCP choose to do. 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? > Message: 2 > Date: Fri, 15 Apr 2022 13:37:03 +0800 > From: Glavo zjx001...@gmail.com > > To: "sminervini.prism" sminervini.pr...@protonmail.com > > Cc: "core-libs-dev@openjdk.java.net" core-libs-dev@openjdk.java.net > > Subject: Re: OpenJDK or SE Java Floating Point Options? > Message-ID: > CAJL5A3nhQOjuH2kktQrEugqxgHHzM=hch946xp02gzkmdmk...@mail.gmail.com > > Content-Type: text/plain; charset="UTF-8" > > Your code snippet C++ shows different results than Java, simply because > cout doesn't output full precision numbers. > > To see accurate results in C++, add this line of code at the beginning of > the main function (need to import header file `iomanip`): > > std::cout << std::setprecision(20); > > > After this, you can see the correct value of floating point numbers in C++.
