the truth about the LCAS

[jaffe]

I'd like to clear up a few misconceptions about the LCAS.

1. First, it's the implementation, not the program, that conforms or not to
the LCAS.

2. It's true that, in order to conform to the LCAS, the implementation must
provide a way of enabling the detection and reporting of integer overflows,
integer divide-by-zeros, floating overflows, floating divide-by-zeros,
and any other "invalid" or "undefined" floating point events.  This need
not be the only mode of operation offered by the implementation, nor even 
the default mode.  

For IEEE implementations, conforming to the LCAS means that there must be 
a way of enabling trapping for "invalid", "overflow", and "zerodivide", 
plus the integer faults (note that "integer" refers only to the integral 
types that correspond to LCAS integers, specifically, signed ints and 
signed longs).

Obviously, documentation on how to enable trapping is critical.

The point of this is to protect the programmer, at least during code
development.  Over the years, I've gotten many "divide by zero" errors.  
Nearly all of them were unexpected, and I was certainly glad to find out 
about them so I could fix my code.  I've never done serious software 
development using the IEEE defaults (NaNs and infinities), so I can't speak 
to how easy it would be to debug programs.  Also, I can't recall being 
bitten by undetected integer overflow, but I'm sure others can.

Once the program is off and running, it may be reasonable to disable 
trapping (especially integer overflows) because at this point the 
programmer is certain that nothing bad will happen now.  In fact, 
as Sam Figueroa points out, there may be a reasonable way to continue 
executing a particular program even after an infinity is generated.  
But the programmer must be very very sure of having anticipated all 
the (bad) possibilities.

2.  Another point of the LCAS is portability.  Lots of numeric programs are
written to run in multi-platform environments - workstations, plus maybe 
a VAX or Cyber, and time-sharing on a Cray.  If I want my code to run
everywhere, either I have to program very defensively to avoid, say,
overflows:
            if (x <= limit) {...}
             else { ...}
or else, if I code to the IEEE defaults, I'll also have to put in handlers 
for my non-IEEE machines in order to allow execution to continue almost
the way it would on an IEEE machine after the infinity was created:
     #ifdef IEEE  ...
     #else ifdef VAX ....
     #else ....

Many non-IEEE (and IEEE) implementations do provide handlers to allow the
program to continue to execute (somehow) after an error.  Again, note that
I really had better know just where the overflows, etc. can occur, and 
I'd better know what the "right thing to do" is if and when they happen.

3.  The only real conflict that I see between the LCAS and the current
ANSI C is in the definition of the error behavior of the <math.h> 
functions, e.g. sqrt.  The problem is that setting errno is too ephemeral 
and is not visible enough (and, let's be honest, how many of us always 
check errno after a call to sqrt?   <grin>).  The NCEG proposal to raise 
"invalid" and return a NaN on negative input to sqrt would allow sqrt(-4) 
to trap, so that IEEE+NCEG systems at least would conform to the LCAS.  
For non-IEEE systems, I'd like to see an error message before continuation 
(with 0.0 or whatever).

4.  By the way, one of the advantages of the LCAS is that it also requires
lots of information (documentation) to be provided - about the 
characteristics of the floating point arithmetic, how rounding is defined, 
how to change rounding modes, how to enable trapping, how to invoke the 
special LCAS functions that are not already in the language, etc.


If you'd like a hardcopy of the LCAS version 3.1, you can get in touch with
me or with any of the authors (see Fred Tydeman's posting).  A postscript
file is available via anonymous FTP from crl.dec.com  (file is 
pub/misc/lcas.ps).


          Martha Jaffe

   (new address)        Digital Equipment Corp.
                          mailstop ZKO 2-3/Q 08
                        110 Spit Brook Road    
                        Nashua NH
                        (603) 881 2384


  [ All opinions herein are mine - but then, they're so reasonable ...]