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
Right now only those two distributions are not generic over float type. For consistency it could be nice to make them generic as well, probably with an additional trait bound specific to Ziggurat.
The text was updated successfully, but these errors were encountered:
Wouldn't this just make them a pain to use? For the parametrised distributions, the Float type can be inferred from arguments, but without arguments it must be explicit for these distributions. Of course the trade-off is that sampled values may have their type inferred.
I was thinking about potential uses with custom float types (e.g. SIMD vectors), but looks like in the current form Float trait is not well suited for that. Feel free to close this issue.
At a minimum, SIMD support would require a redesign of the ziggurat function; this is currently internal; to allow external crates to implement SIMD would require making it a public trait. I'm not sure we want that.
The num-traits author makes a good point about expermental crates building on conservative ones, but in this case we'd have to significantly adjust rand_distr to allow this and expect the SIMD crate to implement a variant of ziggurat.
In my opinion it would be better to keep this within rand_distr (though potentially still with a trait, to allow impl<F: Ziggurat> Distribution<F> for Exp1).
Right now only those two distributions are not generic over float type. For consistency it could be nice to make them generic as well, probably with an additional trait bound specific to Ziggurat.
The text was updated successfully, but these errors were encountered: