18 Jun 91 22:31:02 GMT

Related articles |
---|

Optimizing IEEE Floating-Point Operations daryl@hpclopt.cup.hp.com (1991-06-06) |

Re: Optimizing IEEE Floating-Point Operations bron@sgi.com (1991-06-11) |

Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14) |

Optimizing IEEE Floating-Point Operations eggert@twinsun.com (1991-06-14) |

Optimizing IEEE Floating-Point Operations cfarnum@valhalla.cs.wright.edu (1991-06-17) |

Re: Optimizing IEEE Floating-Point Operations henry@zoo.toronto.edu (1991-06-17) |

Re: Optimizing IEEE Floating-Point Operations bill@hcx2.ssd.csd.harris.com (1991-06-18) |

Re: Optimizing IEEE Floating-Point Operations jbc@hpcupt3.cup.hp.com (1991-06-19) |

Newsgroups: | comp.compilers |

From: | bill@hcx2.ssd.csd.harris.com (Bill Leonard) |

Keywords: | Fortran, arithmetic |

Organization: | Harris Computer Systems Division, Fort Lauderdale, FL |

References: | 91-06-016 91-06-011 91-06-022 |

Distribution: | ssd |

Date: | 18 Jun 91 22:31:02 GMT |

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

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.