Language Independent Arithmetic or Licensed Inadequate Arithmetic?

[David Hough]

> While I am prepared to believe that the IEEE 754 standard was originally
> a crusade founded on technical virtue, the assumption that the LIA is a 
> counter-crusade marshaled by the forces of DEC-the-Infidel is not only 
> unwarranted, it is simply false.

True or false it may be, but the only apparent potential 
economic beneficiaries of LIA in its present form
are DEC and IBM, and as far as I know IBM has expressed disinterest or
opposition to LIA.
I asked software providers on this list to so identify themselves if they
anticipated any significant economic benefit from LIA; so far none have.
But I don't think LIA will do a thing even for DEC.   That's because people
who still run VAX/VMS will probably do so for as long as DEC supports it,
but making it a standard won't induce anybody else to migrate to it
who is interested in scientific computation.
The harm in LIA if adopted in its present form
will be to legitimize substandard IEEE 754 implementations such as are
common in the PC world, which if widespread enough would undermine the
benefits of standard IEEE 754 implementations.   I have no idea whether this
is an intentional or accidental consequence, but it is surely of greater
import than any imagined direct benefit to DEC.

There are two aspects of LIA that have been unnecessarily intertwined;
one is a specification ultimately for arithmetic hardware, and the other
is a specification for language standards to document how they relate to
computer arithmetic.

The arithmetic hardware specification is the problem.
It serves no useful purpose to anybody and it must be removed.
It does not encompass IEEE 754; it is directly antithetic.
Bad money drives out good.

The arithmetic 
documentation specification for language standards is more salvageable
although any economic benefit will be long delayed until various language
standards are revised to meet the arithmetic documentation standard.

> It was the perception of the UK National 
> Physical Laboratory, supported by similar views at NIST and several major 
> computer manufacturers, that the specification of the required characteristics
> of arithmetic in programming language standards is execrable.  The adoption 
> of IEEE 754, in various precisions and implementations, by a segment of the 
> computer producer community has improved the predictability of numerical 
> results, but not in two important ways:
>     1.  There is no standard which permits the programmer to obtain
> the values of parameters which meaningfully describe the characteristics
> of a given arithmetic implementation, whether or not it conforms to 
> IEEE 754.  This lack of specification has led to trick software which attempts
> to determine those values by curious expressions whose utility is dependent
> on the compiler performing exactly the floating arithmetic operations the
> author had in mind.  This in turn has led to countless meaningless
> debates in the numerical analysis community over what expressions can be
> optimized or reordered by compilers and whether computation at precisions
> greater than that apparently specified is permitted.

Some of this is true, and relevant to the documentation aspect of LIA, 
although LIA won't solve the described problem, which is to make existing
software work with new hardware and compilers. 

>     2.  The average user, which includes most scientists and engineers, is
> often unable to obtain any indication that an arithmetic error has occurred
> during a computation, without sophisticated use of the exceptional-values
> provided by IEEE 754 or their equivalents, supported, if at all, by extensions
> to the standard programming languages.  This lack of notification has
> resulted in the publication of erroneous scientific results, through no
> obvious fault of the scientist involved.

The most common cause of erroneous results is roundoff, which LIA exacerbates
by legitimizing implementations which omit directed rounding modes
and the inexact flag.
Better quality IEEE implementations have followed the advice freely offered
since 1978 and provided retrospective diagnostics about standing exceptions,
such as Sun Fortran users get.   If anybody had been able to think of a 
reasonable way to standardize a requirement to deliver such retrospective
diagnostics, it would have been incorporated into 754.

Sun gets complaints asking how to turn off
the messages that make the users uncomfortable with their results.   I suppose
other IEEE vendors get complaints from even more uncomfortable users who have
had to retract erroneous results obtained from porting non-IEEE codes
blindly to IEEE systems.   Again, LIA won't do a thing to help port existing
codes.

Better quality IEEE implementations that
seek to attract the remaining VAX/VMS scientific computation installed
base might do as Sun Fortran does by providing a (correctly identified) -fnonstd
option that provides non-standard arithmetic (abrupt underflow, traps on
overflow, division by zero, and invalid).    That didn't need a standard, just
the normal working of the competitive market place.

> No one has yet presented evidence that the promulgation of the IEEE 754 
> standard has improved the quality of numerical SOFTWARE, in programs 
> conforming strictly to ISO programming language standards.

Programs that conform "strictly" to existing programming language standards
can't depend in any way on any feature of IEEE 754 or any other arithmetic
system.

However since propagation of IEEE 754 it is now possible in principle
to write better, more robust software, that is widely transportable to PC's
and workstations, indeed almost all computers in the world.   
It's not literally portable because the methods for accessing IEEE 754 features
vary among systems.  The NCEG IEEE extensions will take care of that for C. 

> The objective of
> the LIA IS to improve the quality of numerical software by improving the
> programming language standards, and the compiler/library implementations 
> thereof, with respect to arithmetic.

Then why constrain machine arithmetic in LIA?
Especially when the apparent constraint is actually a kind of license to
unconstrain sort-of-IEEE implementations. 
Instead, LIA can perform a useful purpose if it
provides a means for the program to
find out about the arithmetic at run time, of whatever kind it may be,
so that the program can adapt if it so chooses,
even to Crays or sort-of-IEEE implementations.