On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote: > This plays havoc with the search tree used internally by Set and Map, > the result being that if you have any NaN values in the data > structure, you may not be able to find other values anymore. 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) > 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). > > In short: Using Doubles in a Set, or as the key to a Map, should be > regarded as a bug until proven otherwise (i.e., proving that NaN will > never be inserted). > > 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe