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

[David Holmes]

"A Z",

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.

David

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