Fri, 14 Jun 91 09:10:46 -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) |

INFs and NaNs richarda@cec825.atl.hp.com (1991-06-17) |

Re: INFs and NaNs presberg@compass.com (1991-06-18) |

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

[1 later articles] |

Newsgroups: | comp.compilers |

From: | bill@hcx2.SSD.CSD.HARRIS.COM (Bill Leonard) |

Keywords: | arithmetic, design, optimize |

Organization: | Compilers Central |

References: | 91-06-011 |

Date: | Fri, 14 Jun 91 09:10:46 -0400 |

In article 91-06-011, bron@sgi.com (Bron Campbell Nelson) writes:

*> My own *personal* opinion is that this is a legal transformation if and*

*> only if the runtime system traps (and aborts) on generation of NaN's and*

*> Inf's. 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." If your particular mathematical*

*> model includes NaN's and Inf's (e.g. the IEEE model), then this transformation*

*> is NOT strictly legal, since the expressions are not always equivalent.*

*> On the other hand, if your mathematical model does not have things like*

*> NaN's and Inf's (i.e. the program blows up if such numbers are produced)*

*> then the transformation IS legal.*

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. Under that rule, the transformation is

perfectly legal. NaNs and INFs represent a failure of the machine model to

adequately represent the _mathematical_ result (i.e., the result you would

get with infinite precision). In that sense, the IEEE standard is

(sometimes) mandating an answer that is mathematical nonsense, since the

answer would actually be zero if the machine had been able to accurately

represent the other operand. (One exception to this is an INF operand that

was generated by a division by zero, as opposed to division by a very small

number. In that case, you have 0/0, which is mathematically undefined.)

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.

--

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.