Java floating point and StrictMath improvement?

[Raffaello Giulietti]

"Computer scientists of the world, unite!

Let's get rid of binary floating-point arithmetic in Java, after 27 
years of honorable service!

Let's adopt decimal floating-point arithmetic, where 1 / 3 + 1 / 3 is 
still different from 2 / 3, but who cares? At least we have 0.1 * 0.1 = 
0.01, as Mathematics commands!"


Just kidding...
More seriously, let's stop this useless discussion.


Raffaello




On 2022-03-16 06:47, A Z wrote:
> To core-libs-dev at openjdk.java.net,
> 
> 
> float and double should be mutually enhanced or
> 
> defaultedly changed, to uphold the following three
> 
> properties:
> 
> 
> 1) Base ten arithmetic on float and double, via operators.
> 
> 2) Base Ten elementary function calls, like
> 
> those made on java.lang.StrictMath,
> 
> on double or float values.
> 
> 3) Base ten Comparison operators. ==, !=, >, <, >=,<=.
> 
> 
> 
> Martin has said:
> 
> 
> 'It is inherently, mathematically *impossible* to emulate decimal
> 
> behaviour with binary IEEE 754 arithmetic. That's why Java also
> 
> offers java.math.BigDecimal, a decimal floating-point library
> 
> implemented in software.'
> 
> 
> Then don't use IEEE 754 alone! Or, have a dual mode, with an
> 
> active alternative. There are binary alternatives, particularly
> 
> that include the likes of SSE, that in fact can.
> 
> 
> The only standards necessary, and really, the 'authoritative standard',
> 
> are those prevalent in mathematics itself. Base 10 arithmetic, algebra,
> 
> elementary functions, range limited real values.
> 
> 
> BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math,
> 
> with its calculator class, take up more room in memory than necessary.
> 
> They are slower, and they do not allow for the use of operators.
> 
> Worse yet, they are not immediately reified in the rest of the language,
> 
> ie all class and interface libraries.
> 
> 
> Raffaello has said:
> 
> 'Exact representation of 0.1 using base 2 is mathematically impossible,
> 
> no matter the language (it is a periodic number in base 2).'
> 
> 
> Consideration of the article:
> 
> https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf
> 
> 
> Which is admittedly older, but still accurate, indicates otherwise.
> 
> 
> I contend that within an upper and lower range, that it is possible.
> 
> While C++ can't use the immediate ==, !=, >,<,>=,<= operators
> 
> immediately accurately, Java has.
> 
> 
> Using 32 or 64 bit buffers, and an SSE or similar buffer, and the
> 
> right algorithms, unto limited range, you can have as much of
> 
> a range representation as required for float or double, even
> 
> though you ultimately don't have 'exact' representation.
> 
> 
> Bernd Eckenfels has said:
> 
> 'The need to round floating point numbers for commercial math
> 
> (and the risk involved in doing so) is nothing new, it predates
> 
> the IEEE standard and should be subject for even basic comp
> 
> sci curriculums all over the world.'
> 
> 
> That is true, but it is the case that range termination
> 
> of decimal values, by means of truncation, is more accurate
> 
> than this. By any processing of rounding, you start gaining
> 
> inaccuracy, which can grow and grow and overpopulate the
> 
> entire number. In Computer Programming, you can need range
> 
> continuous range accuracy. Such as with 2D and 3D processing.
> 
> The present Java approach is slower and a waste of memory.
> 
> 
> Given all this, and given that humans, and representations
> 
> of the real world rely on base 10 first, shouldn't the 3
> 
> properties I outlined at the beginning of my post be
> 
> at least mutually, compatibly, instituted in Java,
> 
> if not defaultedly?
>