On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer <daniel.is.fisc...@googlemail.com> 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. >> 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe