A bug with Sum (as in Monoid)

Carter Schonwald carter.schonwald at gmail.com
Tue Nov 12 22:39:05 UTC 2019


Well said, naive summation of numbers with errors built into the geometry /
representation of real numbers are def non associative when restricted to
bounded / fixed size finite reps! (I like to point out to folks that if you
take the log_2 transformation of each half of the real line and then do a
uniform grid, then truncate that grid to a finite width interval on each
half real line , that roughly gives you the floating point numbers ).

There’s a few different algorithms you can do for extended / high precision
summation, though I don’t think they have the nice associative incremental
algorithm we associate (hah!) with the summation and product monoids.  But
I would love to be wrong.  Can we use some clever trick to have a higher
precision constant space summation alg? Perhaps using eds compensated lib
or something else under the covers ?

On Wed, Nov 6, 2019 at 5:41 PM Dannyu NDos <ndospark320 at gmail.com> wrote:

> Imprecise calculation shouldn't be considered as a bug. Topologically
> speaking, floating point types are regarded as if they had countably
> infinite precision. So the elements in domain are positive reals, negative
> reals, the zeros, the infinities, and the NaN.
>
> 2019년 11월 7일 (목) 07:29, Brent Yorgey <byorgey at gmail.com>님이 작성:
>
>> Hint: the problem has nothing to do with zeros.
>>
>> λ> 0.1 + (0.2 + 0.3) == (0.1 + 0.2) + 0.3
>> False
>>
>>
>> On Wed, Nov 6, 2019 at 4:20 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>>
>>> Omg, addition is not even associative? The zeros truly ruined everything.
>>>
>>> 2019년 11월 7일 (목) 06:58, Brent Yorgey <byorgey at gmail.com>님이 작성:
>>>
>>>> How is that worse than the fact that addition is already not
>>>> associative for floating point types?  At least +0 is really the identity
>>>> up to (==).
>>>>
>>>> On Wed, Nov 6, 2019, 3:49 PM Dannyu NDos <ndospark320 at gmail.com> wrote:
>>>>
>>>>> Sum has bug with floating points. Current definition states +0 as the
>>>>> identity element, while the actual identity is -0 since +0 + -0 = +0.
>>>>> _______________________________________________
>>>>> Libraries mailing list
>>>>> Libraries at haskell.org
>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>>>
>>>> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20191112/d649c26e/attachment.html>


More information about the Libraries mailing list