# Mean of integers overflows - bug or expected behaviour?

**URL:** https://discourse.julialang.org/t/mean-of-integers-overflows-bug-or-expected-behaviour/34767
**Category:** Statistics
**Tags:** integer-overflow
**Created:** [February 17, 2020, 4:54pm UTC](https://discourse.julialang.org/t/mean-of-integers-overflows-bug-or-expected-behaviour/34767 "2020-02-17T16:54:34Z")
**Posts on this page:** 1
**Showing post:** 44

<div class="post-metadata">

### Author: ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [February 18, 2020, 6:44pm UTC](https://discourse.julialang.org/t/mean-of-integers-overflows-bug-or-expected-behaviour/34767/44 "2020-02-18T18:44:01Z")

</div>

> [@Tamas\_Papp](#):
>
> but `mean` is “correct” in the sense of being equal to `sum(v) / length(v)`

This seems like a circular argument; that’s an algorithm, and you could _assert_ it as a definition, but I would say that it is not the _conventional_ definition. You could just as well “define” `norm(x) = sqrt(sum(abs2, x))` and say that `Inf` is therefore the “correct” result for `norm([1e300])`. Put another way, if we change the implementation of `sum` in a way that changes the roundoff error for floating-point inputs, are we changing the “definition” of `mean(::Vector{Float64})`?

**For a floating-point function** , it is the ordinary expectation to define “correctness” and “accuracy” with respect to the function as computed with _infinite_ precision (i.e. over ℝ). I think that expectation applies here, since `mean(::Vector{Int})` returns a `Float64`.

(Matters are different for arithmetic functions whose inputs _and_ outputs are a finite-precision integer type.)

---

_[View the full topic](https://discourse.julialang.org/t/mean-of-integers-overflows-bug-or-expected-behaviour/34767)._