Java numerics issue

[James Gosling]

As the guy who wrote the original Java compiler and runtime, I made
all the early decisions, so I suppose I ought to jump into this debate.

For the issue that Coonen raised, about exact behaviour and extended
precision, it's really an issue of point-of-view and priority.  The
point of view in his paper was essentially:
	Make this program as fast and accurate as possible
	on the box in front of me.
The point of view that drove the design of Java was:
	Maximize correct program behaviour on a broad spectrum
	of machines where the application writer doesn't know
	what those machines are.
Fast and accurate were important too, but not as important as knowing
that if my program works on the machine in front of me, it works on all
others.  We aren't as perfect in this as I would like to be, but allowing
non-deterministic use of things like fused-multiply-add would make it
worse.  Exploiting FMA via an explicit method call (which could be
optimized away) would be perfectly OK, however.

The suggestion was made that the Java FP semantics were driven by some
need to promote SPARC chips.  This is nuts.  Java started out being designed
for embedded systems and consumer electronics.  The chips I was concerned
with at the time were ARM, M32, SH-n, 68K and several others.  SPARC was *not*
on the list because it's *way* too expensive.  Outside of the computer
mainstream there are a lot of CPU architectures in use -- it's this mind
boggling list that made portability concerns so important.

> >    I've been curious to know why complex numbers were left out
> >of Java.  Since there is no operator overloading the syntax for
> >working with, for example, objects of type ZDouble will be pretty
> >ugly.

As Arthur said, simplicity was a big driver in leaving complex numbers
out.  Another, about as important, was that we just didn't need them.
Java's design target wasn't people doing serious numerical work.

These reasons aside, there are other problems with doing complex numbers.

There are other data types that, in other fields, are at least as important
as complex numbers.  One of my favorites is 3D graphics where points and
transformation matricies are what matter.  Doing something special in the
language for just complex numbers would be wrong: it needs to be generally
extensible.  This is what classes are for, and how complex numbers are
done in languages like C++. Performance, however, often suffers.  Guy Steele
has a proposal for something he calls "tuples" that
are a simpler and faster alternative to classes that work for small objects.

Operator overloading got left out, as Arthur said, for simplicity.  It's
also a feature that is often abused.  About the only reasonable use I've
seen for it is things like complex numbers.  There are a couple of other
reasons that matter to me personally: there's only a small number of operators
available for overloading (what do you do about dot and cross product?  Which
gets to use '*'?); and even when you use them, math is still ugly and
incomprehensible.  I think the real answer to this is in tools.  I've attached
a screen shot from an editor I've been working on occasionally that allows
you to define the visual representation of program fragments in a really
general way: sqrt(pow(x,2)+pow(y,2)) looks right!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/x-sun-tiff-file
Size: 12994 bytes
Desc: tiff-file
Url : http://mailman.oakapple.net/pipermail/numeric-interest/attachments/19970131/f9cebb12/attachment.bin