Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true

Subject: Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-05-09 11:27:44

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Joachim
> Faulhaber
> Sent: Wednesday, May 09, 2012 3:32 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true
> 
> 2012/5/9 Paul A. Bristow <pbristow_at_[hidden]>:
> >
> >> 2012/5/8 Joachim Faulhaber <afojgo_at_[hidden]>:
> >> >
> >> > I don't think the ICL should support NaN. Moreover I believe boost
> >> > libraries and generic concepts should not integrate NaN in general.
> >> > In a way I conceive NaN as being "anti generic". Wherever I run
> >> > into the NaN phenomenon, it tends to jeopardize simplicity and
> >> > elegance in generic designs.
> >>
> >>
> >> NaNtheLess! I found a generic solution to the problem :)
> >>
> >> template<class Float>
> >> struct NaNtheLess
> >> {
> >>     bool operator()(Float lhs, Float rhs)const
> >>     {
> >>         return tr1::isnan(lhs)
> >>                     ? !tr1::isnan(rhs)
> >>                     : std::less<Float>()(lhs, rhs);
> >>     }
> >> };
> >>
> >>
> >> Hope this solves your problems. NaNtheless, I am a NaN loather ;)
> >
> > Well, in a way everyone hates them too, but they *are out there*, and hitting them is nasty.
> >
> > This sounds an excellent solution, protecting the hapless user from
> > the almost certainly unpleasant results of tripping over a NaN in the
> > night ;-)
> 
> Hi Paul, nice to meet you here again :)

:-)

> I am afraid though that this "solution" like every NaN-workaround for sound generic concepts is
only a
> bluff package that tries to heal the fundamental flaws of NaN, that are incurable by construction.
Functor
> NaNtheLess bends the semantic of NaN for sake of sortability:
> 
> As the nanySet shows
> >  {[1.#QNAN,2.22507e-308)(2.22507e-308,42]}
> 
> we now assume that
> 
> NaN < numeric_limits<Float>::min()
> 
> which directly contradicts the semantics defined for NaN. If we'd extend this for infinities we
might end up
> with constructions like
> 
> NaN < -numeric_limits<Float>::infinity()
> 
> that adds just another bizarre oddity to the land of NaN sense.

So it is better to be more conservative and just prohibit NaN from intervals?  

Your original instinct, but maybe adding a check when creating an interval.

(Perhaps throw an exception if the user tries to create an interval using a NaN?)

And contains() returns false for all NaN?  (which is what Andrew wanted to start with).

(Of course, he could also achieve that by testing  isnan(value) ? false : contains(value)),

and making sure that he didn't create an interval with a NaN (less risk but worse results?)

Musing out loud (or should that be mumbling ;-).

Cheers

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]