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
feat!: Update strum
and ordered-float
dependencies and change From<LogProb> into TryFrom<LogProb> for NotNan<f64>.
#491
Conversation
Figure we'll need to change eventually.
3081213
to
2f1b29e
Compare
ordered-float ditched their From<f64> methods for NotNan and instead made them TryFrom<f64> (reem/rust-ordered-float@39f76bb). This change makes sense because From trait implementations generally shouldn’t panic, which the implementation did if the f64 was a NaN, and so TryFrom is more appropriate. This commit accounts for this change in the upgrade
`ndarray` has renamed `genrows()` to `rows()`
strum
cratesstrum
and ordered-float
crates
src/stats/probs/mod.rs
Outdated
@@ -403,7 +403,7 @@ impl From<NotNan<f64>> for LogProb { | |||
|
|||
impl From<LogProb> for NotNan<f64> { |
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.
Should probably also add a TryFrom
impl here for people who want to acknowledge the fact that the conversion is fallible.
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.
Hmm, that's more of a larger change, but would be consistent with the reasoning in unordered-float
@@ -43,7 +43,7 @@ use ordered_float::NotNan; | |||
/// ); | |||
/// abs_diff_eq!(integral.exp(), 0.682, epsilon=0.01); | |||
/// ``` | |||
pub fn ln_integrate_exp<T, F>( | |||
pub fn ln_integrate_exp<T, F, E>( |
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 think a PR changing the signature of a public method like this (which, granted, in most cases won't actually affect most users because the type will just be inferred, but will affect anyone who needs to specify any of the generic parameters) should probably not be labeled "chore", since "chore" PRs don't show up in the changelog.
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.
Would you classify it at a build:
then?
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 think it should be feat: actually, since the API is extended with a new feature here (allowing to have a fallible conversion from f64)
impl From<LogProb> for NotNan<f64> { | ||
fn from(p: LogProb) -> NotNan<f64> { | ||
NotNan::new(*p).unwrap() | ||
impl TryFrom<LogProb> for NotNan<f64> { |
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.
Sorry I was unclear but I would actually probably recommend leaving the (potentially-panicing) From
implementation for now in order to avoid breaking compatibility, but mark it as deprecated.
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.
unfortunately you don't seem to be able to implement a deprecated From
and a non-deprecated TryFrom
, as the blanket implementation (https://github.com/rust-lang/rust/blob/3e525e3f6d9e85d54fa4c49b52df85aa0c990100/src/libcore/convert.rs#L580) leads to the compiler thinking you've implemented TryFrom
already and so it won't compile.
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 prefer the tryfrom here, let's make this a breaking change (feat!:), then.
643b09a
to
c036645
Compare
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 like packed_simd is broken
src/stats/probs/mod.rs
Outdated
@@ -403,7 +403,7 @@ impl From<NotNan<f64>> for LogProb { | |||
|
|||
impl From<LogProb> for NotNan<f64> { |
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.
Hmm, that's more of a larger change, but would be consistent with the reasoning in unordered-float
impl From<LogProb> for NotNan<f64> { | ||
fn from(p: LogProb) -> NotNan<f64> { | ||
NotNan::new(*p).unwrap() | ||
impl TryFrom<LogProb> for NotNan<f64> { |
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.
unfortunately you don't seem to be able to implement a deprecated From
and a non-deprecated TryFrom
, as the blanket implementation (https://github.com/rust-lang/rust/blob/3e525e3f6d9e85d54fa4c49b52df85aa0c990100/src/libcore/convert.rs#L580) leads to the compiler thinking you've implemented TryFrom
already and so it won't compile.
@@ -43,7 +43,7 @@ use ordered_float::NotNan; | |||
/// ); | |||
/// abs_diff_eq!(integral.exp(), 0.682, epsilon=0.01); | |||
/// ``` | |||
pub fn ln_integrate_exp<T, F>( | |||
pub fn ln_integrate_exp<T, F, E>( |
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.
Would you classify it at a build:
then?
The conversion from LogProb is not guaranteed to succeed, so we use `TryFrom` instead of `From`, as per the Rust docs: ```Note: The From trait must not fail. The From trait is intended for perfect conversions. If the conversion can fail or is not perfect, use TryFrom.``` Note this does change the API.
c036645
to
096e156
Compare
@johanneskoester should probably take a look - I can chime in if he's not able to review in the next couple days. |
@@ -37,16 +37,16 @@ serde_derive = "1.0" | |||
approx = ">=0.3, <0.6" | |||
custom_derive = "0.1" | |||
newtype_derive = "0.1" | |||
ordered-float = "1.0" | |||
ordered-float = "2.0" |
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.
Once we're updating this... would it be possible to make this
ordered-float = "2.0" | |
ordered-float = ">=2, <4" |
There were breaking changes in 3.0.0, but if they don't break this crate then it would be preferable to allow users to decide which version they want.
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.
Sounds reasonable to me. @adam-azarchs are you sure that the breaking changes don't affect us here?
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.
Not 100%. They don't look like behavior changes, just some dropped implementations, so it should be easy enough to just try it and see if it compiles. I know for our internal purposes we're not going to be updating to 3.0 particularly soon but future proofing is good.
@@ -37,16 +37,16 @@ serde_derive = "1.0" | |||
approx = ">=0.3, <0.6" | |||
custom_derive = "0.1" | |||
newtype_derive = "0.1" | |||
ordered-float = "1.0" | |||
ordered-float = "2.0" |
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.
Sounds reasonable to me. @adam-azarchs are you sure that the breaking changes don't affect us here?
@@ -43,7 +43,7 @@ use ordered_float::NotNan; | |||
/// ); | |||
/// abs_diff_eq!(integral.exp(), 0.682, epsilon=0.01); | |||
/// ``` | |||
pub fn ln_integrate_exp<T, F>( | |||
pub fn ln_integrate_exp<T, F, E>( |
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 think it should be feat: actually, since the API is extended with a new feature here (allowing to have a fallible conversion from f64)
impl From<LogProb> for NotNan<f64> { | ||
fn from(p: LogProb) -> NotNan<f64> { | ||
NotNan::new(*p).unwrap() | ||
impl TryFrom<LogProb> for NotNan<f64> { |
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 prefer the tryfrom here, let's make this a breaking change (feat!:), then.
strum
and ordered-float
cratesstrum
and ordered-float
crates
Co-authored-by: Adam Azarchs <adam.azarchs@10xgenomics.com>
strum
and ordered-float
cratesstrum
and ordered-float
dependencies and change From<LogProb> into TryFrom<LogProb> for NotNan<f64>.
35c1c94
to
aa90c4e
Compare
The MSRV failure here has nothing to do with this PR (or, in fact with any changes in this repo). I have a fix for the MSRV build in another PR: #497 |
Figure it'll need to change eventually.