-Whenever there there is an arithmetic continuing carry operation involving Java Float or Double, there can be an underflow or overflow.
This means that comparisons at the data level using >, ==,<,<=.>=, .equals(), etc. will begin to misbehave. Whatever the behind the scenes implementation, there must be at least both options; there should be a class level keyword to enfource accuracy mode floating point arithmetic. There needs to be an accurate arithmetic mode using these types, in order to best minimise memory and instructions usage in source code. Also, programmers should be free to use accuracy arithmetic with any of the decimal supporting number types, so that they can make their own decisions about choosing types to model and actuate all sorts of phenomena in their programs. There are also syntax advantages in programming this way, too. Every othermajor language allows a requisite option to turn off floating point overflow and underflow. Java needs to. Consider, then, statements in the following online paper: http://www.sonic.net/~jddarcy/Research/jgrande.pdf There also should be operator support for BigDecimal and BigInteger, as well as a StrictMath class that supports BigDecimal trigonometry, base 2, Euler's constant e, base 10 logarithms, powers, square, cube, nth root, computation of e and pi for arbitrarily specified numbers of places (all in terms of a BigDecimal or BigInteger specified number of places).
