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

Fix #91 #111

Merged
merged 1 commit into from Jan 29, 2022
Merged

Fix #91 #111

merged 1 commit into from Jan 29, 2022

Conversation

gzsombor
Copy link
Contributor

with an exact formula to calculate the number of vertices needed to approximate a circle

Copy link
Owner

@hannobraun hannobraun left a comment

Choose a reason for hiding this comment

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

Thank you, @gzsombor, this is awesome! I'm really enjoying getting rid of that crummy loop 😄

This looks great. I'm going to merge it. Especially good job on the testing!

I've left a bunch of comments, but all of those are just nitpicking on a high level. Definitely none of them are a blocker, and I'm going to merge the pull request right away. If you want to, feel free to address those in a follow-up PR. (Or if anyone else happens to come by, wanting to help out, that goes for you too.)

@@ -34,31 +34,7 @@ impl Circle {
// and the circle. This is the same as the difference between
// the circumscribed circle and the incircle.
//
Copy link
Owner

Choose a reason for hiding this comment

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

That empty comment line served as a separator between paragraphs in the comment, and is no longer necessary.

Suggested change
//

@@ -73,4 +49,46 @@ impl Circle {
out.push(point);
}
}

fn number_of_vertices(&self, tolerance: f64, radius: f64) -> i64 {
Copy link
Owner

Choose a reason for hiding this comment

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

We'll never have a negative number of vertices, so using i64 (or any other i type) seems slightly inappropriate.

Suggested change
fn number_of_vertices(&self, tolerance: f64, radius: f64) -> i64 {
fn number_of_vertices(&self, tolerance: f64, radius: f64) -> u64 {

Applying this change by itself will cause a build error. I'll try to leave suggestions in the other locations too, but I can't guarantee I caught them all. (edit: I missed all the ones in the tests)

if tolerance > radius / 2. {
3
} else {
(PI / (1. - (tolerance / radius)).acos()).ceil() as i64
Copy link
Owner

Choose a reason for hiding this comment

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

See comment about i64 above.

Suggested change
(PI / (1. - (tolerance / radius)).acos()).ceil() as i64
(PI / (1. - (tolerance / radius)).acos()).ceil() as u64

@@ -73,4 +49,46 @@ impl Circle {
out.push(point);
}
}

fn number_of_vertices(&self, tolerance: f64, radius: f64) -> i64 {
Copy link
Owner

Choose a reason for hiding this comment

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

This method doesn't access its &self argument, and I think it should be removed. It can then be accessed at the call site as Self::number_of_vertices, or in the tests as Circle::number_of_vertices.

Given the context of the call site, I think taking the radius here is the right choice. Taking &self in addition is unnecessary and confusing (see comment in test::verify_result).

An alternative would be to move it out of the impl block and make it a freestanding function. Doesn't make a difference really. I'd leave it where it is. It belongs to Circle, so having it in that namespace seems appropriate.

fn verify_result(tolerance: f64, radius: f64, n: i64) {
let circle = Circle {
center: Point::origin(),
radius: vector![100., 0., 0.],
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 a bit confusing. It gave me pause during the review, thinking you had forgotten to set the radius correctly here, but it is correct. number_of_vertices ignores self and gets the radius as a parameter.

If the situation were different, I'd suggest adding a short comment to explain here. But in this case, removing the &self argument (and hence the need for a Circle here) is the better solution. See comment above.

@hannobraun hannobraun merged commit ad3a80b into hannobraun:main Jan 29, 2022
@gzsombor
Copy link
Contributor Author

Thanks for the comments, yes, you're right, the self is not needed, and u32 is better type for counting things.

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

2 participants