Subject: Specifications for java.lang.Math

From: John Brophy <[email-masked]>
Date: Fri, 14 Aug 1998 12:07:27 -0500

In Sun's latest JDK 1.2beta4 in the documentation for java.lang.Math
there is the following statement:

"To help ensure portability of Java programs, the definitions of many of
the numeric functions in this package require that they produce the same
results as certain published algorithms. These algorithms are available
from the well-known network library netlib as the package "Freely
Distributable Math Library" (fdlibm). These algorithms, which are
written in the C programming language, are then to be understood as
executed with all floating-point operations following the rules of Java
floating-point arithmetic. "
	
This would seem to imply that all implementations of Java must return
the same (bit-identical) values
on all platforms. That is clearly unrealistic.

A more realistic standard would be the requirement that the functions in
java.lang.Math meet the
requirements of C9x. For example, C9x requires that for the function
sin(x) 
		sin(+0) = +0
		sin(-0) = -0
		sin( +/- infinity) = NaN and raises the invalid
exception.

We may also want to add other conditions, such as

1)	| sin(x) | <= 1 for all finite x.
This implies that sin(x) always returns a finite value (not a NaN) even
for very large |x|.

2) 	For each finite x there exists an x* such that |x-x*| <= eps*|x|
and sin(x)=Sin(x*), where
Sin(x) is the mathematically exact version of the approximate sin(x).

	In Sun's JDK 1.1.6 for Windows NT there are a number of places
where these conditions
are violated. For example,  sin(1e300) returns 1e300 and exp(-infinity)
returns NaN not 0.
Micosoft's JDK 1.1 has a slightly different list of problems.

	These problems have been fixed in Sun's latest JDK 1.2beta4, but
there are a few new cases
that are incorrect on WindowsNT. Specifically, sqrt(-infinity) returns
+infinity instead of NaN and 
all of the following return 0 instead of NaN: sin(+-infinity),
cos(+-infinity), tan(+-infinity), tan(NaN)
and pow(+-1,+-infinity). 

These differences all seem to be bugs due to over-optimization of the
fdlibm C code.
The comments in fdlibm imply that they should return the results that
C9x would require.
I have reported this as a bug to Sun at http://developer.javasoft.com.

	I would propose that Sun adopt an explicit set of criterion for
java.lang.Math along the lines of
C9x to replace the implied requirement that all JVMs exactly match
fdlibm. It would also be good
if tests of these requirements were part of Sun's test suite to be run
before release of an JVM.

	This proposal also affects the exception flag proposal, since
computing the sin(infinity) would 
require that the invalid exception flag be set.

					John Brophy
					Visual Numerics
					[email-masked]

---

From: [email-masked]
Date: Fri, 14 Aug 1998 13:31:39 -0400

A proposal is currently been discussed to change the definition of the math
library so as to require correct rounding: the library will return the
result that would obtain by nearest rounding of the result computed with
infinite precision.  It seems feasible to have an efficient
(multiprecision) implementation of the math functions to fulfil this
condition.  If reasonable performance can be achieved this way, then this
is the obvious "right" definition.  Otherwise, one would have to go the way
you propose, and specify the math lib behavior in terms of a bound on the
error, and aset of suitable algebraic conditions.  In fact, one can pursue
both ways, and have a library that provides strict reproducibility, at some
performance expense, and a library that provides more performance at the
expense of strict bit by bit reproducibility.  It is correct that many
current Java implementations violates the current specification of
java.lang.Math

Marc Snir, Senior Manager
Scalable Parallel Systems
Tel: 914-945-3204 (8-862-3204)
Fax: 914-945-4425 (8-862-4425)
URL: http://www.research.ibm.com/people/s/snir

---

From: Michael Tobis <[email-masked]>
Date: Tue, 18 Aug 1998 15:05:50 -0500

Marc Snir wrote (excerpt):

>  In fact, one can pursue
>expense of strict bit by bit reproducibility.

I'd like to point out that this suggestion generalizes, and would
provide an enormous benefit for an environment that generally
offerred a compile-time switch between "Strict" and "Efficient"
modes, the former being of benefit to development and the
latter to production.

A good deal of HPC effort goes into decomposing large problems
into multiple processes. Bitwise reproducibility offers a stringent
test of such decompositions. An instance might be an integral
over a field represented in many memory spaces. Achieving
bitwise reproducibility even under true Java reproducibility then
would require that sums be taken in a particular sequence. This
would in general be inefficient, so even the "Strict" mode could
not be used to apply a bitwise reproducibiluty test to an efficiently
designed parallel scalable global calculation. 

A practical solution can be found in performing the intermediate
arithmetic calculations at a higher precision. This may not satisfy
purists, since some enormous number of calculations might still
cause rounding problems, but in practice this is unlikely. From
the developer's point of view this would amount to specifying some
set of calculations as "Extremely Strict" or "Fanatical" for the development 
phase. From the point of view of language design this would require 
providing a high precision float and a complete set of strict math routines 
on them. This sounds like a big request but I suspect the payoff for the 
development phase in multi-threaded computations would be considerable. 

On the other hand, going to a lot of trouble to provide "strict" 
mathematics without support for easy invocation/suppression
of extra precision mathematics has relatively limited value for
the sorts of situations I'm familiar with. It's certainly possible
that I'm missing something.

I'm sure we all agree that in computation bound applications reproducibility
is relatively less important than efficiency. If an easy way to declare
computations within some scope as high precision is offerred, though,
reproducibility can be used in service of efficiency.
mt
--
Michael Tobis
Division of Mathematics and Computer Science
Building 221 - Argonne National Laboratory
9700 S Cass Av
Argonne IL 60439

(630) 252 - 7908
[email-masked]