On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer
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.
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. 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!
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. - C.