[Numpy-discussion] Re: Software Freedom Conservancy calls for move from Github

[Charles R Harris]

On Mon, Jul 4, 2022 at 7:48 AM Matthew Brett 
wrote:

> Hi,
>
> I just came across this:
>
> https://sfconservancy.org/GiveUpGitHub/
>
> I guess this is something we should review and consider - although it
> would obviously have serious costs.
>
> Cheers,
>
>
I didn't see anything in the article that made me want to switch. I would
need to see actual cases of abuse. I also recall that Linus used Bitkeeper
because it was the best tool at the time and made that argument. The
trouble arose when Andrew Tridgell reversed engineered the protocol, which
Larry McVoy complained violated the terms of use. So on and so forth. I
haven't noted problems along that line with GitHub. It doesn't bother me
that it is proprietary as long as they are responsive and I do appreciate
the work going on to make it better. Someone has to pay for that and we are
getting a free ride. It might be nice if we could back up the issues and
PRs so history wouldn't be lost if we did need to move at some point, but
that would be a good idea on any site.

Chuck
___
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.1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.23.1. NumPy 1.23.1 is a maintenance release that fixes bugs discovered
after the 1.23.0 release. Notable fixes are:

   - Fix searchsorted for float16 NaNs
   - Fix compilation on Apple M1
   - Fix KeyError in crackfortran operator support (Slycot)

The Python versions supported for this release are 3.8-3.10. Wheels can be
downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
.

*Contributors*

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

   - Charles Harris
   - Matthias Koeppe +
   - Pranab Das +
   - Rohit Goswami
   - Sebastian Berg
   - Serge Guelton
   - Srimukh Sripada +

*Pull requests merged*

A total of 8 pull requests were merged for this release.

   - #21866: BUG: Fix discovered MachAr (still used within valgrind)
   - #21867: BUG: Handle NaNs correctly for float16 during sorting
   - #21868: BUG: Use ``keepdims`` during normalization in ``np.average``
   and...
   - #21869: DOC: mention changes to ``max_rows`` behaviour in
   ``np.loadtxt``
   - #21870: BUG: Reject non integer array-likes with size 1 in delete
   - #21949: BLD: Make can_link_svml return False for 32bit builds on x86_64
   - #21951: BUG: Reorder extern "C" to only apply to function
   declarations...
   - #21952: BUG: Fix KeyError in crackfortran operator support

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

[Numpy-discussion] Re: Setting C and linker flags for Windows build

[Charles R Harris]

On Wed, Jun 29, 2022 at 5:26 PM Matthew Brett 
wrote:

> Hi,
>
> I am very sorry - I feel I should know this, or be able to work it
> out, but is there a way of setting the flags to the C compiler and the
> linker, for the Numpy build, on Windows?
>
> I'm trying to set the flags for a build with Windows mingw-w64 - but I
> believe Numpy is ignoring $env:LDFLAGS, $env:CFLAGS and $env:OPT - and
> I can't see any way of setting these options from the command line.
> Am I missing something?
>
> Cheers,
>
> Matthew
>

I don't know how you are using env, but variables set that way are local to
the shell in which they are set. In PS that is every separate shell
invocation.

Chuck
___
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: Setting C and linker flags for Windows build

[Charles R Harris]

On Thu, Jun 30, 2022 at 11:02 AM Matthew Brett 
wrote:

> Hi Chuck,
>
> On Thu, Jun 30, 2022 at 2:13 PM Charles R Harris
>  wrote:
> >
> >
> >
> > On Wed, Jun 29, 2022 at 5:26 PM Matthew Brett 
> wrote:
> >>
> >> Hi,
> >>
> >> I am very sorry - I feel I should know this, or be able to work it
> >> out, but is there a way of setting the flags to the C compiler and the
> >> linker, for the Numpy build, on Windows?
> >>
> >> I'm trying to set the flags for a build with Windows mingw-w64 - but I
> >> believe Numpy is ignoring $env:LDFLAGS, $env:CFLAGS and $env:OPT - and
> >> I can't see any way of setting these options from the command line.
> >> Am I missing something?
> >>
> >> Cheers,
> >>
> >> Matthew
> >
> >
> > I don't know how you are using env, but variables set that way are local
> to the shell in which they are set. In PS that is every separate shell
> invocation.
>
> Maybe you are thinking of local PS variables?  $env: variables do get
> passed to subshells, like exported Bash variables.
>

Yes. But my experience was azure-pipelines where every shell invocation was
a different subprocess (I think), so setting the environment variables in
one shell using env: didn't show up in the others. But I don't know what
your usage is.

Chuck
___
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.0 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.23.0. The NumPy 1.23.0 release continues the ongoing work to improve the
handling and promotion of dtypes, increase the execution speed, clarify the
documentation, and expire old deprecations. The highlights are:


   - Implementation of ``loadtxt`` in C, greatly improving its performance.
   - Exposing DLPack at the Python level for easy data exchange.
   - Changes to the promotion and comparisons of structured dtypes.
   - Improvements to f2py.

The Python versions supported in this release are 3.8-3.10, 3.11 will be
supported when it comes out. Note that 32 bit wheels are only provided for
Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and
other Linux distributions dropping 32 bit support. All 64 bit wheels are
also linked with 64 bit OpenBLAS. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @GalaxySnail +
   - @code-review-doctor +
   - @h-vetinari
   - Aaron Meurer
   - Alexander Shadchin
   - Alexandre de Siqueira
   - Allan Haldane
   - Amrit Krishnan
   - Andrei Batomunkuev
   - Andrew J. Hesford +
   - Andrew Murray +
   - Andrey Andreyevich Bienkowski +
   - André Elimelek de Weber +
   - Andy Wharton +
   - Arryan Singh
   - Arushi Sharma
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavuk Kalra +
   - Brigitta Sipőcz
   - Brénainn Woodsend +
   - Burlen Loring +
   - Caio Agiani +
   - Charles Harris
   - Chiara Marmo
   - Cornelius Roemer +
   - Dahyun Kim +
   - Damien Caliste
   - David Prosin +
   - Denis Laxalde
   - Developer-Ecosystem-Engineering
   - Devin Shanahan +
   - Diego Wang +
   - Dimitri Papadopoulos Orfanos
   - Ding Liu +
   - Diwakar Gupta +
   - Don Kirkby +
   - Emma Simon +
   - Eric Wieser
   - Evan Miller +
   - Evgeni Burovski
   - Evgeny Posenitskiy +
   - Ewout ter Hoeven +
   - Felix Divo
   - Francesco Andreuzzi +
   - Ganesh Kathiresan
   - Gaëtan de Menten
   - Geoffrey Gunter +
   - Hans Meine
   - Harsh Mishra +
   - Henry Schreiner
   - Hood Chatham +
   - I-Shen Leong
   - Ilhan Polat
   - Inessa Pawson
   - Isuru Fernando
   - Ivan Gonzalez +
   - Ivan Meleshko +
   - Ivan Yashchuk +
   - Janus Heide +
   - Jarrod Millman
   - Jason Thai +
   - Jeremy Volkman +
   - Jesús Carrete Montaña +
   - Jhong-Ken Chen (陳仲肯) +
   - John Kirkham
   - John-Mark Gurney +
   - Jonathan Deng +
   - Joseph Fox-Rabinovitz
   - Jouke Witteveen +
   - Junyan Ou +
   - Jérôme Richard +
   - Kassian Sun +
   - Kazuki Sakamoto +
   - Kenichi Maehashi
   - Kevin Sheppard
   - Kilian Lieret +
   - Kushal Beniwal +
   - Leo Singer
   - Logan Thomas +
   - Lorenzo Mammana +
   - Margret Pax
   - Mariusz Felisiak +
   - Markus Mohrhard +
   - Mars Lee
   - Marten van Kerkwijk
   - Masamichi Hosoda +
   - Matthew Barber
   - Matthew Brett
   - Matthias Bussonnier
   - Matthieu Darbois
   - Matti Picus
   - Melissa Weber Mendonça
   - Michael Burkhart +
   - Morteza Mirzai +
   - Motahhar Mokf +
   - Muataz Attaia +
   - Muhammad Motawe +
   - Mukulika Pahari
   - Márton Gunyhó +
   - Namami Shanker +
   - Nihaal Sangha +
   - Niyas Sait
   - Omid Rajaei +
   - Oscar Gustafsson +
   - Ovee Jawdekar +
   - P. L. Lim +
   - Pamphile Roy +
   - Pantelis Antonoudiou +
   - Pearu Peterson
   - Peter Andreas Entschev
   - Peter Hawkins
   - Pierre de Buyl
   - Pieter Eendebak +
   - Pradipta Ghosh +
   - Rafael Cardoso Fernandes Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raphael Kruse
   - Raúl Montón Pinillos
   - Robert Kern
   - Rohit Goswami
   - Ross Barnowski
   - Ruben Garcia +
   - Sadie Louise Bartholomew +
   - Saswat Das +
   - Sayed Adel
   - Sebastian Berg
   - Serge Guelton
   - Simon Surland Andersen +
   - Siyabend Ürün +
   - Somasree Majumder +
   - Soumya +
   - Stefan van der Walt
   - Stefano Miccoli +
   - Stephan Hoyer
   - Stephen Worsley +
   - Tania Allard
   - Thomas Duvernay +
   - Thomas Green +
   - Thomas J. Fan
   - Thomas Li +
   - Tim Hoffmann
   - Ting Sun +
   - Tirth Patel
   - Toshiki Kataoka
   - Tyler Reddy
   - Warren Weckesser
   - Yang Hau
   - Yoon, Jee Seok +

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

[Numpy-discussion] Re: NumPy 1.23.0 released

[Charles R Harris]

On Wed, Jun 22, 2022 at 6:49 PM Charles R Harris 
wrote:

> Hi All,
>
> On behalf of the NumPy team, I'm pleased to announce the release of NumPy
> 1.23.0. The NumPy 1.23.0 release continues the ongoing work to improve the
> handling and promotion of dtypes, increase the execution speed, clarify the
> documentation, and expire old deprecations. The highlights are:
>
>
>- Implementation of ``loadtxt`` in C, greatly improving its
>performance.
>- Exposing DLPack at the Python level for easy data exchange.
>- Changes to the promotion and comparisons of structured dtypes.
>- Improvements to f2py.
>
> The Python versions supported in this release are 3.8-3.10, 3.11 will be
> supported when it comes out. Note that 32 bit wheels are only provided for
> Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and
> other Linux distributions dropping 32 bit support. All 64 bit wheels are
> also linked with 64 bit OpenBLAS. Wheels can be downloaded from PyPI
> <https://pypi.org/project/numpy/1.23.0/>; source archives, release notes,
> and wheel hashes are available on Github
> <https://github.com/numpy/numpy/releases/tag/v1.23.0>.
>

 I included the buggy pdf doc files in the documentation. As
discussed before, we should probably just drop those from the website. It
looks like deleting two lines will remove the links, I'm not sure how to
remove the content and didn't try. It was enough trouble editing
the Makefile to ignore the bugs and run with Python 3.10. Deleting those
files has got to help the growing size of the numpy.org repo, which is
enormous these days.

Chuck
___
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.0rc3 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.23.0rc2. The NumPy 1.23.0 release continues the ongoing work to improve
the handling and promotion of dtypes, increase the execution speed, clarify
the documentation, and expire old deprecations. The highlights are:


   - Implementation of ``loadtxt`` in C, greatly improving its performance.
   - Exposing DLPack at the Python level for easy data exchange.
   - Changes to the promotion and comparisons of structured dtypes.
   - Improvements to f2py.

The Python versions supported in this release are 3.8-3.10, 3.11 will be
supported when it comes out. Note that 32 bit wheels are only provided for
Windows, all other wheels are 64 bits on account of Ubuntu, Fedora, and
other Linux distributions dropping 32 bit support. All 64 bit wheels are
also linked with 64 bit OpenBLAS. Wheels can be downloaded from PyPI
; source archives, release
notes, and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @GalaxySnail +
   - @code-review-doctor +
   - @h-vetinari
   - Aaron Meurer
   - Alexander Shadchin
   - Alexandre de Siqueira
   - Allan Haldane
   - Amrit Krishnan
   - Andrei Batomunkuev
   - Andrew J. Hesford +
   - Andrew Murray +
   - Andrey Andreyevich Bienkowski +
   - André Elimelek de Weber +
   - Andy Wharton +
   - Arryan Singh
   - Arushi Sharma
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavuk Kalra +
   - Brigitta Sipőcz
   - Brénainn Woodsend +
   - Burlen Loring +
   - Caio Agiani +
   - Charles Harris
   - Chiara Marmo
   - Cornelius Roemer +
   - Dahyun Kim +
   - Damien Caliste
   - David Prosin +
   - Denis Laxalde
   - Developer-Ecosystem-Engineering
   - Devin Shanahan +
   - Diego Wang +
   - Dimitri Papadopoulos Orfanos
   - Ding Liu +
   - Diwakar Gupta +
   - Don Kirkby +
   - Emma Simon +
   - Eric Wieser
   - Evan Miller +
   - Evgeni Burovski
   - Evgeny Posenitskiy +
   - Ewout ter Hoeven +
   - Felix Divo
   - Francesco Andreuzzi +
   - Ganesh Kathiresan
   - Gaëtan de Menten
   - Geoffrey Gunter +
   - Hans Meine
   - Harsh Mishra +
   - Henry Schreiner
   - Hood Chatham +
   - I-Shen Leong
   - Ilhan Polat
   - Inessa Pawson
   - Isuru Fernando
   - Ivan Gonzalez +
   - Ivan Meleshko +
   - Ivan Yashchuk +
   - Janus Heide +
   - Jarrod Millman
   - Jason Thai +
   - Jeremy Volkman +
   - Jesús Carrete Montaña +
   - Jhong-Ken Chen (陳仲肯) +
   - John Kirkham
   - John-Mark Gurney +
   - Jonathan Deng +
   - Joseph Fox-Rabinovitz
   - Jouke Witteveen +
   - Junyan Ou +
   - Jérôme Richard +
   - Kassian Sun +
   - Kazuki Sakamoto +
   - Kenichi Maehashi
   - Kevin Sheppard
   - Kilian Lieret +
   - Kushal Beniwal +
   - Leo Singer
   - Logan Thomas +
   - Lorenzo Mammana +
   - Margret Pax
   - Mariusz Felisiak +
   - Markus Mohrhard +
   - Mars Lee
   - Marten van Kerkwijk
   - Masamichi Hosoda +
   - Matthew Barber
   - Matthew Brett
   - Matthias Bussonnier
   - Matthieu Darbois
   - Matti Picus
   - Melissa Weber Mendonça
   - Michael Burkhart +
   - Morteza Mirzai +
   - Motahhar Mokf +
   - Muataz Attaia +
   - Muhammad Motawe +
   - Mukulika Pahari
   - Márton Gunyhó +
   - Namami Shanker +
   - Nihaal Sangha +
   - Niyas Sait
   - Omid Rajaei +
   - Oscar Gustafsson +
   - Ovee Jawdekar +
   - P. L. Lim +
   - Pamphile Roy +
   - Pantelis Antonoudiou +
   - Pearu Peterson
   - Peter Andreas Entschev
   - Peter Hawkins
   - Pierre de Buyl
   - Pieter Eendebak +
   - Pradipta Ghosh +
   - Rafael Cardoso Fernandes Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raphael Kruse
   - Raúl Montón Pinillos
   - Robert Kern
   - Rohit Goswami
   - Ross Barnowski
   - Ruben Garcia +
   - Sadie Louise Bartholomew +
   - Saswat Das +
   - Sayed Adel
   - Sebastian Berg
   - Serge Guelton
   - Simon Surland Andersen +
   - Siyabend Ürün +
   - Somasree Majumder +
   - Soumya +
   - Stefan van der Walt
   - Stefano Miccoli +
   - Stephan Hoyer
   - Stephen Worsley +
   - Tania Allard
   - Thomas Duvernay +
   - Thomas Green +
   - Thomas J. Fan
   - Thomas Li +
   - Tim Hoffmann
   - Ting Sun +
   - Tirth Patel
   - Toshiki Kataoka
   - Tyler Reddy
   - Warren Weckesser
   - Yang Hau
   - Yoon, Jee Seok +

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

[Numpy-discussion] New stable documentation

[Charles R Harris]

Hi All,

I've put up new stable documentation for NumPy 1.22.4. I'd appreciate it if
those familiar with how they want the documentation to look could take a
look at it so that fixes can be made while I'm still in the documentation
state.

Chuck
___
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] Remove nose support?

[Charles R Harris]

Hi All,

I propose to remove nose support from numpy/testing/. We moved to pytest
about five years ago because nose was no longer maintained, but kept the
outdated nose support for downstream projects who had not yet dropped it.
Nose itself has been replaced with nose2, and while it remains available on
some distros it will require patching to continue working for Python 3.12.
Keeping nose support does not cost us anything and removing it may break
some old downstream projects that are no longer maintained, but getting rid
of it will remove some files that are about to become useless.

Chuck
___
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: Automatic formatters for only changed lines

[Charles R Harris]

On Fri, May 6, 2022 at 2:10 AM Sebastian Berg 
wrote:

> On Thu, 2022-05-05 at 15:32 -0700, Stefan van der Walt wrote:
> > On Thu, May 5, 2022, at 12:00, Trevor Gross wrote:
> > > I don't necessarily know that this should be enforced on CI off the
> > > bat (though in the future it could be), but at least having the
> > > tool available and easily usable would help to incrementally
> > > improve codebase style, and remove the need for formatting by hand.
> >
> > On all projects we've set up pre-commit with style formatting, it has
> > significantly reduced noise and nitpicks in PR discussions.  It makes
> > for a better contributor experience, thus I am in favor.  Black isn't
> > perfect by any means, but never having to talk about formatting again
> > makes it worth it!
>
>
> While I have no love for blacks style (yet), it seems time to seriously
> consider adopting it.
> There was the `yapf` idea (more forgiving/closer to what we have), but
> I am unclear whether it is as easy to set up, especially since many
> projects settled on black.
>
> For the C-code we have a clang-tidy setup which is decent and we could
> use, I am not sure what the PR currently does?
>
>
> In general, I still like to defer to Chuck to make the decisions in the
> hope that makes it simpler to reach a verdict, here :).
>

