Update 2023-11-18 /fp:strict does not mean what I thought it meant. /fp:pecise (and the default) is what I am looking for. Except I think, for VCRayApp, that /fp:fast is good enough and it implies fp:contract.
https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior.
I also need to consider whether /fp:contract is worth employing, a feature that is new in VS 2022. This allows hardware combined-operations such as FMA (floating multiply and add) to be introduced as part of expression optimization. The effect is no rounding of the intermediate result. That rather seems like a good idea although it leads to portability issues. (This is implied by fp:fast so I don't have to consider it separately.)
When I dive into raymath.h, that may assist in determining what the benefit is, and whether the impact on portability is worth it. It will be tricky to show the impact, something that is needed in numerical exercises demonstrating math and raymath.
Update 2023-11-18
/fp:strictdoes not mean what I thought it meant./fp:pecise(and the default) is what I am looking for. Except I think, for VCRayApp, that/fp:fastis good enough and it impliesfp:contract.https://learn.microsoft.com/en-us/cpp/build/reference/fp-specify-floating-point-behavior.
I also need to consider whether
/fp:contractis worth employing, a feature that is new in VS 2022. This allows hardware combined-operations such as FMA (floating multiply and add) to be introduced as part of expression optimization. The effect is no rounding of the intermediate result. That rather seems like a good idea although it leads to portability issues. (This is implied byfp:fastso I don't have to consider it separately.)When I dive into
raymath.h, that may assist in determining what the benefit is, and whether the impact on portability is worth it. It will be tricky to show the impact, something that is needed in numerical exercises demonstratingmathandraymath.