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