COMPAT: Change khcomplex64/128_t typedefs #54375
Conversation
|
@mroeschke |
| typedef struct { | ||
| float real; | ||
| float imag; | ||
| } khcomplex64_t; |
There was a problem hiding this comment.
| } khcomplex64_t; | |
| } khcomplex64_t; |
Just a minor readability thing if you have to edit again. We should probably run this whole file through clang-format in a separate PR / CI
| } khcomplex64_t; | ||
| typedef struct { | ||
| double real; | ||
| double imag; |
There was a problem hiding this comment.
will this change anything on platforms where float/double aren't 32/64 bits? (which i guess we have zero testing for so not a huge deal)
There was a problem hiding this comment.
Not sure. It appears in numpy/numpy#24085 in numpy/core/include/numpy/npy_math.h numpy also defines real/imag components as doubles
There was a problem hiding this comment.
I think the misnomer is to call these complex64 and complex128. The C99 standard has float complex and double complex types, but nothing that is a fixed width
See also https://stackoverflow.com/questions/2524737/fixed-size-floating-point-types#2524933
There was a problem hiding this comment.
Yeah, I guess technically float32/float64 are sized aliases under the assumption they refer to float/double, but in practice the assumption seems so strong that I doubt it matters.
I am very puzzled about the change though, this is exactly what it was after all, and I don't think C cares about type aliases (even if there was interaction anywhere). I am wondering if the include <numpy/arrayobject.h> somehow is involved, but I don't see why it should be either?
I assume the value stored is correct here and just the printing somehow thinks it is printing a NaN?
|
Can't reproduce this locally, but it seems that |
|
I think it might be a Python 3.12 issue. The regular numpy dev build doesn't fail. |
I think numpy dev has cached dependencies so maybe the changes haven't caught up |
|
Looks like this change subtly changed how |
xref numpy/numpy#24085
suggestion by @seberg