#665 should get merged after any changes to the C implementation to validate against macos (which was our canary that something was up).

So, in general, here are the changes:

• The public encode function that receives lat and lng in floats:
  • Multiply each by the precision and truncate to an integer
  • Add latitude max degrees (90) * lat max precision (2.5e7) to the latitude integer and then clip it:
    • If latitude is less than zero, set it to zero
    • If it is greater than or equal to 2 x 90 x 2.5e7, set it to 2 x 90 x 2.5e7 - 1
  • Add longitude max degrees (180) * lng max precision (8.192e6) and then normalise it:
    • If longitude is less than zero, get the modulo remainder of longitude with 2 x 180 x 8.192e6, and then add 2 x 180 x 8.192e6
    • If longitude is greater or equal to 2 x 180 x 8.192e6, then get the modulo remainder of longitude with 2 x 180 x 8.192e6
• Then the rest of encoding can stay the same.
• The clipLatitude() and normaliseLongitude() functions, if there were any, might be able to be removed. (They might still be used for a decode nearest, where the precision isn't so important.)

Just VisualBasic to go!

Once that's done, cut a new release (1.0.5) of the project so that the JS CDNs update.

Since the splitting has turned out to not be necessary, and the only implementation I actually split was C, I'm going to merge them back together.

As per the comment in #716 (comment), once I add tests that confirm a code's bounding box contains the original coordinates I get failures. It doesn't matter whether I use Round() or Floor() in the conversion from float to integer, because the issue is with the accuracy of the float representation.

So I thought I wasn't going to have to do all this but it looks as though I will.

Quick reality check - in #716, you state that this mostly happens for 15-digit plus codes. I'm not sure these play a large role in real-world applications, since they have sizes of only some square millimeters, likely smaller than precision/accuracy of the devices they are used on.

Perhaps it would be a sensible alternative to further restrict valid code lengths instead?

Hi @bocops good to hear from you!

I don't think restricing the code length gets us out completely because at least part of the issue is floating point precision. The tests are using "0.1" in the csv file but when it's read in and converted to a float, IEEE-754 means that you actually get 0.1000000000002 (or something) and the difference is sufficient to cause failures.

Also converting the floats to integers using rounding is wrong (issue #717) and I need to address that first.

(I'm on vacation for a week so will think about it and update once I get back.)

Due to issue #717 it's apparent that I still need to do this. For example, with a longitude of 129.7:

• Multiplying by the precision 8.192e6 should provide an integer value 1062502400, but in golang you get 1062502399: https://go.dev/play/p/gkniS5Tjss5

So since we can't even do simple arithmetic (thanks IEEE 754) I'm going to have to do this split (and add tests for the conversion functions).