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

Subject: Re: [boost] [ICL] #6853: boost::icl::contains(NaN) returns true
From: Andrew Hundt (athundt_at_[hidden])
Date: 2012-05-08 14:25:00

>
> Hi Andrew, list,
> the NaN topic is not my favorite topic it's more a NaTo (not a Topic ;)

Thank you for your time and response Joachim, it is very insightful.
However,
it leads me back to a question I've been grappling with for some time.

(3) Undefinedness, invalidness, over/underflow, infinities for data
> types are concepts do not live at the same abstraction level as the
> data values themselves. I think it is a bad idea to try to code them
> into the level of naked values.

Suppose in the ICL tutorial example of finding a party's average guest
height, one guest refuses to disclose their height when they enter.
Every other piece of information is there, you can't pretend this
guest is not present, and the average over everyone else is still
useful.

I originally considered boost.optional and NaN for that situation, and
decided to go with NaN. If NaN is a flawed design decision, is there
an effective alternative in cases where invalid values are not
avoidable that can be used with various algorithms as you describe?

I expect using boost.optional would require many similar workarounds
to use. Perhaps those workarounds are simply a requirement of any
design I could choose, given that invalid values of some kind are a
constraint I must contend with.

Cheers!
Andrew Hundt