Can you please post using appropriate subject lines, and formatting and
follow basic email etiquette - which includes identifying yourself.
You are quoting 20 year old papers. The JavaGrande effort was born in
1998 and died a few years later.
On 7/03/2018 9:38 AM, A Z wrote:
-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
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:
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).