core-libs-dev Digest, Vol 131, Issue 26

[A Z]

-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).