C Compiler options may change AT results

[lfarv]

When running the Matlab tests comparing Matlab and python results on macOS with arm processor, it appeared that for the 1st time, the results of simple tracking differ. Since the tracking is performed in pure C, we expected up to now that results were strictly identical. When running on arm processor they are sightly different, by about 1.0e-20 relative difference.

It appeared that this comes from different compiler options set by setup.py on one side and mex on the other side. More precisely, the -ffp-contract option is left to default in setup.py and forced to -ffp-contract=off by mex on macOS (any processor).

This option is available in both gcc and clang on all platforms. From the clang documentation:

"Specify when the compiler is permitted to form fused floating-point operations, such as fused multiply-add (FMA). Fused operations are permitted to produce more precise results than performing the same operations separately.

The C standard permits intermediate floating-point results within an expression to be computed with more precision than their type would normally allow. This permits operation fusing, and Clang takes advantage of this by default."

The behaviour of this option is difficult to predict since:

• its default value depends on the optimisation options (-O, -O2…), and on the compiler (gcc or clang),
• its effect depend on the processor (can it perform the so-called "fused multiply-add").

From a google search, it seems that FMA operation usually give more accurate results by minimising rounding errors, but may give completely crazy results in some conditions… I could not find why mex disables them on macOS.

Practically, the difference is negligible for AT results, and there seems to have no effect on Ubuntu or macOS Intel. So I propose to put in setup.py the same option as in mex, just to have the comparison tests succeed in all cases.