Another crucial use of NaNs is if you have a sensor. If the sensor has failed, the sensed value should be transmitted as NaN, not 0, so the receiver knows the data is bad.
Do not mask the invalid operation exception, which was actually the original recommendation of the IEEE standard, which was that the default behavior should be to mask all exceptions, except the invalid operation exception.
When the invalid operation exception is not masked, NaNs are never generated and any NaN present in the input data will generate an exception, which will abort the program, unless the exception is handled.
This behavior avoids the bugs caused by careless programmers. Unfortunately, the original suggestion was not adopted by most programming language implementers, so nowadays the typical default setting is to have all exceptions masked. When the programmers also omit to handle the special values, bugs may remain unnoticed.
Special values need not be handled everywhere, because infinities and NaNs will propagate through many operations, so they will remain in the final results. But wherever a value is not persistent, but it is used in some decision and it is discarded after that, special values like NaNs must be handled correctly.
I think your initialization is smart in many use cases, but the sensor application probably isn’t one of them except for that single failure mode. It can still lead to masked failures and false assumptions (“the sensor is getting a value so it must be working”). That’s the same issue as what you’re supposedly fixing by that design choice. It still requires engineering knowledge to assess correctly.
The point of a NaN value is it does not require sophisticated engineering knowledge to realize that a NaN output is not what you're expecting.
Bold assumption. I would be willing to bet this is more the exception than the rule on most sensors/systems.
>The point of a NaN value is it does not require sophisticated engineering knowledge to realize that a NaN output is not what you're expecting.
What I was pointing out is this only captures a relatively narrow set of failure modes and may lead to bad assumptions due to automation bias. E.g., "I only need to think about failures if the sensor gives an NaN because it's based on the assumption that a failure produces an NaN" whereas having an actual principled knowledge of operation can catch the other errors.