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,

Interval Container Library [Boost.Icl]

Boost list run by bdawes at, gregod at, cpdaniel at, john at