OpenJDK or SE Java Floating Point Options?

[sminervini.prism]

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 zjx001202 at gmail.com
>
> To: "sminervini.prism" sminervini.prism at protonmail.com
>
> Cc: "core-libs-dev at openjdk.java.net" core-libs-dev at openjdk.java.net
>
> Subject: Re: OpenJDK or SE Java Floating Point Options?
> Message-ID:
> CAJL5A3nhQOjuH2kktQrEugqxgHHzM=HCH946XP02GZkmDmKmgg at 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++.