https://d.puremagic.com/issues/show_bug.cgi?id=12169
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #5 from [email protected] 2014-02-16 07:00:53 PST --- (In reply to comment #1) > This is by design in the code, presumably to avoid overflow (which you are > usually so concerned about, what changed?) > > I actually agree with you though. I'd expect sum!(int[]) to return int. In > general, I'd expect sum!(T[]) to return typeof(T.init + T.init), and respect > the language integral promotions. > ... +1. (In reply to comment #2) > If sum returned int for ranges of int, it would be 100% identical to > std.algorithm.reduce. Not yet, there are more special cases. (but a more general divide and conquer reduction algorithm might be an useful addition.) BTW: D semantics do not seem to support Kahan summation. (Walter has expressed in the past that any operation might arbitrarily be performed at higher precision.) > It's worth returning a 64-bit quantity because > (a) 64-bit summing is about as fast as 32-bit summing, > (b) the result can be cast to int if needed. > IMO it's not worth the special casing. (Another thing I find questionable: extending range capabilities can reduce precision.) Allowing specification of the summation type is enough. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
