[Numpy-discussion] Re: Representation of NumPy scalars

2022-09-09 Thread Kevin Sheppard 
+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  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: arch...@mail-archive.com

[Numpy-discussion] Re: Representation of NumPy scalars

2022-09-09 Thread Evgeni Burovski 
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 :

> +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 
> 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

[Numpy-discussion] Re: Representation of NumPy scalars

2022-09-09 Thread Sebastian Berg 
On Thu, 2022-09-08 at 21:15 -0400, Warren Weckesser wrote:
> On 9/8/22, Andrew Nelson  wrote:
> 
> > 



> > 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.)
> 

To me, that should be mainly a guiding principle maybe not a strict
goal.  But I do wonder if there are any alternative thoughts on what
the representation should be?
Since I doubt Python will add infix operators that allow `123.4_f64`
soon that is probably not worth a thought :).

For booleans I think we previously had rather settled on `np.True_` and
`np.False_`.

Cheers,

Sebastian


> 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.
> > 
> ___
> 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

[Numpy-discussion] Re: Representation of NumPy scalars

2022-09-09 Thread Sebastian Berg 
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("")
float32()

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

[Numpy-discussion] NumPy 1.23. 3 Release

2022-09-09 Thread Charles R Harris 
Hi All,

On behalf of the NumPy team, I am pleased to announce the release of
NumPy 1.23.3. NumPy 1.23.3 is a maintenance release that fixes bugs
discovered after the 1.23.2 release. There is no major theme for this
release, the main improvements are for some downstream builds and some
annotation corner cases. The Python versions supported for this release are
3.8-3.11. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

Note that we will move to MacOS 11 for the NumPy 1.23.4 release, the 10.15
version currently used will no longer be supported by our build
infrastructure at that point.

*Contributors*

A total of 16 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Aaron Meurer
   - Bas van Beek
   - Charles Harris
   - Ganesh Kathiresan
   - Gavin Zhang +
   - Iantra Solari+
   - Jyn Spring 琴春 +
   - Matti Picus
   - Rafael Cardoso Fernandes Sousa
   - Rafael Sousa +
   - Ralf Gommers
   - Rin Cat (鈴猫) +
   - Saransh Chopra +
   - Sayed Adel
   - Sebastian Berg
   - Serge Guelton



*Pull requests merged*
A total of 14 pull requests were merged for this release.

   - #22136: BLD: Add Python 3.11 wheels to aarch64 build
   - #22148: MAINT: Update setup.py for Python 3.11.
   - #22155: CI: Test NumPy build against old versions of GCC(6, 7, 8)
   - #22156: MAINT: support IBM i system
   - #22195: BUG: Fix circleci build
   - #22214: BUG: Expose heapsort algorithms in a shared header
   - #22215: BUG: Support using libunwind for backtrack
   - #22216: MAINT: fix an incorrect pointer type usage in f2py
   - #0: BUG: change overloads to play nice with pyright.
   - #1: TST,BUG: Use fork context to fix MacOS savez test
   - #2: TYP,BUG: Reduce argument validation in C-based
   ``__class_getitem__``
   - #3: TST: ensure ``np.equal.reduce`` raises a ``TypeError``
   - #4: BUG: Fix the implementation of numpy.array_api.vecdot
   - #22230: BUG: Better report integer division overflow (backport)


Cheers,

Charles Harris
___
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