Add support for LogarithmicNumbers (also to SpecialFunctions and StatsFuns)?

[oschulz]

LogarithmicNumbers is a neat package that allows for passing around seemingly non-logarithmic (e.g.) values that are stored as their logarithm internally. This allows for using somefunc instead of logsomefunc even though the non-log value would exceed the dynamic range of standard float types.

The problem is that while LogarithmicNumbers itself is quite lightweight

julia> @time_imports using LogarithmicNumbers
      0.9 ms  ┌ Requires
     39.7 ms  LogarithmicNumbers

it becomes uncomfortably heavy to use as a widespread dependency when Distributions (and SpecialFunctions and StatsFuns) are likely to enter the mix downstream, due to the @requires that get activated (adding logarithmic number support to pdf, cdf, gamma, beta, etc.).

julia> @time_imports using Distributions, LogarithmicNumbers
    [...]
    753.1 ms  Distributions
      0.5 ms  ┌ Requires
    378.4 ms  LogarithmicNumbers

If SpecialFunctions, StatsFuns, Distributions would directly depend on LogarithmicNumbers however, the additional functions would likely have negligible load-time effect as they would get precompiled (it's adding them via @require that's costly). Since LogarithmicNumbers itself is much more lightweight than any of those packages, this would seems to be a natural dependency relation. Maybe LogarithmicNumbers could be moved to JuliaMath in the process to make it more "official"?

I'm just throwing this out here as a suggestions - I'm not a maintainer of any of the involved packages, just a downstream user trying to reduce my dependency load times. :-)

I think this would also significantly reduce the load time of packages like MeasureBase.

CC @cjdoris, @devmotion, @andreasnoack, @cscherrer, @mschauer

[devmotion]

As I mentioned on discourse a while ago, I'm sceptical if it's a good idea to support LogarithmicNumbers in Distributions.

I’m not sure if this is desirable. I imagine that it would be quite surprising if sometimes logarithmic numbers are returned and in many cases you would have to convert the values to standard number types anyway since many functions don’t support logarithmic types (similar to operator overloading AD such as ForwardDiff.Dual). More importantly, it seems you could just use logcdf and wrap the output as a logarithmic number if desired, couldn’t you?

It also seems that the overloads that LogarithmicNumbers defines for e.g. Distributions don't follow the API of logpdf etc. (https://github.com/cjdoris/LogarithmicNumbers.jl/blob/deec7e55866e11f9452ceec765490db93c6efa5d/src/LogarithmicNumbers.jl#L657-L659).

I think it would be simpler if users that want to wrap the result of logpdf, logcdf etc. computations as a ULogarithmic use explicit calls of e.g. uexp(pdf(dist, x)) etc. Load times could be improved for users of Distributions + LogarithmicNumbers by removing the overloads in LogarithmicNumbers and dropping the Requires dependency there.

[oschulz]

Load times could be improved for users of Distributions + LogarithmicNumbers by removing the overloads in LogarithmicNumbers and dropping the Requires dependency there.

Makes sense, it's not much more code for the user, after all.