To core-libs-dev@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?
