|
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