Mon, 17 Jun 91 09:30:03 -0400

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: | cfarnum@valhalla.cs.wright.edu (Charles Farnum) |

Keywords: | Fortran, arithmetic |

Organization: | Compilers Central |

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

Date: | Mon, 17 Jun 91 09:30:03 -0400 |

In article 91-06-016, bill@hcx2.SSD.CSD.HARRIS.COM

(Bill Leonard) writes:

]In article 91-06-011, bron@sgi.com (Bron Campbell

Nelson) writes:

]> ...For example, the Fortran standard clearly states that an expression

]> may be replaced by one that is "mathematically equivalent" but without

]> specifing just what kind of "mathematics." ...

]As far as I know, there is only _one_ kind of mathematics. The FORTRAN

]standard is referring to real mathematics, not any particular means of

]_approximating_ mathematics.

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.

]Our compilers, I believe, would perform the transformation. As a general

]rule, we take the view that NaNs and INFs are exceptional conditions,

]rather than the norm. 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.

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.

/charlie

--

Post a followup to this message

Return to the
comp.compilers page.

Search the
comp.compilers archives again.