Skip to content
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

Implement clamp #377

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Implement clamp #377

wants to merge 4 commits into from

Conversation

jacg
Copy link
Contributor

@jacg jacg commented Sep 23, 2022

clamp has two distinct implementations, one in Ord (which floats aren't) and another in f{32,64}.

I don't know how to separate these inside uom.

@jacg jacg mentioned this pull request Sep 23, 2022
src/system.rs Outdated
@@ -1083,6 +1098,15 @@ macro_rules! system {
value: self.value.min(other.value),
}
}

#[inline(always)]
fn clamp(self, min: Self, max: Self) -> Self {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

src/system.rs Outdated
Comment on lines 762 to 769
pub fn clamp(self, min: Self, max: Self) -> Self
where
V: $crate::num::Float,
{
Quantity {
dimension: $crate::lib::marker::PhantomData,
units: $crate::lib::marker::PhantomData,
value: self.value.clamp(min.value, max.value),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is failing because it doesn't know where the value.clamp function is defined for the generic type V. The compiler is guessing the Ord trait because it is the only one with a clamp method. I see a couple solutions:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're going to raise the MSRV to 1.50.0, then I'd rather couple to the standard behaviour.

Create another storage_types! block just for float

You mean, alongside the one which already exists for Float and Complex?

If so, I'm getting something that compiles, but fails tests because of panics in the case that max < min. How do you put constraints on what quickcheck generates?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both my suggestions were in the context of raising the MSRV to 1.50. The first, using num::clamp, could be implemented in the impl<D, U, V> Quantity<D, U, V> ... block and would apply to all underlying storage types, however because it's using num::clamp it may not be as performant as a direct f32::clamp call. The second suggestion would be another storage_types! block that is just for float (the existing can't be used because Complex doesn't have a clamp method) and would essentially proxy f32/f64 clamp. I lean towards the second option.

Reject invalid test input using TestResult::discard();:

uom/src/tests/system.rs

Lines 112 to 114 in 7c4b27b

if !Test::approx_eq(&f1, &i1) {
return TestResult::discard();
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I add some #[should_panic] tests? If so, I'm not sure how these fit in to the test strucre.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, something like ??? with #[should_panic] can be added as a non-quickcheck test up around line 263.

@dnsco
Copy link

dnsco commented Oct 24, 2023

@iliekturtles Is there any way I can help get this merged?

The last failure seems to be about old MSRV

@iliekturtles
Copy link
Owner

@iliekturtles Is there any way I can help get this merged?

The last failure seems to be about old MSRV

@dnsco, @jacg I took a brief look and it seems like rebasing+squashing on master fixes the previous build failures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants