2012/5/9 Paul A. Bristow <pbristow@hetp.u-net.com>:
2012/5/8 Joachim Faulhaber <afojgo@googlemail.com>:
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