On 4/20/22 10:15, sminervini.prism wrote:
> To the Java Community Process, and OpenJDK community,
>
> A number of us have been waiting on serious consideration for
apprehension of
>
> core-libs-dev Digest Vol 180 Issue 174 Topic 1
>
> since we have posted, but not received an addressal and apprehending
response
>
> in some time. We know that our posting comes soon after Easter.
Still, we have
>
> been wondering what the internal state of discussion is on the
aforementioned
>
> Topic 1, and are hoping that it can be apprehended, certainly in the
compatible
>
> manner it discusses, to gain the advantages discussed, while removing
>
> disadvantages and bringing on board no real disadvantages, for the
>
> Java OpenJDK and the Java Community at the more official level.
>
> We wait with bated breath for a reply in future core-libs-dev
>
> digests for a positive, active reply!
>
> Sent with [ProtonMail](https://protonmail.com/) secure email.
Heeeh???? I don't understand a single word.
What is this "core-libs-dev Digest Vol 180 Issue 174 Topic 1" stuff you
are talking about? It would help to refer to a concrete message instead
of some digest number.
The only thing I can remember is that you were spamming the list with at
least three identical postings which has been answered by Andrew right
after the first message already.
If this is what you're asking for, here is what he wrote:
On 4/16/22 09:04, sminervini.prism wrote:
> It is still the case that I and others need Java floating point and
StrictMath
> (the key double type calculator class) to be repaired.
If you are going to pursue this line of reasoning, you must be aware
of some things.
Firstly, it is not possible to change Java's core floating-point
arithmetic in a compatible way. We certainly will not adopt decimal
floating-point for Java's core arithmetic.
Secondly, Java should not be your focus. We will not change Java's
arithmetic in a way that is incompatible with other languages or
which makes Java slower on existing hardware.
You must read and fully understand this before you go any further. It
will require a lot of study:
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
> 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?
In a word, no. That possibility is so unlikely that it is not worthy
of consideration.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
