Optimizing IEEE Floating-Point Operations

bill@hcx2.SSD.CSD.HARRIS.COM (Bill Leonard)
Fri, 14 Jun 91 09:10:46 -0400

          From comp.compilers

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]
| List of all articles for this month |

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

Post a followup to this message

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