Fix for a corner-case numerical problem and corresponding unit test.

[EdFuentetaja]

Thank you for this excellent library.

I noticed this problem decoding some ADS-B messages. The local airborne decoding failed is some particular cases.

There seems to be some oddities with the Python modulus operator. E.g.:

>>> 30.508474576271183 % 6.101694915254237
6.101694915254235
>>> import math
>>> def mod(x, y):
...     return x - y * math.floor(x / y)
...
>>> mod(30.508474576271183, 6.101694915254237)
0.0

Checking the standard (1090 MOPS, Vol.1 DO-260C), section 1.7.5 in Appendix A, shows an equivalent and simpler expression that doesn't require use of a modulus function. I think this should be the preferred approach since it's more accurate and requires less computations.

[xoolive]

The correct message here (with CRC) would be 8d06a15358bf17ff7d4a84b47b95

[EdFuentetaja]

Thanks for this. I added the CRC to the message.

[xoolive]

Thanks for pointing that out!
I have a related question: are there any required changes in the decoding of surface messages as well?

[EdFuentetaja]

Thanks for pointing that out! I have a related question: are there any required changes in the decoding of surface messages as well?

You are right, it's the same situation. I just applied the same fix there.

In general, given the odd behavior of the % operator, I would replace it everywhere by its definition:

def mod(x,y):
    return x - y*math.floor(x / y)

I'd like to know more about how the % operator is implemented in Python to understand where the numerical error is coming from.

[EdFuentetaja]

Python's % operator is mostly a call to the fmod C function. On x86 with -ffast-math this is implemented with a call to the fprem CPU instruction, which is affected by the same numerical problem. I think this is a very peculiar corner case.
Numerically accurate computation is hard. I'd follow the recommendation of the standard and implement MOD as stated in A.1.7.2.c:

MOD(x, y) = x - y floor(x/y) where y ≠ 0.

[xoolive]

Yes nice comment. We should look into more occurrences of calculations of j and m in this file.

FYI I did the same in my Rust version following your comment (current version here but opened issue and PR accordingly) and it seems the modulo in Rust behaves differently but has a similar issue.

[junzis]

Thank you, @EdFuentetaja. Awesome bug fix! we will fix the surface position functions too.

[EdFuentetaja]

Thank you @junzis and @xoolive. Is there anything else I could do you help this PR get merged? Thank you for the positive feedback.