
for equational laws to be sensible requires a sensible notion of equality, the Eq for Floating point numbers is
could it not be then that for floating points to be a monoid you must specify a satisfying notion of equality? (well, i guess nothing is stopping anyone from doing that themselves; and your point is that simply not having floats as a monoid is somehow "bad"?) On Sat, Sep 27, 2014 at 5:41 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
for equational laws to be sensible requires a sensible notion of equality, the Eq for Floating point numbers is meant for handling corner cases (eg: am i about to divide by zero), not "semantic/denotational equivalence"
Exact equality is fundamentally incorrect for finite precision mathematical computation. You typically want to have something like
nearlyEq tolerance a b = if distance a b <= tolerance then True else False
Floating point is geometry, not exact things https://hackage.haskell.org/package/ieee754-0.7.3/docs/Data-AEq.html is a package that provides an approx equality notion.
Basically, floating points work the way they do because its a compromise that works decently for those who really need it. If you dont need to use floating point, dont! :)
On Fri, Sep 26, 2014 at 9:28 AM, Jason Choy
wrote: subject to certain caveats. It's not unfair to say that
floating point multiplication is (nearly) associative "within a few ulp".
I'm not disputing this.
However, you can't deny that this monoid law is broken for the floating point operations:
mappend x (mappend y z) = mappend (mappend x y) z
Perhaps I'm being pedantic, but this law should hold for all x, y, z, and it clearly doesn't.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Noon Silk, ن https://sites.google.com/site/noonsilk/ "Every morning when I wake up, I experience an exquisite joy — the joy of being this signature."