A proposal for RealJava

[Jerome T. Coonen]

David Chase wrote, re. the recent RealJava proposal:

 >> <...many detailed comments about IEEE rounding modes and
 >> exceptions at the language level...>
 >> 
 >> But basically, no, I do not like this proposal (that includes the
parts
 >> I did not comment on, fused operations and extended
representations).
 >> As an implementor, it only adds more work (I've still got to do all
 >> that tricky slow stuff to get it right for Pure Java) and will only
 >> fragment the market, and subvert write-once-run-anywhere. 
 >> 
 >> Enquiring minds want to know:
 >> 
 >>   what is wrong with C++?
 >>   what is wrong with Fortran?
 >>   why not just let Java be what it was intended to be?
 >> 
 >> There are other choices that probably have everything that you want
 >> except for Java's bandwagon -- Modula-3, for instance, has garbage
 >> collection, "objects", generics, better array support than Java,
 >> and it has a generally available "standard interface" that provides
 >> IEEE support pretty much like what was described in Jerome Coonen's
 >> proposal.

David,

Thanks for your comments.

I would respond, briefly, by referring to the desiderata stated at
the start of the document.  The point is to get

 * decent expression evaluation across all platforms, and
 * minimal IEEE-754 conformance

It doesn't seem like much to ask, and for some programs it buys a
lot.  I packaged the proposal as a superset of Pure Java and with
minimal language impact because even discussing changes to Java
is such a delicate topic.

The library-function interface to the IEEE modes and flags is
drawn directly from C9x and other prior practice.  I'm not
opposed to constructs tied more tightly to Java syntax.

Although you didn't say this, one should not construe the
RealJava proposal as an attempt to create the numerical
programmer's paradise.  It's merely one way to make "Java"
commercially viable.

Here's another alternative: PDP-Java on Pentiums, in which the fpu
is set to round results to 53 bits, the registers are treated
as doubles, and all evaluation is to double, a la the PDP-11.

PDP-Java is fast on Pentium and about as accurate as Pure Java,
but it introduces anomalies depending on whether intermediate
values spill from the registers; spilled values are stored as
doubles, so they lose extended range.  As one of a host of
examples, an expression like

   z = (x*y) / (x*y);

can lead to zero, one, infinity, or NaN, depending on x, y,
and which products spill.  PDP-Java is fast, usually
accurate, and in most respects not far from Pure Java, but
it's so anomalous that it's no step forward.

The demand for speed is so great that it's difficult to believe
that vendors of platforms with extended intermediates or fused
mul-add won't be forced to implement one or another impure
"Java" to exploit the capabilities of their platform.
I wrote the RealJava proposal in the belief that the
performance penalties of Pure Java are too onerous and
that a design offering fast, portable code with essential IEEE
features is a better choice than lower-overhead schemes like 
PDP-Java.

-Jerome Coonen