Heh. I think automatic formatting is the future and was happy to see the
PR. The only question is if black is the way we want to go. IIRC, the main
sticking points were

   - Line length (<= 79).
   - Quotation mark changes (noisy).
   - Formatting of  '*', '**', and '/'

Even if the result isn't perfect by our current standards, I suspect we
will get used to it and just not worry anymore. The main problem I've run
into before is the formatting of large test data sets, which are often
easier to read if the format is not strictly conforming. But that isn't
something we are likely to see every day anyway. The main things we should
shoot for are consistency, readability, and ease of use. The choice of a
particular style is secondary.


>
> When it comes to reformatting the code base: I think we should maybe
> just do it.  Is a semi-black code base really better than just getting
> it over with and needing a bit to get used to it?  [1]
>

Cheers,
>
> Sebastian
>
>
> [1] The main thing that it might disrupt are backports?  In which case
> I guess very late in the dev-cycle would be the right time, to avoid
> cross style-change backports as much as possible.
>

That happened with the rearrangement of the Fortran files, I wasn't able to
backport some fixes. But that was a much bigger change than the style
changes proposed here.

Chuck
___
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: Discussion: History & Possible Deprecation/Removal of numpy.linalg.{eig(), eigvals()}?

[Charles R Harris]

On Tue, May 3, 2022 at 6:41 PM Leo Fang  wrote:

