This issue tracker
has been migrated to
GitHub
,
and is currently
read-only
.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
fp = cast(cp, POINTER(c_float))
print(fp.contents.value) # nan
print(struct.pack(">f", fp.contents.value).hex()) # 7fd4e57c
# value changed: 7f94e57c -> 7fd4e57c
fp = cast(cp, POINTER(c_float))
print(fp.contents.value) # nan
p = pointer(c_float(fp.contents.value))
ip = cast(p, POINTER(c_int))
print(hex(ip.contents.value)) #'0x7fd4e57c'
I believe that this may be the same issue as this thread
https://mail.python.org/archives/list/[email protected]/thread/35NECLGFIVAHWTIPAYDBJOJJX3FSY233/
in particular this comment:
https://mail.python.org/archives/list/[email protected]/message/QIC4DLFYEI3IVGUFK5KRTIELTKFI76B6/
There's an implicit float-to-double conversion here (`fp.contents.value` is represented as a Python float, which is backed by a C double). What you're seeing is that converting the single-precision signaling NaN to double precision loses the signaling bit, producing a quiet double-precision NaN with the same sign and payload (modulo the signaling bit). That's what I'd expect under IEEE 754 semantics. (IEEE 754-2008 says, in section 6.2, "Under default exception handling, any operation signaling an invalid operation exception and for which a floating-point result is to be delivered shall deliver a quiet NaN.".)
I don't think there's anything we can or should do about this at Python level. ctypes is correctly reflecting the existing C-level behaviour. In other words, this is expected behaviour, not a bug.
OK. Seems it's the default behavior of CPU instruction. And CPU follows the IEEE standard of float.
Is there any workaround?
> Is there any workaround?
Sorry, I can't answer that without knowing what it is you're trying to do - that is, I don't know which part of the behaviour you want a workaround for. But that's getting off topic for this tracker, which is for bug reporting; I'd suggest taking the discussion to one of the mailing lists, Stack Overflow, or some other resource.
2022-04-11 14:59:44adminsetgithub: 88106
2021-04-26 08:47:06mark.dickinsonsetstatus: open -> closed
messages:
+
msg391885
stage: resolved
2021-04-26 08:38:26yang8621setstatus: pending -> open
messages:
+
msg391884
2021-04-26 08:15:19mark.dickinsonsetstatus: open -> pending
resolution: not a bug
2021-04-26 07:40:59mark.dickinsonsetmessages:
+
msg391883
2021-04-26 05:54:20steven.dapranosetnosy:
+
steven.daprano
messages:
+
msg391880
2021-04-26 05:14:27yang8621setmessages:
+
msg391879
2021-04-26 04:50:23rhettingersetnosy:
+
tim.peters
,
rhettinger
,
mark.dickinson
2021-04-26 03:00:01yang8621setmessages:
+
msg391877
2021-04-26 02:52:44yang8621create
