The function mean(), when used on Int inputs, returns a float result.
However, it may silently overflow on integer arithmetic.
Maintainer of Statistics.jl closed
the issue, saying that this is an expected behaviour of integer arithmetic. However,
the output of mean() is not expected to be an integer, so I feel that this is
not a good decision.
Julia’s built-in integers will always overflow silently for performance reasons, and mean won’t auto-convert its arguments to floating-point numbers for the same reason. If overflow safety is important to you, consider https://github.com/JeffreySarnoff/SaferIntegers.jl.
Unlike sum(), the function mean() will always convert to float even when
the result is integer. So conversion happens after summing, which sets
up a user for a nasty surprise.
EDIT: I understand the explanation, but I believe it prioritizes minuscule performance
savings over significant time that will undoubtedly be wasted by
tripping up users with this behaviour. Moreover, this misbehaviour propagates to other functions that rely on mean, like std()
The conversion operation (vcvtsi2sdq on my machine) is expensive compared to vaddsd, which leads to a ~6x slowdown for Int64 -> Float64 conversion. I’m not sure that’s worth it when the safe behavior is so easily accessible with mean(float, v), although it’d be good to add a note of warning to the documentation.
It’s hard to know in advance what will surprise users the most. At least we cannot assume they all come from MATLAB (Julia’s goal is not just to be a MATLAB replacement).
One could almost say that an obviously incorrect result can sometimes be better than a slightly incorrect one, as the former will more obviously be noticed. Suprising people with a visible problem isn’t as bad as silently misleading them.
Anyway, the performance issue raised by @stillyslalom is serious and needs to be addressed before considering changing the behavior. A 6× penalty is not the kind of hit we usually accept in Julia for increased safety.
To be fair, Matlab has a whole lot of other “surprises” to make up for this. Arguments to copy what Matlab does do not always achieve the desired effect on this forum, but YMMV.
FWIW, I find the whole “surprise” line of reasoning specious: people have heterogeneous expectations, and someone is always going to be surprised about something. This is not a solid basis for API design.
I would argue for consistency instead. In Julia, Base, the standard libraries, and most packages rarely convert Int to Float64 to just to avoid overflow, leaving this choice to the user instead.
The basic problem here is calling mean on integers, which is a very peculiar use case when you think about it. If you are working with eg measurement data that has large values, they are very rarely integers in practice.
Yes, but that’s precisely the kind of tradeoff that Julia makes when it’s really worth it (the case in point being precisely integer addition). A 6× performance gain is probably considered as “worth it”.
OS shouldn’t be irrelevant, but FWIW I see roughly the same result on a three-year-old Intel Core i5 (Skylake).
That’s an interesting solution! Now the problem with that approach is that it doesn’t work for types larger than Int, which would have to use another approach. BigInt can always be used, but it will be quite slow. Overall this makes either the result or performance harder to predict than a simple rule like overflowing (current approach) or accumulating in the type of the result (proposed approach in this thread).
Integer addition is not a good parallel, because the integer overflow is not unexpected there and there is no logical alternative to it. That is why I raise the issue with respect to mean() rather than sum().
Horses for courses. I deal with thousands of different measurements every day in my work. Temperatures, pressures, flows, compositions, reaction rates etc. In more than 20 years I have yet to find one of them that was an integer.
Now, obviously for you the reality is different, but be careful when you claim universal truths.