|Re: Arithmetic accuracy, was Compiler bugs email@example.com (Joachim Durchholz) (2002-01-16)|
|Re: Arithmetic accuracy, was Compiler bugs firstname.lastname@example.org (2002-01-18)|
|Re: Arithmetic accuracy, was Compiler bugs email@example.com (2002-01-24)|
|Re: Arithmetic accuracy, was Compiler bugs firstname.lastname@example.org (2002-01-24)|
|From:||email@example.com (Nick Maclaren)|
|Date:||24 Jan 2002 16:11:58 -0500|
|Organization:||University of Cambridge, England|
|Posted-Date:||24 Jan 2002 16:11:58 EST|
John Dallman <firstname.lastname@example.org> wrote:
>email@example.com (Nick Maclaren) wrote:
>> Firstly, numerical experts do NOT depend on such things, because they
>> know better. One of their main objections (sic) to consistent
>> floating-point is that it is extremely harmful in many important ways,
>> and it leads non-experts to believe that their answers are right
>> because they are the same on multiple systems. I see this delusion
>I think anyone would feel entitled to object to the explanation I once
>got in a presentation from a processor manufacturer to the effect that
>"This set of floating-point instructions on this processor is not
>guaranteed to produce results consistent with this other, overlapping,
>set of floating point instructions at the same precision on this same
>processor". To make it extra worrying, they tried to flip over that
>slide to fast for anyone to read. However, it fortunately turned out
>that the people who wrote the presentation didn't know what they were
>No brand names, no packdrill.
Now, which of the vendors who did that do you mean? :-(
Yes, that is precisely the point. It doesn't much matter what the
arithmetic does, provided that it is half-way sane and mathematically
consistent. Inconsistent arithmetic is a nightmare. For example:
IF (A .NE. 0.0) A = A/A
C That caused the divide by zero exception ....
But the sense of consistent that I was using in the first paragraph,
was consistent across all implementations. And THAT is not needed,
or even particularly helpful. Theoretically, it might help when
writing distributed applications, but in practice there are so many
"gotchas" when doing that that a few more pass unnoticed.
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Tel.: +44 1223 334761 Fax: +44 1223 334679
Return to the
Search the comp.compilers archives again.