bug: The functions "h3_exact_edge_length_m" and "h3_exact_edge_length_km" may exhibit cross-platform inconsistencies in floating-point values.

[ct20000901]

Search before asking

• I had searched in the issues and found no similar issues.

Version

What's Wrong?

however, the expected output is:

This problem causes my unit test to fail.

How to Reproduce?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[ct20000901]

It appears that all functions related to "geo_h3" may experience similar issues with cross-platform floating-point inconsistencies. cc @ariesdevil. Thank you very much, and I appreciate your assistance.

[ariesdevil]

@ct20000901 The core issue in this situation is caused by the bit width provided by different float processor registers. This was addressed by IBM when they provided an 'Extended Precision' extension in their standard. This extension allows the float bit width to be expanded to 80-bit. For instance, the Motorola 88k architecture employs this extension, as does Apple (iOS and today's M-series).

The specific differences in parameters are explained in the link below, which discusses the relationship and specifics of processor register precision:
https://en.wikipedia.org/wiki/Processor_register

In other words, this is a computer problem.

[ct20000901]

@ct20000901 The core issue in this situation is caused by the bit width provided by different float processor registers. This was addressed by IBM when they provided an 'Extended Precision' extension in their standard. This extension allows the float bit width to be expanded to 80-bit. For instance, the Motorola 88k architecture employs this extension, as does Apple (iOS).

The specific differences in parameters are explained in the link below, which discusses the relationship and specifics of processor register precision: https://en.wikipedia.org/wiki/Processor_register

In other words, this is a computer problem.

I understand this, but it may cause unit tests to fail on the macOS platform. Therefore, it might be necessary to modify the test cases or optimize this part to address the issue?

[ariesdevil]

@ct20000901 I create a new issue for this, we may need to refactor all float-point return value tests like this one.