Java float, double, StrictMath correction?

[A Z]

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?