You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This makes sense of course as we divide by the magnitude! However it can be a little tricky for newer users to hunt down the source of these NaNs.
Processing solves this by first checking if the magnitude is zero and if so returns [0, 0]. This is a little more expensive but perhaps also a little more user-friendly?
Perhaps we could leave the normalize method as is and instead add a new method which does this check? Currently it looks like the only solution for users is to 1. check that v.magnitude() > 0.0 before calling normalize() (this means that magnitude ends up gettinng calculated twice) or 2. implement their own normalize function.
I picked the cgmath because it’s marketed as “for games/CG” and this behavior is totally useless in games/CG
adding checked_normalize is one option, but IMO, should just change magnitude to return 0 in this case. it aligns better with the project goals, and I seriously doubt anybody is relying on this behavior for anything— pragmatism is cool in “games/CG”.
This makes sense of course as we divide by the magnitude! However it can be a little tricky for newer users to hunt down the source of these NaNs.
Processing solves this by first checking if the magnitude is zero and if so returns [0, 0]. This is a little more expensive but perhaps also a little more user-friendly?
Perhaps we could leave the
normalize
method as is and instead add a new method which does this check? Currently it looks like the only solution for users is to 1. check thatv.magnitude() > 0.0
before callingnormalize()
(this means that magnitude ends up gettinng calculated twice) or 2. implement their own normalize function.cc @JoshuaBatty
The text was updated successfully, but these errors were encountered: