-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Monday, August 20, 2012 6:44 PM To: boost@lists.boost.org Subject: Re: [boost] several messages
Paul A. Bristow wrote:
William Kahan and the rest of the IEE754 designers wisely built in the concept of NotANumber. It provides protection against spurious, zero-information results.
And, as we have discovered in writing functions and distributions in Boost.Math, it is a big simplification if all number systems also support a NaN concept, however it is implemented.
This is a topic which I'm curious about. I would have thought that code which either produces or uses a NaN should always throw an exception. But this is not the case - though apparently it's a compile time option in some environments. What is the reasoning behind this design? I would
think that
plowing forward with an invalid result would always be a bad idea. Then only thing I could think of was at the time (ca 1984) makiing a hardware interrupt was too complicated - on an alread complicated hardware spec (sub normal values, etc.) and a software implemntation was considered too slow and didn't work with fortran. I'm just curious about this, BTW we once had an opportunity to have Kahan himself speak a Boost Con but it didn't work out. Oh Well
Well there is/used to be a std::numeric_limits<FPT>::signaling_NaN() but it has fallen into disuse (or never got into use?). What you suggest has some merits but now poses insuperable portability issues. And sometimes, as Dave explained, you don't want to abort just because one value is duff. It's easier to wait until you try to use it before squeaking loudly. Paul