-
Notifications
You must be signed in to change notification settings - Fork 32
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
Consider changing naming convention to indicate squared distances #40
Comments
I see the confusion. Definitely at the very least the documentation for the I originally choose not to put the word |
Actually, one small counterpoint to the point about squared distances being unanimous: Some parameters are actually not squared, such as |
Yes, you are right dhat and dmin are unsquared. |
Just spent some time scratching my head with
CollisionConstraints::compute_minimum_distance
. The documentation says it returns the minimum distance, but I found this in the implementation:// NOTE: Actually distance squared
I realize that you're basically working with squared distances throughout (although for an outside user it is not clear if this holds in all cases), but it's still very confusing that "distance", which is a very unambiguously defined term in my opinion, actually means "squared distance". In my opinion, it would reduce confusion a lot for the new users and possible contributors if squared distances were always marked as such, e.g. by using naming like
compute_squared_distance
,compute_distance2
or similar.(I labeled this as "bug" as, if you take the documentation and function names at their face value, what is returned is not what the naming suggests)
The text was updated successfully, but these errors were encountered: