Java Floating Points.

[Joseph D. Darcy]

In the spirit of repeating previous messages, I again refer interested 
readers to my 2018 email to core-libs-dev which addresses many of the 
technical points being (re)raised here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html

Appeal to authority is a commonly used rhetorical technique. A worse 
variant of appeal to authority is when the work being cited does not in 
fact support the argument being put forward. Case point, the document

     "How Java’s Floating-Point Hurts Everyone Everywhere"
     https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf

originally authored by Prof. Kahan and myself in 1998, does not advocate 
decimal-only computation. The word "decimal" appears exactly zero times 
in the July 30, 2004 version of the document (Prof. Kahan often revises 
and reposts his documents).

In brief, the thesis of the "JavaHURT" paper is that the Java platform 
commits sins of omission by requiring IEEE 754 arithmetic while 
forbidding certain mandatory feature of the IEEE 754 standard and by 
precluding support for the 80-bit floating-point format found on 
contemporary x86 processors. Moral conclusions aside, it is correct that 
the Java platform then, as now, does not natively support those 
mandatory features of IEEE 754 (rounding modes, floating-point exception 
handling) for the built-in floating-point types float and double. No 
other widely used and available programming platform I know of supports 
those features either. In the intervening years, the 80-bit format 
originating with the x87 co-processor has been effectively deprecated by 
both Intel and AMD.

While IEEE 754 is commonly thought of as a hardware standard, the 
designers of the standard intended it to provide a programming platform. 
More recent revisions of IEEE 754 have tried to make this intention clearer.

Without researching the exact JDK where SSE support was first included, 
it was would have been at least 15 years ago, probably more.

The SSE instructions do *not* support decimal floating-point 
computation; they are primarily, but not exclusively, about 32-bit and 
64-bit binary floating-point operations:

     https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions

The POWER6 chip is one of the few that does have hardware support for 
decimal floating-point, a feature added in the 2008 revision of IEEE 754:

     https://en.wikipedia.org/wiki/Decimal_floating_point

Rather than re-asking core-libs-dev every few days if the the platform 
stewards have suddenly decided to undertake this large, but poorly 
defined effort, I suggest trying you organize like minded parties, 
perhaps including A Z poweruserm at live.com.au, to yourselves build a 
library/environment/platform with the features you envision to 
concretely demonstrate its benefits.

-Joe

On 4/21/2022 11:55 PM, sminervini.prism wrote:
> mailto:core-libs-deb at openjdk.net
> To core-libs, OpenJDK, JCP, and all
>
> For the sake of the consequences of the real issues it raises,
> I include the rebuttal to Andrew Haley's earlier comments,
> and I reiterate that the real need is to improve the Java software
> at its roots level, more so.
>
> Andrew Haley said, and we reply:
>
> 1) 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.
>
> While I don't like re-submitting this article, certainly not on this forum,
> there has always been this article:
>
> https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
>
> The age of this article does not matter. It is as bearing to action in 2022
> as it was then.
>
> -Even without recombiling floating point or StrictMath code, of course it could
> be changed, and compatibly. Runtime or compile time switches could be introduced.
> Key words could be introduced that may apply at many different levels. Maybe
> even annotations could be used for the compiler, which can already apply at
> any point that floating point arithmetic and StrictMath methods and fields
> may occur. Whevever there is a code space, there could be an annotation
> or a keyword. At the class or interface or static block level. At the
> variable, data, field and method level. Even at the main method,
> Thread level, Runnable or Future level, or even further.
>
> 2) 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.
>
> -There could be dual mode floating point correction, implemented inside
> Java at any level you could like. Dual mode couldn't be incompatible
> with anything.
>
> 3) 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.
>
> -IEEE 754 has a blind spot, an oversight error. It says nothing about
> operation values that straddle the range of the arithmetic or method result,
> partway in, partway out. BigInteger, BigDecimal, or the big-math library
> at https://github.com/eobermuhlner/big-math are only temporary stop-gap measures
> that are two large in memory, more than needed, and too slow. The article included
> as part of 3) doesn't even mention SSE, the presence of end of range
> carrying additional bits.
>
> Speed at the expense of accurary, ie. providing a rapid falsehood, is also a
> logic error that can compromise the entire enterprise of computer software
> itself. What is required is the inclusion of SSE additional registers and their
> use; just a little bit of extra registry space to handle range end carries if they occur.
>
> We wish to appeal to reason and software needs on this subject, if not the odds!
>
> A mechanical clock is really amazing because it is complex, and because all the pieces whizz around together at amazing speed, but because it maintains those earlier two
> properties while maintaining accurate time. The clock loses usefulness,
> and even any usefulness, if the accurate time can't be set or maintained,
> at the rate it needs to operate at.
>
> The fact that more registers are referred to, to uphold float and double, has not been
> enough of a speed compromise to prevent 128 bit numbers elsewhere.
> Besides, the emptiness of extra bits past the range limit of float and double
> could be optimised and controlled by one flag bit.
>
> When the enhancements to the switch statements came along, all previous options were
> maintained, while including, even integrating, the new ones: the abbility to switch on String, and the ability to coelesce cases in any way. There ended up being no kind of ultimate problem, no matter which developers used which approach for accurate, logic correct software. Whatever approach is taken, floating point correction need be no better, and offers in-place advantages. And the present state of floating point is a logic error, with IEEE 754 on this precise point being silent, incorrect, and irrelevant.
>
> Is there someone else involved in core-libs-dev at openjdk.java.net, or the JCP,
> who can give a more particular response to this issue via the points raised here,
> and engender change to the attitudes to floating point arithmetic and
> floating point elementary functions, so that release versions of Java SE and
> OpenJDK can include FP error correction in this Java domain?
>
> Sergio MinerviniS.M.
>
> Sent with [ProtonMail](https://protonmail.com/) secure email.