[Haskell-cafe] Sum and Product do not respect the Monoid laws

[Carter Schonwald]

For anything to be a Monoid (or any type class with laws), you implicitly
have a definition of equivalence you want your laws to use.  And for many
classes, those laws are using an equivalence not definable using Eq.  A
good example Is monad! You can not define Eq instances for arbitrary a-> m
b.  We can still define and talk about lawful monads.

Point of order though, no Num  a instance has a Monoid  a instance.
Instead Sum a and Product a are the Monoid Instances.
On Sep 26, 2014 9:46 PM, "Noon Silk" <noonslists at gmail.com> wrote:

> > 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 at 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 <jjwchoy at gmail.com> 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 at 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140926/a0ded2c2/attachment.html>