Skip to content

Make tests circular #676

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

Open
drinckes opened this issue Jan 10, 2025 · 4 comments
Open

Make tests circular #676

drinckes opened this issue Jan 10, 2025 · 4 comments
Assignees

Comments

@drinckes
Copy link
Contributor

The encoding tests should be circular - that is, the encoding test converts coordinates into a code, verify it is the correct code, and in addition, if the encoding was correct, it should decode and verify that the bounding box contains the original location.

Similar for the decoding tests, and possibly also the shorten and recover tests.

@drinckes
Copy link
Contributor Author

I'm not sure how necessary this is, and I'm kind of put off by the amount of code this will require to be added into every test implementation.

@drinckes
Copy link
Contributor Author

Hmm. Actually this looks like it's worthwhile. I'm testing golang and getting a bunch of failures. All the code lengths are >= 13 digits (mostly 15) so at least they're not across the common code lengths.

@drinckes
Copy link
Contributor Author

It looks as though at extremely high resolutions (code lengths of 15), we sometimes get the bounding box failing to contain the original coordinates.

The initial conversion of the coordinates to integer is Round(lat * 2.5e7) or Round(lng * 8.192e6). What appears to be happening is that the rounding is increasing the integer by one, which with a code length of 15 is sufficient for it to generate the adjacent code. (I assume it could happen with shorter lengths if the coordinate is close enough to the boundary value.)

The bounding box is produced by decoding, which doesn't have any rounding. (It computes the integer value and then just multiplies it by 2.5e7 (latitude) or 8.192e6 (longitude), so it's "correct".

I created a comparison of using either Round() or Floor() for this and Floor() seems like the better approach. It will always produce an integer value that will convert back to a float that is lower than or equal to the original coordinate, but the bounding box of the resulting code will also contain the original coordinate.

I'm going to modify the Go implementation, then use that to update the Encoding tests (the Decoding tests are ok). If that all works then it should be simple to modify all the subsequent implementations.

@drinckes
Copy link
Contributor Author

I'm going to pause PR #716 since doing it for integers will be all new.

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

No branches or pull requests

1 participant