On 9/8/22, Andrew Nelson <andyfaff@gmail.com> wrote:
On Thu, 8 Sept 2022, 19:42 Sebastian Berg, <sebastian@sipsolutions.net> wrote:
TL;DR: NumPy scalars representation is e.g. `34.3` instead of `float32(34.3)`. So the representation is missing the type information. What are your thoughts on changing that?
I like the idea, but as others have noted, this could result in a lot of churn in the docs of many projects.
From the Python documentation on repr:
From the Python documentation on repr:
"this should look like a valid Python expression that could be used to recreate an object with the same value"
To quote from https://docs.python.org/3/library/functions.html#repr:
For many types, this function makes an attempt to return a string that would yield an object with the same value when passed to eval();
Sebastian, is this an explicit goal of the change? (Personally, I've gotten used to not taking this too seriously, but my world view is biased by the long-term use of NumPy, which has never followed this guideline.) If that is a goal, than the floating point types with precision greater than double precision will need to display the argument of the type as a string. For example, the following is run on a platform where numpy.longdouble is extended precision (80 bits): ``` In [161]: longpi = np.longdouble('3.14159265358979323846') In [162]: longpi Out[162]: 3.1415926535897932385 In [163]: np.longdouble(3.1415926535897932385) # Argument is parsed as 64 bit float Out[163]: 3.141592653589793116 In [164]: np.longdouble('3.1415926535897932385') # Correctly reproduces the longdouble Out[164]: 3.1415926535897932385 ``` Warren
I think it definitely we should definitely have:
repr(np.float32(34.3)) == 'float32(34.3)' And str(np.float32(34.3)) == '34.3'
It seems buglike not to have that.