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

Improve the Readme #87

Merged
merged 15 commits into from
Dec 20, 2018
Merged

Improve the Readme #87

merged 15 commits into from
Dec 20, 2018

Conversation

nbraud
Copy link
Collaborator

@nbraud nbraud commented Dec 11, 2018

  • Reorganised things to separate convenience accessors, math operators, and methods.
  • Documented various notations that weren't mentioned.
  • Specified the behaviour of vector negation and the range of Vector2.angle.
  • Fixed errors in the documentation of scale and truncate.

Return the normalized `Vector2` for the given `Vector2`.
### normalize()

Return a vector with the same direction, and unit length.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Love this change.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

<3

@nbraud
Copy link
Collaborator Author

nbraud commented Dec 11, 2018

@pathunstrom The CI is going to fail because there's one doctest issue I'm unsure how to handle:

Failed example:
    Vector2(1, 0).rotate(90)
Expected:
    Vector2(0.0, 1.0)
Got:
    Vector2(6.123233995736766e-17, 1.0)

Ideally, I would like Vector2.rotate to produce the right result, but the previous rounding behaviour introduced a bunch of quirks that were pretty undesireable.
I think it should be possible to make it happen by selecting values of cos_r and sin_r such that their sum of squares is closer to 1 (i.e. values that preserve the vector length better), but that sounds like a non-trivial thing to do.

@AstraLuma
Copy link
Member

We could also special case multiples of 90deg? I suspect that'll come up with more problems

@nbraud
Copy link
Collaborator Author

nbraud commented Dec 11, 2018

@astronouth7303 Do you mean that special-casing multiples of 90 degrees will come with more problems, or that solving the general problem will?

nbraud added a commit to nbraud/ppb-vector that referenced this pull request Dec 11, 2018
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)
@nbraud nbraud mentioned this pull request Dec 11, 2018
3 tasks
@nbraud
Copy link
Collaborator Author

nbraud commented Dec 11, 2018

@astronouth7303 Fixed in #89

nbraud added a commit to nbraud/ppb-vector that referenced this pull request Dec 11, 2018
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)
nbraud added a commit to nbraud/ppb-vector that referenced this pull request Dec 16, 2018
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)
@nbraud
Copy link
Collaborator Author

nbraud commented Dec 20, 2018

Could someone rerun the build?
Since #89 was merged, the CI failure should now be fixed.

@nbraud
Copy link
Collaborator Author

nbraud commented Dec 20, 2018

Nevermind, I had to rebase anyway now that #79 was merged, so I could add documentation for vector-scalar division.

@AstraLuma
Copy link
Member

How likely is the doctest stuff to break? I'm nervous that Floating Point will happen.

@nbraud
Copy link
Collaborator Author

nbraud commented Dec 20, 2018

@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 normalize, scale, truncate, and reflect; I guess I can fix that :)

scale_to may now overflow with vector lengths larger than 1e75,
which is a non-issue.
@nbraud
Copy link
Collaborator Author

nbraud commented Dec 20, 2018

Mmmh, can't brain enough r.n. to find some exact values for reflect.
I say we just deal with it if it comes up.

@AstraLuma AstraLuma merged commit 6d1ae36 into ppb:master Dec 20, 2018
@nbraud nbraud deleted the readme branch December 21, 2018 01:05
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.

3 participants