I’ve discovered a lot of inconsistent behavior today with the sum and mean functions (while investigating a question asked here on Discourse), some of which are regressions compared to v0.4.x. For example, on v0.4.x: julia> sum([0xff,0xff]) 0x00000000000001fe julia> sum((0xff,0xff)) 0xfe julia> su…

Throwing a few ideas out in the form of rhetorical-ish questions: Is wraparound ever desirable in practical situations? Wouldn’t you always want to throw an overflow error or return NaN? (Is an overflow even a NaN?) Shouldn’t it be the user’s responsibility to cater for potential overflow errors…

@pitao Please don’t make this issue broader than it is (and apologizing about the signal-to-noise ratio as a preamble doesn’t really help). Deciding on the best behavior for sum and mean is already enough for on thread. Checking for overflow everywhere is a hard question, see for example this issue . …

[image] nalimilan: float works for Complex arguments you mean the float() function. yes, i was acknowledging that, but it is already different than the proposal of using Float as accumulator. however, as i said, what about types that does not support float()? and don’t ask me to give an examp…

[image] pint: but you know what? here is an example: now i can compute the mean of rationals. if you float-ize the accumulator, mean of rationals will be float. Right. I guess the most general and most correct approach would be to accumulate using the type of (one(T)+one(T))/one(T), i.e. the …

[image] pint: you mean the float() function. yes, i was acknowledging that, but it is already different than the proposal of using Float as accumulator. however, as i said, what about types that does not support float()? I would only use this method for a set of types known to work: T<:smalli…

@nalimilan Yes (although, it’s not just tuples, it seems to be anything that is not an AbstractArray). Thanks, that would be great. I’m only trying to improve the overall quality of Julia here (and I’m not saying that the overall quality is bad at all (I wouldn’t be using it for production code ever…

Remember that the problem with mean is the inconsistency based on collection type. The result type for mean on an AbstractArray of Integer types is typeof(one(widen(T))/1), (not one(T)), for Bool types it is typeof(1/1), and for other iterables, typeof((zero(T)+zero(T))/1). I’d be rather concerne…

[image] nalimilan: it could be slower than preserving the input type note, that the input type is now not preserved in general. for iterables, there is a complex mechanism to determine the accumulator type. in particular for integers, it widens to Int32 from smaller sizes, and to Int64 from I…

At this point, we should really consider removing automatic widening from reduction over numeric types – except Bool which I think should not be numeric anymore anyway. If someone wants a larger result type, it’s better that they specify it, otherwise, we should just give them what normal promotion …

[image] nalimilan: (one(T)+one(T))/one(T) Why not zero(T)/one(T)?

Inconsistent behavior of `sum`,`mean` (and probably others) on different collection types

Internals & Design

Topic		Replies	Views
Mean of integers overflows - bug or expected behaviour? Statistics integer-overflow	94	4668	March 3, 2020
Why I love Julia Community announcement	34	5046	October 11, 2019
[RFC] What should the arithmetic within the FixedPointNumbers be Visualization package , colors , numerics	65	4128	May 11, 2024
Tonight I hated julia, REPL and overflows New to Julia integer-overflow	64	6670	March 14, 2020
A plea for int overflow checking as the default Internals & Design question , proposal , integer-overflow	80	12324	December 17, 2021

Inconsistent behavior of `sum`,`mean` (and probably others) on different collection types

Related topics