Repository navigation
BUG: clongdouble(str) parses string to float64 and loses precision in string conversion. #26701
Description
Describe the issue:
When given a string, it looks like np.clongdouble() is parsing the numeric values as float64 and losing precision in the conversion. For example, in the following, I expect np.longdouble(s) and np.clongdouble(s).real to give the same result:
In [73]: s = "0.333333333333333333333333"
In [74]: np.longdouble(s)
Out[74]: np.longdouble('0.33333333333333333334')
In [75]: np.clongdouble(s).real
Out[75]: np.longdouble('0.33333333333333331483')
Instead, clongdouble() appears to be parsing to float64, c.f.
In [78]: np.longdouble(np.float64(s))
Out[78]: np.longdouble('0.33333333333333331483')
This is on a Linux machine where the long double type is 80 bit extended precision.
Python and NumPy Versions:
2.1.0.dev0+git20240613.787ff0f
3.12.3 (main, Apr 25 2024, 11:11:06) [GCC 11.4.0]
Runtime Environment:
[{'numpy_version': '2.1.0.dev0+git20240613.787ff0f',
'python': '3.12.3 (main, Apr 25 2024, 11:11:06) [GCC 11.4.0]',
'uname': uname_result(system='Linux', node='pop-os', release='6.8.0-76060800daily20240311-generic', version='#202403110203171518180122.04~aba43ee SMP PREEMPT_DYNAMIC Wed M', machine='x86_64')},
{'simd_extensions': {'baseline': ['SSE', 'SSE2', 'SSE3'],
'found': ['SSSE3',
'SSE41',
'POPCNT',
'SSE42',
'AVX',
'F16C',
'FMA3',
'AVX2'],
'not_found': ['AVX512F',
'AVX512CD',
'AVX512_KNL',
'AVX512_KNM',
'AVX512_SKX',
'AVX512_CLX',
'AVX512_CNL',
'AVX512_ICL']}},
{'architecture': 'Zen',
'filepath': '/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so',
'internal_api': 'openblas',
'num_threads': 24,
'prefix': 'libopenblas',
'threading_layer': 'pthreads',
'user_api': 'blas',
'version': '0.3.20'}]
Activity
[-]BUG: `clongdouble(str)` to parses as `float64` and loses precision in string conversion.[/-][+]BUG: `clongdouble(str)` parses string to `float64` and loses precision in string conversion.[/+]Searchingdays commentedon Jun 16, 2024
python version: 3.11.4
numpy version: 1.25.2
Ipython version: 8.19.0
In windows system all of the above number types return the same truncated decimal value 0.3333333333333333. I tried both with string value and numeric value. Results are same.
In [4]: s = "0.333333333333333333333333"
In [5]: np.longdouble(s)
Out[5]: 0.3333333333333333
In [6]: p = 0.333333333333333333333333
In [7]: np.longdouble(p)
Out[7]: 0.3333333333333333
In [8]: np.clongdouble(s)
Out[8]: (0.3333333333333333+0j)
In [9]: np.clongdouble(p)
Out[9]: (0.3333333333333333+0j)
In [10]: np.longdouble(np.float64(s))
Out[10]: 0.3333333333333333
WarrenWeckesser commentedon Jun 16, 2024
Thanks for checking, @Searchingdays, but to see the issue, you need to use a system where
long doublehas higher precision thandouble. With MSVC,long doubleis the same asdouble.michelledeeney85 commentedon Nov 8, 2024
I can reproduce this on Debian 12, with Python version 3.11.2 and numpy version 2.1.2
input:
output:
The types output by dtype match the documentation (https://numpy.org/doc/stable/user/basics.types.html).
But the result of clongdouble is still wrong, despite the type appearing to be correct.