FFP | Fast FIX

-fno-rounding-math is the gcc default. It enables optimisations which assume no-rounding IEEE arithmetic. -frounding-math turns these optimisations off. The switch itself does not change the rounding behaviour, and thus does not change whether the macro is defined.

For the record, this ...

The macro NAN is defined if and only if the implementation supports quiet NaNs for the float type. It expands to a constant expression of type float representing a quiet NaN.

... is C17 7.12/5, and it probably has the same or similar numbering in C2x.

Updated

The fact that when used with MSVC or Clang on Windows, your test program causes the FE_INVALID FP exception to be raised suggests that the combination of

• Microsoft's C standard library and runtime environment with
• the MSVC and Clang compilers and
• the options you are specifying to those

is causing a signaling NaN to be generated and used as an arithmetic operand. I would agree that that is an unexpected result, probably indicating that these combinations fail to fully conform to the C language specification in this area.

has nothing to do with whether the resulting NaN is a quiet or a signaling one. The misconception there is that the FE_INVALID flag would be raised only as a consequence of generating or operating on a signaling NaN. That is not the case.

For one thing, IEEE-754 does not define any case in which a signaling NaN is generated. All defined operations that produce an NaN produce a quiet NaN, including operations in which one operand is a signaling NaN (so MSVC and Clang on Windows almost certainly do produce a quiet NaN as the value of the NAN macro). Most operations with at least one signaling NaN as an operand do, by default, cause the FE_INVALID flag to be raised, but that is not the usual reason for that flag to be raised.

Rather, under default exception handling, the FE_INVALID flag is raised simply because of a request to compute an operation with no defined result, such as infinity times 0. The result will be a quiet NaN. Note that this does not include operations with at least one NaN operand, which do have a defined result: a quiet NaN in many cases, unordered / false for comparisons, and other results in a few cases.

With that for context, it is important to recognize that just because NAN expands to a constant expression (in a conforming C implementation) does not mean that the value of that expression is computed at compile time. Indeed, given the specifications for MSVC's and Clang's strict fp modes, I would expect those modes to disable most, if not all, compile-time computation of FP expressions (or at minimum to propogate FP status flags as if the computations were performed at run time).

Thus, raising FE_INVALID is not necessarily an effect of the assignment in f = NAN. If (as in Microsoft's C standard library) NAN expands to an expression involving arithmetic operations then the exception should be raised as a result of the evaluating that expression, notwithstanding that the resulting NaN is quiet. At least in implementations that claim full conformance with IEC 60559 by defining the __STDC_IEC_559__ feature-test macro.

Therefore, although I will not dispute that

people may wonder: "how writing to memory may cause raising floating-point exceptions?".

, no convincing evidence has been presented to suggest that such causation has been observed.

Nevertheless, the value represented by a particular appearance of NAN in an expression that is evaluated has some kind of physical manifestation. It is plausible for that to be in an FPU register, and storing a signaling NaN from an FPU register to memory indeed could cause a FP exception to be raised on some architectures.

Because it is a bug in the Universal CRT.

The OP was under impression that term conversion implies only implicit conversion and explicit conversion (cast operation) (see C11 6.3 Conversions). Meaning that OP was under impression that term function is not a conversion.

However, C11 F.3 Operators and functions (emphasis added) explicitly states that:

The lrint and llrint functions in provide the IEC 60559 conversions.

Hence, yes, C11 F.4 Floating to integer conversion (emphasis added) answers the question:

F.4 Floating to integer conversion

1    ... Otherwise, if the floating value is infinite or NaN or if the integral part of the floating value exceeds the range of the integer type, then the ‘‘invalid’’ floating-point exception is raised and the resulting value is unspecified. ...

Without -ffloat-store, GCC targeting x87 does violate the standard: it keeps values un-rounded even across statements. (-mfpmath=387 is the default for -m32). Assignment like double x = y; is supposed to round to actual double in ISO C++, and probably also passing a function arg.

So I think your code is safe for ISO C++ rules, even with the FLT_EVAL_METHOD == 2 that GCC claims to be doing. (https://en.cppreference.com/w/cpp/types/climits/FLT_EVAL_METHOD)

See also https://randomascii.wordpress.com/2012/03/21/intermediate-floating-point-precision/ for more about the real-world issues, with actual compilers for x86.

https://gcc.gnu.org/wiki/x87note doesn't really mention the difference between when GCC rounds vs. when ISO C++ requires rounding, just describes GCC's actual behaviour.

PATH variable isn't updated correctly, $PATH is not makefile syntax. Fix:

Not sure why you use pandas - you can do this using simple python with no imports whatsoever:

I didn't see anything wrong but I think you can save the image without using the open method. Also, you can paste on your mat image and save it as another image with save

The reason the Numpy implementation is much faster is that it does not compute the same thing as the two others.

Indeed, the python version does not read z in the expression np.sin(x) * np.cos(x). As a result, the Numba JIT is clever enough to execute the loop only once justifying a factor of 100 between Fastor and Numba. You can check that by replacing range(100) by range(10000000000) and observing the same timings.

Finally, XTensor is faster than Fastor in this benchmark as it seems to use its own fast SIMD implementation of exp/sin/cos while Fastor seems to use a scalar implementation from libm justifying the factor of 2 between XTensor and Fastor.

Answer to the update:

Fastor/Xtensor performs really bad in exp, sin, cos, which was surprising.

No. We cannot conclude that from the benchmark. What you are comparing is the ability of compilers to optimize your code. In this case, Numba is better than plain C++ compilers as it deals with a high-level SIMD-aware code while C++ compilers have to deals with a huge low-level template-based code coming from the Fastor/Xtensor libraries. Theoretically, I think that it should be possible for a C++ compiler to apply the same kind of high-level optimization than Numba, but it is just harder. Moreover, note that Numpy tends to create/allocate temporary arrays while Fastor/Xtensor should not.

In practice, Numba is faster because u is a constant and so is exp(u), sin(u) and cos(u). Thus, Numba precompute the expression (computed only once) and still perform the sum in the loop. The following code give the same timing: