-
Notifications
You must be signed in to change notification settings - Fork 428
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
Make distributions generic / impl for f32 #785
Conversation
Note that initial attempts to make |
@vks would you be able to review? |
I wonder whether it would make sense to make the parameter an associated type of |
let x: f64 = self.sample(rng); | ||
x as f32 | ||
} | ||
} |
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.
What is the motivation of this? To exercise the type change and optimize later? As of now, it does not seem worth to add this, when dist.sample(&mut rng) as f32
is equivalent.
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.
Yes, an optimised impl can follow later. Even like this though it helps with some generic coding.
Remember, the (unparameterised) |
That is a good point, it would make using unparametrized distributions much more cumbersome, so the current approach is probably best for now. |
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.
Looks good! I think this is the way we want the interface to look like.
Implement #100: impl for
f32
and make distributions generic over the parameter type.Status: partial type changes only. I haven't started on optimising the algorithms, but have found a few resources of interest.
So far I am liking the way this is going. A few extra type annotations are needed but not many due to the language's preference to resolve floats as
f64
(example).This adds a dependency on the
num-traits
crate, but only forrand_distr
; I think this is acceptable.Slight annoyance:
NumCast::from
returns anOption
, thus requires.unwrap()
(less concise and compiler cannot prove there is no panic). We could instead usestd::comvert::From
, but this would require an extra bound:N: From<f32>
.