Re: Optimizing IEEE Floating-Point Operations

In article 91-06-022, cfarnum@valhalla.cs.wright.edu (Charles Farnum) writes:
> There are many different mathematical systems. Some happen to have operators
> that are much easier to work with efficiently, or even effectively, than
> others. The IEEE standard is one such, and the best one available in the
                              ^^^^^^^^^^^^^
> eyes of most of the people who study such things. Keep in mind that Kahan's
> contributions to the standard helped win a Turing Award. And Kahan is *not*
> an ivory-tower academic; he is most emphatically interested in the real use
> of computers for number crunching.


You misunderstood my point. The IEEE standard is NOT a "mathematical
system", it is a method for _approximating_ mathematical operations. The
FORTRAN standard, however, refers to the mathematical system upon which
those approximations are based -- namely, the kind taught in mathematics
books. My point was that the FORTRAN standard says that the processor can
do any transformation that is mathematically equivalent to the original,
provided it doesn't violate parenthesization. The FORTRAN standard also
says that performing an operation that is NOT mathematically defined
renders a program non-standard conforming; in those circumstances, a
processor can do anything it wants.


So, the situation we have is that either a NaN or an INF represents a
failure of the machine to represent the result of an operation that has a
mathematically defined result, or it represents the result of an operation
that is not mathematically defined. From the FORTRAN standard's point of
view, transforming X*0 => 0 is perfectly valid.


> ]There may be applications where that view is incorrect, but so far we've
> ]not encountered them.
>
> There are many applications *in principle* where that view is incorrect.
> There are not many in practice because most computer scientists know very
> little about writing code that is robust in the presence of NaNs and INFs.
> This is primarily a problem of education, not of the difficulty of writing
> such code.


But the process of producing commercial compilers is one of practicality, not
principle. We do what most pleases the majority of our customers. In our
case, this means getting the most performance available from the machine.


> I would steer clear of compilers that make such transformations; performing
> algebraic manipulations valid in one mathematical system for some
> computations to be performed in another mathematical system is dangerous.
> Although I agree that they agree with the F77 standard (which is ambiguous on
> the point, hardly avoidable given the different mathematical systems in
> common use on computers in 1977), they can break well-written (i.e.,
> efficient, readable, and robust) code that makes use of the provisions of the
> IEEE standard.


It may be all those things, but portable it is not, because IEEE didn't
choose to address the issue of how to access the features of the standard
from any particular programming language. I would question, in fact, your
assertion that the code "makes use of the provisions of the IEEE standard".
What it actually does is assume a particular mapping of non-portable code to
the IEEE standard.


I would be among the first to welcome a standard for accessing IEEE 754
features from FORTRAN (or any other language), provided it was a well-written
standard and didn't conflict with the language standard. Until there is such
a thing, however, it seems rather unfair to berate vendors for not adhering
to it.


--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
bill@ssd.csd.harris.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.