
On Wednesday 21 September 2011, 01:23:48, Casey McCann wrote:
On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer
wrote: On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote:
Because NaN values never compare equal to themselves, I'm not sure if it's even possible to remove them from the structure,
filter (not . isNaN)
resp.
filterWithKey (\k _ -> not $ isNaN k)
Er, right. Yes, of course. I'm not sure what I was thinking there. :] Though that still leaves the question of any damage done in the meantime, unless the filtering would repair the tree in the process.
With fromList . Prelude.filter (not . isNaN) . toList and the corresponding for Maps, you'll get a valid NaN-less tree. However, damage done in the meantime generally couldn't be undone.
and because of tree rebalancing I'm not sure how to predict what the impact of one or more NaNs would be over multiple operations on the data structure.
Yuck. Don't even try to predict that (unless you absolutely have to).
Agreed. The consequence of not trying, however, is that it isn't viable to let things slide at all--every insertion must be checked for NaNs, because otherwise you lose any guarantee that the tree will be valid next time you use it.
Yes, where NaNs matter, you always have to check (well, unless you *know* that your calculations don't produce any NaNs). Btw, -0.0 can be problematic too.
One can imagine a similar data structure designed to be resilient and predictable in the face of ill-behaved comparisons, but surely it would be easier to just fix the problem instances!
Except that people might expect IEEE semantics for (==), (<) etc. However, nowadays I tend to think that making the Eq and Ord instances well-behaved (wrt the class contract) and having separate IEEE comparisons would overall be preferable. There is still the question whether all NaNs should be considered equal or not [and where Ord should place NaNs].
If you'd like to see an explicit demonstration (which you can try in GHCi yourself!) see here: http://stackoverflow.com/questions/6399648/what-happens-to-you-if-you -br eak-the-monad-laws/6399798#6399798 where I use it as an example of why it's important for type class instances to obey the relevant laws.
Nice and short.
Yes, and credit where due for the original example. :] Don't recall which -cafe thread that came from, though.
Google suggests "Exception for NaN" from May.