LogExpFunctions.jl icon indicating copy to clipboard operation
LogExpFunctions.jl copied to clipboard

logstatsexp

Open cossio opened this issue 2 years ago • 10 comments

Adds the functions logmeanexp, logvarexp, logstdexp

cossio avatar Nov 11 '23 16:11 cossio

These functions are usually useful for me, thought it'd be nice to have them here.

Not sure why CI is failing on Julia 1.0 ?

cossio avatar Nov 11 '23 16:11 cossio

I don't have an strong opinion on this, but Is it possible to implement this as an extension? This package is a really low level one, and adding a new dependency could have effects on downstream packages? The same thing applies to LinearAlgebra, (but they should be it's own issue)

longemen3000 avatar Nov 11 '23 18:11 longemen3000

@longemen3000 The PR is not introducing any dependencies.

cossio avatar Nov 11 '23 18:11 cossio

Statistics, while a Stdlib, it is a new dependency

longemen3000 avatar Nov 11 '23 18:11 longemen3000

Ohhh, nvm, my error, in that case, no comment at all

longemen3000 avatar Nov 11 '23 18:11 longemen3000

@longemen3000 Yes but Statistics is only used in tests

cossio avatar Nov 11 '23 18:11 cossio

CI passing now.

@devmotion I agree the implementation is not optimal but I don't have time to tune it now. Could we merge as it is now?

cossio avatar Nov 11 '23 19:11 cossio

I think we can merge now and work on optimization later.

Honestly, it's just a huge pain trying to optimize for allocations without having Transducers.jl, laziness, or good functional primitives in Julia.

ParadaCarleton avatar Nov 11 '23 19:11 ParadaCarleton

@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 ready and can be merged. In my opinion, being a member of JuliaStats doesn't mean that you are able and should merge PRs in repos that you haven't contributed to and/or are not familiar with. For instance, there are many JuliaStats packages where I don't think it's appropriate for me to merge PRs.

devmotion avatar Nov 11 '23 19:11 devmotion

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 not resolved. For instance, I think currently the following things are missing in this PR:

  • Definitions for non-AbstractArray inputs (it seems the same algorithm could be applied?)
  • Avoiding allocating R .- log(N) etc. when R is an Array and broadcasting when R is a scalar
  • Tests with non-Float64 inputs (these would have uncovered the promotion issues)

devmotion avatar Nov 11 '23 19:11 devmotion