Fix Color precision error in the documentation generated on M4 macOS.

[bruvzg]

Running doctool on M4 Pro macOS (not reproducible on M1) result in unnecessary diffs.

The issue is related to use of atan2f and precision of π:

ok_color.h header define π as 3.1415926535897932384626433832795028841971693993751058209749445923078164062 which is rounded to the nearest representable float value 3.14159274101257324219, but atan2f(-0.0, -0.0) (and some other math functions with negative argument) seems to round it the other way and return 3.14159250259399414062 (previous representable value, one bit less).

[lawnjelly]

To be honest I'm not sure this is the right / best way to solve this.

Rounding errors are expected to be different on different platforms.

To elaborate:

• The documentation is essentially asserting that you'd get the same result when running doctool on a different platform, which is NOT the case for floating point.
• Changing the core code to bodge around this is kind of a case of the "tail wagging the dog", so to speak. It will slow down these functions, just to work around a bug / design flaw in the doctool.
• Now there could be a case for doing this for numerical reasons in core, but that case should be made separately as the result of a real problem seen by users, as it has a cost.

As for some other ideas how to solve:

• Have the doctool use a limited number of sig figs such that these rounding errors don't change the result.
• Also could cap values close to 0 and 1 (or maybe all whole numbers) to the whole number if they are within a small margin.

[akien-mga]

As for some other ideas how to solve:

• Have the doctool use a limited number of sig figs such that these rounding errors don't change the result.
• Also could cap values close to 0 and 1 (or maybe all whole numbers) to the whole number if they are within a small margin.

Yeah I agree that something like this may be a better approach.