You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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
andGamma
).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:
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) andgsl_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:
choose
andshuffle
guaranteed to be the same across versions? #586 asks about stability ofchoose
andshuffle
The text was updated successfully, but these errors were encountered: