René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"IEEE floating point signalling bit can be inverted on MIPS (Python assumes its not)","articleBody":"Probably better links for this, but on MIPS, the floating point signalling bit seems typically inverted: https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html\r\n\r\nHowever, Python's [_Py_dg_stdnan](https://github.com/python/cpython/blob/45a9e3834a6ed20ee250e2e5a8583dffcef0eb73/Python/dtoa.c#L1409-L1418) should create quiet NaNs, but hard-codes the bit to 0.\r\n\r\nThis again continues to do weird things if mixed with NumPy apparently visible in some `fmin` downstream test failures (to be clear, I don't think the signalling bit _should_ matter for that, but it is incorrect anyway; the bit should never be set in our part of the world).  (See https://github.com/numpy/numpy/issues/23158)\r\n\r\nTo me, all of that is a bit moot though.  Python has this manual definition for NaN and Inf, but also defines `Py_NAN` and `Py_HUGE_VAL`.  In theory, `Py_HUGE_VAL` doesn't need to be inf and `Py_NAN` I am not actually sure what it could be if NaN is not available...\r\n\r\nBut...  If you have IEEE doubles and setting the bit-pattern manually is reasonable.  You certainly can assume that both are defined to the right thing and `Py_NAN` is in fact a `NaN` value.  Doing that simplifies the code, but should also solve the MIPS issue since `Py_NAN` presumably is correctly defined to a quiet NaN.\r\n\r\nThis is done in gh-104202.  I suppose a test might be:\r\n```\r\nif hasattr(math, \"nan\"):\r\n    bits_nan1 = struct.pack(\"d\", math.inf - math.inf)\r\n    bits_nan2 = struct.pack(\"d\", math.nan)\r\n    assert bits_nan1 == bits_nan2\r\n```","author":{"url":"https://github.com/seberg","@type":"Person","name":"seberg"},"datePublished":"2023-05-07T08:04:33.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":13},"url":"https://github.com/104263/cpython/issues/104263"}