Add overloads for sum

[jmh530]

This PR adds the overloads for sum that exist for prod and some of the other statistical functions already.

[codecov-commenter]

Codecov Report

Merging #264 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
+ Coverage   90.19%   90.22%   +0.03%     
==========================================
  Files          52       52              
  Lines       10694    10706      +12     
==========================================
+ Hits         9645     9660      +15     
+ Misses       1049     1046       -3     

Impacted Files	Coverage Δ
source/mir/math/numeric.d	89.24% <100.00%> (-0.12%)	⬇️
source/mir/math/stat.d	99.66% <100.00%> (ø)
source/mir/math/sum.d	97.11% <100.00%> (+0.62%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4cfc899...152cbd9. Read the comment docs.

[9il]

Why this overload is required?

[jmh530]

I added two overloads as part of this PR. This one is for when you do `sum(1, 2, 3)` and also `sum(1f, 2, 3)`. The other one is for when you do `sum!float(1, 2, 3)` or `sum!float(1f, 2f, 3f)`. The main difference is that it means the user does not have to provide the type. I wouldn't say it is required. It is a quality-of-life enhancement. The ability to call functions like `f(1, 2, 3)` and have the same behavior as `f([1, 2, 3])` is part of D and I see no reason not to incorporate it if someone is willing to put in the work to add them. If they should not be added for `sum`, then they should be removed from other functions that I have added them for consistency. I think it is valuable to have this functionality for some of these numerical functions, but I would understand if you were not in favor of that.

…

On Mon, Jun 1, 2020 at 7:06 AM Ilya Yaroshenko ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In source/mir/math/sum.d <#264 (comment)>: > @@ -1722,6 +1750,15 @@ template sum(Summation summation = Summation.appropriate) import core.lifetime: move; return .sum!(F, ResolveSummationType!(summation, Range, F))(r.move, seed); } + + /// + sumType!(CommonType!T) sum(T...)(T r) Why this overload is required? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#264 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBFNST4KW6OMR4JDJTEEGLRUODTXANCNFSM4NPXBERQ> .

[9il]

I added two overloads as part of this PR. This one is for when you do sum(1, 2, 3) and also sum(1f, 2, 3). The other one is for when you do sum!float(1, 2, 3) or sum!float(1f, 2f, 3f). The main difference is that it means the user does not have to provide the type.

The following works well without a variadic template. It is very preferred to avoid variadic templates of functions, the generates a lot of template bloat and hard to maintain.

F sum(F)(scope F[] ar...)
{
    return ar[0];
}
void main() {
    auto s = sum(1f, 2, 3);
}

[jmh530]

@9il Sounds good. I used scope const instead of just scope since you had recommended that previously.

One question I had as I was working on this is that I did not use core.lifetime.move for the typesafe variadic functions. Is this ok? I don't have a good sense of when that should be used (definitely with slice/range but otherwise?).

[9il]

One question I had as I was working on this is that I did not use core.lifetime.move for the typesafe variadic functions. Is this ok? I don't have a good sense of when that should be used (definitely with slice/range but otherwise?).

Yes. But it would make sense to add move to fold if it hasn't been used before.