On Thu, 2022-09-08 at 23:19 -0700, Stefan van der Walt wrote:
> I am in favor of such a change. It will make what is returned more
> transparent to users (and reduce confusion for newcomers).
>
> With NEP50, we're already adopting a philosophy of explicit scalar
> usage anyway: no longer pretending or trying to make transparent that
> Python floats and NumPy floats are the same.
>
> No one *actually* round-trips objects via repr, but if a user could
> look at a result and know how to construct the object, that is an
> improvement.
True, the only worry would be loss of a bit of a precision when someone
has a copy-paste workflow. But at that point, users probably don't
care about the last ULP.
Even float32/float16 `repr` use is tricky in principle since
float32("<number>")
float32(<number>)
May not be identical, but I would have to dig into the subtleties there
(and presumably NumPy gets it subtly wrong anyway right now!).
Not sure it is a big worry, but probably worthwhile to note down if we
end up writing a brief NEP.
Cheers,
Sebastian
>
> Stéfan
>
> On Thu, Sep 8, 2022, at 22:26, Matti Picus wrote:
> > On 9/9/22 04:15, Warren Weckesser wrote:
> > > ...
> > > 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
> >
> >
> > As others have mentioned, the change will greatly enhance UX at the
> > cost
> > of documentation cleanups. While the representation may not be
> > perfectly
> > roundtrip-able, I think it still is an improvement and worthwhile.
> > Elsewhere I have suggested we need more documentation around
> > array/scalar printing, perhaps that would be a place to mention the
> > limitations of string representations.
> >
> > Matti
> _______________________________________________
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
