Re: [boost] several messages

Subject: Re: [boost] several messages
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-08-20 13:35:23

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert
> Ramey
> Sent: Monday, August 20, 2012 6:44 PM
> To: boost_at_[hidden]
> 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