Toon Moene wrote:
>> This is certainly true - but then one loses the benefits of intermediate
>> 80-bit results as well (and they benefit much more than they harm).
>
>True as well, but they also make exact reasoning about the behaviour of
>floating point algorithms pretty hairy, because you have to be aware
Yes, that is what I meant by saying that it harmed (some) "expert" users.
Naive users are usually helped because they don't do "exact reasoning".
[All gross generalisations].
>> For instance, various library routines like "exp" that provide (say)
>> 60 bits of precision might provide several bits less if intermediate
>> results are limited to 64 bits (the implementor of the routine may
>> have designed and tested it only with 80-bit internal working in
>> mind).
>
>But wouldn't it then be the responsibility of the writer of this routine
>to ensure the right setting of the CPU's control word ?
Again, too slow. This is slowing everyone down for the sake of a few
nitpicky routines (which can virtually always be rewritten not to exhibit
the unfortunate behaviour - and can always be compiled with -float-store
anyway).
>PS: I thought NAG's compiler needed -ffloat-store to be able to
>implement Chapter 15 (support for IEEE-754 arithmetic) of the upcoming
>F2K standard - am I wrong in this ?
Yes, because -float-store is not necessary to implement IEEE semantics; the
Intel86 floating-point model is entirely within the allowed behaviour of the
IEEE standard.
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|