Switch to InverseFunctions.inverse

[icweaver]

Just following up from here TuringLang/Bijectors.jl#212

[codecov]

Codecov Report

Merging #33 (1086ef9) into main (16fc5c9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #33   +/-   ##
=======================================
  Coverage   91.70%   91.70%           
=======================================
  Files          14       14           
  Lines        1181     1181           
=======================================
  Hits         1083     1083           
  Misses         98       98           

---

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 16fc5c9...1086ef9. Read the comment docs.

[mileslucas]

Thanks, Ian! The changes look good, I just want to check something-

@oschulz should we change the definition here to use InverseFunctions instead of Bijectors.Inverse?

Transits.jl/src/distributions.jl

Line 58 in 16fc5c9

function (::Inverse{<:Kipping13Transform})(y::AbstractVector)

[oschulz]

@oschulz should we change the definition here to use InverseFunctions instead of Bijectors.Inverse

No, I think it can stay as it is. InverseFunctions.inverse only provides an abstract API but no implementations of inverses that you could specialize on (except for InverseFunctions.square). So for the inverse transform, you can either create an explicit struct InverseKipping13Transform or use Inverse{<:Kipping13Transform}, or ...

If you implement both the InverseFunctions.jl and ChangesOfVariables.jl API, you may be able to not depend on Bijectors.jl at all, though.

[mileslucas]

If you implement both the InverseFunctions.jl and ChangesOfVariables.jl API, you may be able to not depend on Bijectors.jl at all, though.

Sounds like that's worth trying in a future PR!

Thanks for the comments Oliver, and thanks for the contribution Ian!

[icweaver]

Sounds good!

Sort of a bookkeeping question, but is there a preference on how we want keep tabs on things like this? I just added it as a discussion, but maybe it would be better to track as a one day issue or something instead?

[mileslucas]

For bookkeeping I have a "rent-free" unit in the back of my head 😂

I think discussion is a good spot for planning contributions, so that's appropriate, then it can move to a PR when someone finds the time.