I am the OP. While I identified inconsistencies between platforms, float sizes, and with respect to documentation, I never considered what propagation issues there might be.I may be misreading the OP but if -nan is interpreted and nan and nans are infs , and it's inconsistent across different datatypes on the same platform, it seemed a reasonable conclusion that nan would not propagate correctly.
My presumption is, that even if the printed value is not how one expects, we have two sets of values, a set of 'valid number value' and a set of 'not a valid number'; nan, -nan, inf, -inf. So long as 'not a valid number' remains as 'not a valid number' that would be suitable propagation. Propagation may not however match what a 'isnan' would be expecting.
I would have used some kind of 'value isn't valid' flag and not care whether propagation had worked, ideally would have skipped the maths when the flag is set. I expect your code is an equivalent to that.I'd already moved to a fortanny solution to get my code working. I did not keep a copy of what did not work.
There's this - https://github.com/raspberrypi/pico-sdk/issues/1582 - which seems to have come from MicroPython which may be what was previously noted. That has been punted down the road to being fixed in SDK 2.3.0 and may get punted again. MicroPython currently appear to be using their own code to handle floats, single and double, rather than rely upon the SDK or other implementation.Isn't there even a bug report on these inconsistent nans?
I don't know what else there is or how to find out rather than looking through all the GitHub issues etc.
It seems to me there are a number of things which need to be done to properly resolve the issue.
That may be an interesting challenge given that native GCC is arguably wrong. Do we consider native GCC correct and say matching that is the proper solution or do we say that's wrong, and implement the correct solution and accept that won't match what native GCC does ?
I would suggest that, whatever is done, things should be consistent between single and double floats and the documentation should accurately reflect what is done. Neither seem to currently be the case.
Maybe you could raise the issue ?
Statistics: Posted by hippy — Mon Oct 27, 2025 1:28 pm