-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Improve the Readme #87
Conversation
Return the normalized `Vector2` for the given `Vector2`. | ||
### normalize() | ||
|
||
Return a vector with the same direction, and unit length. |
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.
Love this change.
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.
<3
@pathunstrom The CI is going to fail because there's one
Ideally, I would like |
We could also special case multiples of 90deg? I suspect that'll come up with more problems |
@astronouth7303 Do you mean that special-casing multiples of 90 degrees will come with more problems, or that solving the general problem will? |
This solves an issue exposed in ppb#87, where imprecisions results in non-null components where the user would expect 0, for instance: >>> Vector2(1, 0).rotate(90) Vector2(6.123233995736766e-17, 1.0)
@astronouth7303 Fixed in #89 |
This solves an issue exposed in ppb#87, where imprecisions results in non-null components where the user would expect 0, for instance: >>> Vector2(1, 0).rotate(90) Vector2(6.123233995736766e-17, 1.0)
This solves an issue exposed in ppb#87, where imprecisions results in non-null components where the user would expect 0, for instance: >>> Vector2(1, 0).rotate(90) Vector2(6.123233995736766e-17, 1.0)
Could someone rerun the build? |
- scale(1) is equivalent to normalize(), not truncate(1); - truncate is better explained in terms of scale, than the reverse.
- Systematically use Vector2, not Vector. - Use the right floats in return values, not integers or incorrect values.
Also use tuples for the second operands everywhere, as it reduces line-noise.
Nevermind, I had to rebase anyway now that #79 was merged, so I could add documentation for vector-scalar division. |
How likely is the doctest stuff to break? I'm nervous that Floating Point will happen. |
@astronouth7303 Pretty unlikely? Floating point arithmetic is deterministic, so no random failures. A code change can still change the precision at which some values are computed, but the examples use exact values, except for |
scale_to may now overflow with vector lengths larger than 1e75, which is a non-issue.
Mmmh, can't brain enough r.n. to find some exact values for |
Vector2.angle
.scale
andtruncate
.