-
-
Notifications
You must be signed in to change notification settings - Fork 480
Description
In the past we have changed sampling algorithms for the Uniform integer and float implementations, thus breaking value stability. There is a good chance we will wish to do the same with some other algorithms in the future (e.g. Normal and Gamma).
We have yet to develop a policy for how to handle this (but see the note on portability in the book). Two things are clear:
- value-breaking changes should not be included in patch releases, excepting bug fixes
- we should add test vectors to all algorithms to detect such breaking changes
Also: changing the algorithm behind an implementation does not change the semantics of the API or cause build issues, thus IMO we should allow algorithm changes in minor releases even after 1.0.
One extra thing we could do is keep multiple implementations under the names of their methods, e.g. GSL has gsl_ran_gamma, gsl_ran_gamma_mt (the same impl) and gsl_ran_gamma_knuth which all implement the same distribution. I'm not keen on doing this everywhere because of the extra code and API, but this might have its uses (e.g. #763).
Are these guidelines sufficient?
Relevant links:
- Are
chooseandshuffleguaranteed to be the same across versions? #586 asks about stability ofchooseandshuffle - Investigate replacing Ziggurat sampling with ETF rand_distr#9 mentions other possible algorithms
- Compromising accuracy and speed [distributions] #494 has another reason for desiring multiple implementations in some cases