-
Notifications
You must be signed in to change notification settings - Fork 432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve algorithm for sampling Beta
#1000
Conversation
Great! Do you mind sharing the reference for the algorithm you are implementing here? Edit: It was part of your commits and the new documentation. Reference: R. C. H. Cheng (1978). Thank you!! |
That was quick @vks! Okay if I review some time this weekend? (Or is someone else wants to, I won't hog all the work 😉) |
@rasa200 I see you already found the source, sorry for not posting it in the PR description. The PDF is a bit tricky to access, but you could also look at the R source code for @dhardy Sure! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just starting to review, though I probably won't finish today.
@vks could you compare benchmarks before/after with a few parameter selections? Speed is not really a deciding factor in this case but it would be nice to have some idea how this performs.
It seems like the performance of this PR is actually worse, at least for the parameters I looked into: On master:
This PR:
|
I think we want this new algorithm for small parameters, but it might make sense to use the old algorithm for large parameters. I also did not really optimize the algorithm in this PR. |
Speed isn't a critical factor (though can be nice). Sorry that I didn't do the review yet. |
Fair enough! However, the algorithm I implemented is actually two rejection-sampling algorithms: BC is used for min(alpha, beta) <= 1, BB is used for larger parameters. It would be unfortunate to switch to a less efficient algorithm for large parameters. However, the reference claims that BB is more efficient than sampling the gamma distribution twice (our current algorithm), so maybe something is off with my implementation/comparison (or maybe their results don't apply to modern hardware). Of course, correctness is much more important, but I did not compare the algorithms for large parameters, so I don't really have an argument for using BB over the current implementation. 😅
No worries, this is not crucial or time-critical. |
I rebased on master, fixed the benchmarks (that were broken on master) and added them to CI (we did not test the The last two commits could be merged separately and are arguably more urgent than the rest of this PR. |
Sorry that I still didn't get to this. @rasa200 would you care to do a review? The main point is to have a second person check correctness (or at least conformance to the paper). This will have to target |
Yes! I will try my best! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The algorithmic part was super clear and followed the paper line-by-line. In doing so, a typo was reproduced (there is a number that should be 72 instead of 18, see comments).
The pre-simulation constants should be corrected. By making the choice of setting the parameters a
and b
from the beginning, before the choice of the variant BB or BC, and the introduction of the variable switched_params
, there is a disparity with the formulas presented in the paper. In the paper, they set the variables a
and b
as the min and max respectively for the BB algorithm, but they do the other way around for the BC algorithm!! Making confusion in the formulas when coding! (You can check this in the first line of each algorihtm in the paper).
Thanks for the detailed review! I overlooked that the definition for I don't think there is a typo in the paper, as far as I can see, the division by for was absorbed in the numerator, so the denominator should not be affected. |
This should be faster than the gamma variate transformation we are currently using, and it seems to work better for parameters smaller than one. The algorithm is also used by the R language, however I did not consult their implementation in order to avoid licensing problems. Reference: R. C. H. Cheng (1978). Generating beta variates with nonintegral shape parameters. Communications of the ACM 21, 317-322. https://doi.org/10.1145/359460.359482
Now that the algorithm is fixed, we are doing much better with performance: This PR:
master:
|
Great!! Thank you very much!! I agree with all the changes, and sorry about the "typo" of the constants, it was my own mistake: it is right the way it is in the code and the paper. |
rand_distr/CHANGELOG.md
Outdated
@@ -4,6 +4,9 @@ All notable changes to this project will be documented in this file. | |||
The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/) | |||
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). | |||
|
|||
## [Unreleased] | |||
- Improve algorithm for sampling `Beta` (#1000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be a little more specific?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to "New Beta
sampling algorithm for improved performance and accuracy".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you both happy with the code now?
I am happy with the code :) |
@dhardy I'm happy with the code, too. Could you please approve the PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing. Thanks for the review, Raimundo.
Fixes #999.
cc @rasa200