[E-Lang] Operators #2: Comparison

[Mark S. Miller]

At 03:23 PM Tuesday 4/10/01, Karp, Alan wrote:
>Mark Miller wrote:
>
>> Is there any way in standard pure Java to control the rounding mode?
>
>Beats me, but then again, I learned Java after I stopped doing scientific
>computing.

Given some of the techniques you invented or used, it sounds like, if you 
hadn't, you would eventually have given up on either Java or scientific 
computing anyway. ;)

I know that Java floating point as evolved some recently.  I'm only 
confident of my comments below for Java < 1.2, but I think they still hold.


At 02:33 PM Tuesday 4/10/01, Karp, Alan wrote:
>[...] People
>who want exceptions can use signalling NaNs, SNaNs.

Signaling NaNs are unavailable in Java.


>Silently propagating QNaNs (quiet, as opposed to SNaNs) allows more
>efficient programs to be written.  Take the simple case of finding the norm
>of a vector.
>
>        s = 0.0;
>        for (i=0; i<N; i++) s += v[i]*v[i];
>        s = sqrt(s);
>
>[...] go through the loop and check s==s at the end to see if there was a
>problem.  If s!=s, I go back and do things the slow way. 

Should be fine in Java as well.


>There are also rules for propagating NaNs.  For example, A+B returns A if
>both A and B are NaNs.  That means a programmer can encode debugging info
>into the mantissa field of a NaN and count on it surviving a sequence of
>operations.  This feature is important enough that I have a patent on how to
>do it with software quad precision.

A patent eh?  Sounds like another good reason to avoid quad precision.

In any case, for each precision, Java only has one NaN, so there's no where 
to put this debugging info.


>The bottom line is that E should follow the IEEE standard exactly.  A lot of
>very smart people worked on it for a long time.  Each feature is there for a
>very good reason, even if no one person understands them all (except for Vel
>Kahan, of course).

Again, we can only support that subset of IEEE supported by Java.  Further, 
for purposes of portable deterministic replay, we only support the 
deterministic subset, which means the Java code implementing E's arithmetic 
must use the strictfp keyword.


>Dean Tribble also wrote: 
>
>> The third is the use of float64 at all, when lots of graphics, etc, 
>> profitably use float32.  
>
>Scientific calculations need float64, so you can't ignore it.  Besides,
>modern machines all do 64-bit ops as fast as 32-bit ops.  Even intrinsic
>libraries are only 10-20% slower on 64-bit numbers.  However, you don't want
>to leave out 32-bit floats.  In addition to memory considerations, there are
>special architecture features.  The iA64 (aka Itanium) has parallel floating
>point ops that let you operate in parallel on 2 float32s in a single, 64-bit
>floating point register.  

E currently leaves out 32 bit floats.  This does not seem a compelling 
reason for introducing them, and having yet another primitive scalar type.

E also leaves out 128 bit floats, as does Java.


        Cheers,
        --MarkM