David Widmann

I think it might be easier to focus on goals 1 (accuracy and consistency with `sum(log, x)`), 4 (type stability), 5 (performance), and GPU compatibility first. Supporting `sumlog(f, x)` and...

> avoid Base._return_type Yes, this is part of the code complexity goal but will also improve stability of LogExpFunctions. All such internal functions and "hacks" should be removed from the...

There's a [PR in the StatsFuns repo](https://github.com/JuliaStats/StatsFuns.jl/pull/101) that implements weighted logsumexp. IIRC it was opened before this package was extracted from StatsFuns and the implementation of logsumexp was rewritten. There's...

@ParadaCarleton as far as I know you've never contributed to this package, so I really think that you should let the maintainers of this package decide when a PR is...

Clearly, we should not over-optimize this PR. But at the same time we should hold off merging PRs if reviewer comments that can be addressed without too much effort are...

Hmm, I think `log2mexp` would be a better approach - but it seems it requires adding a `_expm1(::Float64)` definition to LogExpFunctions? Or to use a `_log2mexp` function on older Julia...

The remaining test errors are caused by the recent Rmath update, see https://github.com/JuliaStats/StatsFuns.jl/pull/156

It seems this PR is almost ready? Only https://github.com/JuliaStats/StatsFuns.jl/pull/148/files#r1019101826 is missing, it seems?

Hmm, for ChainRules-compatible AD systems we can add the missing rules just in StatsFuns (or, of course, SpecialFunctions directly if the rule is missing there). I think we might want...

Yes, that's why I assumed you might want to add rules to StatsFuns (or, e.g., Distributions) instead of SpecialFunctions (even though in the example above you would need rules for...