Boost logo

Boost :

Subject: Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2012-05-09 10:31:43


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 bizarr oddity to the land of NaN sense.

Best regards,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk