Bryan O'Sullivan wrote: > apfelmus wrote: > >> In a sense, the instances of Eq and Ord for floating point numbers are >> wrong. What about rolling new classes for approximate equality and >> ordering? >> >> class ApproxEq a where >> (≈) :: a -> a -> Bool -- almost equal to > > The problems with this approach are generally worse than those with Eq, > whose shortcomings are at least well defined and widely understood.
What I wanted to do is to capture common patterns x - y >= epsilon abs (x - y) <= epsilon for comparing floating point numbers in nice functions x >> y = x - y >= epsilon x ≈ y = abs (x - y) <= epsilon This way, one could simply use >> and ≈ with floating point numbers and be assured without much thinking that the resulting code is more or less robust. But I guess that there are too many variants of these patterns and that thinking is always required. > You need to choose an epsilon of the right magnitude for the numbers > you're working with, and the epsilon is likely to be domain-specific. In case the epsilon is problem specific but static, one can use phantom types. > Also, since these aren't equivalence relations, ApproxEq has the > weird property that a ≈ b and b ≈ c does not imply a ≈ c; > ApproxOrd suffers from the same problem. Yes. But that's intended and the very nature of robustly comparing Doubles and Floats :( Regards, apfelmus _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe