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

Constrain coslon in _geoAzDistanceRads #213

Merged
merged 2 commits into from
Mar 28, 2019

Conversation

isaacbrodsky
Copy link
Collaborator

#212

This needs additional tests to cover all the branches in this function. Lcov doesn't report it, but the branches around lines 250~253 are uncovered. Lcov only reports lines, so we don't know about untested code like this. If we can't have the coverage tool we use report branch coverage, we should consider setting the formatter to put the branch condition always on a new line.

It looks like the vertex issue is likely a copy+paste error resulting in coslon being tested but sinlon being constrained. After fixing the index 87dc6d364ffffff and it's neighbors look right.

Unrelated to this, I noticed that we are using long double constants in this file, which I don't think is necessary since the library was changed to use doubles. I changed the constants in this function but not the other places in the library.

@@ -221,36 +221,36 @@ void _geoAzDistanceRads(const GeoCoord* p1, double az, double distance,
if (fabs(p2->lat - M_PI_2) < EPSILON) // north pole
{
p2->lat = M_PI_2;
p2->lon = 0.0L;
p2->lon = 0.0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

What if anything is the affect of removing the L suffix? Do we lose precision? I'm guessing no, just wanted to understand if this is expected to be a no-op.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

p2->lon is a double, so this should have the same result.

The comparisons using long doubles are different, I assume in those cases the double variables are promoted to long doubles for the purpose of comparison. I believe that could possibly have issues in edge cases.

@coveralls
Copy link

coveralls commented Mar 27, 2019

Coverage Status

Coverage remained the same at 100.0% when pulling d6d3c1b on isaacbrodsky:constrain-coslon into 643d8e4 on uber:master.

@isaacbrodsky isaacbrodsky merged commit b714793 into uber:master Mar 28, 2019
@isaacbrodsky isaacbrodsky deleted the constrain-coslon branch March 28, 2019 00:34
mrdvt92 pushed a commit to mrdvt92/h3 that referenced this pull request Jun 19, 2022
Constrain `coslon` in `_geoAzDistanceRads`
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.

5 participants