|Optimizing IEEE Floating-Point Operations email@example.com (1991-06-06)|
|Re: Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-11)|
|Optimizing IEEE Floating-Point Operations bill@hcx2.SSD.CSD.HARRIS.COM (1991-06-14)|
|Optimizing IEEE Floating-Point Operations email@example.com (1991-06-14)|
|Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-17)|
|Re: Optimizing IEEE Floating-Point Operations email@example.com (1991-06-17)|
|Re: Optimizing IEEE Floating-Point Operations firstname.lastname@example.org (1991-06-18)|
|Re: Optimizing IEEE Floating-Point Operations email@example.com (1991-06-19)|
|From:||firstname.lastname@example.org (Charles Farnum)|
|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, email@example.com (Bron Campbell
]> ...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
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
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
Return to the
Search the comp.compilers archives again.