Optimizing IEEE Floating-Point Operations

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
--

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