On Wednesday 21 September 2011, 01:23:48, Casey McCann wrote: > 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.
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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
