# Sum of float64 vector gives slightly incorrect answer

**URL:** <https://discourse.julialang.org/t/sum-of-float64-vector-gives-slightly-incorrect-answer/8577>\
**Category:** Performance\
**Tags:** question\
**Created:** [January 24, 2018, 10:38pm UTC](https://discourse.julialang.org/t/sum-of-float64-vector-gives-slightly-incorrect-answer/8577 "2018-01-24T22:38:46Z")\
**Posts on this page:** 1\
**Showing post:** 45

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [April 29, 2019, 3:19pm UTC](https://discourse.julialang.org/t/sum-of-float64-vector-gives-slightly-incorrect-answer/8577/45 "2019-04-29T15:19:07Z")

</div>

I know this has been a long and wide-ranging discussion, but I feel like it’s incomplete without linking to Stefan’s post about the ability to sum a list of 2046 elements to _any floating point value you so choose_ just based upon its ordering. Because sometimes it’s helpful to see the absolute worst case while you’re chasing the best.

> [@Array ordering and naive summation](https://discourse.julialang.org/t/array-ordering-and-naive-summation/1929):
>
> One of the first things you learn in numerical analysis is that floating-point operations are not associative. A classic example is this: julia\> (0.1 + 0.2) + 0.3 0.6000000000000001 julia\> 0.1 + (0.2 + 0.3) 0.6 I was thinking of ways to make floating-point summation independent of the order of the summands without making the performance much worse (this is a hobby of mine). Julia currently uses a pairwise summation algorithm, which is much better than naive left-to-right reduction while havin…

---

_[View the full topic](https://discourse.julialang.org/t/sum-of-float64-vector-gives-slightly-incorrect-answer/8577)._