A naive question: what actually are the differences, what an end user need to worry about when mixing python scalars and numpy scalars? Same question about a library author. Or is it mainly about fixed-width integers vs python integers?
Cheers, Evgeni пт, 9 сент. 2022 г., 09:58 Kevin Sheppard <kevin.k.shepp...@gmail.com>: > +1 from me. They are a frequent source of confusion when starting, and > there appear to be far fewer now then in earlier releases. It also might > make it easier to spot any inadvertent scalars coming out if these could be > Python floats. > > Kevin > > On Fri, Sep 9, 2022, 07:23 Stefan van der Walt <stef...@berkeley.edu> > 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. >> >> 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: kevin.k.shepp...@gmail.com >> > _______________________________________________ > 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: evgeny.burovs...@gmail.com >
_______________________________________________ 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
