Merge ARSampling.jl (JuliaRegistries/General/151430)

[Eliassj]

For background see JuliaRegistries/General/151430

This pull request merges a redesign of both the implementation and API of sampling which aims to:

• Reduce allocations (sampling is now allocation-free, adding segments is allocation-free for the first 50).
• Significantly improve sampling speed.
• Allow types other than Float64 (such as BigFloat etc).
• Allow other AD backends through DifferentiationInterface.jl.

Changes to public API:

• Target distribution and its gradient is specified through the new Objective struct which is then passed to the sampler. It allows specifiyng a manual gradient or automatically through an AD backend of choice with the default being ForwardDiff.jl. Target functions are now expected to be in their log form when passed to Objective.
• The sampler is created mostly like before with some changes in the expected types of arguments.
• Maximum number of segments is specified when drawing samples instead of at sampler creation.
• As it currently stands the sampler is named ARSampler instead of RejectionSampler and the sampling function is named sample! instead of run_sampler!.

Example of new interface

For more examples see: https://eliassj.github.io/ARSampling.jl/dev/

using AdaptiveRejectionSampling: Objective, ARSampler, sample!
using DifferentiationInterface, Enzyme
using Chairmarks

# Sampling from a Beta distribution truncated to 0.5--1.0
const alpha::Float64 = 2.5
const beta::Float64 = 5.0

f(x) = x^(alpha - 1) * (1 - x)^(beta - 1)
f_log(x) = log(f(x))
const obj = Objective(f_log; adbacked = AutoEnzyme())
const sam_bounded = ARSampler(obj, (0.5, 1.0), [0.8])

@time samples_bounded = sample!(sam_bounded, 100000; max_segments = 10)

TODO

• Finish updating README and benchmarks.
• Rename the sampler / sampling function or align it with the rand-interface.

[Eliassj]

@mauriciogtec is it ok if I merge this?

[mauriciogtec]

nit: f_gamma does not seem to be used?

[Eliassj]

Will fix!

[mauriciogtec]

@Eliassj you can merge. Should we bump up the version?

[Eliassj]

@mauriciogtec Thanks! I'll just finish updating the README and check that the CI / docs is working and we should be ready to bump. What is your stance on moving the package to StatsJulia?

[mauriciogtec]

I support the transfer. What are the steps?

[Eliassj]

I believe we contact someone in the organization @DilumAluthge? (JuliaRegistries/General#151430 (comment))

[DilumAluthge]

Sure, I'm happy to help transfer this repo to JuliaStats. The process is this:

1. The owner of this repo (mauriciogtec) transfers this repo to me (DilumAluthge).
2. I transfer this repo to JuliaStats.
3. I restore @mauriciogtec's admin permissions on the repo.
4. I can then add anyone else that needs access to the repo.

@mauriciogtec As a first step, can you transfer this repo to me?

[mauriciogtec]

@DilumAluthge I have made transfer request.

[DilumAluthge]

1. I have transferred the repo to JuliaStats.
2. I have restored @mauriciogtec's admin permissions on the repo.

@mauriciogtec Do you want me to give anyone else admin (or maintain, or write/commit) permissions on the repo?

[mauriciogtec]

@DilumAluthge Please also give admin permissions to @Eliassj

[DilumAluthge]

@Eliassj I've given you admin permissions.

[DilumAluthge]

The last piece we need is to update the repo URL in the registry: JuliaRegistries/General#154331

[Eliassj]

@DilumAluthge Is there anything organization-specific one should be aware of (such as style of docs/how these should be deployed) when maintaining a package in JuliaStats?

[DilumAluthge]

I'm not aware of any styles we enforce at the organization-wide level, I think most things we defer to the maintainer of each package.