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

geometry::Arc: use angles for start and end #1609

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

rmburg
Copy link
Contributor

@rmburg rmburg commented Jan 27, 2025

Why? What?

What the title says. Previously, we used Point2s for the start and end points of arcs.
This made arcs over-defined. A neat side effect of this change is reduced complexity of most of the affected calculations.

ToDo / Known Issues

It's perfect

Ideas for Next Iterations (Not This PR)

It's perfect

How to Test

Stare at the code.
I can add more unit tests if there are any areas where you are unsure if the changes are correct.

@rmburg rmburg added the is:Refactoring No changes in functionality, only in coding style. label Jan 27, 2025
@knoellle knoellle self-assigned this Jan 27, 2025
Copy link
Member

@schmidma schmidma left a comment

Choose a reason for hiding this comment

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

only a few comments, leaving the approval to @knoellle as he is assigned to this PR

@@ -78,14 +78,14 @@ impl<Frame> LineSegment<Frame> {
self.signed_acute_angle_to_orthogonal(other).abs() < epsilon
}

pub fn projection_factor(&self, point: Point2<Frame>) -> f32 {
pub fn projection_factor(&self, point: &Point2<Frame>) -> f32 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To save a copy here. filter only gives me a reference.

.filter(|intersection_point| {
(0.0..1.0).contains(&self.projection_factor(intersection_point))
})

Copy link
Contributor

Choose a reason for hiding this comment

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

Those two floats are probably in a register already or the function may be optimized away completely.
I think we copy our linear algebra types almost everywhere.

"Optimizations" at this level are irrelevent I think

Copy link
Contributor Author

@rmburg rmburg Feb 19, 2025

Choose a reason for hiding this comment

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

I completely agree, this was not meant as an optimization, but more of an ergonomics thing. I could just as well create an explicit copy in filter.

@rmburg rmburg requested a review from knoellle February 5, 2025 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:Refactoring No changes in functionality, only in coding style.
Projects
Status: Request for Review
Development

Successfully merging this pull request may close these issues.

3 participants