Comments on Java Numerics

[Bill Joy]

David G. Hough at validgh wrote:
> 
> Java doesn't allow VAX, IBM 370, or Cray floating-point formats; Java
> implementations on those systems must emulate IEEE 754 single and double
> precision.     Java's insistence on a single expression evaluation model means
> that systems that are intended only to execute Java will not support other
> kinds of expression evaluation, but there are numerous other languages -
> namely almost every other language - available for that purpose.
> 
> 
> *** What Java needs
> 
>      The next few paragraphs describe some extensions to Java that would make
> it a better language for scientific computing.  For all I know, some of these
> may be planned for future releases.
> 
> Operator extension to user-defined types
> 
>      Java's definers wisely defined only a few numerical types as primitive in
> the language, and excluded operator overloading, a technique available in some
> languages that can be used to redefine the meaning of integer addition, for
> instance. I sympathize with that exclusion.  Not so wisely, though, there is
> no operator notation extension to cover necessary user-defined types, such as
> complex, interval, or extended precision, not to mention complex extended
> intervals.    Thus adding numerical types to Java by class definitions is
> either unduly burdensome to users, because every operator becomes a function
> invocation, or programs require a source code preprocessor of the style
> popular in Fortran circles twenty years ago - with the result that the code
> executed by the interpreter or examined by a debugger does not resemble the
> source code used by the programmer.

We have considered whether to allow these extended numeric types to be
defined
and hooked to infix operators, without fully going to operator
overloading.
For example, a class could declare that it implemented a certain magic
interface
that hooked it to the operators.  It would make sense to consider a
facility
like this while considering parameterized types, which seem to be
required to
support naive versions of this that I have looked at.

> IEEE 754 Exceptions
> 
>      Java recognizes certain exceptions such as integer overflow, but doesn't
> recognize the five IEEE 754 exceptions.    These are essential to building
> robust fast programs.    The minimum useful support is to detect specified
> exceptions when they arise in basic blocks of code and take alternate action
> if they do.    By not specifying how much of the protected block is executed
> when an exception is detected, the definition would permit implementations to
> use flags or traps and to optimize within blocks fairly freely.    There would
> be discernible differences in implementations that examined side effects
> produced by basic blocks whose partial execution was interrupted by an
> exception, but such programs could be deemed illegal Java.
> 
>      Unmentioned exceptions would produce IEEE 754 nonstop defaults as at
> present.    Handling exceptions arising in external functions would require
> more infrastructure since the external functions might be separately compiled
> and thus would have to be careful about preserving flags or traps.
> 
>      Exception handling that protects only basic blocks is quite a bit less
> than IEEE 754 requires and recommends, but it should suffice for many
> applications.

I would support exception handling, provided it was "well bracketed", in
a statement
like "try", i.e.
	try enabling FloatingPointOverflow {
		// code where overflow enabled
	} catch {
		...
	}
where you would be required to catch the exceptions you enable, and they
would be enabled
only in the code that is marked as enabled, e.g. not in methods called
by
this try statement.

> Undefined areas
> 
>      If the elementary transcendental functions in class math do not have a
> published reference implementation yet, then their implementation currently
> depends on good taste.   It would be better to have a reference implementation
> such as a translation of fdlibm. In some ways a correctly-rounded reference
> implementation would be even better, but such an implementation based only on
> high-precision software arithmetic would be very slow, and one based on large
> tables would be unsuitable for the embedded applications for which Java was
> first designed; these points might be overlooked if good public
> implementations of correctly-rounded transcendental functions were available,
> but that has not happened yet.

Guy looked closely at this; we decided not to do the definition that
required huge
tables, not only because the tables were very large but also because the
performance
is unpredictable...  They are defined with reference to a standard C
implementation
(the spec gives the exact reference) whose source is widely available.
We expect that fully accurate versions would be provided in another java
package
rather than being required in every implementation by being part of
java.lang.

> 
>      Java conversions from binary floating-point to decimal string
> representations are intended to be correctly rounded but are somewhat limited
> in releases so far.    Correctly-rounded base conversion is an important
> aspect of portable identical results.

I asked Richard Tuck (in 95) to adapt the exact input and output
routines which
had previously been implemented, e.g. in Lisp.  I believe the current
state
is that the specification is of these routines, but whether they are
released
yet or not I do not know.


Guy is the lead on these issues among the three of us.
I hope he weighs in more, just thought I'd pass this early stuff along.

Thanks for the careful explanation of the issues as you see them.
What we wanted with Java is that you could write a numeric program
and send it to someone else after testing it and know it would behave,
for them, the same way it behaved for you.  Otherwise there is no way
to ever finish "testing" a program.  The ability to write once and test
once
and have confidence everywhere is the KEY idea of Java...

	Regards,
		Bill Joy