> Hi, I am catching up with an assigned task that I slipped. I am wondering
> a few things about the numpy.linalg.eig() API (eigvals() is also included
> in this discussion, but for simplicity let's focus on eig()). AFAIU the
> purpose of eig() is for handling general eigen-systems which have left and
> right eigenvectors (that could differ beyond transpose/conjugate). For
> this, I have two questions:
>
> 1. What's the history of NumPy adding this eig() routine? My guess would
> be NumPy added it because Matlab had it, but I couldn't tell from a quick
> commit search.
> 2. Would it be possible to deprecate/remove this API? From past
> discussions with users and developers, I found:
> - numpy.linalg.eig() only returns the right eigenvectors, so it's not very
> useful:
>   * When the left eigenvectors are not needed --- which is the majority of
> the use cases --- eigh() is the right routine, but most users (especially
> those transitioning from Matlab) don't know it's there
>

eigh() is for Hermitian matrices, the svd won't return eigenvectors in the
general case, especially when they are not orthogonal or form a complete
basis. The left eigenvectors can be obtained by passing the transpose to
eig().

In my experience, the main problem with eig() is accuracy, and sometimes
(IIRC) it doesn't find all the eigenvectors, so it should not be used when
the matrix is Hermitian.


>   * When the left eigenvectors are needed, users have to use
> scipy.linalg.eig() anyway
> - A general support for eig() could be challenging (numerical issues), and
> doing SVDs instead is usually the better way out (in terms of both
> numerical stability and mathematical sense).
>
>
Chuck
___
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: Automatic formatters for only changed lines

[Charles R Harris]

On Sun, May 8, 2022 at 10:30 AM Joshua Wilson 
wrote:

> As someone who worked on a project that used to use yapf, a word of
> caution - regardless of quality of formatting versus black, it generally
> has not had the resources to keep up with new releases of Python. See
>
> https://github.com/google/yapf/issues/772
> https://github.com/google/yapf/issues/993
> https://github.com/google/yapf/issues/1001
>
> for example. We eventually had to switch to black because of the lack of
> 3.8 support. (Though with 3.8 in particular you'd be fine if you banned
> using the walrus operator.)
>

That was my main concern, one of the advantages of using a widely used
package like black (or clang-format) is that it is more likely to be
maintained going forward. It is also easier to find help if needed.



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

[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

[Numpy-discussion] NumPy 1.23.4 released.

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of
NumPy 1.23.4. NumPy 1.23.4 is a maintenance release that fixes bugs
discovered after the 1.23.3 release and keeps the build infrastructure
current. The main improvements are fixes for some annotation corner cases,
a fix for a long time *nested_iters* memory leak, and a fix of complex
vector dot for very large arrays. 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 the mypy version needs to be 0.981+ if you test using Python
3.10.7, otherwise the typing tests will fail.


*Contributors*

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

   - Bas van Beek
   - Charles Harris
   - Matthew Barber
   - Matti Picus
   - Ralf Gommers
   - Ross Barnowski
   - Sebastian Berg
   - Sicheng Zeng +



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

   - #22368: BUG: Add ``__array_api_version__`` to ``numpy.array_api``
   namespace
   - #22370: MAINT: update sde toolkit to 9.0, fix download link
   - #22382: BLD: use macos-11 image on azure, macos-1015 is deprecated
   - #22383: MAINT: random: remove ``get_info`` from "extending with
   Cython"...
   - #22384: BUG: Fix complex vector dot with more than NPY_CBLAS_CHUNK
   elements
   - #22387: REV: Loosen ``lookfor``'s import try/except again
   - #22388: TYP,ENH: Mark ``numpy.typing`` protocols as runtime checkable
   - #22389: TYP,MAINT: Change more overloads to play nice with pyright
   - #22390: TST,TYP: Bump mypy to 0.981
   - #22391: DOC: Update delimiter param description.
   - #22392: BUG: Memory leaks in numpy.nested_iters
   - #22413: REL: Prepare for the NumPy 1.23.4 release.
   - #22424: TST: Fix failing aarch64 wheel builds.

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

[Numpy-discussion] Re: mypy occasional error on _UnknownType in _array_like.py since 1.22 or 1.23

[Charles R Harris]

On Mon, Oct 10, 2022 at 12:27 PM Nick Gerner  wrote:

> I upgraded from 1.21 to 1.23.3 recently and got a variety of mypy issues.
> I seem to have resolved all of them, but I occasionally still see this show
> up:
>
> .venv/lib/python3.10/site-packages/numpy/_typing/_array_like.py:153:
> error: Type argument "_UnknownType" of "dtype" must be a subtype of
> "generic"  [type-var]
>
> On mypy 0.981 this is not 100% repro and if I restart dmypy it goes
> away... until it comes back. I just now upgraded to mypy 0.982 and didn't
> get it on one run, at least not right away. Maybe this was some kind of
> mypy issue, but time will tell.
>
> I haven't seen exactly this error getting posted anywhere. I know this is
> a fairly recent change and it looks like there's a lot of type hinting work
> going on (excellent work! I love it, thank you numpy devs!).
>
> Anyone else got any insight on what's going on here? Is this a known
> issue? Is this a mypy issue?
>
> Thanks everyone.
>

I'd be very curious to know if 0.982 fixes things. I know that using python
3.10.7 causes problems for mypy < 0.981.

Chuck
___
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.2 release

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of
NumPy 1.23.2. NumPy 1.23.2 is a maintenance release that fixes bugs
discovered after the 1.23.1 release. Notable features are:

   - Typing changes needed for Python 3.11
   - Wheels for Python 3.11.0rc1

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
.

*Contributors*

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

   - Alexander Grund +
   - Bas van Beek
   - Charles Harris
   - Jon Cusick +
   - Matti Picus
   - Michael Osthege +
   - Pal Barta +
   - Ross Barnowski
   - Sebastian Berg


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

   - #22030: ENH: Add ``__array_ufunc__`` typing support to the ``nin=1``
   ufuncs
   - #22031: MAINT, TYP: Fix ``np.angle`` dtype-overloads
   - #22032: MAINT: Do not let ``_GenericAlias`` wrap the underlying
   classes'...
   - #22033: TYP,MAINT: Allow ``einsum`` subscripts to be passed via
   integer...
   - #22034: MAINT,TYP: Add object-overloads for the ``np.generic`` rich
   comparisons
   - #22035: MAINT,TYP: Allow the ``squeeze`` and ``transpose`` method to...
   - #22036: BUG: Fix subarray to object cast ownership details
   - #22037: BUG: Use ``Popen`` to silently invoke f77 -v
   - #22038: BUG: Avoid errors on NULL during deepcopy
   - #22039: DOC: Add versionchanged for converter callable behavior.
   - #22057: MAINT: Quiet the anaconda uploads.
   - #22078: ENH: reorder includes for testing on top of system
   installations...
   - #22106: TST: fix test_linear_interpolation_formula_symmetric
   - #22107: BUG: Fix skip condition for test_loss_of_precision[complex256]
   - #22115: BLD: Build python3.11.0rc1 wheels.

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

[Numpy-discussion] Python 3.11.0rc1 is out

[Charles R Harris]

Hi All,

Just to note that Python 3.11.0rc1 has been released. I plan to make a
NumPy 1.23.2 release with support for that as soon as it is available on
our build platforms.

Chuck
___
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.24.1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.1. NumPy 1.24.1 is a maintenance release that fixes bugs and
regressions discovered after the 1.24.0 release.

The Python versions supported by this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - Andrew Nelson
   - Ben Greiner +
   - Charles Harris
   - Clément Robert
   - Matteo Raso
   - Matti Picus
   - Melissa Weber Mendonça
   - Miles Cranmer
   - Ralf Gommers
   - Rohit Goswami
   - Sayed Adel
   - Sebastian Berg


*Pull requests merged*

A total of 18 pull requests were merged for this release.

   - #22820: BLD: add workaround in setup.py for newer setuptools
   - #22830: BLD: CIRRUS_TAG redux
   - #22831: DOC: fix a couple typos in 1.23 notes
   - #22832: BUG: Fix refcounting errors found using pytest-leaks
   - #22834: BUG, SIMD: Fix invalid value encountered in several ufuncs
   - #22837: TST: ignore more np.distutils.log imports
   - #22839: BUG: Do not use getdata() in np.ma.masked_invalid
   - #22847: BUG: Ensure correct behavior for rows ending in delimiter
   in\...
   - #22848: BUG, SIMD: Fix the bitmask of the boolean comparison
   - #22857: BLD: Help raspian arm + clang 13 about builtin_mul_overflow
   - #22858: API: Ensure a full mask is returned for masked_invalid
   - #22866: BUG: Polynomials now copy properly (#22669)
   - #22867: BUG, SIMD: Fix memory overlap in ufunc comparison loops
   - #22868: BUG: Fortify string casts against floating point warnings
   - #22875: TST: Ignore nan-warnings in randomized out tests
   - #22883: MAINT: restore npymath implementations needed for freebsd
   - #22884: BUG: Fix integer overflow in in1d for mixed integer dtypes
   #22877
   - #22887: BUG: Use whole file for encoding checks with
   `charset_normalizer`.


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

[Numpy-discussion] Re: status of long double support and what to do about it

[Charles R Harris]

On Sun, Dec 4, 2022 at 9:36 AM  wrote:

> Hello,
>
> I am interested in contributing to this. I am a contributor in the PINT
> pulsar timing package Scott mentioned. But I am new to contributing to
> numpy, and I am not sure where or how to begin. Are there beginner-level
> resources that I can look at?
>
> Regards
>
> Abhimanyu Susobhanan
> Postdoctoral fellow
> Centre for Gravitation, Cosmology, and Astrophysics
> University of Wisconsin Milwaukee
>

I think the first thing to do is have a discussion in the astropy
community. Dependence on extended precision is fragile at best, it
isn't available on all platforms and probably doesn't offer enough
precision to be future proof. Then gather some performance data.

   1. What computations are needed?
   2. Can the computational algorithms be improved?
   3. Would parallel computation help?
   4. How much faster is extended precision?
   5. Where are the performance bottlenecks in the double-double time type?
   6. Is there hope of improving the double-double performance.

My own hope would be that a combination parallel computation and lower
level code for double-double would be a viable solution.

Chuck
___
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.24.0 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.0. The NumPy 1.24.0 release continues the ongoing work to improve the
handling and promotion of dtypes, increase execution speed, and
clarify the documentation. There are also a large number of new and expired
deprecations due to changes in promotion and cleanups. This might be called
a deprecation release. Highlights are

   - Many new deprecations.
   - Many expired deprecations.
   - New f2py features and fixes.
   - New "dtype" and "casting" keywords for stacking functions.

The Python versions supported in this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @amagicmuffin +
   - @dg3192 +
   - @h-vetinari
   - @juztamau5 +
   - @swagatip +
   - Aaron Meurer
   - Aayush Agrawal +
   - Adam Knapp +
   - Adarsh Singh +
   - Al-Baraa El-Hag
   - Alban Desmaison +
   - Ales Crocaro +
   - Alex Low +
   - Alexander Grund +
   - Alexander Kanavin +
   - Andras Deak
   - Andrew Nelson
   - Angéllica Araujo +
   - Anselm Hahn +
   - Ari Cooper Davis +
   - Axel Huebl +
   - Bas van Beek
   - Bhavuk Kalra
   - Bram Ton +
   - Brent Tan +
   - Brigitta Sipőcz
   - Callum O'Riley +
   - Charles Harris
   - Chiara Marmo
   - Christoph Reiter
   - Damien Caliste
   - Dan Schult +
   - Daniel da Silva
   - DanielHabenicht +
   - Dave Goel +
   - David Gilbertson +
   - Developer-Ecosystem-Engineering
   - Digya Acharya +
   - Dimitri Papadopoulos Orfanos
   - Eric-Shang +
   - Evgeni Burovski
   - Ewout ter Hoeven
   - Felix Hirwa Nshuti +
   - Frazer McLean +
   - Ganesh Kathiresan
   - Gavin Zhang +
   - Gaëtan de Menten
   - Greg Lucas
   - Greg Sadetsky +
   - Gregory P. Smith [Google LLC] +
   - Hameer Abbasi
   - Hannah Aizenman +
   - Hood Chatham
   - I-Shen Leong
   - Iantra Solari +
   - Ikko Ashimine +
   - Inessa Pawson
   - Jake Bowhay +
   - Jake Close +
   - Jarrod Millman
   - Jason Thai
   - JessePires +
   - Jessé Pires +
   - Jhonatan Cunha +
   - Jingxuan He +
   - Johnathon Cusick +
   - Jon Morris
   - Jordy Williams +
   - Josh Wilson
   - João Fontes Gonçalves +
   - Juan Luis Cano Rodríguez
   - Jyn Spring 琴春 +
   - KIU Shueng Chuan
   - Karl Otness +
   - Kevin Sheppard
   - Kinshuk Dua +
   - Leo Fang
   - Leona Taric +
   - Lev Maximov +
   - Lillian Zha +
   - Loïc Estève
   - M. Eric Irrgang +
   - Mariusz Felisiak
   - Mark Harfouche
   - Martin Zacho +
   - Matheus Santana Patriarca +
   - Matt Williams +
   - Matteo Raso +
   - Matthew Barber
   - Matthew Brett
   - Matthew Sterrett +
   - Matthias Bussonnier
   - Matthias Koeppe +
   - Matti Picus
   - Meekail Zain +
   - Melissa Weber Mendonça
   - Michael Osthege +
   - Michael Siebert +
   - Mike Toews
   - Miki Watanabe +
   - Miles Cranmer +
   - Monika Kubek +
   - Muhammad Jarir Kanji +
   - Mukulika Pahari
   - Namami Shanker
   - Nathan Goldbaum +
   - Nathan Rooy +
   - Navpreet Singh +
   - Noritada Kobayashi +
   - Oleksiy Kononenko +
   - Omar Ali +
   - Pal Barta +
   - Pamphile Roy
   - Patrick Hoefler +
   - Pearu Peterson
   - Pedro Nacht +
   - Petar Mlinarić +
   - Peter Hawkins
   - Pey Lian Lim
   - Pieter Eendebak
   - Pradipta Ghosh
   - Pranab Das +
   - Precision Wordcraft LLC +
   - PrecisionWordcraft +
   - Rafael CF Sousa +
   - Rafael Cardoso Fernandes Sousa
   - Rafael Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Rin Cat (鈴猫) +
   - Robert Kern
   - Rohit Davas +
   - Rohit Goswami
   - Ross Barnowski
   - Roy Smart +
   - Ruth Comer +
   - Sabiha Tahsin Soha +
   - Sachin Krishnan T V +
   - Sanjana M Moodbagil +
   - Sanya Sinha +
   - Sarah Coffland +
   - Saransh Chopra +
   - Satish Kumar Mishra +
   - Satish Mishra +
   - Sayed Adel
   - Schrijvers Luc +
   - Sebastian Berg
   - Serge Guelton
   - Seva Lotoshnikov +
   - Shashank Gupta +
   - Shoban Chiddarth +
   - Shreya Singh +
   - Shreyas Joshi +
   - Sicheng Zeng +
   - Simran Makandar +
   - Shuangchi He +
   - Srimukh Sripada +
   - Stefan van der Walt
   - Stefanie Molin +
   - Stuart Archibald
   - Tania Allard
   - Thomas A Caswell
   - Thomas Kastl +
   - Thomas Mansencal +
   - Tony Newton / Teng Liu +
   - Toshiki Kataoka
   - Tyler Reddy
   - Vardhaman Kalloli +
   - Warren Weckesser
   - Will Ayd +
   - William Stein +
   - XinRu Lin +
   - Yin Li +
   - Yunika Bajracharya +
   - Zachary Blackwood +
   - 渡邉 美希 +

Cheers,

Charles Harris
___
NumPy-Discussion mailing list -- 

[Numpy-discussion] Re: status of long double support and what to do about it

[Charles R Harris]

On Wed, Dec 14, 2022 at 1:44 PM Scott Ransom  wrote:

> On 12/14/22 3:01 PM, Carl Kleffner wrote:
> > Hi Scott,
> >
> > may I ask you which kind of vector / matrix operation in extended
> precision (np.longdouble) is
> > supported in 'pint' ? It can't be backed by the underlying blas library
> as extended precision
> > functions are not supported there.
> >
> > Carl
>
> Hi Carl,
>
> The vast majority of them are simply a vector of np.longdoubles (which are
> usually times or time
> differences) which are operated on by regular Numpy math functions to
> compute new quantities.  For
> example, polynomial computations base on time, many trigonometric
> operations on the times for orbit
> calculations, things like that.
>
> We don't really do big longdouble matrix operations.
>

Sounds like a good place to start looking for improvements is in addition
and multiplication.

Chuck
___
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.24.0rc2 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.0rc1. The NumPy 1.24.0 release continues the ongoing work to improve
the handling and promotion of dtypes, increase execution speed, and
clarify the documentation. There are also a large number of new and expired
deprecations due to changes in promotion and cleanups. This might be called
a deprecation release. Highlights are

   - Many new deprecations.
   - Many expired deprecations.
   - New f2py features and fixes.
   - New "dtype" and "casting" keywords for stacking functions.

The Python versions supported in this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release
notes, and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @amagicmuffin +
   - @dg3192 +
   - @h-vetinari
   - @juztamau5 +
   - @swagatip +
   - Aaron Meurer
   - Aayush Agrawal +
   - Adam Knapp +
   - Adarsh Singh +
   - Al-Baraa El-Hag
   - Alban Desmaison +
   - Ales Crocaro +
   - Alex Low +
   - Alexander Grund +
   - Alexander Kanavin +
   - Andras Deak
   - Angéllica Araujo +
   - Anselm Hahn +
   - Ari Cooper Davis +
   - Axel Huebl +
   - Bas van Beek
   - Bhavuk Kalra
   - Bram Ton +
   - Brent Tan +
   - Brigitta Sipőcz
   - Callum O'Riley +
   - Charles Harris
   - Chiara Marmo
   - Christoph Reiter
   - Damien Caliste
   - Dan Schult +
   - Daniel da Silva
   - DanielHabenicht +
   - Dave Goel +
   - David Gilbertson +
   - Developer-Ecosystem-Engineering
   - Digya Acharya +
   - Dimitri Papadopoulos Orfanos
   - Eric-Shang +
   - Evgeni Burovski
   - Ewout ter Hoeven
   - Felix Hirwa Nshuti +
   - Frazer McLean +
   - Ganesh Kathiresan
   - Gavin Zhang +
   - Gaëtan de Menten
   - Greg Lucas
   - Greg Sadetsky +
   - Gregory P. Smith [Google LLC] +
   - Hameer Abbasi
   - Hannah Aizenman +
   - Hood Chatham
   - I-Shen Leong
   - Iantra Solari +
   - Ikko Ashimine +
   - Inessa Pawson
   - Jake Bowhay +
   - Jake Close +
   - Jarrod Millman
   - Jason Thai
   - JessePires +
   - Jessé Pires +
   - Jhonatan Cunha +
   - Jingxuan He +
   - Johnathon Cusick +
   - Jon Morris
   - Jordy Williams +
   - Josh Wilson
   - João Fontes Gonçalves +
   - Juan Luis Cano Rodríguez
   - Jyn Spring 琴春 +
   - KIU Shueng Chuan
   - Karl Otness +
   - Kevin Sheppard
   - Kinshuk Dua +
   - Leo Fang
   - Leona Taric +
   - Lev Maximov +
   - Lillian Zha +
   - Loïc Estève
   - M. Eric Irrgang +
   - Mariusz Felisiak
   - Mark Harfouche
   - Martin Zacho +
   - Matheus Santana Patriarca +
   - Matt Williams +
   - Matteo Raso +
   - Matthew Barber
   - Matthew Brett
   - Matthew Sterrett +
   - Matthias Bussonnier
   - Matthias Koeppe +
   - Matti Picus
   - Meekail Zain +
   - Melissa Weber Mendonça
   - Michael Osthege +
   - Michael Siebert +
   - Mike Toews
   - Miki Watanabe +
   - Miles Cranmer +
   - Monika Kubek +
   - Muhammad Jarir Kanji +
   - Mukulika Pahari
   - Namami Shanker
   - Nathan Goldbaum +
   - Nathan Rooy +
   - Navpreet Singh +
   - Noritada Kobayashi +
   - Oleksiy Kononenko +
   - Omar Ali +
   - Pal Barta +
   - Pamphile Roy
   - Patrick Hoefler +
   - Pearu Peterson
   - Pedro Nacht +
   - Petar Mlinarić +
   - Peter Hawkins
   - Pey Lian Lim
   - Pieter Eendebak
   - Pradipta Ghosh
   - Pranab Das +
   - Precision Wordcraft LLC +
   - PrecisionWordcraft +
   - Rafael CF Sousa +
   - Rafael Cardoso Fernandes Sousa
   - Rafael Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Rin Cat (鈴猫) +
   - Robert Kern
   - Rohit Davas +
   - Rohit Goswami
   - Ross Barnowski
   - Ruth Comer +
   - Sabiha Tahsin Soha +
   - Sachin Krishnan T V +
   - Sanjana M Moodbagil +
   - Sanya Sinha +
   - Sarah Coffland +
   - Saransh Chopra +
   - Satish Kumar Mishra +
   - Satish Mishra +
   - Sayed Adel
   - Schrijvers Luc +
   - Sebastian Berg
   - Serge Guelton
   - Seva Lotoshnikov +
   - Shashank Gupta +
   - Shoban Chiddarth +
   - Shreya Singh +
   - Shreyas Joshi +
   - Sicheng Zeng +
   - Simran Makandar +
   - Shuangchi He +
   - Srimukh Sripada +
   - Stefan van der Walt
   - Stefanie Molin +
   - Stuart Archibald
   - Tania Allard
   - Thomas A Caswell
   - Thomas Kastl +
   - Thomas Mansencal +
   - Tony Newton / Teng Liu +
   - Toshiki Kataoka
   - Tyler Reddy
   - Vardhaman Kalloli +
   - Warren Weckesser
   - Will Ayd +
   - William Stein +
   - XinRu Lin +
   - Yin Li +
   - Yunika Bajracharya +
   - Zachary Blackwood +
   - 渡邉 美希 +

Cheers,

Charles Harris
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe 

[Numpy-discussion] Re: status of long double support and what to do about it

[Charles R Harris]

On Thu, Nov 17, 2022 at 6:30 PM Scott Ransom  wrote:

>
>
> On 11/17/22 7:13 PM, Charles R Harris wrote:
> >
> >
> > On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers  > <mailto:ralf.gomm...@gmail.com>> wrote:
> >
> > Hi all,
> >
> > We have to do something about long double support. This is something
> I wanted to propose a long
> > time ago already, and moving build systems has resurfaced the pain
> yet again.
> >
> > This is not a full proposal yet, but the start of a discussion and
> gradual plan of attack.
> 
> > I would agree that extended precision is pretty useless, IIRC, it was
> mostly intended as an accurate
> > way to produce double precision results. That idea was eventually
> dropped as not very useful. I'd
> > happily do away with subnormal doubles as well, they were another not
> very useful idea. And strictly
> > speaking, we should not support IBM double-double either, it is not in
> the IEEE standard.
> >
> > That said, I would like to have a quad precision type. That precision is
> useful for some things, and
> > I have a dream that someday it can be used for a time type.
> Unfortunately, last time I looked
> > around, none of the available implementations had a NumPy compatible
> license.
> >
> > The tricky thing here is to not break downstream projects, but that may
> be unavoidable. I suspect
> > the fallout will not be that bad.
> >
> > Chuck
>
> A quick response from one of the leaders of a team that requires 80bit
> extended precision for
> astronomical work...
>
> "extended precision is pretty useless" unless you need it. And the
> high-precision pulsar timing
> community needs it. Standard double precision (64-bit) values do not
> contain enough precision for us
> to pass relative astronomical times via a single float without extended
> precision (the precision
> ends up being at the ~1 microsec level over decades of time differences,
> and we need it at the
> ~1-10ns level) nor can we store the measured spin frequencies (or do
> calculations on them) of our
> millisecond pulsars with enough precision. Those spin frequencies can have
> 16-17 digits of base-10
> precision (i.e. we measure them to that precision). This is why we use
> 80-bit floats (usually via
> Linux, but also on non X1 Mac hardware if you use the correct compilers)
> extensively.
>
> Numpy is a key component of the PINT software to do high-precision pulsar
> timing, and we use it
> partly *because* it has long double support (with 80-bit extended
> precision):
> https://github.com/nanograv/PINT
> And see the published paper here, particularly Sec 3.3.1 and footnote #42:
> https://ui.adsabs.harvard.edu/abs/2021ApJ...911...45L/abstract
>
> Going to software quad precision would certainly work, but it would
> definitely make things much
> slower for our matrix and vector math.
>
> We would definitely love to see a solution for this that allows us to get
> the extra precision we
> need on other platforms besides Intel/AMD64+Linux (primarily), but giving
> up extended precision on
> those platforms would *definitely* hurt. I can tell you that the pulsar
> community would definitely
> be against option "B". And I suspect that there are other users out there
> as well.
>
> Scott
> NANOGrav Chair
> www.nanograv.org
>
>
>
Pulsar timing is one reason I wanted a quad precision time type. I thought
Astropy was using a self implemented double-double type to work around that?

Chuck
___
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.24.0rc1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.0rc1. The NumPy 1.24.0 release continues the ongoing work to improve
the handling and promotion of dtypes, increase execution speed, and
clarify the documentation. There are also a large number of new and expired
deprecations due to changes in promotion and cleanups. This might be called
a deprecation release. Highlights are

   - Many new deprecations.
   - Many expired deprecations.
   - New f2py features and fixes.
   - New "dtype" and "casting" keywords for stacking functions.

The Python versions supported in this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release
notes, and wheel hashes are available on Github
. The Python 3.8
aarch64 wheel is missing from this pre-release due to build problems.

*Contributors*

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


   - @DWesl
   - @h-vetinari
   - Aaron Meurer
   - Aayush Agrawal +
   - Adam Knapp +
   - Adarsh Singh +
   - Al-Baraa El-Hag
   - Alban Desmaison +
   - Ales Crocaro +
   - Alex +
   - Alexander Grund +
   - Alexander Kanavin +
   - Andras Deak
   - Angéllica Araujo +
   - Anselm Hahn +
   - Ari Cooper Davis +
   - Axel Huebl +
   - Bas van Beek
   - Bhavuk Kalra
   - Bram Ton +
   - Brent Tan +
   - Brigitta Sipőcz
   - Callum O'Riley +
   - Charles Harris
   - Chiara Marmo
   - Christoph Reiter
   - Damien Caliste
   - Dan Schult +
   - Daniel da Silva
   - DanielHabenicht +
   - Dave Goel +
   - David Gilbertson +
   - Developer-Ecosystem-Engineering
   - Digya Acharya +
   - Dimitri Papadopoulos Orfanos
   - Eric-Shang +
   - Evgeni Burovski
   - Ewout ter Hoeven
   - Felix Hirwa Nshuti +
   - Frazer McLean +
   - Ganesh Kathiresan
   - Gavin Zhang +
   - Gaëtan de Menten
   - Greg Lucas
   - Greg Sadetsky +
   - Gregory P. Smith [Google LLC] +
   - Hameer Abbasi
   - Hannah Aizenman +
   - Hood Chatham
   - I-Shen Leong
   - Iantra Solari +
   - Ikko Ashimine +
   - Inessa Pawson
   - Jake Bowhay +
   - Jake Close +
   - Jarrod Millman
   - Jason Thai
   - Jessé Pires +
   - Jhonatan Cunha +
   - Jingxuan He +
   - Johnathon Cusick +
   - Jon Morris
   - Jordy Williams +
   - Josh Wilson
   - João Fontes Gonçalves +
   - Juan Luis Cano Rodríguez
   - Jyn Spring 琴春 +
   - KIU Shueng Chuan
   - Karl Otness +
   - Kevin Sheppard
   - Kinshuk Dua +
   - Leo Fang
   - Leona Taric +
   - Lev Maximov +
   - Lillian Zha +
   - Loïc Estève
   - M. Eric Irrgang +
   - Mariusz Felisiak
   - Mark Harfouche
   - Martin Zacho +
   - Matheus Santana Patriarca +
   - Matt Williams +
   - Matteo Raso +
   - Matthew Barber
   - Matthew Brett
   - Matthew Sterrett +
   - Matthias Bussonnier
   - Matthias Koeppe +
   - Matti Picus
   - Meekail Zain +
   - Melissa Weber Mendonça
   - Michael Osthege +
   - Michael Siebert +
   - Mike Toews
   - Miki Watanabe +
   - Miles Cranmer +
   - MilesCranmer +
   - Monika Kubek +
   - Muhammad Jarir Kanji +
   - Mukulika Pahari
   - Namami Shanker
   - Nathan Goldbaum +
   - Nathan Rooy +
   - Navpreet Singh +
   - Noritada Kobayashi +
   - Oleksiy Kononenko +
   - Omar +
   - Pal Barta +
   - Pamphile Roy
   - Patrick Hoefler +
   - Pearu Peterson
   - Pedro Nacht +
   - Petar Mlinarić +
   - Pey Lian Lim
   - Pieter Eendebak
   - Pradipta Ghosh
   - Pranab Das +
   - Precision Wordcraft LLC +
   - PrecisionWordcraft +
   - Rafael CF Sousa +
   - Rafael Cardoso Fernandes Sousa
   - Rafael Sousa +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Rin Cat (鈴猫) +
   - Robert Kern
   - Rohit Davas +
   - Rohit Goswami
   - Ross Barnowski
   - Ruth Comer +
   - Sabiha Tahsin Soha +
   - Sachin Krishnan T V +
   - Sanjana M Moodbagil +
   - Sanya Sinha +
   - Sarah Coffland +
   - Saransh Chopra +
   - Satish Kumar Mishra +
   - Satish Mishra +
   - Sayed Adel
   - Schrijvers Luc +
   - Sebastian Berg
   - Serge Guelton
   - Seva Lotoshnikov +
   - Shashank Gupta +
   - Shoban Chiddarth +
   - Shreya Singh +
   - Shreyas Joshi +
   - Sicheng Zeng +
   - Simran Makandar +
   - Srimukh Sripada +
   - Stefan van der Walt
   - Stefanie Molin +
   - Stuart Archibald
   - Tania Allard
   - Thomas A Caswell
   - Thomas Kastl +
   - Thomas Mansencal +
   - Tony Newton / Teng Liu +
   - Toshiki Kataoka
   - Tyler Reddy
   - Vardhaman Kalloli +
   - Warren Weckesser
   - Will Ayd +
   - William Stein +
   - XinRu Lin +
   - Yin Li +
   - Yulv-git +
   - Yunika Bajracharya +
   - Zachary Blackwood +
   - amagicmuffin +
   - dg3192 +
   - juztamau5 +
   - swagatip +
   - 渡邉 美希 +

Cheers,

Charles Harris
___
NumPy-Discussion mailing 

[Numpy-discussion] NumPy 1.24.x branched

[Charles R Harris]

Hi All,

NumPy 1.24.x has been branched.

Chuck
___
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: ANN: NumPy Fellowship Program & Sayed Adel as our first Developer in Residence

[Charles R Harris]

On Thu, Dec 1, 2022 at 2:22 PM Ralf Gommers  wrote:

> Hi all,
>
> I'm excited to be able to share this announcement on behalf of the NumPy
> Steering Council. We have created a new program, the NumPy Fellowship
> Program, and offered Sayed Adel the very first Developer in Residence role.
> Sayed starts his 1 year tenure in that role today, and we are really
> looking forward to him working on NumPy full-time.
>
> We wrote a blog post about the program, and why we offered the role to
> Sayed: https://blog.scientific-python.org/numpy/fellowship-program/. I've
> copied the blog post content at the end of this email.
>
> In addition, here is some more detail on NumPy project finances that
> didn't make it into the blog post (which is likely to have a wider audience
> than the readership of this mailing list), but is quite relevant to share
> here:
>
> Over the past decade, NumPy has accumulated individual donations as well
> as payments from Tidelift. NumPy has been a fiscally sponsored project of
> NumFOCUS for a decade - meaning that NumFOCUS, as a 501(c)3 nonprofit,
> administers funds for NumPy. As a result, NumPy has accumulated funds for a
> long time - and those are now transparently administered on Open
> Collective . There you will see a
> "general fund", currently with a ~$23,000 balance, and two open "projects"
> with committed funding - one for the active CZI grant we have, and one for
> this new Fellowship Program. Guidelines for using those funds are described
> in https://numpy.org/neps/nep-0048-spending-project-funds.html.
>
> Finally it is worth pointing out that we are now able to solicit donations
> on Open Collective, and have added contribution tiers on the front page of
> https://opencollective.com/numpy. Until now, we have never actively
> solicited donations as a project, because the accounting support and
> transparent financial reporting was not in place. That has changed now
> though, so we are hoping that with guidelines to spend funds plus a
> concrete fellowship program that we're expecting to be quite impactful, we
> are now able to confidently tell people that if they donate to NumPy, we
> will manage their contribution well and translate it into more time for
> someone on the NumPy team to make NumPy better.
>
> Cheers,
> Ralf
>
>
> blog post content:
>
> The NumPy team is excited to announce the launch of the NumPy Fellowship
> Program and the appointment of Sayed Adel (@seiko2plus) as the first NumPy
> Developer in Residence. This is a significant milestone in the history of
> the project: for the first time, NumPy is in a position to use its project
> funds to pay for a full year of maintainer time. We believe that this will
> be an impactful program that will contribute to NumPy’s long-term
> sustainability as a community-driven open source project.
>
> Sayed has been making major contributions to NumPy since the start of
> 2020, in particular around computational performance. He is the main author
> of the NumPy SIMD architecture (NEP 38, docs), generously shared his
> knowledge of SIMD instructions with the core developer team, and helped
> integrate the work of various volunteer and industry contributors in this
> area. As a result, we’ve been able to expand support to multiple CPU
> architectures, integrating contributions from IBM, Intel, Apple, and
> others, none of which would have been possible without Sayed. Furthermore,
> when NumPy tentatively started using C++ in 2021, Sayed was one of the
> proponents of the move and helped with its implementation.
>
> The NumPy Steering Council sees Sayed’s appointment to this role as both
> recognition of his past outstanding contributions as well as an opportunity
> to continue improving NumPy’s computational performance. In the next 12
> months, we’d like to see Sayed focus on the following:
>
> SIMD code maintenance,
> code review of SIMD contributions from others,
> performance-related features,
> sharing SIMD and C++ expertise with the team and growing a NumPy
> sub-team around it,
> SIMD build system migration to Meson,
> and wherever else Sayed’s interests take him.
>
> “I’m both happy and nervous: this is a great opportunity, but also a
> great responsibility,” said Sayed in response to his appointment.
>
> The funds for the NumPy Fellowship Program come from a partnership with
> Tidelift and from individual donations. We sincerely thank both Tidelift
> and everyone who donated to the project—without you, this program would not
> be possible! We also acknowledge the CPython Developer-in-Residence and the
> Django Fellowship programs, which served as inspiration for this program.
>
> Sayed officially starts as the NumPy Developer in Residence today, 1
> December 2022. Already, we are thinking about opportunities beyond this
> first year: we imagine “in residence” roles that focus on developing,
> improving, and maintaining other parts of the NumPy project 

[Numpy-discussion] Re: status of long double support and what to do about it

[Charles R Harris]

On Thu, Nov 17, 2022 at 3:15 PM Ralf Gommers  wrote:

> Hi all,
>
> We have to do something about long double support. This is something I
> wanted to propose a long time ago already, and moving build systems has
> resurfaced the pain yet again.
>
> This is not a full proposal yet, but the start of a discussion and gradual
> plan of attack.
>
> The problem
> ---
> The main problem is that long double support is *extremely* painful to
> maintain, probably far more than justified. I could write a very long story
> about that, but instead I'll just illustrate with some of the key points:
>
> (1) `long double` is the main reason why we're having such a hard time
> with building wheels on Windows, for SciPy in particular. This is because
> MSVC makes long double 64-bit, and Mingw-w64 defaults to 80-bit. So we have
> to deal with Mingw-w64 toolchains, proposed compiler patches, etc. This
> alone has been a massive time sink. A couple of threads:
>   https://github.com/numpy/numpy/issues/20348
>
> https://discuss.scientific-python.org/t/releasing-or-not-32-bit-windows-wheels/282
> The first issue linked above is one of the key ones, with a lot of detail
> about the fundamental problems with `long double`. The Scientific Python
> thread focused more on Fortran, however that Fortran + Windows problem is
> at least partly the fault of `long double`. And Fortran may be rejuvenated
> with LFortran and fortran-lang.org; `long double` is a dead end.
>
> (2) `long double` is not a well-defined format. We support 9 specific
> binary representations, and have a ton of code floating around to check for
> those, and manually fiddle with individual bits in long double numbers.
> Part of that is the immediate pain point for me right now: in the configure
> stage of the build we consume object files produced by the compiler and
> parse them, matching some known bit patterns. This check is so weird that
> it's the only one that I cannot implement in Meson (short of porting the
> hundreds of lines of Python code for it to C), see
> https://github.com/mesonbuild/meson/issues/11068 for details. To get an
> idea of the complexity here:
>
> https://github.com/numpy/numpy/blob/9e144f7c1598221510d49d8c6b79c66dc000edf6/numpy/core/setup_common.py#L264-L434
>
> https://github.com/numpy/numpy/blob/9e144f7c1598221510d49d8c6b79c66dc000edf6/numpy/core/src/npymath/npy_math_private.h#L179-L484
>
> https://github.com/numpy/numpy/blob/main/numpy/core/src/npymath/npy_math_complex.c.src#L598-L619
>
> https://github.com/numpy/numpy/blob/main/numpy/core/src/multiarray/dragon4.c#L2480-L3052
> Typically `long double` has multiple branches, and requires more code than
> float/double.
>
> (3) We spend a lot of time dealing with issues and PR to keep `long
> double` working, as well as dealing with hard-to-diagnose build issues.
> Which sometimes even stops people from building/contributing, especially on
> Windows. Some recent examples:
> https://github.com/numpy/numpy/pull/20360
> https://github.com/numpy/numpy/pull/18536
> https://github.com/numpy/numpy/pull/21813
> https://github.com/numpy/numpy/pull/22405
> https://github.com/numpy/numpy/pull/19950
> https://github.com/numpy/numpy/pull/18330/commits/aa9fd3c7cb
> https://github.com/scipy/scipy/issues/16769
> https://github.com/numpy/numpy/issues/14574
>
> (4) `long double` isn't all that useful. On both Windows and macOS `long
> double` is 64-bit, which means it is just a poor alias to `double`. So it
> does literally nothing for the majority of our users, except confuse them
> and take up extra memory. On Linux, `long double` is 80-bit precision,
> which means it doesn't do all that much there either, just a modest bump in
> precision.
>
> Let me also note that it's not just the user-visible dtypes that we have
> to consider; long double types are also baked into the libnpymath static
> library that we ship with NumPy. That's a thing we have to do something
> about anyway (shipping static libraries is not the best idea, see
> https://github.com/numpy/numpy/issues/20880). We just have to make sure
> to not forget about it when thinking about solutions here.
>
>
> Potential solutions
> ---
>
> (A) The ideal solution would be to have a proper, portable quad-precision
> (128 bits of precision) dtype. It's now possible to write that externally,
> after all the work that Sebastian and others have put into the dtype
> infrastructure. The dtype itself already exists (
> https://github.com/peytondmurray/quaddtype, maybe there are more
> implementations floating around). It just need the people who have an
> actual need for it to drive that. It's still a significant amount of work,
> so I'll not go into this one more right now.
>
> (B) Full deprecation and removal of all `long double` support from NumPy
> (and SciPy), irrespective of whether the quad dtype comes to life.
>
> Given the current state, I'm personally convinced that that is easily
> justified. However, I know some folks 

[Numpy-discussion] Release of NumPy 1.23.5

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of
NumPy 1.23.5. NumPy 1.23.5 is a maintenance release that fixes bugs
discovered after the 1.23.4 release and keeps the build infrastructure
current. 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
.

*Contributors*

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

   - @DWesl
   - Aayush Agrawal +
   - Adam Knapp +
   - Charles Harris
   - Navpreet Singh +
   - Sebastian Berg
   - Tania Allard


*Pull requests merged*

A total of 10 pull requests were merged for this release.

   - #22489: TST, MAINT: Replace most setup with setup_method (also
   teardown)
   - #22490: MAINT, CI: Switch to cygwin/cygwin-install-action@v2
   - #22494: TST: Make test_partial_iteration_cleanup robust but require
   leak...
   - #22592: MAINT: Ensure graceful handling of large header sizes
   - #22593: TYP: Spelling alignment for array flag literal
   - #22594: BUG: Fix bounds checking for ``random.logseries``
   - #22595: DEV: Update GH actions and Dockerfile for Gitpod
   - #22596: CI: Only fetch in actions/checkout
   - #22597: BUG: Decrement ref count in gentype_reduce if allocated
   memory...
   - #22625: BUG: Histogramdd breaks on big arrays in Windows

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

[Numpy-discussion] Re: Congratulation to our newest maintainer Mukulika Pahari

[Charles R Harris]

On Fri, Jan 27, 2023 at 3:23 AM Matti Picus  wrote:

> The NumPy steering council recently granted maintainer rights to
> Mukulika Pahari (https://github.com/Mukulikaa/)
>
>
> Mukulika was recently elected to co-lead the numpy documentation team,
> and has been active in reviewing documentation issues and PRs. Welcome
> and thanks for all you do.
> Matti
>

This is a great addition. Welcome Mukulika.

Chuck
___
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: Getting scipy.interpolate.pchip_interpolate to return the first derivative of a pchip interpolation

[Charles R Harris]

You should post at the scipy-user mailing list. See
https://svn.scipy.org/scipylib/mailing-lists.html.

On Sat, Jan 21, 2023 at 4:08 PM Samuel Dupree  wrote:

> I'm running SciPy ver. 1.9.3 under Python ver. 3.9.15  on a Mac Pro (2019)
> desktop running Mac OSX ver. 13.1 Ventura. The problem I'm having is
> getting scipy.interpolate.pchip_interpolate to return the first derivative
> of a pchip interpolation.
>
> The test program I'm using is given below (and attached to this note).
>
>
> import numpy as np
> import matplotlib.pyplot as plt
> from scipy.interpolate import pchip_interpolate
>
> x_observed  = np.linspace(0.0, 360.0, 51)
> y_observed  = np.sin(np.pi*x_observed/180)
> dydx_observed = np.cos(np.pi*x_observed/180)
>
> x= np.linspace(min(x_observed), max(x_observed), num=100)
> y= pchip_interpolate(x_observed, y_observed, x, der=0, axis=0)
> dydx = pchip_interpolate(x_observed, y_observed, x, der=1, axis=0)
>
> plt.plot(x_observed,y_observed, "bo" , label="observation funct")
> plt.plot(x_observed, dydx_observed, "rx" , label="observation deriv")
> plt.plot(x , y, "c-", label="pchip interpolation
> funct")
> plt.plot(x , dydx , "k-", label="pchip interpolation
> deriv")
> plt.legend()
> plt.savefig("pchip_example_01.png")
> plt.show()
>
>
> The program generates values of the sine function (y_observed) over the
> range of 0 to 360 degrees. (x_observed). In a similar fashion, the cosine
> function (first derivative of the sine function) is generated over the same
> range (dydx_observed). pchip_interpolate is used to perform the
> interpolation over a specified range for the function and its first
> derivative. A composite plot is generated showing the points for the
> function (the sine) and its first derivative (cosine). The interpolated
> points overlay the function (sine) as expected. However, the first
> derivative returned fails to overlay the cosine function. The plot is
> attached to this note.
>
> Any thoughts or suggestions?
>
> Sam Dupree
> ___
> 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: charlesr.har...@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: dropping support for Gitpod and our Docker image builds

[Charles R Harris]

On Mon, Mar 20, 2023 at 3:13 PM Ralf Gommers  wrote:

> Hi all,
>
> We received a notification from Docker that there Free Team organization
> no longer exists, and that we have until April 14 to upgrade to a paid
> tier. We only use Docker to support Gitpod. Gitpod builds have been broken
> in main for quite a while (see
> https://github.com/numpy/numpy/actions/workflows/gitpod.yml). Since it's
> a cron job that doesn't show up on PRs, but I get the notifications.
>
> Overall, Gitpod has been useful during some sprints, but it has proven to
> be too much maintenance effort. Maintaining a Docker team, CI jobs for
> building 2 Docker images, and a nontrivial amount of code and docs is no
> longer a good tradeoff.
>
> Here is what we have related to Gitpod:
> https://github.com/numpy/numpy/tree/main/tools/gitpod
> https://github.com/numpy/numpy/blob/main/.github/workflows/docker.yml
> https://github.com/numpy/numpy/blob/main/.github/workflows/gitpod.yml
>
> https://github.com/numpy/numpy/blob/main/doc/source/dev/development_gitpod.rst
> https://hub.docker.com/u/numpy
>
> We have a reasonable alternative, which is GitHub Codespaces. All it
> currently requires is ~lines of simple to understand code (
> https://github.com/numpy/numpy/tree/main/.devcontainer) and no CI jobs.
> We have one tracking issue for feedback in case you try it and find gaps:
> https://github.com/numpy/numpy/issues/23134. It doesn't pre-build NumPy
> locally, but that's only 1-2 minutes of wait time and is something a new
> contributor anyway has to learn about. The dev environment is reproducible,
> so this isn't much of a hurdle. We need replacement docs for that, but they
> can be much simpler I'd say. It's basically "go to
> https://github.com/codespaces/, hit the green button, and select the
> numpy repo, then it'll drop you into a VSCode IDE with a ready to go dev
> env".
>
> So my proposal is to drop all the Docker Hub and Gitpod related code and
> docs. I have already discussed this with Tania Allard, who did most of the
> heavy lifting on the initial creation of the Gitpod machinery (for SciPy,
> which was then synced to NumPy).
>
> Thoughts?
>
> Cheers,
> Ralf
>
>
That's fine with me. I did run it a couple of times to see what it did and
the setup time excruciating :) If removing it also reduces the maintenance
burden, so much the better.

Chuck
___
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: Github updated its RSA public key

[Charles R Harris]

Note that "actions/checkout" was updated today by dependabot, so we should
be good on that score.

Chuck
___
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] Github updated its RSA public key

[Charles R Harris]

Hi All,

Just a heads up, you may see this message:

@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host
isSHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Host key for github.com has changed and you have requested strict checking.
Host key verification failed.

You can fix it by following the instructions at
https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

Chuck
___
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.24.3 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.3. NumPy 1.24.3 is a maintenance release that fixes bugs and
regressions discovered after the 1.24.2 release.

The Python versions supported by this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

*Contributors*

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

   - Aleksei Nikiforov +
   - Alexander Heger
   - Bas van Beek
   - Bob Eldering
   - Brock Mendel
   - Charles Harris
   - Kyle Sunden
   - Peter Hawkins
   - Rohit Goswami
   - Sebastian Berg
   - Warren Weckesser
   - dependabot[bot]



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

   - #23206: BUG: fix for f2py string scalars (#23194)
   - #23207: BUG: datetime64/timedelta64 comparisons return NotImplemented
   - #23208: MAINT: Pin matplotlib to version 3.6.3 for refguide checks
   - #23221: DOC: Fix matplotlib error in documentation
   - #23226: CI: Ensure submodules are initialized in gitpod.
   - #23341: TYP: Replace duplicate reduce in ufunc type signature with
   reduceat.
   - #23342: TYP: Remove duplicate CLIP/WRAP/RAISE in ``__init__.pyi``.
   - #23343: TYP: Mark ``d`` argument to fftfreq and rfftfreq as optional...
   - #23344: TYP: Add type annotations for comparison operators to
   MaskedArray.
   - #23345: TYP: Remove some stray type-check-only imports of ``msort``
   - #23370: BUG: Ensure like is only stripped for ``like=`` dispatched
   functions
   - #23543: BUG: fix loading and storing big arrays on s390x
   - #23544: MAINT: Bump larsoner/circleci-artifacts-redirector-action
   - #23634: BUG: Ignore invalid and overflow warnings in masked setitem
   - #23635: BUG: Fix masked array raveling when ``order="A"`` or
   ``order="K"``
   - #23636: MAINT: Update conftest for newer hypothesis versions
   - #23637: BUG: Fix bug in parsing F77 style string arrays.


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

[Numpy-discussion] Re: Error from "import numpy": undefined symbol: _ZSt21__glibcxx_assert_failPKciS0_S0_

[Charles R Harris]

I can confirm. Please open a github issue for this.

Chuck

On Sat, Apr 15, 2023 at 5:29 PM Chiara Marmo  wrote:

> Dear list,
>
> I am compiling numpy from source (main 1.25.0.dev0+1173.g7f682bca5) on
> Fedora 37.
> - Python 3.11
> - GNU C Library (GNU libc) stable release version 2.36.
> - g++ (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2)
>
> I am compiling in a python venv, the C and C++ libraries are from the
> Fedora distribution.
> The compilation went well, but when importing:
>
> >>> import numpy
> gives
>
> Traceback (most recent call last):
>   File "/home/cmarmo/software/numpy/numpy/core/__init__.py", line 23, in
> 
> from . import multiarray
>   File "/home/cmarmo/software/numpy/numpy/core/multiarray.py", line 10, in
> 
> from . import overrides
>   File "/home/cmarmo/software/numpy/numpy/core/overrides.py", line 8, in
> 
> from numpy.core._multiarray_umath import (
> ImportError: /home/cmarmo/software/numpy/numpy/core/_
> multiarray_umath.cpython-311-x86_64-linux-gnu.so: undefined symbol:
> _ZSt21__glibcxx_assert_failPKciS0_S0_
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/home/cmarmo/software/numpy/numpy/__init__.py", line 139, in
> 
> from . import core
>   File "/home/cmarmo/software/numpy/numpy/core/__init__.py", line 49, in
> 
> raise ImportError(msg)
> ImportError:
>
> IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
>
> Importing the numpy C-extensions failed. This error can happen for
> many reasons, often due to issues with your setup or how NumPy was
> installed.
>
> We have compiled some common reasons and troubleshooting tips at:
>
> https://numpy.org/devdocs/user/troubleshooting-importerror.html
>
> Please note and check the following:
>
>   * The Python version is: Python3.11 from
> "/home/cmarmo/numpydevenv/bin/python"
>   * The NumPy version is: "1.25.0.dev0+1173.g7f682bca5"
>
> and make sure that they are the versions you expect.
> Please carefully study the documentation linked above for further help.
>
> Original error was: /home/cmarmo/software/numpy/numpy/core/_
> multiarray_umath.cpython-311-x86_64-linux-gnu.so: undefined symbol:
> _ZSt21__glibcxx_assert_failPKciS0_S0_
>
> I have upgraded and downgraded the libstdc++ as far as possible in
> fedora37, but the error is still there.
> I have compiled with meson too and the result is the same.
> I can provide both the buildlogs for setuptools and meson, they are
> vvverbose and big (17M), just let me know where I can upload them.
>
> I don't know if the issue is from numpy or the fedora packaging.
> I hope some fedora packagers related to python are also in the list,
> perhaps they may provide some hint?
>
> Thanks for your attention!
> Regards,
>
> Chiara
>
> --
> GPG Key ID: ed25519/7611FA19766900CD
> Fingerprint FD45 A232 211E DE9F 23E9  DDD5 7611 FA19 7669 00CD
> ___
> 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: charlesr.har...@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] NumPy 1.24. 2 Release

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.2. NumPy 1.24.2 is a maintenance release that fixes bugs and
regressions discovered after the 1.24.1 release.

The Python versions supported by this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - Bas van Beek
   - Charles Harris
   - Khem Raj +
   - Mark Harfouche
   - Matti Picus
   - Panagiotis Zestanakis +
   - Peter Hawkins
   - Pradipta Ghosh
   - Ross Barnowski
   - Sayed Adel
   - Sebastian Berg
   - Syam Gadde +
   - dmbelov +
   - pkubaj +



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

   - #22965: MAINT: Update python 3.11-dev to 3.11.
   - #22966: DOC: Remove dangling deprecation warning
   - #22967: ENH: Detect CPU features on FreeBSD/powerpc64*
   - #22968: BUG: np.loadtxt cannot load text file with quoted fields
   separated...
   - #22969: TST: Add fixture to avoid issue with randomizing test order.
   - #22970: BUG: Fix fill violating read-only flag. (#22959)
   - #22971: MAINT: Add additional information to missing scalar
   AttributeError
   - #22972: MAINT: Move export for scipy arm64 helper into main module
   - #22976: BUG, SIMD: Fix spurious invalid exception for sin/cos on
   arm64/clang
   - #22989: BUG: Ensure correct loop order in sin, cos, and arctan2
   - #23030: DOC: Add version added information for the strict parameter
   in...
   - #23031: BUG: use ``_Alignof`` rather than ``offsetof()`` on most
   compilers
   - #23147: BUG: Fix for npyv__trunc_s32_f32 (VXE)
   - #23148: BUG: Fix integer / float scalar promotion
   - #23149: BUG: Add missing  header.
   - #23150: TYP, MAINT: Add a missing explicit ``Any`` parameter to the
   ``npt.ArrayLike``...
   - #23161: BLD: remove redundant definition of npy_nextafter [wheel build]


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

[Numpy-discussion] NumPy 1.25.1 release

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.25.1. NumPy 1.25.1 is a maintenance release that fixes bugs discovered
after the 1.24.3 release and updates the build infrastructure to stay
current with upstream changes.

The Python versions supported by this release are 3.9-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - Andrew Nelson
   - Charles Harris
   - Developer-Ecosystem-Engineering
   - Hood Chatham
   - Nathan Goldbaum
   - Rohit Goswami
   - Sebastian Berg
   - Tim Paine +
   - dependabot[bot]
   - matoro +



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

   - #23968: MAINT: prepare 1.25.x for further development
   - #24036: BLD: Port long double identification to C for meson
   - #24037: BUG: Fix reduction `return NULL` to be `goto fail`
   - #24038: BUG: Avoid undefined behavior in array.astype()
   - #24039: BUG: Ensure `__array_ufunc__` works without any kwargs passed
   - #24117: MAINT: Pin urllib3 to avoid anaconda-client bug.
   - #24118: TST: Pin pydantic<2 in Pyodide workflow
   - #24119: MAINT: Bump pypa/cibuildwheel from 2.13.0 to 2.13.1
   - #24120: MAINT: Bump actions/checkout from 3.5.2 to 3.5.3
   - #24122: BUG: Multiply or Divides using SIMD without a full vector
   can\...
   - #24127: MAINT: testing for IS_MUSL closes #24074
   - #24128: BUG: Only replace dtype temporarily if dimensions changed
   - #24129: MAINT: Bump actions/setup-node from 3.6.0 to 3.7.0
   - #24134: BUG: Fix private procedures in f2py modules

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

[Numpy-discussion] Time to start NumPy 1.26 development?

[Charles R Harris]

Hi All,

We plan to release NumPy 1.26 soon after the release of the Python
3.12.0rc1 release, which is currently scheduled for July 31, just a bit
more than two weeks off. What I'd like to do is


   1. Tag the commit after v1.25.1 -- f9e85438782cc5 -- as 'v1.26.0.dev0',
   marking it as the start of 1.26 development.
   2. Backport the `meson.build` files from main. This is mostly automatic,
   but a few changes need to be made.
   3. Backport the files for spin builds.
   4. Begin  testing the Python 3.12 betas
   5. Update OpenBLAS when we are happy with it.
   6. Wait for SIMD support?

I'm wondering if we can split the builds, using distutils for Python
3.9-3.11 and meson only for 3.12, or if that is even worth the trouble.

Thoughts?

Chuck
___
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: Welcome Nathan Goldbaum as a Maintainer

[Charles R Harris]

On Mon, May 29, 2023 at 1:15 AM Sebastian Berg 
wrote:

> Hi all,
>
> On behalf of the steering council, I am very happy to announce that
> Nathan has joined us as a Maintainer!
>
> Nathan has been consistently contributing and reviewing NumPy PRs for a
> while and is for example actively working on a better string DType
> which often means diving into the NumPy core as needed.
>
> Looking forward to working more with you!
>
> Cheers,
>
> Sebastian
>
>
Welcome aboard Nathan.

Chuck
___
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.25.0rc1 released

[Charles R Harris]

Hi All,

The NumPy 1.25.0 release continues the ongoing work to improve the handling
and promotion of dtypes, increase the execution speed, and clarify the
documentation. There has also been work to prepare for the future NumPy
2.0.0
release, resulting in a large number of new and expired deprecation.
Highlights are:

   - Support for MUSL, there are now MUSL wheels.
   - Support the Fujitsu C/C++ compiler.
   - Object arrays are now supported in einsum
   - Support for inplace matrix multiplication (@=).

We will release NumPy 1.26 on top of the 1.25 code when Python 12 reaches
the rc stage. That is needed because distutils has been dropped by Python
12 and we will be switching to using meson for future builds. The next
mainline release will be NumPy 2.0.0. We plan that the 2.0 series will
still support downstream projects built against earlier
versions of NumPy.

The Python versions supported in this release are 3.9-3.11. Wheels can be
downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @partev +
   - @pierreloicq +
   - @pkubaj +
   - @pmvz +
   - @tajbinjohn +
   - A Chethan Reddy +
   - Aaron Meurer
   - Aleksei Nikiforov +
   - Alex Rogozhnikov
   - Alexander Heger
   - Alexander Neumann +
   - Andrew Nelson
   - Arun Kota +
   - Bas van Beek
   - Ben Greiner +
   - Berke Kocaoğlu +
   - Bob Eldering
   - Brian Soto
   - Brock Mendel
   - Charles Harris
   - Charles Young +
   - Chris Brown
   - Chris Sidebottom +
   - Christian Lorentzen +
   - Christian Veenhuis +
   - Christopher Sidebottom +
   - Chun-Wei Chen +
   - Clément Robert
   - Cédric Hannotier +
   - Daiki Shintani +
   - Daniel McCloy +
   - Derek Homeier
   - Developer-Ecosystem-Engineering
   - DhavalParmar61 +
   - Dimitri Papadopoulos Orfanos
   - Dmitry Belov +
   - Dominic Davis-Foster +
   - Eddie Darling +
   - Edward E +
   - Eero Vaher
   - Eric Wieser
   - Eugene Kim +
   - Evgeni Burovski
   - Facundo Batista +
   - Francesc Elies +
   - Ganesh Kathiresan
   - Hongyang Peng +
   - Hood Chatham
   - Ikko Ashimine
   - Ikko Eltociear Ashimine +
   - Inessa Pawson
   - Irit Katriel
   - Ivan Gonzalez
   - JP Ungaretti +
   - Jarrod Millman
   - Jean-François B +
   - Johana De La Rosa +
   - Johnson Sun +
   - Jonathan Kohler +
   - Jory Klaverstijn +
   - Joyce Brum +
   - Jules Kouatchou +
   - Kentaro Kawakami +
   - Khem Raj +
   - Kyle Sunden
   - Larry Bradley
   - Lars Grüter
   - Laurenz Kremeyer +
   - Lee Johnston +
   - Lefteris Loukas +
   - Leona Taric
   - Lillian Zha
   - Lu Yun Chi +
   - Malte Londschien +
   - Manuchehr Aminian +
   - Mariusz Felisiak
   - Mark Harfouche
   - Mark J. Olson +
   - Marko Pacak +
   - Marten van Kerkwijk
   - Matteo Raso
   - Matthew Muresan +
   - Matti Picus
   - Meekail Zain
   - Melissa Weber Mendonça
   - Michael Kiffer +
   - Michael Lamparski
   - Michael Siebert
   - Michail Gaganis +
   - Mike Toews
   - Mike-gag +
   - Miki Watanabe
   - Miki Watanabe (渡邉 美希)
   - Miles Cranmer
   - Muhammad Ishaque Nizamani +
   - Mukulika Pahari
   - Nathan Goldbaum
   - Nico Schlömer
   - Norwid Behrnd +
   - Noé Rubinstein +
   - Oleksandr Pavlyk
   - Oscar Gustafsson
   - Pamphile Roy
   - Panagiotis Zestanakis +
   - Paul Romano +
   - Paulo Almeida +
   - Pedro Lameiras +
   - Peter Hawkins
   - Peyton Murray +
   - Philip Holzmann +
   - Pierre Blanchard +
   - Pieter Eendebak
   - Pradipta Ghosh
   - Pratyay Banerjee +
   - Prithvi Singh +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Richie Cotton +
   - Robert Kern
   - Rohit Goswami
   - Ross Barnowski
   - Roy Smart +
   - Rustam Uzdenov +
   - Sadi Gulcelik +
   - Sarah Kaiser +
   - Sayed Adel
   - Sebastian Berg
   - Simon Altrogge +
   - Somasree Majumder
   - Stefan Behnel
   - Stefan van der Walt
   - Stefanie Molin
   - StepSecurity Bot +
   - Syam Gadde +
   - Sylvain Ferriol +
   - Talha Mohsin +
   - Taras Tsugrii +
   - Thomas A Caswell
   - Tyler Reddy
   - Warren Weckesser
   - Will Tirone +
   - Yamada Fuyuka +
   - Younes Sandi +
   - Yuki K +

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

[Numpy-discussion] Re: Precision changes to sin/cos in the next release?

[Charles R Harris]

On Wed, May 31, 2023 at 8:05 AM Robert Kern  wrote:

> I would much, much rather have the special functions in the `np.*`
> namespace be more accurate than fast on all platforms. These would not
> have been on my list for general purpose speed optimization. How much time
> is actually spent inside sin/cos even in a trig-heavy numpy program? And
> most numpy programs aren't trig-heavy, but the precision cost would be paid
> and noticeable even for those programs. I would want fast-and-inaccurate
> functions to be strictly opt-in for those times that they really paid off.
> Probably by providing them in their own module or package rather than a
> runtime switch, because it's probably only a *part* of my program that
> needs that kind of speed and can afford that precision loss while there
> will be other parts that need the precision.
>
>
I think that would be a good policy going forward.



Chuck
___
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: Precision changes to sin/cos in the next release?

[Charles R Harris]

On Wed, May 31, 2023 at 9:12 AM Robert Kern  wrote:

> On Wed, May 31, 2023 at 10:40 AM Ralf Gommers 
> wrote:
>
>>
>>
>> On Wed, May 31, 2023 at 4:19 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, May 31, 2023 at 8:05 AM Robert Kern 
>>> wrote:
>>>
>>>> I would much, much rather have the special functions in the `np.*`
>>>> namespace be more accurate than fast on all platforms. These would not
>>>> have been on my list for general purpose speed optimization. How much time
>>>> is actually spent inside sin/cos even in a trig-heavy numpy program? And
>>>> most numpy programs aren't trig-heavy, but the precision cost would be paid
>>>> and noticeable even for those programs. I would want fast-and-inaccurate
>>>> functions to be strictly opt-in for those times that they really paid off.
>>>> Probably by providing them in their own module or package rather than a
>>>> runtime switch, because it's probably only a *part* of my program that
>>>> needs that kind of speed and can afford that precision loss while there
>>>> will be other parts that need the precision.
>>>>
>>>>
>>> I think that would be a good policy going forward.
>>>
>>
>> There's a little more to it than "precise and slow good", "fast == less
>> accurate == bad". We've touched on this when SVML got merged (e.g., [1])
>> and with other SIMD code, e.g. in the "Floating point precision
>> expectations in NumPy" thread [2]. Even libm doesn't guarantee the best
>> possible result of <0.5 ULP max error, and there are also considerations
>> like whether any numerical errors are normally distributed around the exact
>> mathematical answer or not (see, e.g., [3]).
>>
>
> If we had a portable, low-maintenance, high-accuracy library that we could
> vendorize (and its performance cost wasn't *horrid*), I might even
> advocate that we do that. Reliance on platform libms is mostly about our
> maintenance burden than a principled accuracy/performance tradeoff. My
> preference *is* definitely firmly on the "precise and slow good" for
> these ufuncs because of the role these ufuncs play in real numpy programs;
> performance has a limited, situational effect while accuracy can have
> substantial ones across the board.
>
> It seems fairly clear that with this recent change, the feeling is that
>> the tradeoff is bad and that too much accuracy was lost, for not enough
>> real-world gain. However, we now had several years worth of performance
>> work with few complaints about accuracy issues.
>>
>
> Except that we get a flurry of complaints now that they actually affect
> popular platforms. I'm not sure I'd read much into a lack of complaints
> before that.
>
>
>> So I wouldn't throw out the baby with the bath water now and say that we
>> always want the best accuracy only. It seems to me like we need a better
>> methodology for evaluating changes. Contributors have been pretty careful,
>> but looking back at SIMD PRs, there were usually detailed benchmarks but
>> not always detailed accuracy impact evaluations.
>>
>
> I've only seen micro-benchmarks testing the runtime of individual
> functions, but maybe I haven't paid close enough attention. Have there been
> any benchmarks on real(ish) *programs* that demonstrate what utility
> these provide in even optimistic scenarios? I care precisely <1ULP about
> the absolute performance of `np.sin()` on its own. There are definitely
> programs that would care about that; I'm not sure any of them are (or
> should be) written in Python, though.
>
>
One of my takeaways is that there are special values where more care should
be taken. Given the inherent inaccuracy of floating point computation, it
can be argued that there should be no such expectation, but here we are.
Some inaccuracies are more visible than others.

I think it is less intrusive to have the option to lessen precision when
more speed is needed than the other way around. Our experience is that most
users are unsophisticated when it comes to floating point, we should
minimise the consequences for those users.

Chuck
___
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.25.2 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.25.2. NumPy 1.25.2 is a maintenance release that fixes bugs and
regressions discovered after the 1.25.1 release. This is the last planned
release in the 1.25.x series, the next final release will be 1.26.0, which
will use the meson build system and support Python 3.12.

The Python versions supported by this release are 3.9-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - Aaron Meurer
   - Andrew Nelson
   - Charles Harris
   - Kevin Sheppard
   - Matti Picus
   - Nathan Goldbaum
   - Peter Hawkins
   - Ralf Gommers
   - Randy Eckenrode +
   - Sam James +
   - Sebastian Berg
   - Tyler Reddy
   - dependabot[bot]



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

   - #24148: MAINT: prepare 1.25.x for further development
   - #24174: ENH: Improve clang-cl compliance
   - #24179: MAINT: Upgrade various build dependencies.
   - #24182: BLD: use ``-ftrapping-math`` with Clang on macOS
   - #24183: BUG: properly handle negative indexes in ufunc_at fast path
   - #24184: BUG: PyObject_IsTrue and PyObject_Not error handling in
   setflags
   - #24185: BUG: histogram small range robust
   - #24186: MAINT: Update meson.build files from main branch
   - #24234: MAINT: exclude min, max and round from ``np.__all__``
   - #24241: MAINT: Dependabot updates
   - #24242: BUG: Fix the signature for np.array_api.take
   - #24243: BLD: update OpenBLAS to an intermediate commit
   - #24244: BUG: Fix reference count leak in str(scalar).
   - #24245: BUG: fix invalid function pointer conversion error
   - #24255: BUG: Factor out slow ``getenv`` call used for memory policy
   warning
   - #24292: CI: correct URL in cirrus.star [skip cirrus]
   - #24293: BUG: Fix C types in scalartypes
   - #24294: BUG: do not modify the input to ufunc_at
   - #24295: BUG: Further fixes to indexing loop and added tests


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

[Numpy-discussion] The 1.26.x maintenance branch has been created.

[Charles R Harris]

Hi All,

The 1.26.x maintenance branch has been created. The 1.26.x branch is a
continuation of the 1.25.x branch and serves to mark the change from our
distutils based builds to the meson builds needed to support the upcoming
Python 3.12 release.

Chuck
___
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: The 1.26.x maintenance branch has been created.

[Charles R Harris]

On Mon, Jul 31, 2023 at 1:08 PM Charles R Harris 
wrote:

>
>
> On Mon, Jul 31, 2023 at 12:16 PM Ralf Gommers 
> wrote:
>
>>
>>
>> On Mon, Jul 31, 2023 at 6:53 PM Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> The 1.26.x maintenance branch has been created. The 1.26.x branch is a
>>> continuation of the 1.25.x branch and serves to mark the change from our
>>> distutils based builds to the meson builds needed to support the upcoming
>>> Python 3.12 release.
>>>
>>
>> Awesome, thanks Chuck! Just checking: are you preparing one or a couple
>> of backport PRs for the merged PRs with the Backport-Candidate label? If
>> you want me to do the build system related ones, please let me know.
>>
>> We're pretty close to the finish line - most of the TODO items at
>> https://github.com/numpy/numpy/issues/23981 were done. The main one left
>> is SIMD support, and Sayed got quite far already in making that work - I'm
>> prioritizing reviewing it now. We should be able to do a beta release
>> without it though, as soon as Python 3.12.0rc1 shows up (possibly it will
>> appear later today).
>>
>>
> Hi Ralf,
>
> There are a bunch of backport candidates with a 1.26.0 milestone, so I'll
> put those in first, then we can get started on the CI updates and the meson
> builds. I'd appreciate any help you can offer with those. I'll try to get
> started with the backports tonight, but there will likely be some problems
> along the way.
>
> Chuck
>


 *as soon as Python 3.12.0rc1 shows up*

It will be a few days before cibuildwheel catches up with the rc1 release,
I expect we can get a beta (or rc1) out in a week or two, but not much
sooner.

Chuck
___
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: The 1.26.x maintenance branch has been created.

[Charles R Harris]

On Mon, Jul 31, 2023 at 12:16 PM Ralf Gommers 
wrote:

>
>
> On Mon, Jul 31, 2023 at 6:53 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> The 1.26.x maintenance branch has been created. The 1.26.x branch is a
>> continuation of the 1.25.x branch and serves to mark the change from our
>> distutils based builds to the meson builds needed to support the upcoming
>> Python 3.12 release.
>>
>
> Awesome, thanks Chuck! Just checking: are you preparing one or a couple of
> backport PRs for the merged PRs with the Backport-Candidate label? If you
> want me to do the build system related ones, please let me know.
>
> We're pretty close to the finish line - most of the TODO items at
> https://github.com/numpy/numpy/issues/23981 were done. The main one left
> is SIMD support, and Sayed got quite far already in making that work - I'm
> prioritizing reviewing it now. We should be able to do a beta release
> without it though, as soon as Python 3.12.0rc1 shows up (possibly it will
> appear later today).
>
>
Hi Ralf,

There are a bunch of backport candidates with a 1.26.0 milestone, so I'll
put those in first, then we can get started on the CI updates and the meson
builds. I'd appreciate any help you can offer with those. I'll try to get
started with the backports tonight, but there will likely be some problems
along the way.

Chuck

> Cheers,
> Ralf
> ___
> 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: charlesr.har...@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: The 1.26.x maintenance branch has been created.

[Charles R Harris]

On Mon, Jul 31, 2023 at 1:13 PM Charles R Harris 
wrote:

>
>
> On Mon, Jul 31, 2023 at 1:08 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 31, 2023 at 12:16 PM Ralf Gommers 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 31, 2023 at 6:53 PM Charles R Harris <
>>> charlesr.har...@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> The 1.26.x maintenance branch has been created. The 1.26.x branch is a
>>>> continuation of the 1.25.x branch and serves to mark the change from our
>>>> distutils based builds to the meson builds needed to support the upcoming
>>>> Python 3.12 release.
>>>>
>>>
>>> Awesome, thanks Chuck! Just checking: are you preparing one or a couple
>>> of backport PRs for the merged PRs with the Backport-Candidate label? If
>>> you want me to do the build system related ones, please let me know.
>>>
>>> We're pretty close to the finish line - most of the TODO items at
>>> https://github.com/numpy/numpy/issues/23981 were done. The main one
>>> left is SIMD support, and Sayed got quite far already in making that work -
>>> I'm prioritizing reviewing it now. We should be able to do a beta release
>>> without it though, as soon as Python 3.12.0rc1 shows up (possibly it will
>>> appear later today).
>>>
>>>
>> Hi Ralf,
>>
>> There are a bunch of backport candidates with a 1.26.0 milestone, so I'll
>> put those in first, then we can get started on the CI updates and the meson
>> builds. I'd appreciate any help you can offer with those. I'll try to get
>> started with the backports tonight, but there will likely be some problems
>> along the way.
>>
>> Chuck
>>
>
>
>  *as soon as Python 3.12.0rc1 shows up*
>
> It will be a few days before cibuildwheel catches up with the rc1 release,
> I expect we can get a beta (or rc1) out in a week or two, but not much
> sooner.
>
>
See https://github.com/numpy/numpy/pull/24308.

Chuck
___
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: numpy.org is now available in Japanese and Portuguese

[Charles R Harris]

On Wed, Aug 2, 2023 at 9:51 PM Inessa Pawson  wrote:

> We are excited to announce that numpy.org is now available in 2
> additional languages: Japanese and Portuguese.
> This wouldn’t be possible without our dedicated volunteers:
>
> Portuguese:
> Melissa Weber Mendonça (melissawm)
> Ricardo Prins (ricardoprins)
> Getúlio Silva (getuliosilva)
> Julio Batista Silva (jbsilva)
> Alexandre de Siqueira (alexdesiqueira)
> Alexandre B A Villares (villares)
> Vini Salazar (vinisalazar)
>
> Japanese:
> Atsushi Sakai (AtsushiSakai)
> KKunai
> Tom Kelly (TomKellyGenetics)
> Yuji Kanagawa (kngwyu)
>
> Looking ahead, we’d love to translate the website into more languages. If
> you’d like to help, please connect with the NumPy translations team on
> Slack:
> https://join.slack.com/t/numpy-team/shared_invite/zt-1gokbq56s-bvEpo10Ef7aHbVtVFeZv2w.
> (Look for the #translations channel.)
>
> We are also building a translations team who will be working on localizing
> documentation and educational content across the Scientific Python
> ecosystem. If this piqued your interest, join us on the Scientific Python
> Discord: https://discord.gg/khWtqY6RKr. (Look for the #translation
> channel.)
>
> The work on the translation infrastructure is supported, in part, with
> funding from the Chan Zuckerberg Initiative.
>
>
Nice. Thanks all.

Chuck
___
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] Interesting article

[Charles R Harris]

Hi All,

Just thought I'd pass along a link to an article I found interesting, IBM,
Red Hat and Free Software: An old maddog’s view

.

Chuck
___
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: Python 3.12.0rc1 released

[Charles R Harris]

On Tue, Aug 8, 2023 at 8:25 AM Charles R Harris 
wrote:

> Hi All,
>
> Just a note that Python 3.12.0rc1 was released Aug 6. It looks like
> manylinux2014 is already updated.
>
>
But cibuildwheel is still at 3.12.0b4.

Chuck
___
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] Python 3.12.0rc1 released

[Charles R Harris]

Hi All,

Just a note that Python 3.12.0rc1 was released Aug 6. It looks like
manylinux2014 is already updated.

Chuck
___
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.25.0 released

[Charles R Harris]

Hi All,

The NumPy 1.25.0 release continues the ongoing work to improve the handling
and promotion of dtypes, increase execution speed, and clarify the
documentation. There has also been work to prepare for the future NumPy
2.0.0
release, resulting in a large number of new and expired deprecation.
Highlights are:

   - Support for MUSL, there are now MUSL wheels.
   - Support the Fujitsu C/C++ compiler.
   - Object arrays are now supported in einsum
   - Support for inplace matrix multiplication (@=).

We will release NumPy 1.26 on top of the 1.25 code when Python 12 reaches
the rc stage. That is needed because distutils has been dropped by Python
12 and we will be switching to using meson for future builds. The next
mainline release will be NumPy 2.0.0. We plan that the 2.0 series will
still support downstream projects built against earlier
versions of NumPy.

The Python versions supported in this release are 3.9-3.11. Wheels can be
downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
.

*Contributors*

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

   - @DWesl
   - @partev +
   - @pierreloicq +
   - @pkubaj +
   - @pmvz +
   - @pratiklp00 +
   - @tajbinjohn +
   - A Chethan Reddy +
   - Aaron Meurer
   - Aleksei Nikiforov +
   - Alex Rogozhnikov
   - Alexander Heger
   - Alexander Neumann +
   - Andrew Nelson
   - Arun Kota +
   - Bas van Beek
   - Ben Greiner +
   - Berke Kocaoğlu +
   - Bob Eldering
   - Brian Soto
   - Brian Walshe +
   - Brock Mendel
   - Charles Harris
   - Charles Young +
   - Chris Brown
   - Chris Sidebottom +
   - Christian Lorentzen +
   - Christian Veenhuis +
   - Christopher Sidebottom +
   - Chun-Wei Chen +
   - Clément Robert
   - Cédric Hannotier +
   - Daiki Shintani +
   - Daniel McCloy +
   - Derek Homeier
   - Developer-Ecosystem-Engineering
   - DhavalParmar61 +
   - Dimitri Papadopoulos Orfanos
   - Dmitry Belov +
   - Dominic Davis-Foster +
   - Eddie Darling +
   - Edward E +
   - Eero Vaher
   - Eric Wieser
   - Eugene Kim +
   - Evgeni Burovski
   - Facundo Batista +
   - Francesc Elies +
   - Ganesh Kathiresan
   - Hongyang Peng +
   - Hood Chatham
   - Ikko Ashimine
   - Ikko Eltociear Ashimine +
   - Inessa Pawson
   - Irit Katriel
   - Ivan Gonzalez
   - JP Ungaretti +
   - Jarrod Millman
   - Jean-François B +
   - Johana De La Rosa +
   - Johnson Sun +
   - Jonathan Kohler +
   - Jory Klaverstijn +
   - Joyce Brum +
   - Jules Kouatchou +
   - Kentaro Kawakami +
   - Khem Raj +
   - Kyle Sunden
   - Larry Bradley
   - Lars Grüter
   - Laurenz Kremeyer +
   - Lee Johnston +
   - Lefteris Loukas +
   - Leona Taric
   - Lillian Zha
   - Lu Yun Chi +
   - Malte Londschien +
   - Manuchehr Aminian +
   - Mariusz Felisiak
   - Mark Harfouche
   - Mark J. Olson +
   - Marko Pacak +
   - Marten van Kerkwijk
   - Matteo Raso
   - Matthew Muresan +
   - Matti Picus
   - Meekail Zain
   - Melissa Weber Mendonça
   - Michael Kiffer +
   - Michael Lamparski
   - Michael Siebert
   - Michail Gaganis +
   - Mike Toews
   - Mike-gag +
   - Miki Watanabe
   - Miki Watanabe (渡邉 美希)
   - Miles Cranmer
   - Muhammad Ishaque Nizamani +
   - Mukulika Pahari
   - Nathan Goldbaum
   - Nico Schlömer
   - Norwid Behrnd +
   - Noé Rubinstein +
   - Oleksandr Pavlyk
   - Oscar Gustafsson
   - Pamphile Roy
   - Panagiotis Zestanakis +
   - Paul Romano +
   - Paulo Almeida +
   - Pedro Lameiras +
   - Peter Hawkins
   - Pey Lian Lim
   - Peyton Murray +
   - Philip Holzmann +
   - Pierre Blanchard +
   - Pieter Eendebak
   - Pradipta Ghosh
   - Pratyay Banerjee +
   - Prithvi Singh +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Richie Cotton +
   - Robert Kern
   - Rohit Goswami
   - Ross Barnowski
   - Roy Smart +
   - Rustam Uzdenov +
   - Sadi Gulcelik +
   - Sarah Kaiser +
   - Sayed Adel
   - Sebastian Berg
   - Simon Altrogge +
   - Somasree Majumder
   - Stefan Behnel
   - Stefan van der Walt
   - Stefanie Molin
   - StepSecurity Bot +
   - Syam Gadde +
   - Sylvain Ferriol +
   - Talha Mohsin +
   - Taras Tsugrii +
   - Thomas A Caswell
   - Tyler Reddy
   - Warren Weckesser
   - Will Tirone +
   - Yamada Fuyuka +
   - Younes Sandi +
   - Yuki K +

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

[Numpy-discussion] Release of NumPy 1.24. 4

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.24.4. NumPy 1.24.4 is a maintenance release that fixes a few bugs
discovered after the 1.24.3 release.

The Python versions supported by this release are 3.8-3.11 Note that 32 bit
wheels are only provided for Windows, all other wheels are 64 bits on
account of Ubuntu, Fedora, and other Linux distributions dropping 32 bit
support. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - Bas van Beek
   - Charles Harris
   - Sebastian Berg
   - Hongyang Peng +



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

   - #23720: MAINT, BLD: Pin rtools to version 4.0 for Windows builds.
   - #23739: BUG: fix the method for checking local files for 1.24.x
   - #23760: MAINT: Copy rtools installation from install-rtools.
   - #23761: BUG: Fix masked array ravel order for A (and somewhat K)
   - #23890: TYP,DOC: Annotate and document the ``metadata`` parameter of...
   - #23994: MAINT: Update rtools installation


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

[Numpy-discussion] Re: Proposal to accept NEP 55: Add a UTF-8 variable-width string DType to NumPy

[Charles R Harris]

On Mon, Jan 22, 2024 at 5:14 PM Nathan  wrote:

> Hi all,
>
> I propose we accept NEP 55 and merge PR #25347 implementing the NEP in
> time for the NumPy 2.0 RC:
>
> https://numpy.org/neps/nep-0055-string_dtype.html
> https://github.com/numpy/numpy/pull/25347
>
> The most controversial aspect of the NEP was support for missing strings
> via a user-supplied sentinel object. In the previous discussion on the
> mailing list, Warren Weckesser argued for shipping a missing data sentinel
> with NumPy for use with the DType, while in code review and the PR for the
> NEP, Sebestian expressed concern about the additional complexity of
> including missing data support at all.
>
> I found that supporting missing data is key to efficiently supporting the
> new DType in Pandas. I think that argues that we need some level of missing
> data support to fully replace object string arrays. I believe the
> compromise proposal in the NEP is sufficient for downstream libraries while
> limiting additional complexity elsewhere in NumPy.
>
> Concerns raised in previous discussions about concretely specifying the C
> API to be made public, preventing use-after-free errors in a multithreaded
> context, and uncertainty around the arena allocator implementation have
> been resolved in the latest version of the NEP and the open PR.
> Additionally, due to some excellent and timely work by Lysandros Nikolaou,
> we now have a number of string ufuncs in NumPy and a straightforward plan
> to add more. Loops have been implemented for all the ufuncs added in the
> NumPy 2.0 dev cycle so far.
>
> I would like to see us ship the DType in NumPy 2.0. This will allow us to
> advertise a major new feature, will spur efforts to support new DTypes in
> downstream libraries, and will allow us to get feedback from the community
> that would be difficult to obtain without releasing the code into the wild.
> Additionally, I am funded via a NASA ROSES grant for work related to this
> effort until the end of 2024, so including the DType in NumPy 2.0 will more
> efficiently use my funded time to fix issues.
>
> If there are no substantive objections to this email, then the NEP will be
> considered accepted; see NEP 0 for more details:
> https://numpy.org/neps/nep-.html
>

Don't worry too much about the timing, we aren't going to branch without
the new strings unless the cat gets into them, which is unlikely.

Chuck
___
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: Enhancement: Chebyshev power using DCT

[Charles R Harris]

On Wed, Jan 24, 2024 at 6:29 AM Fabio Matti 
wrote:

> Hi,
>
> In the `numpy.polynomial.chebyshev` module, the function for raising a
> Chebyshev polynomial to a power, `chebpow` [1], is essentially implemented
> in the following way:
>
> {{{#!highlight python
> def chebpow(c, pow):
> """Raise a Chebyshev series to a power."""
> zs = _cseries_to_zseries(c)
> prd = zs
> for i in range(2, pow + 1):
> prd = np.convolve(prd, zs)
> return _zseries_to_cseries(prd)
> }}}
>
> For large coefficient arrays `c` and big exponents `pow`, this procedure
> is not efficient. In fact, the complexity of this function is
> `O(pow*len(c)^2)`, since the numpy convolution does not make use of a Fast
> Fourier Transform (FFT).
>
> It is known that Chebyshev polynomials can be multiplied with Discrete
> Cosine Transforms (DCT) [2]. What results is the following
> algorithm`O(pow*len(c)*log(pow*len(c)))` algorithm for raising a Chebyshev
> polynomial with coefficients `c` to an integer power:
>
> {{{#!highlight python
> def chebpow_dct(c, pow):
> """Raise a Chebyshev series to a power."""
> pad_length = (pow - 1) * (len(c) - 1)
> c = np.pad(c, (0, pad_length))
> c[1:-1] /= 2
> c_pow = idct(dct(c) ** pow)
> c_pow[1:-1] *= 2
> return c_pow
> }}}
>
> The only issue I am having is that as far as I know, `numpy` (unlike
> `scipy`) does not have a specialized implementation for the DCT. So the
> only way of getting the code to work is "emulating" a DCT with two calls to
> `numpy.fft.rfft`, which is slightly slower than  using the `scipy.fft.dct`.
>
> I have created a Google colab notebook which compares the error and
> runtime of the different implementations (current implementation,
> implementation using `scipy.fft.dct`, and pure numpy implementation) [3].
> Especially for larger degree polynomials and higher powers this enhancement
> would make a huge difference in terms of runtime.
>
> Similarly, `chebmul` and `chebinterpolate` can also be implemented more
> efficiently by using a DCT.
>
> Do you think this enhancement is worth pursuing, and should I create a
> pull-request for it?
>
> Best,
>
> Fabio
>
> [1]
> https://github.com/numpy/numpy/blob/main/numpy/polynomial/chebyshev.py#L817
> [2] https://www.sciencedirect.com/science/article/pii/0024379595006966
> [3]
> https://colab.research.google.com/drive/1JtDDeWC1CEQHDidZ9f5_Ma_ifoBv4Tuz?usp=sharing


This is a tricky sort of decision. The various polynomial functions were
designed so that they could be used with different types, Fractions, for
instance, and for degrees less than about 50 max. They are sort of a cross
between teaching tools and quick prototyping. I agree that for fast
production code and big degrees, DCT is the way to go for Chebyshev. There
are even some packages out there designed on that basis. I wouldn't
complain if someone produced a package with restricted types that was more
efficient than what NumPy has, indeed, types are already restricted for
curve fitting. NumPy is trending towards specialization these days, I
suspect a separate polynomial package would be a better place for such
improvements.

Chuck
___
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.26.3 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.3. NumPy 1.26.3 is a maintenance release that fixes bugs and
regressions discovered after the 1.26.2 release. The most notable fixes are
the f2py bug fixes. The Python versions supported by this release are
3.9-3.12. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

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

   - @DWesl
   - @Illviljan
   - Alexander Grund
   - Andrea Bianchi +
   - Charles Harris
   - Daniel Vanzo
   - Johann Rohwer +
   - Matti Picus
   - Nathan Goldbaum
   - Peter Hawkins
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Rohit Goswami
   - Sayed Adel
   - Sebastian Berg
   - Stefano Rivera +
   - Thomas A Caswell
   - matoro



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

   - #25130: MAINT: prepare 1.26.x for further development
   - #25188: TYP: add None to ``__getitem__`` in ``numpy.array_api``
   - #25189: BLD,BUG: quadmath required where available [f2py]
   - #25190: BUG: alpha doesn't use REAL(10)
   - #25191: BUG: Fix FP overflow error in division when the divisor is
   scalar
   - #25192: MAINT: Pin scipy-openblas version.
   - #25201: BUG: Fix f2py to enable use of string optional inout argument
   - #25202: BUG: Fix -fsanitize=alignment issue in
   numpy/_core/src/multiarray/arraytypes.c.src
   - #25203: TST: Explicitly pass NumPy path to cython during tests (also...
   - #25204: BUG: fix issues with ``newaxis`` and ``linalg.solve`` in
   ``numpy.array_api``
   - #25205: BUG: Disallow shadowed modulenames
   - #25217: BUG: Handle common blocks with kind specifications from modules
   - #25218: BUG: Fix moving compiled executable to root with f2py -c on
   Windows
   - #25219: BUG: Fix single to half-precision conversion on PPC64/VSX3
   - #25227: TST: f2py: fix issue in test skip condition
   - #25240: Revert "MAINT: Pin scipy-openblas version."
   - #25249: MAINT: do not use ``long`` type
   - #25377: TST: PyPy needs another gc.collect on latest versions
   - #25378: CI: Install Lapack runtime on Cygwin.
   - #25379: MAINT: Bump conda-incubator/setup-miniconda from 2.2.0 to 3.0.1
   - #25380: BLD: update vendored Meson for AIX shared library fix
   - #25419: MAINT: Init ``base`` in cpu_avx512_kn
   - #25420: BUG: Fix failing test_features on SapphireRapids
   - #25422: BUG: Fix non-contiguous memory load when ARM/Neon is enabled
   - #25428: MAINT,BUG: Never import distutils above 3.12 [f2py]
   - #25452: MAINT: make the import-time check for old Accelerate more
   specific
   - #25458: BUG: fix macOS version checks for Accelerate support
   - #25465: MAINT: Bump actions/setup-node and
   larsoner/circleci-artifacts-redirector-action
   - #25466: BUG: avoid seg fault from OOB access in RandomState.set_state()
   - #25467: BUG: Fix two errors related to not checking for failed
   allocations
   - #25468: BUG: Fix regression with ``f2py`` wrappers when modules and
   subroutines...
   - #25475: BUG: Fix build issues on SPR
   - #25478: BLD: fix uninitialized variable warnings from
   simd/neon/memory.h
   - #25480: BUG: Handle ``iso_c_type`` mappings more consistently
   - #25481: BUG: Fix module name bug in signature files [urgent] [f2py]
   - #25482: BUG: Handle .pyf.src and fix SciPy [urgent]
   - #25483: DOC: ``f2py`` rewrite with ``meson`` details
   - #25485: BUG: Add external library handling for meson [f2py]
   - #25486: MAINT: Run f2py's meson backend with the same python that
   ran...
   - #25489: MAINT: Update ``numpy/f2py/_backends`` from main.
   - #25490: MAINT: Easy updates of ``f2py/*.py`` from main.
   - #25491: MAINT: Update crackfortran.py and f2py2e.py from main


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

[Numpy-discussion] Re: welcome Raghuveer, Chris, Mateusz and Matt to the NumPy maintainers team

[Charles R Harris]

On Fri, Jan 26, 2024 at 1:08 PM Ralf Gommers  wrote:

> Hi all,
>
> We've got four new NumPy maintainers! Welcome to the team, and
> congratulations to:
>
> - Raghuveer Devulapalli (https://github.com/r-devulap)
> - Chris Sidebottom (https://github.com/mousius)
> - Mateusz Sokół (https://github.com/mtsokol/)
> - Matt Haberland (https://github.com/mdhaber)
>
> Raghuveer and Chris have been contribution to the effort on SIMD and
> performance optimizations for quite a while now. Mateusz has done a lot of
> the heavy lifting on the Python API improvements for NumPy 2.0 And Matt has
> been contributing to the test infrastructure and docs.
>
> Thanks to all four of you for the great work to date!
>
>
Welcome to all four.

Chuck
___
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: New matvec and vecmat functions

[Charles R Harris]

On Tue, Jan 23, 2024 at 3:18 PM Marten van Kerkwijk 
wrote:

> Hi All,
>
> I have a PR [1] that adds `np.matvec` and `np.vecmat` gufuncs for
> matrix-vector and vector-matrix calculations, to add to plain
> matrix-matrix multiplication with `np.matmul` and the inner vector
> product with `np.vecdot`.  They call BLAS where possible for speed.
> I'd like to hear whether these are good additions.
>
> I also note that for complex numbers, `vecmat` is defined as `x†A`,
> i.e., the complex conjugate of the vector is taken. This seems to be the
> standard and is what we used for `vecdot` too (`x†x`). However, it is
> *not* what `matmul` does for vector-matrix or indeed vector-vector
> products (remember that those are possible only if the vector is
> one-dimensional, i.e., not with a stack of vectors). I think this is a
> bug in matmul, which I'm happy to fix. But I'm posting here in part to
> get feedback on that.
>
> Thanks!
>
> Marten
>

I tend to agree with not using the complex conjugate for vecmat, but would
prefer having separate functions for that that make it explicit in the
name. I also note that mathematicians use sesquilinear forms, which have
the vector conjugate on the other side, so there are different conventions.
I prefer the Dirac convention myself, but many mathematical methods texts
use the opposite. It is tricky for the teacher in introductory courses,
right up there with vectors being called contravariant when they are
actually covariant (the coefficients are contravariant). Anyway, I think
having the convention explicit in the name will avoid confusion.

Chuck
___
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: API: make numpy.lib._arraysetops.intersect1d work on multiple arrays #25688

[Charles R Harris]

On Fri, Feb 2, 2024 at 6:34 AM Stephan Kuschel via NumPy-Discussion <
numpy-discussion@python.org> wrote:

> All the Best
>
Stephan
> ___
> NumPy-Discussion mailing li

Dear Community,
>
> For my own work, I required the intersect1d function to work on multiple
> arrays while returning the indices (using `return_indizes=True`).
> Consequently I changed the function in numpy and now I am seeking
> feedback from the community.
>
> This is the corresponding PR: https://github.com/numpy/numpy/pull/25688
>
> My motivation for the change may also apply to a larger group of people
> as it is important for lots of simulation data analysis:
>
> In various simulations there is often the case that many entities
> (particles, cells, vehicles, whatever the simulation consists of) are
> being tracked throughout the simulation. A typical approach is to assign
> a unique ID to every entity which stays constant and unique throughout
> the simulation and is written together with other properties of the
> entities on every simulation snapshot in time. Note, that during the
> simulation new entities may enter or leave the simulation and due to
> parallelization the order of those entities is not conserved.
> Tracking the position of entities over, lets say, 100 snapshots requires
> the intersection of 100 id lists instead of only two.
>
> Consequently I changed the intersect1d function from
> `intersect1d(ar1, ar2, assume_unique=False, return_indices=False)` to
> `intersect1d(*ars, assume_unique=False, return_indices=False)`.
>
> Please let me know if there is any interest in those changes -- be it in
> this form or another.
>
>
Seems reasonable. I don't know if it is faster, but NumPy is all about
vectorization.

Chuck
___
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.26.4 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.4. NumPy 1.26.4 is a maintenance release that fixes bugs and
regressions discovered after the 1.26.3 release. This is the last planned
release in the 1.26.x series. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github


*Contributors*

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

   - Charles Harris
   - Elliott Sales de Andrade
   - Lucas Colley +
   - Mark Ryan +
   - Matti Picus
   - Nathan Goldbaum
   - Ola x Nilsson +
   - Pieter Eendebak
   - Ralf Gommers
   - Sayed Adel
   - Sebastian Berg
   - Stefan van der Walt
   - Stefano Rivera


*Pull requests merged*

A total of 19 pull requests were merged for this release.

   - #25323: BUG: Restore missing asstr import
   - #25523: MAINT: prepare 1.26.x for further development
   - #25539: BUG: ``numpy.array_api``: fix ``linalg.cholesky`` upper
   decomp...
   - #25584: CI: Bump azure pipeline timeout to 120 minutes
   - #25585: MAINT, BLD: Fix unused inline functions warnings on clang
   - #25599: BLD: include fix for MinGW platform detection
   - #25618: TST: Fix test_numeric on riscv64
   - #25619: BLD: fix building for windows ARM64
   - #25620: MAINT: add ``newaxis`` to ``__all__`` in ``numpy.array_api``
   - #25630: BUG: Use large file fallocate on 32 bit linux platforms
   - #25643: TST: Fix test_warning_calls on Python 3.12
   - #25645: TST: Bump pytz to 2023.3.post1
   - #25658: BUG: Fix AVX512 build flags on Intel Classic Compiler
   - #25670: BLD: fix potential issue with escape sequences in
   ``__config__.py``
   - #25718: CI: pin cygwin python to 3.9.16-1 and fix typing tests [skip...
   - #25720: MAINT: Bump cibuildwheel to v2.16.4
   - #25748: BLD: unvendor meson-python on 1.26.x and upgrade to
   meson-python...
   - #25755: MAINT: Include header defining backtrace
   - #25756: BUG: Fix np.quantile([Fraction(2,1)], 0.5) (#24711)


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

[Numpy-discussion] Re: Switching default order to column-major

[Charles R Harris]

On Sat, Nov 11, 2023 at 8:07 AM Valerio De Benedetto 
wrote:

> Hi, I found that the documented default row-major order is enforced
> throughout the library with a series of `order='C'` default parameters, so
> given this I supposed there's no way to change the default (or am I wrong?)
> If, supposedly, I'd change that by patching the library (substituting 'C's
> for 'F's), do you think there would by any problem with other downstream
> libraries using numpy in my project? Do you think they assume a
> default-constructed array is always row-major and access the underlying
> data?
>

Nobody expects the column major arrays.

Chuck
___
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.26. 2 released

[Charles R Harris]

Charles R Harris 
Sat, Oct 14, 3:03 PM
to numpy-discussion, SciPy, bcc: python-announce-list
Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.2. NumPy 1.26.2 is a maintenance release that fixes bugs and
regressions discovered after the 1.26.1 release. The Python versions
supported by this release are 3.9-3.12. Wheels can be downloaded from PyPI
<https://pypi.org/project/numpy/1.26.2/>; source archives, release notes,
and wheel hashes are available on Github
<https://github.com/numpy/numpy/releases/tag/v1.26.2>. The release notes
have documentation of the new meson functionality.

*Contributors*

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

   - @stefan6419846
   - @thalassemia +
   - Andrew Nelson
   - Charles Bousseau +
   - Charles Harris
   - Marcel Bargull +
   - Mark Mentovai +
   - Matti Picus
   - Nathan Goldbaum
   - Ralf Gommers
   - Sayed Adel
   - Sebastian Berg
   - William Ayd +



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

   - #24814: MAINT: align test_dispatcher s390x targets with
   _umath_tests_mtargets
   - #24929: MAINT: prepare 1.26.x for further development
   - #24955: ENH: Add Cython enumeration for NPY_FR_GENERIC
   - #24962: REL: Remove Python upper version from the release branch
   - #24971: BLD: Use the correct Python interpreter when running tempita.py
   - #24972: MAINT: Remove unhelpful error replacements from
   ``import_array()``
   - #24977: BLD: use classic linker on macOS, the new one in XCode 15
   has...
   - #25003: BLD: musllinux_aarch64 [wheel build]
   - #25043: MAINT: Update mailmap
   - #25049: MAINT: Update meson build infrastructure.
   - #25071: MAINT: Split up .github/workflows to match main
   - #25083: BUG: Backport fix build on ppc64 when the baseline set to
   Power9...
   - #25093: BLD: Fix features.h detection for Meson builds [1.26.x
   Backport]
   - #25095: BUG: Avoid intp conversion regression in Cython 3 (backport)
   - #25107: CI: remove obsolete jobs, and move macOS and conda Azure
   jobs...
   - #25108: CI: Add linux_qemu action and remove travis testing.
   - #25112: MAINT: Update .spin/cmds.py from main.
   - #25113: DOC: Visually divide main license and bundled licenses in
   wheels
   - #25115: MAINT: Add missing ``noexcept`` to shuffle helpers
   - #25116: DOC: Fix license identifier for OpenBLAS
   - #25117: BLD: improve detection of Netlib libblas/libcblas/liblapack
   - #25118: MAINT: Make bitfield integers unsigned
   - #25119: BUG: Make n a long int for np.random.multinomial
   - #25120: BLD: change default of the ``allow-noblas`` option to true.
   - #25121: BUG: ensure passing ``np.dtype`` to itself doesn't crash


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

[Numpy-discussion] NumPy 2.0.0b1 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.0b1. NumPy 2.0.0 is the first major release since 2006. It is the
result of 10 months of development since the last feature release and is
the work of 190
contributors spread over 968 pull requests. It contains a large number of
exciting new features as well as changes to both the Python and C APIs.

This major release includes breaking changes that could not happen in a
regular minor (feature) release - including an ABI break, changes to type
promotion rules, and API changes which may not have been emitting
deprecation warnings in 1.26.x. Key documents related to how to adapt to
changes in NumPy 2.0 include:

   - The release notes on Github
   
   - The numpy-2-migration-guide
   
   - The numpy 2.0-specific advice in for downstream package authors
   

Highlights include:

   - A new variable-length string dtype, StringDType, and a new
   `numpy.strings` namespace with performant ufuncs for string operations.
   - Support for float32 and long double in all `numpy.fft` functions.
   - Support for the array API standard in the main numpy namespace.
   - MacOS Accelerate support and binary wheels for macOS >=14.
   - A new tracing and introspection API.
   - Performance improvements.
   - Python API improvements.
   - C API improvements.

Wheels can be downloaded from PyPI
; source
archives, release notes, and wheel hashes are available on Github



*Contributors*

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

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mykykh +
   - @pojaghi +
   - @pratiklp00 +
   - @stefan6419846 +
   - @undermyumbrella1 +
   - Aaron Meurer
   - Aditi Saluja +
   - Agriya Khetarpal +
   - Albert Steppi +
   - Alex Cabrera +
   - Alexander Grund
   - Andrea Bianchi +
   - Andreas Florath +
   - Andrew Ardill +
   - Andrew Ho +
   - Andrew Nelson
   - Andrey Rybakov +
   - Ankur Singh +
   - Anton Prosekin +
   - Antony Lee
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavya Alekhya +
   - Brandon Smith +
   - Brian Walshe +
   - Brigitta Sipőcz
   - Brock Mendel
   - Carl Meyer +
   - Charles Bousseau +
   - Charles Harris
   - Chris Sidebottom
   - Christian Lorentzen
   - Christian Veenhuis
   - Christoph Reiter
   - Christopher Sidebottom
   - Clément Robert
   - Cédric Hannotier
   - D.J. Ramones +
   - DanShatford +
   - Daniel Li +
   - Daniel Vanzo
   - Daval Parmar
   - Developer-Ecosystem-Engineering
   - Dhruv Rawat +
   - Dimitri Papadopoulos Orfanos
   - Edward E
   - Edward Yang +
   - Eisuke Kawashima +
   - Eliah Kagan +
   - Élie Goudout +
   - Elliott Sales de Andrade
   - Emil Olszewski +
   - Emily Hunt +
   - Éric Piel +
   - Eric Wieser
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Ganesh Kathiresan
   - Hans Meine
   - Heberto Mayorquin +
   - Heinz-Alexander Fuetterer +
   - Hood Chatham
   - Ivan A. Melnikov +
   - Jacob M. Casey +
   - Jake Lishman +
   - Jake VanderPlas
   - Jake Vanderplas
   - James Oliver +
   - Jan Wassenberg +
   - Janukan Sivajeyan +
   - Johann Rohwer +
   - Johannes Kaisinger +
   - John Muradeli +
   - Kai Striega
   - Kevin Sheppard
   - Kevin Wu +
   - Khawaja Junaid +
   - Kit Lee +
   - Kristian Minchev +
   - Kuan-Wei Chiu +
   - Lane Votapka +
   - Larry Bradley
   - Leo Singer
   - Liang Yan +
   - Linus Sommer +
   - Logan Thomas
   - Lucas Colley +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten Henric van Kerkwijk +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matthew Barber
   - Matthias Bussonnier
   - Matthias Koeppe
   - Matthias Schaufelberger +
   - Matti Picus
   - Maxwell Aladago
   - Maya Anderson +
   - Melissa Weber Mendonça
   - Meng Xiangzhuo +
   - Michael Kiffer
   - Miki Watanabe (渡邉 美希)
   - Milan Curcic +
   - Miles Cranmer
   - Miro Hrončok +
   - Mohamed E. BRIKI +
   - Mohaned Qunaibit +
   - Mohit Kumar +
   - Muhammed Muhsin +
   - Mukulika Pahari
   - Munira Alduraibi +
   - Namami Shanker
   - Nathan Goldbaum
   - Nyakku Shigure +
   - Ola x Nilsson +
   - Olivier Mattelaer +
   - Omid Rajaei
   - Pablo Losada +
   - Pamphile Roy
   - Paul Reece +
   - Pedro Kaj Kjellerup Nacht +
   - Peiyuan Liu +
   - Peter Hawkins
   - Pierre
   - Pieter Eendebak
   - Quentin Barthélemy +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Randy Eckenrode +
   - Richard Howe +
   - Robert Kern
   - Rohit Goswami
   - Ronald van Elburg +
 

[Numpy-discussion] numpy 2.0.x has been branched.

[Charles R Harris]

Hi All,

Numpy 2.0.x has been branched, further work on the release notes should be
made against that branch. The main branch is now 2.1.0.

Chuck
___
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: numpy 2.0.x has been branched.

[Charles R Harris]

On Fri, Mar 8, 2024 at 2:48 PM Oscar Benjamin 
wrote:

> Hi Chuck,
>
> Is there a rough expected landing time for NumPy 2.0?
>
> Also does the branching mean that the intention/guarantee is not to
> make further incompatible changes?
>
> SymPy's current master branch is compatible with the current NumPy
> master branch but SymPy's last release is not and will not be
> compatible with NumPy 2.0. That means that we want to have a SymPy
> release before NumPy 2.0 that includes the changes needed in
> preparation. Ideally I also want that SymPy release to be made after
> NumPy has finished making breaking changes though.
>
> Basically I want to know what the interval of time is between NumPy
> finishing its incompatible changes and NumPy 2.0 actually being
> released (to the extent that that is knowable).
>
> Oscar
>
>
We plan on a beta release, which will probably have a stable API, but not
guaranteed, then an rc1. At that point the API should be stable and the
final release will wait for the most important downstream projects to make
compatible releases. I would hope we are talking about a month in total,
but it will depend on how things go.

Chuck
___
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: numpy 2.0.x has been branched.

[Charles R Harris]

On Fri, Mar 8, 2024 at 4:45 PM Oscar Benjamin 
wrote:

> On Fri, 8 Mar 2024 at 23:31, Aaron Meurer  wrote:
> >
> > How bad are the NumPy 2.0 breakages in SymPy? We could do a backport
> > release if they are serious.
>
> I don't remember exactly what needed changing but some basic things in
> sympy needed changing because of basic changes in numpy.
>
> I don't see what purpose a backport release would serve. I would like
> to get out a sympy release right now. I would also like to know when
> is the right time to put out a release that is tested with all new
> numpy changes and that should be expected to be compatible with numpy
> 2.0.
>
> I am asking for a timeline: is numpy 2.0 coming out in 1 week, 1
> month, 2 months, 3 months, 6 months, 12 months?
>
> I understand if it is difficult to be precise but right now I have no
> idea what timeline anyone is talking about and I am pretty sure that
> numpy folks have a much clearer idea: please share it with me!
>
>
About a month from now.

Chuck
___
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: Polyfit error in displacement

[Charles R Harris]

On Mon, Mar 25, 2024 at 11:28 AM Luca Bertolotti <
luca72.bertolo...@gmail.com> wrote:

> Hello
> in a vb program they use 3rd degree approx and get this value including
> displacement:(SC)
> [image: image.png]
>
> Ii think that i'm doing the same with numpy but I get different value does
> anyone can help me please
>
> radious = [1821, 1284, 957, 603,450, 245]
> y = [6722, 6940, 7227, 7864,8472, 10458]
> p = np.polyfit(radious, y, 3,)
> t = np.polyval(p, radious)
> [ 6703.33694696  7061.23784145  7051.49974149  7838.84623289
>   8654.47847319 10373.60076402]
> You can see polyval is difference from the sc. of the table
> Any help is really appreciated
>

What is sc?

Chuck
___
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: numpy 2.0.x has been branched.

[Charles R Harris]

On Mon, Mar 25, 2024 at 5:54 PM Oscar Benjamin 
wrote:

> On Sat, 9 Mar 2024 at 10:16, Ralf Gommers  wrote:
> >
> > On Sat, Mar 9, 2024 at 2:03 AM Oscar Benjamin <
> oscar.j.benja...@gmail.com> wrote:
> >>
> >> On Sat, 9 Mar 2024 at 00:44, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >> >
> >> > About a month from now.
> >>
> >> What will happen about a month from now? It might seem obvious to you
> >> but I can interpret this in different ways.
> >>
> >> To be clear numpy 2.0 is expected to be released in full to the public
> >> in about one month's time from today?
> >
> > Let me give the optimistic and pessimistic timelines. Optimistic:
> >
> > - 2.0.0b1 later today
> > - 2.0.0rc1 (ABI stable) in 7-10 days
> > - 2.0.0 final release in 1 month
> >
> > Pessimistic:
> >
> > - 2.0.0b1 within a few days
> > - 2.0.0rc1 (ABI stable) in 2 weeks
> > - 2.0.0rc2 in 4 weeks
> > - 2.0.0rc3 in 6 weeks
> > - 2.0.0 final release in 8 weeks
>
> Thanks Ralf and Chuck. Sorry, I meant to reply to this earlier but got
> distracted with other things.
>
> We are now 16 days into the future so NumPy 2.0 would be 2 weeks time
> for the optimistic timescale.
>
> I assume that now the beta release is out the intention is no further
> breaking changes. Then if SymPy master is currently compatible with
> NumPy 2.0.0b1 a good time for a SymPy release with accumulated fixes
> is... ASAP!
>
> Presumably now that NumPy 2.0 is branched downstream projects should
> test in CI against the prereleases (pip install --pre numpy) rather
> than the nightly wheels. (SymPy does not usually test against the
> nightly wheels. I added that for NumPy 2.0 but maybe we should keep
> it...)
>
>
The rc1 release is now waiting on pybind11, so there is an (uncertain)
delay.

Chuck
___
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 2.0.0rc1 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.0rc1. NumPy 2.0.0 is the first major release since 2006. It is the
result of 10 months of development since the last feature release and is
the work of 193 contributors spread over 1005 pull requests. It contains a
large number of exciting new features as well as changes to both the Python
and C APIs.

This major release includes breaking changes that could not happen in a
regular minor (feature) release - including an ABI break, changes to type
promotion rules, and API changes which may not have been emitting
deprecation warnings in 1.26.x. Key documents related to how to adapt to
changes in NumPy 2.0 include:

   - The release notes on Github
   
   - The numpy-2-migration-guide
   
   - The numpy 2.0-specific advice in for downstream package authors
   

Highlights include:

   - A new variable-length string dtype, StringDType, and a new
   `numpy.strings` namespace with performant ufuncs for string operations.
   - Support for float32 and long double in all `numpy.fft` functions.
   - Support for the array API standard in the main numpy namespace.
   - MacOS Accelerate support and binary wheels for macOS >=14.
   - A new tracing and introspection API.
   - Performance improvements.
   - Python API improvements.
   - C API improvements.

This release supports Python 3.9-3.12. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.


*Contributors*

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mykykh +
   - @pojaghi +
   - @pratiklp00 +
   - @stefan6419846 +
   - @undermyumbrella1 +
   - Aaron Meurer
   - Aditi Saluja +
   - Adrin Jalali +
   - Agriya Khetarpal +
   - Albert Steppi +
   - Alex Cabrera +
   - Alexander Grund
   - Andrea Bianchi +
   - Andreas Florath +
   - Andrew Ardill +
   - Andrew Ho +
   - Andrew Nelson
   - Andrey Rybakov +
   - Ankur Singh +
   - Anton Prosekin +
   - Antony Lee
   - Bas van Beek
   - Bharat Raghunathan
   - Bhavya Alekhya +
   - Brandon Smith +
   - Brian Walshe +
   - Brigitta Sipőcz
   - Brock Mendel
   - Carl Meyer +
   - Charles Bousseau +
   - Charles Harris
   - Chris Sidebottom
   - Christian Lorentzen
   - Christian Veenhuis
   - Christoph Reiter
   - Christopher Sidebottom
   - Clément Robert
   - Cédric Hannotier
   - D.J. Ramones +
   - DanShatford +
   - Daniel Li +
   - Daniel Vanzo
   - Daval Parmar
   - Developer-Ecosystem-Engineering
   - Dhruv Rawat +
   - Dimitri Papadopoulos Orfanos
   - Edward E
   - Edward Yang +
   - Eisuke Kawashima +
   - Eliah Kagan +
   - Élie Goudout +
   - Elliott Sales de Andrade
   - Emil Olszewski +
   - Emily Hunt +
   - Éric Piel +
   - Eric Wieser
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Ganesh Kathiresan
   - Gonzalo Tornaría +
   - Hans Meine
   - Heberto Mayorquin +
   - Heinz-Alexander Fuetterer +
   - Hood Chatham
   - Ivan A. Melnikov +
   - Jacob M. Casey +
   - Jake Lishman +
   - Jake VanderPlas
   - Jake Vanderplas
   - James Oliver +
   - Jan Wassenberg +
   - Janukan Sivajeyan +
   - Johann Rohwer +
   - Johannes Kaisinger +
   - John Muradeli +
   - Kai Striega
   - Kevin Sheppard
   - Kevin Wu +
   - Khawaja Junaid +
   - Kit Lee +
   - Kristian Minchev +
   - Kuan-Wei Chiu +
   - Lane Votapka +
   - Larry Bradley
   - Leo Singer
   - Liang Yan +
   - Linus Sommer +
   - Logan Thomas
   - Lucas Colley +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten Henric van Kerkwijk +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matthew Barber
   - Matthias Bussonnier
   - Matthias Koeppe
   - Matthias Schaufelberger +
   - Matti Picus
   - Maxwell Aladago
   - Maya Anderson +
   - Melissa Weber Mendonça
   - Meng Xiangzhuo +
   - Michael Kiffer
   - Miki Watanabe (渡邉 美希)
   - Milan Curcic +
   - Miles Cranmer
   - Miro Hrončok +
   - Mohamed E. BRIKI +
   - Mohaned Qunaibit +
   - Mohit Kumar +
   - Muhammed Muhsin +
   - Mukulika Pahari
   - Munira Alduraibi +
   - Namami Shanker
   - Nathan Goldbaum
   - Nyakku Shigure +
   - Ola x Nilsson +
   - Olivier Mattelaer +
   - Omid Rajaei
   - Pablo Losada +
   - Pamphile Roy
   - Paul Reece +
   - Pedro Kaj Kjellerup Nacht +
   - Peiyuan Liu +
   - Peter Hawkins
   - Pierre
   - Pieter Eendebak
   - Quentin Barthélemy +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Randy Eckenrode +
   - Raquel Braunschweig +
   - Richard Howe +
   - Robert Kern
   - Rohit Goswami
   - Ronald van Elburg +
   - Ross 

[Numpy-discussion] Re: Moving the weekly traige/community meetings

[Charles R Harris]

On Sun, Apr 7, 2024 at 8:37 PM Matti Picus  wrote:

> Could we move the weekly community/triage meetings one hour later? Some
> participants have a permanent conflict, and the current time is
> inconvenient for my current time zone.
>
> Matti
>
>
Works for me.

Chuck
___
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: Please consider dropping Python 3.9 support for Numpy 2.0

[Charles R Harris]

On Fri, May 10, 2024 at 8:47 AM Ralf Gommers  wrote:

>
>
> On Thu, May 9, 2024 at 12:28 AM Thomas Caswell  wrote:
>
>> I think the spirit of NEP 29 is to pick your supported Python's when you
>> pick a target release date and you should then stick to it (to avoid "we
>> delayed so long we are over a cliff" decisions like this one).
>>
>
> That's true I believe.
>
>
>> We did NEP29 around the same time that Python went from 18 to 12 month
>> releases (my memory is that the cadence change was being considered but not
>> set).  If Python is targeting an 18mo release cycle, then a 36mo window +
>> 2mo delayed Python release could land you in only supporting one version of
>> Python which seems too few (again, my memory could be a bit off).  I was
>> not at the meeting where SPEC 0 was discussed,
>>
>
> Same here, I wasn't at that meeting so am unsure. I only got added to SPEC
> 0 as a co-author at the end because it's mostly a copy of NEP 29. "change
> in release cycle" is probably right as the motivation though.
>
>
>> but I suspect that the narrowing is to better align with an integer
>> number of Python releases while always hitting at least 2 versions of
>> Python.
>>
>
> At least 3, right? 36 months is always 3 minor versions.
>
>
>
>> 
>>
>> It is worth considering that CPython has both a concept of "bugfix"
>> (which is 18mo) and "security" (which is 42mo and source-only) support.  It
>> is arguable that by having "new feature" support and binary release
>> targeting a given version of Python for 36mo we are supporting a given
>> minor version of Python longer than upstream [speaking for myself I would
>> sign onto a proposal to do security release against the last version of our
>> libraries for all versions of Python that still have security support].
>>
>> 
>>
>> > So only 30% of users have Python 3.10+ or newer. Most smaller or newer
>> projects can more than double their user base by supporting  3.8+. I could
>> even argue that 3.7+ is still helpful for a new project. Once a library is
>> large and stable, then it can go higher, even 3.13+ and not hurt anyone
>> unless there's a major development.
>>
>> I have the exact opposite view of Henry here, I think for new projects
>> you should be very aggressive and only support the newest Python version as
>> you don't have any users (so do not have to be responsible yet)!
>>
>
> I think what you do as a new project author totally depends on your goals
> and priorities. Either way, the argument that only so few users "have a new
> Python" seems a bit off-target. That's not how people think - they look for
> new packages to use when they need functionality, and once they find
> something that fits their needs, they make it work. Nor are the statistics
> reflective of usage needs, especially for manylinux - it's more that
> production deployments stay on the same version of Python for their own
> lifetime I suspect. But such deployments also pin all their dependencies,
> so they're irrelevant to new versions/projects.
>
> It gets ever-easier to install new Python versions, with pyenv/conda/etc.
> The "my single Python install comes from python.org and I'm using the
> same one because I am afraid to upgrade" is much less of an issue than it
> was 10 years ago. And it's caused mostly by users having knowledge gaps. So
> yes it can be a pain for them, but they'll have to learn at some point
> anyway. Same for "my old HPC cluster uses ..." - it's often an even older
> Python anyway, and you'll have tons of reasons why you don't want your
> cluster-installed stack - learn to use Spack or Conda, and you'll be much
> happier in the long run.
>
> ---
>
> Back to the topic of dropping 3.9 here: there seem to be some minor
> concerns. Tom is right about the spirit of NEP29/SPEC0. And Sebastian is
> partially right I think: not about `pip install scipy-image==0.22`, because
> that should be picking 0.22.1 plus an older numpy; but `==0.22.0` instead
> cannot be fixed anyway, and that's perhaps a more common way of spelling an
> `==` constraint. So the last-minute dropping will at most have a marginally
> useful impact.
>
> Since Mark has started working on doing a single release of scikit-image
> supporting Python 3.9 (
> https://github.com/scikit-image/scikit-image/pull/7412), perhaps we can
> close the book on this request now, and decide to not change anything?
> I.e., we do release with 3.9 support as planned.
>
>
I'll add that numpy 2.1.0 should follow a few months after 2.0.0. Normally,
it would be released in June without Python 3.9 support, but due to the
extended release cycle needed to get 2.0.0 out, it will be delayed.
Current policy is that we always support at least three Python versions,
but because we are not synced with Python, we end up with four. For
instance, 2.1.0 will support three versions on release (3.10-3.12), but
will finish with four after Python 3.13 is released. The current difficulty
is unique to the breaking changes in 2.0.0 

[Numpy-discussion] NumPy 2.0.0rc2 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.0rc2. NumPy 2.0.0 is the first major release since 2006. It is the
result of 11 months of development since the last feature release and is
the work of 198 contributors spread over 1041 pull requests. It contains a
large number of exciting new features as well as changes to both the Python
and C APIs.

This major release includes breaking changes that could not happen in a
regular minor (feature) release - including an ABI break, changes to type
promotion rules, and API changes which may not have been emitting
deprecation warnings in 1.26.x. Key documents related to how to adapt to
changes in NumPy 2.0 include:

   - The release notes on Github
   
   - The numpy-2-migration-guide
   
   - The numpy 2.0-specific advice in for downstream package authors
   

Highlights include:

   - A new variable-length string dtype, StringDType, and a new
   `numpy.strings` namespace with performant ufuncs for string operations.
   - Support for float32 and long double in all `numpy.fft` functions.
   - Support for the array API standard in the main numpy namespace.
   - MacOS Accelerate support and binary wheels for macOS >=14.
   - A new tracing and introspection API.
   - Performance improvements.
   - Python API improvements.
   - C API improvements.

This release supports Python 3.9-3.12. Wheels can be downloaded from PyPI
; source archives, release notes,
and wheel hashes are available on Github
.

*Contributors*

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

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mykykh +
   - @pojaghi +
   - @pratiklp00 +
   - @stefan6419846 +
   - @undermyumbrella1 +
   - Aaron Meurer
   - Aditi Saluja +
   - Adrin Jalali +
   - Agriya Khetarpal +
   - Albert Steppi +
   - Alex Cabrera +
   - Alexander Grund
   - Andrea Bianchi +
   - Andreas Florath +
   - Andrew Ardill +
   - Andrew Ho +
   - Andrew Nelson
   - Andrey Rybakov +
   - Ankur Singh +
   - Anton Prosekin +
   - Antony Lee
   - Bas van Beek
   - Ben Woodruff +
   - Bharat Raghunathan
   - Bhavya Alekhya +
   - Brandon Smith +
   - Brian Walshe +
   - Brigitta Sipőcz
   - Brock Mendel
   - Carl Meyer +
   - Charles Bousseau +
   - Charles Harris
   - Chris Sidebottom
   - Christian Lorentzen
   - Christian Veenhuis
   - Christoph Reiter
   - Christopher Sidebottom
   - Clément Robert
   - Cédric Hannotier
   - D.J. Ramones +
   - DanShatford +
   - Daniel Li +
   - Daniel Vanzo
   - Daval Parmar
   - Developer-Ecosystem-Engineering
   - Dhruv Rawat +
   - Dimitri Papadopoulos Orfanos
   - Edward E
   - Edward Yang +
   - Eisuke Kawashima +
   - Eliah Kagan +
   - Élie Goudout +
   - Elliott Sales de Andrade
   - Emil Olszewski +
   - Emily Hunt +
   - Éric Piel +
   - Eric Wieser
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Francisco Sousa +
   - Ganesh Kathiresan
   - Gonzalo Tornaría +
   - Hans Meine
   - Heberto Mayorquin +
   - Heinz-Alexander Fuetterer +
   - Hood Chatham
   - Hugo van Kemenade
   - Ivan A. Melnikov +
   - Jacob M. Casey +
   - Jake Lishman +
   - Jake VanderPlas
   - James Oliver +
   - Jan Wassenberg +
   - Janukan Sivajeyan +
   - Johann Rohwer +
   - Johannes Kaisinger +
   - John Muradeli +
   - Joris Van den Bossche
   - Kai Striega
   - Kevin Sheppard
   - Kevin Wu +
   - Khawaja Junaid +
   - Kit Lee +
   - Kristian Minchev +
   - Kristoffer Pedersen +
   - Kuan-Wei Chiu +
   - Lane Votapka +
   - Larry Bradley
   - Leo Singer
   - Liang Yan +
   - Linus Sommer +
   - Logan Thomas
   - Lucas Colley +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten Henric van Kerkwijk +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matthew Barber
   - Matthias Bussonnier
   - Matthias Koeppe
   - Matthias Schaufelberger +
   - Matti Picus
   - Maxwell Aladago
   - Maya Anderson +
   - Melissa Weber Mendonça
   - Meng Xiangzhuo +
   - Michael Kiffer
   - Miki Watanabe (渡邉 美希)
   - Milan Curcic +
   - Miles Cranmer
   - Miro Hrončok +
   - Mohamed E. BRIKI +
   - Mohaned Qunaibit +
   - Mohit Kumar +
   - Muhammed Muhsin +
   - Mukulika Pahari
   - Munira Alduraibi +
   - Namami Shanker
   - Nathan Goldbaum
   - Nyakku Shigure +
   - Ola x Nilsson +
   - Olivier Mattelaer +
   - Omid Rajaei
   - Pablo Losada +
   - Pamphile Roy
   - Paul Reece +
   - Pedro Kaj Kjellerup Nacht +
   - Peiyuan Liu +
   - Peter Hawkins
   - Pierre
   - 

[Numpy-discussion] Re: 3.13 wheels

[Charles R Harris]

On Tue, May 14, 2024 at 12:24 AM Andrew Nelson  wrote:

> I'm not sure if we've discussed this yet. I propose we start making
> nightly wheels for cp313 just after numpy2.0 gets officially released. That
> way there's no churn in the wheel infra. Note that there's already a
> 3.13dev job in CI.
>

Note that the latest cibuildwheel update supports 3.13.0b1. It does seem a
bit early as the API hasn't stabilized yet, but if it works, it works.

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