BUG: clongdouble(str) loses precision during string conversion #29746
Conversation
|
Neat! Just a head's up - longdouble is a bit of an unloved feature. That said, this seems reasonable to support. Some suggestions:
I wonder if the linalg test that is failing is relying on the old broken conversion. Ping @SwayamInSync - you might be interested in this. Swayam has been working on a quad precision DType we're hoping will ultimately allow us to deprecate longdouble support (or at least the float128 alias) in NumPy proper. The fact that longdouble has a subtly different meaning under different architectures is a constant source of bug reports and most users won't need it at all. |
|
Not a full review, but here are a couple issues that should be easy to fix:
|
|
Again not a full review (sorry), but it looks like the failures are because the new |
|
|
||
| const char *p = end; | ||
| if (*p != '+' && *p != '-') { | ||
| if(*p == 'j') { |
There was a problem hiding this comment.
| if(*p == 'j') { | |
| if (*p == 'j' || *p == 'J') { |
There was a problem hiding this comment.
Probably should allow parentheses (as CPython, and hence np.cdouble does). Python likes to put parentheses in complex reprs, so I think it is important to handle this case at least, even if you're dropping support for some of the more esoteric bits of the CPython parser, like 1-j and 1_000.
| b = op; | ||
| Py_XINCREF(b); | ||
| } | ||
| s = PyBytes_AsString(b); |
There was a problem hiding this comment.
Most of these type checks and conversions are redundant because string_to_long_cdouble is only ever passed bytes or unicode objects it seems. Why not just have string_to_long_cdouble(char *s)?
This pull request addresses #26701. Converting to a
np.clongdoublefrom a string would result in a loss of precision. This is because the conversion process involves Python's complex type as an intermediate, which has less precision thannp.clongdouble. The pull request adds a test which fails on themainbranch on linux, x86.