[Numpy-discussion] Re: welcome Andrew Nelson to the NumPy maintainers team

[Charles R Harris]

On Mon, Aug 21, 2023 at 10:09 PM Andrew Nelson  wrote:

> On Mon, 21 Aug 2023 at 18:39, Ralf Gommers  wrote:
>
>> Hi all,
>>
>> On behalf of the steering council, I am very happy to announce that
>> Andrew is joining the Maintainers team. Andrew has been contributing to our
>> CI setup in particular for the past year, and has contributed for example
>> the Cirrus CI setup and the musllinux builds:
>> https://github.com/numpy/numpy/pulls/andyfaff.
>>
>> Welcome Andrew, I'm looking forward to working with you more!
>>
>
> Thanks Ralf, it's good to join the team.
>

Welcome aboard.

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: Dealing with static local variables in Numpy

[Charles R Harris]

On Fri, Sep 1, 2023 at 11:11 AM Sebastian Berg 
wrote:

> On Tue, 2023-08-29 at 08:01 +, Nicolas Holzschuch wrote:
> > Hello,
> >
> > This is my first post to this group; I'd like to start by expressing
> > my appreciation for the amazing work in developing and maintaining
> > Numpy.
> >
> > I have a question. Numpy has quite a lot of static local variables
> > (variables defined as static inside a function, like this
> > (core/src/multiarraymodule.c, line 4483):
> > if (raise_exceptions) {
> > static PyObject *too_hard_cls = NULL;
> > /* ... */
> > }
> >
> > I understand that these variables provide local caching and are
> > important for efficiency. They do however cause some issues when
> > dealing with multiple subinterpreters, where the static local
> > variable might have been initialized by one of the subinterpreters,
> > and is not reset when accessed by another subinterpreter.
> > More globally, they cannot be reset when the Numpy module is
> > released, and thus will likely cause an issue if it is reloaded after
> > being released.
>
>
> Right, but in the end these caches are there for a reason (or almost
> all), and just removing them does not seem acceptable to me.
>
> However, there are better ways to solve this.  You can move it into
> module state.  In the vast majority of cases that should not be hard:
> The patterns are known.  In a few cases it may be harder but I believe
> CPython offers decent solutions now (not sure how it looks like).
> I had for a long time hoped for the HPy drive will solve this, but
> there is no reason to wait for it.
>
> In any case, contributions to this effect are very much welcome, I have
> been hoping they would come for a long time, but I am not excited about
> just removing the "static".
>
> - Sebastian
>
>
>
> >
> > I have seen the issue mentionned in at least one pull request:
> > https://github.com/numpy/numpy/pull/15169 and in several issues. If I
> > understand correctly, the issue is not considered as important
> > because subinterpreters are not yet prominent in CPython, static
> > local variables provide an important service in caching data locally
> > (instead of exposing these variables globally). So the benefits
> > outweigh the costs and risks (that would be a huge change to the code
> > base).
> >
> > I happen to maintain, compile and run a version of Python on iOS (
> > https://github.com/holzschu/a-shell/ or
> > https://apps.apple.com/us/app/a-shell/id1473805438), where I have to
> > remove all these static local variables, because of the specificity
> > of the platform (in order to run Python multiple times, I have to
> > release and reset all modules). Right now, I'm maintaining the
> > changes to the code base in a separate branch (
> > https://github.com/holzschu/numpy/) and not necessarily in a very
> > clean way.
> >
> > With the recent renewed interest in subinterpreters, I was wondering
> > if there was a way I could contribute these changes back to the main
> > numpy branch. I would have to clean up the code, obviously, and
> > probably get guidance on how to do it cleanly, but the first question
> > is: would there be an interest, or is that something I should keep in
> > my separate branch?
> >
> > > From a technical point of view, about 80% of these static local
> > > variables are just before a call to npy_cache_import(), and the
> > > most efficient way to do it (in terms of lines of code) is just to
> > > remove the part where npy_cache_import uses the static local
> > > variable. You pay a price in performance, but gain in usability.
> >
> > Best regards,
> > Nicolas Holzschuch
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: sebast...@sipsolutions.net
> >
>
>
This was discussed at the last community meeting. We are open to the idea,
but would like to see how it works out in practice. In particular, what the
code looks like.

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.0rc1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.0rc1. The NumPy 1.26.0 release is a continuation of the 1.25.x release
cycle with the addition of Python 3.12.0 support. Python 3.12 dropped
distutils, consequently supporting it required finding a replacement for
the setup.py/distutils based build system NumPy was using. We have chosen
to use the Meson build system instead, and this is the first NumPy release
supporting it. This is also the first release that supports Cython 3.0 in
addition to retaining 0.29.X compatibility. Supporting those two upgrades
was a large project, over 100 files have been touched in this release. The
changelog doesn't capture the full extent of the work, special thanks to
Ralf Gommers, Sayed Adel, Stéfan van der Walt, and Matti Picus who did much
of the work in the main development branch.

The highlights of this release are:

   - Python 3.12.0 support.
   - Cython 3.0.0 compatibility.
   - Use of the Meson build system
   - Updated SIMD support
   - f2py fixes, meson and bind(x) support
   - Support for the updated Accelerate BLAS/LAPACK library

The Python versions supported by this release are 3.9-3.12. Note that no 32
bit wheels are provided. 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
   - Albert Steppi +
   - Bas van Beek
   - Charles Harris
   - Developer-Ecosystem-Engineering
   - Jake Vanderplas
   - Marten van Kerkwijk
   - Matti Picus
   - Melissa Weber Mendonça
   - Namami Shanker
   - Nathan Goldbaum
   - Ralf Gommers
   - Rohit Goswami
   - Sayed Adel
   - Sebastian Berg
   - Stefan van der Walt
   - Tyler Reddy
   - Warren Weckesser



*Build system changes*
In this release, NumPy has switched to Meson as the build system and
meson-python as the build backend. Installing NumPy or building a wheel can
be
done with standard tools like ``pip`` and ``pypa/build``. The following are
supported:

   - Regular installs: ``pip install numpy`` or (in a cloned repo) ``pip
   install .``
   - Building a wheel: ``python -m build`` (preferred), or ``pip wheel .``
   - Editable installs: ``pip install -e . --no-build-isolation``
   - Development builds through the custom CLI implemented with spin
   : ``spin build``.

All the regular ``pip`` and ``pypa/build`` flags (e.g.,
``--no-build-isolation``) should work as expected.


*NumPy-specific build customization*
Many of the NumPy-specific ways of customizing builds have changed.
The ``NPY_*`` environment variables which control BLAS/LAPACK, SIMD,
threading,
and other such options are no longer supported, nor is a ``site.cfg`` file
to
select BLAS and LAPACK. Instead, there are command-line flags that can be
passed to the build via ``pip``/``build``'s config-settings interface. These
flags are all listed in the ``meson_options.txt`` file in the root of the
repo.
Detailed documented will be available before the final 1.26.0 release; for
now,
please see `the SciPy building from source
 docs since most build
customization
works in an almost identical way in SciPy as it does in NumPy.


*Build dependencies*
While the runtime dependencies of NumPy have not changed, the build
dependencies have. Because we temporarily vendor Meson and meson-python,
there are several new dependencies - please see the ``[build-system]``
section
of ``pyproject.toml`` for details.

*Troubleshooting*

This build system change is quite large. In case of unexpected issues, it is
still possible to use a ``setup.py``-based build as a temporary workaround
(on
Python 3.9-3.11, not 3.12), by copying ``pyproject.toml.setuppy`` to
``pyproject.toml``. However, please open an issue with details on the NumPy
issue tracker. We aim to phase out ``setup.py`` builds as soon as possible,
and
therefore would like to see all potential blockers surfaced early on in the
1.26.0 release cycle.


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.26.0rc1 released

[Charles R Harris]

On Wed, Sep 6, 2023 at 4:53 PM Charles R Harris 
wrote:

> Hi All,
>
> On behalf of the NumPy team, I'm pleased to announce the release of NumPy
> 1.26.0rc1. The NumPy 1.26.0 release is a continuation of the 1.25.x release
> cycle with the addition of Python 3.12.0 support. Python 3.12 dropped
> distutils, consequently supporting it required finding a replacement for
> the setup.py/distutils based build system NumPy was using. We have chosen
> to use the Meson build system instead, and this is the first NumPy release
> supporting it. This is also the first release that supports Cython 3.0 in
> addition to retaining 0.29.X compatibility. Supporting those two upgrades
> was a large project, over 100 files have been touched in this release. The
> changelog doesn't capture the full extent of the work, special thanks to
> Ralf Gommers, Sayed Adel, Stéfan van der Walt, and Matti Picus who did much
> of the work in the main development branch.
>
> 

Two observations:

1. There are still no 32 bit wheels for Windows.
2., Do we want to build wheels with the new accelerate?

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: Curious performance different with np.unique on arrays of characters

[Charles R Harris]

On Thu, Sep 14, 2023 at 11:34 AM Devulapalli, Raghuveer <
raghuveer.devulapa...@intel.com> wrote:

> What processor you are running this on? np.sort uses AVX-512 accelerated
> sorting for np.int32, so just wondering if you that is the reason for this
> difference.
>
> Raghuveer


We also have radix sort for stable sorting of int8, int16, which should be
quite fast.

Hmm, I wonder if radix sort could be vectorized?

When we dropped Python 2.7, there were some folks who ended up using a
uint8 array subtype for storing data. All they needed to add was automatic
translation to strings for
certain accesses. This gave them a 4x advantage in storage space.



>
>
> > -Original Message-
> > From: sal...@caltech.edu 
> > Sent: Wednesday, September 13, 2023 6:14 PM
> > To: numpy-discussion@python.org
> > Subject: [Numpy-discussion] Curious performance different with np.unique
> on
> > arrays of characters
> >
> > Hello -
> >
> > In the course of some genomics simulations, I seem to have come across a
> curious
> > (to me at least) performance difference in np.unique that I wanted to
> share. (If
> > this is not the right forum for this, please let me know!)
> >
> > With a np.array of characters (U1), np.unique seems to be much faster
> when
> > doing np.view as int -> np.unique -> np.view as U1 for arrays of decent
> size. I
> > would not have expected this since np.unique knows what's coming in as
> S1 and
> > could handle the view-stuff internally. I've played with this a number
> of ways (e.g.
> > S1 vs U1; int32 vs int64; return_counts = True vs False; 100, 1000, or
> 10k
> > elements) and seem to notice the same pattern. A short illustration
> below with
> > U1, int32, return_counts = False, 10 vs 10k.
> >
> > I wonder if this is actually intended behavior, i.e. the view-stuff is
> actually a good
> > idea for the user to think about and implement if appropriate for their
> usecase (as
> > it is for me).
> >
> > Best regards,
> > Shyam
> >
> >
> > import numpy as np
> >
> > charlist_10 = np.array(list('ASDFGHJKLZ'), dtype='U1') charlist_10k =
> > np.array(list('ASDFGHJKLZ' * 1000), dtype='U1')
> >
> > def unique_basic(x):
> > return np.unique(x)
> >
> > def unique_view(x):
> > return np.unique(x.view(np.int32)).view(x.dtype)
> >
> > In [27]: %timeit unique_basic(charlist_10)
> > 2.17 µs ± 40.7 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops
> each)
> >
> > In [28]: %timeit unique_view(charlist_10)
> > 2.53 µs ± 38.4 ns per loop (mean ± std. dev. of 7 runs, 100,000 loops
> each)
> >
> > In [29]: %timeit unique_basic(charlist_10k)
> > 204 µs ± 4.61 µs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)
> >
> > In [30]: %timeit unique_view(charlist_10k)
> > 66.7 µs ± 2.91 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops
> each)
> >
> > In [31]: np.__version__
> > Out[31]: '1.25.2'
> >
> >
> >
> > --
> > Shyam Saladi
> > https://shyam.saladi.org
> > ___
> > 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: raghuveer.devulapa...@intel.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: 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.26.0 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.0. The NumPy 1.26.0 release is a continuation of the 1.25.x release
cycle with the addition of Python 3.12.0 support. Python 3.12 dropped
distutils, consequently supporting it required finding a replacement for
the setup.py/distutils based build system NumPy was using. We have chosen
to use the Meson build system instead, and this is the first NumPy release
supporting it. This is also the first release that supports Cython 3.0 in
addition to retaining 0.29.X compatibility. Supporting those two upgrades
was a large project, over 100 files have been touched in this release. The
changelog doesn't capture the full extent of the work, special thanks to
Ralf Gommers, Sayed Adel, Stéfan van der Walt, and Matti Picus who did much
of the work in the main development branch.

The highlights of this release are:

   - Python 3.12.0 support.
   - Cython 3.0.0 compatibility.
   - Use of the Meson build system
   - Updated SIMD support
   - f2py fixes, meson and bind(x) support
   - Support for the updated Accelerate BLAS/LAPACK library

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 20 people contributed to this release.  People with a "+" by
their names contributed a patch for the first time.

   -  @DWesl
   -  Albert Steppi +
   -  Bas van Beek
   -  Charles Harris
   -  Developer-Ecosystem-Engineering
   -  Filipe Laíns +
   -  Jake Vanderplas
   -  Liang Yan +
   -  Marten van Kerkwijk
   -  Matti Picus
   -  Melissa Weber Mendonça
   -  Namami Shanker
   -  Nathan Goldbaum
   -  Ralf Gommers
   -  Rohit Goswami
   -  Sayed Adel
   -  Sebastian Berg
   -  Stefan van der Walt
   -  Tyler Reddy
   -  Warren Weckesser




*Build system changes*
In this release, NumPy has switched to Meson as the build system and
meson-python as the build backend. Installing NumPy or building a wheel can
be
done with standard tools like ``pip`` and ``pypa/build``. The following are
supported:

   - Regular installs: ``pip install numpy`` or (in a cloned repo) ``pip
   install .``
   - Building a wheel: ``python -m build`` (preferred), or ``pip wheel .``
   - Editable installs: ``pip install -e . --no-build-isolation``
   - Development builds through the custom CLI implemented with spin
   : ``spin build``.

All the regular ``pip`` and ``pypa/build`` flags (e.g.,
``--no-build-isolation``) should work as expected.


*NumPy-specific build customization*
Many of the NumPy-specific ways of customizing builds have changed.
The ``NPY_*`` environment variables which control BLAS/LAPACK, SIMD,
threading,
and other such options are no longer supported, nor is a ``site.cfg`` file
to
select BLAS and LAPACK. Instead, there are command-line flags that can be
passed to the build via ``pip``/``build``'s config-settings interface. These
flags are all listed in the ``meson_options.txt`` file in the root of the
repo.
Detailed documented will be available before the final 1.26.0 release; for
now,
see the SciPy building from source
 docs since most build
customization
works in an almost identical way in SciPy as it does in NumPy.


*Build dependencies*
While the runtime dependencies of NumPy have not changed, the build
dependencies have. Because we temporarily vendor Meson and meson-python,
there are several new dependencies - please see the ``[build-system]``
section
of ``pyproject.toml`` for details.

*Troubleshooting*

This build system change is quite large. In case of unexpected issues, it is
still possible to use a ``setup.py``-based build as a temporary workaround
(on
Python 3.9-3.11, not 3.12), by copying ``pyproject.toml.setuppy`` to
``pyproject.toml``. However, please open an issue with details on the NumPy
issue tracker. We aim to phase out ``setup.py`` builds as soon as possible,
and
therefore would like to see all potential blockers surfaced early on in the
1.26.0 release cycle.


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.26.1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.1. NumPy 1.26.1 is a maintenance release that fixes bugs and
regressions discovered after the 1.26.0 release. In addition, it adds new
functionality for detecting BLAS and LAPACK when building from source.
Highlights are:

   - Improved detection of BLAS and LAPACK libraries for meson builds
   - Pickle compatibility with the upcoming NumPy 2.0.

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

   - Andrew Nelson
   - Anton Prosekin +
   - Charles Harris
   - Chongyun Lee +
   - Ivan A. Melnikov +
   - Jake Lishman +
   - Mahder Gebremedhin +
   - Mateusz Sokół
   - Matti Picus
   - Munira Alduraibi +
   - Ralf Gommers
   - Rohit Goswami
   - Sayed Adel



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

   - #24742: MAINT: Update cibuildwheel version
   - #24748: MAINT: fix version string in wheels built with setup.py
   - #24771: BLD, BUG: Fix build failure for host flags e.g.
   ``-march=native``...
   - #24773: DOC: Updated the f2py docs to remove a note on -fimplicit-none
   - #24776: BUG: Fix SIMD f32 trunc test on s390x when baseline is none
   - #24785: BLD: add libquadmath to licences and other tweaks (#24753)
   - #24786: MAINT: Activate ``use-compute-credits`` for Cirrus.
   - #24803: BLD: updated vendored-meson/meson for mips64 fix
   - #24804: MAINT: fix licence path win
   - #24813: BUG: Fix order of Windows OS detection macros.
   - #24831: BUG, SIMD: use scalar cmul on bad Apple clang x86_64 (#24828)
   - #24840: BUG: Fix DATA statements for f2py
   - #24870: API: Add ``NumpyUnpickler`` for backporting
   - #24872: MAINT: Xfail test failing on PyPy.
   - #24879: BLD: fix math func feature checks, fix FreeBSD build, add CI...
   - #24899: ENH: meson: implement BLAS/LAPACK auto-detection and many CI...
   - #24902: DOC: add a 1.26.1 release notes section for BLAS/LAPACK
   build...
   - #24906: MAINT: Backport ``numpy._core`` stubs. Remove
   ``NumpyUnpickler``
   - #24911: MAINT: Bump pypa/cibuildwheel from 2.16.1 to 2.16.2
   - #24912: BUG: loongarch doesn't use REAL(10)


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: We've recevied a NumFOCUS SDG!

[Charles R Harris]

On Wed, Nov 8, 2023 at 4:24 PM  wrote:

> Hello NumPy community,
>
> I am thrilled to announce that I have been awarded a NumFocus Small
> Development Grant for my work on NumPy-Financial. This grant will enable me
> to enhance compatibility with NumPy 2.0, attract new contributors, improve
> testing and documentation, and perform the UFunc rework. I'm looking
> forward to contributing to the scientific Python community!
>
> As part of this grant, I am looking for any NumPy-Financial users input,
> especially in regard to setting up some benchmarks of real world scenarios.
> If you are currently using NumPy-Financial please get in touch.
>
> I hope everyone is going well
>
> Kai
> __


That's great. Congratulations.

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: 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 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: 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] 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: 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: 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] 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] 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] 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 B

[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 and

[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
   - Piete

[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

[Numpy-discussion] Generate documentation for the 2.0.0 release

[Charles R Harris]

Hi All,

Could someone running Python < 3.12 generate the documentation for the
NumPy 2.0.0 release. My native Python is 3.12, which works fine except that
there is no distutils. Trying to run the build under 3.11, after hard
coding the Python version in the doc/Makefile, runs into various problems,
and there are probably some subtle Python version mismatches buried in the
scripts somewhere that I don't want to spend time chasing down at the
moment.

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: Generate documentation for the 2.0.0 release

[Charles R Harris]

PS, you will need to check out `.spin/cmds.py` from the main branch in
order to build the documentation.

Chuck

On Sun, Jun 16, 2024 at 9:59 AM Charles R Harris 
wrote:

> Hi All,
>
> Could someone running Python < 3.12 generate the documentation for the
> NumPy 2.0.0 release. My native Python is 3.12, which works fine except that
> there is no distutils. Trying to run the build under 3.11, after hard
> coding the Python version in the doc/Makefile, runs into various problems,
> and there are probably some subtle Python version mismatches buried in the
> scripts somewhere that I don't want to spend time chasing down at the
> moment.
>
> 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: Generate documentation for the 2.0.0 release

[Charles R Harris]

PPS, the problem can probably be solved in the spin command, I suspect it
doesn't use the virtual environment everywhere it should.

Chuck

On Sun, Jun 16, 2024 at 10:04 AM Charles R Harris 
wrote:

> PS, you will need to check out `.spin/cmds.py` from the main branch in
> order to build the documentation.
>
> Chuck
>
> On Sun, Jun 16, 2024 at 9:59 AM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> Could someone running Python < 3.12 generate the documentation for the
>> NumPy 2.0.0 release. My native Python is 3.12, which works fine except that
>> there is no distutils. Trying to run the build under 3.11, after hard
>> coding the Python version in the doc/Makefile, runs into various problems,
>> and there are probably some subtle Python version mismatches buried in the
>> scripts somewhere that I don't want to spend time chasing down at the
>> moment.
>>
>> 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: Generate documentation for the 2.0.0 release

[Charles R Harris]

Thanks Matti.

Chuck


On Sun, Jun 16, 2024 at 10:31 AM Matti Picus  wrote:

> I will make a PR to https://github.com/numpy/doc
>
> Matti
>
>
> On 16/06/2024 19:04, Charles R Harris wrote:
> > PS, you will need to check out `.spin/cmds.py` from the main branch in
> > order to build the documentation.
> >
> > Chuck
> >
> > On Sun, Jun 16, 2024 at 9:59 AM Charles R Harris
> >  wrote:
> >
> > Hi All,
> >
> > Could someone running Python < 3.12 generate the documentation for
> > the NumPy 2.0.0 release. My native Python is 3.12, which works
> > fine except that there is no distutils. Trying to run the build
> > under 3.11, after hard coding the Python version in the
> > doc/Makefile, runs into various problems, and there are probably
> > some subtle Python version mismatches buried in the scripts
> > somewhere that I don't want to spend time chasing down at the moment.
> >
> > 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: matti.pi...@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: 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 2.0.0 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 212 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - @Algorithmist-Girl +
   - @DWesl
   - @Illviljan
   - @Searchingdays
   - @ellaella12 +
   - @liang3zy22 +
   - @matoro +
   - @mcp292 +
   - @mgunyho +
   - @msavinash +
   - @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
   - Arun Kannawadi +
   - 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
   - Cobalt Yang +
   - Gonçalo Bárias +
   - 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
   - Eric Xie +
   - Even Rouault +
   - Evgeni Burovski
   - Filipe Laíns +
   - Francisco Sousa +
   - Ganesh Kathiresan
   - Gonçalo Bárias +
   - 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
   - Justus Magin
   - Jyn Spring 琴春
   - 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 +
   - Luiz Eduardo Amaral +
   - Lukas Geiger
   - Lysandros Nikolaou +
   - Maanas Arora +
   - Maharshi Basu +
   - Mahder Gebremedhin +
   - Marcel Bargull +
   - Marcel Loose +
   - Mark Mentovai +
   - Mark Ryan +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matt Thompson +
   - Matthew Barber
   - Matthew Thompson +
   - 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 Go

[Numpy-discussion] NumPy 2.0.1 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.1. NumPy 2.0.1 is a maintenance release that fixes bugs and regressions
discovered after the 2.0.0 release. NumPy 2.0.1 is the last planned release
in the 2.0.x series, 2.1.0rc1 should be out shortly.

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 15 people contributed to this release.  People with a "+" by
their names contributed a patch for the first time.

   - @vahidmech +
   - Alex Herbert +
   - Charles Harris
   - Giovanni Del Monte +
   - Leo Singer
   - Lysandros Nikolaou
   - Matti Picus
   - Nathan Goldbaum
   - Patrick J. Roddy +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Rostan Tabet +
   - Sebastian Berg
   - Tyler Reddy
   - Yannik Wicke +


*Pull requests merged*

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

   - #26711: MAINT: prepare 2.0.x for further development
   - #26792: TYP: fix incorrect import in ``ma/extras.pyi`` stub
   - #26793: DOC: Mention '1.25' legacy printing mode in
   ``set_printoptions``
   - #26794: DOC: Remove mention of NaN and NAN aliases from constants
   - #26821: BLD: Fix x86-simd-sort build failure on openBSD
   - #26822: BUG: Ensure output order follows input in numpy.fft
   - #26823: TYP: fix missing sys import in numeric.pyi
   - #26832: DOC: remove hack to override _add_newdocs_scalars (#26826)
   - #26835: BUG: avoid side-effect of 'include complex.h'
   - #26836: BUG: fix max_rows and chunked string/datetime reading in
   ``loadtxt``
   - #26837: BUG: fix PyArray_ImportNumPyAPI under -Werror=strict-prototypes
   - #26856: DOC: Update some documentation
   - #26868: BUG: fancy indexing copy
   - #26869: BUG: Mismatched allocation domains in
   ``PyArray_FillWithScalar``
   - #26870: BUG: Handle --f77flags and --f90flags for meson [wheel build]
   - #26887: BUG: Fix new DTypes and new string promotion when signature
   is...
   - #26888: BUG: remove numpy.f2py from excludedimports
   - #26959: BUG: Quantile closest_observation to round to nearest even
   order
   - #26960: BUG: Fix off-by-one error in amount of characters in strip
   - #26961: API: Partially revert unique with return_inverse
   - #26962: BUG,MAINT: Fix utf-8 character stripping memory access
   - #26963: BUG: Fix out-of-bound minimum offset for in1d table method
   - #26971: BUG: fix f2py tests to work with v2 API
   - #26995: BUG: Add object cast to avoid warning with limited API


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: git status

[Charles R Harris]

On Sun, Aug 4, 2024 at 4:25 PM Andrew Nelson  wrote:

> Hi all,
> for some reason my fork has got way out of date and is missing commits
> from back to April. I'm not sure if my fork got messed up, or whether the
> numpy repo history has been affected.
>
> Is anyone else experiencing problems?
>

I haven't noticed any problems here, but that doesn't mean there aren't
any. How do you update your fork?

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: git status

[Charles R Harris]

What does your `.git/config` file show as the source for fetching numpy? I
just do `git pull upstream main`. I think you can also pull with `--force`,
which will overwrite your main branch. I wouldn't do that if you have
dependent branches, I also think GitHub added a button to update your
forked repository.

On Sun, Aug 4, 2024 at 9:33 PM Andrew Nelson  wrote:

> On Mon, 5 Aug 2024 at 10:34, Charles R Harris 
> wrote:
>
>>
>> On Sun, Aug 4, 2024 at 4:25 PM Andrew Nelson  wrote:
>>
>>> Hi all,
>>> for some reason my fork has got way out of date and is missing commits
>>> from back to April. I'm not sure if my fork got messed up, or whether the
>>> numpy repo history has been affected.
>>>
>>> I haven't noticed any problems here, but that doesn't mean there aren't
>> any. How do you update your fork?
>>
>> Chuck
>>
>
>
> On my local fork I:
>
> > git fetch numpy
> > git checkout main
> > git rebase numpy/main
> > git push origin main
>
> When I did that the push step hung. I couldn't resync my fork on github
> either (there's a button for that), there was a conflict.
> In the end I had to delete the main branch on my GH fork, after setting
> something else to be the default branch, and then repush my local main to
> my GH fork.
> ___
> 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: git status

[Charles R Harris]

For reference, the relevant part of my config file looks like:

[remote "origin"]
url = g...@github.com:charris/numpy.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "upstream"]
url = g...@github.com:numpy/numpy
fetch = +refs/heads/*:refs/remotes/upstream/*

I am using ssh, which is the `git@` bit, you probably want the `https://`
version.

Chuck

On Sun, Aug 4, 2024 at 9:38 PM Charles R Harris 
wrote:

> What does your `.git/config` file show as the source for fetching numpy? I
> just do `git pull upstream main`. I think you can also pull with `--force`,
> which will overwrite your main branch. I wouldn't do that if you have
> dependent branches, I also think GitHub added a button to update your
> forked repository.
>
> On Sun, Aug 4, 2024 at 9:33 PM Andrew Nelson  wrote:
>
>> On Mon, 5 Aug 2024 at 10:34, Charles R Harris 
>> wrote:
>>
>>>
>>> On Sun, Aug 4, 2024 at 4:25 PM Andrew Nelson  wrote:
>>>
>>>> Hi all,
>>>> for some reason my fork has got way out of date and is missing commits
>>>> from back to April. I'm not sure if my fork got messed up, or whether the
>>>> numpy repo history has been affected.
>>>>
>>>> I haven't noticed any problems here, but that doesn't mean there aren't
>>> any. How do you update your fork?
>>>
>>> Chuck
>>>
>>
>>
>> On my local fork I:
>>
>> > git fetch numpy
>> > git checkout main
>> > git rebase numpy/main
>> > git push origin main
>>
>> When I did that the push step hung. I couldn't resync my fork on github
>> either (there's a button for that), there was a conflict.
>> In the end I had to delete the main branch on my GH fork, after setting
>> something else to be the default branch, and then repush my local main to
>> my GH fork.
>> ___
>> 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 2.1.x branched, main is open for 2.2.0 development

[Charles R Harris]

Hi All,

Just a note that the 'maintenance/2.1.x' branch has been created and the
main branch is now ready for 2.2.0 development.
The OpenBlas problems have not yet been resolved, hopefully that can be
taken care of before the 2.1.0 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] NumPy 2.1.0rc1 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.1.0rc1. NumPy 2.1.0rc1 provides support for the upcoming Python 3.13
release and drops support for Python 3.9. In addition to the usual bug
fixes and updated Python support, it helps get us back into our usual
release cycle after the extended development of 2.0.  Some 455 pull
requests were merged for this release, highlights are:

   - Support for the array-api 2023.12 standard.
   - Support for Python 3.13.
   - Preliminary support for free threaded Python 3.13

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


*Contributors*

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

   - !ogidig5 +
   - !partev
   - !vahidmech +
   - Aaron Meurer
   - Adrin Jalali +
   - Agriya Khetarpal
   - Ajay Kumar Janapareddi +
   - Alex Herbert +
   - Andras Deak
   - Andrej Zhilenkov +
   - Andrew Nelson
   - Anne Gunn +
   - Antony Lee
   - Arnaud Ma +
   - Arun Kannawadi +
   - Arun Pa +
   - Bas van Beek
   - Ben Woodruff +
   - Bruno Oliveira +
   - Carlos Henrique Hermanny Moreira da Silva +
   - Charles Harris
   - Chris Sidebottom
   - Christian Heimes +
   - Christian Lorentzen
   - Christopher Sidebottom
   - Christopher Titchen +
   - Clément Robert
   - Cobalt Yang +
   - Devyani Chavan +
   - Dimitri Papadopoulos Orfanos
   - Ebigide Jude +
   - Eric Xie +
   - Evgeni Burovski
   - Fabian Vogt +
   - Francisco Sousa +
   - GUAN MING +
   - Gabriel Fougeron +
   - Gagandeep Singh
   - Giovanni Del Monte +
   - Gonzalo Tornaría +
   - Gonçalo Bárias +
   - Hugo van Kemenade
   - Jakob Stevens Haas +
   - Jakob Unfried +
   - James Joseph Thomas +
   - Jean Lecordier +
   - Joren Hammudoglu +
   - Joris Van den Bossche
   - Julia Poo +
   - Justus Magin
   - Jyn Spring 琴春
   - KIU Shueng Chuan
   - Karthik Gangula +
   - Karthik Kaiplody +
   - Kevin Sheppard
   - Kristoffer Pedersen +
   - Leo Singer
   - Liang Yan
   - Liangyu Zhang +
   - Lucas Colley
   - Luiz Eduardo Amaral +
   - Lysandros Nikolaou
   - Marcel Loose +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matt Thompson +
   - Matthew Roeschke +
   - Matthew Thompson +
   - Matthias Bussonnier
   - Matti Picus
   - Melissa Weber Mendonça
   - Milica Dančuk +
   - Moritz Schreiber +
   - Nathan Goldbaum
   - Olivier Grisel
   - Patrick J. Roddy +
   - Paul Juma Otieno +
   - Pieter Eendebak
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raquel Braunschweig +
   - Robert Kern
   - Rohit Goswami
   - Romain Geissler +
   - Ross Barnowski
   - Rostan Tabet +
   - Sam Morley +
   - Sayed Adel
   - Sean Cheah
   - Sebastian Berg
   - Serge Guelton
   - Slobodan +
   - Stefan van der Walt
   - Thomas A Caswell
   - Thomas Li
   - Timo Röhling +
   - Tsvika Shapira +
   - Tuhin Sharma +
   - Tyler Reddy
   - Victor Eijkhout +
   - Warren Weckesser
   - Warrick Ball
   - Xiangyi Wang +
   - Yair Chuchem +
   - Yang Liu +
   - Yannik Wicke +
   - Yevhen Amelin +
   - 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] NumPy 2.1.0 released.

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.1.0. NumPy 2.1.0 provides support for the upcoming Python 3.13 release
and drops support for Python 3.9. In addition to the usual bug fixes and
updated Python support, this release helps get NumPy back into its usual
release cycle after the extended development of 2.0.  Some 469 pull
requests were merged for this release, highlights are:

   - Support for the array-api 2023.12 standard.
   - Support for Python 3.13.
   - Preliminary support for free threaded Python 3.13

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


*Contributors*

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

   - !ogidig5 +
   - !partev
   - !vahidmech +
   - !h-vetinari
   - Aaron Meurer
   - Adrin Jalali +
   - Agriya Khetarpal
   - Ajay Kumar Janapareddi +
   - Alex Herbert +
   - Andras Deak
   - Andrej Zhilenkov +
   - Andrew Nelson
   - Anne Gunn +
   - Antony Lee
   - Arnaud Ma +
   - Arun Kannawadi +
   - Arun Pa +
   - Bas van Beek
   - Ben Woodruff +
   - Bruno Oliveira +
   - Carlos Henrique Hermanny Moreira da Silva +
   - Charles Harris
   - Chris Sidebottom
   - Christian Heimes +
   - Christian Lorentzen
   - Christopher Sidebottom
   - Christopher Titchen +
   - Clément Robert
   - Cobalt Yang +
   - Devyani Chavan +
   - Dimitri Papadopoulos Orfanos
   - Ebigide Jude +
   - Eric Xie +
   - Evgeni Burovski
   - Fabian Vogt +
   - Francisco Sousa +
   - GUAN MING +
   - Gabriel Fougeron +
   - Gagandeep Singh
   - Giovanni Del Monte +
   - Gonzalo Tornaría +
   - Gonçalo Bárias +
   - Hugo van Kemenade
   - Jakob Stevens Haas +
   - Jakob Unfried +
   - James Joseph Thomas +
   - Jean Lecordier +
   - Joren Hammudoglu +
   - Joris Van den Bossche
   - Julia Poo +
   - Justus Magin
   - Jyn Spring 琴春
   - KIU Shueng Chuan
   - Karthik Gangula +
   - Karthik Kaiplody +
   - Kevin Sheppard
   - Kristoffer Pedersen +
   - Leo Singer
   - Liang Yan
   - Liangyu Zhang +
   - Lucas Colley
   - Luiz Eduardo Amaral +
   - Lysandros Nikolaou
   - Marcel Loose +
   - Marten van Kerkwijk
   - Mateusz Sokół
   - Matt Haberland
   - Matt Thompson +
   - Matthew Roeschke +
   - Matthew Thompson +
   - Matthias Bussonnier
   - Matti Picus
   - Melissa Weber Mendonça
   - Milica Dančuk +
   - Moritz Schreiber +
   - Nathan Goldbaum
   - Olivier Grisel
   - Patrick J. Roddy +
   - Paul Juma Otieno +
   - Pieter Eendebak
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raquel Braunschweig +
   - Robert Kern
   - Rohit Goswami
   - Romain Geissler +
   - Ross Barnowski
   - Rostan Tabet +
   - Sam Morley +
   - Sayed Adel
   - Sean Cheah
   - Sebastian Berg
   - Serge Guelton
   - Slobodan +
   - Stefan van der Walt
   - Thomas A Caswell
   - Thomas Li
   - Timo Röhling +
   - Tsvika Shapira +
   - Tuhin Sharma +
   - Tyler Reddy
   - Victor Eijkhout +
   - Warren Weckesser
   - Warrick Ball
   - Xiangyi Wang +
   - Yair Chuchem +
   - Yang Liu +
   - Yannik Wicke +
   - Yevhen Amelin +
   - 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] Documentation for the 2.0.0 release.

[Charles R Harris]

Hi All,

Just a note that someone running a version of Python < 3.12 needs to
generate the 2.1.0 release documentation. I can't do it, as Python 12 is my
system Python and somewhere along the way it gets called, even when the
documentation script is run with 3.11, and the build fails because Python
3.12 lacks distutils.

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 Joren Hammudoglu to the NumPy Maintainers Team

[Charles R Harris]

On Mon, Aug 19, 2024 at 4:44 AM Sebastian Berg 
wrote:

> Hi all,
>
> please join me in welcoming Joren (https://github.com/jorenham) to the
> NumPy maintainers team.
>
> Joren has done a lot of work recently contributing, reviewing, and
> maintaining typing related improvements to NumPy.
> We are looking forward to see new momentum to improve NumPy typing.
>
> Thanks for all the contributions!
>
>
Welcome aboard Joren.

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: Documentation for the 2.0.0 release.

[Charles R Harris]

On Mon, Aug 19, 2024 at 2:30 PM matti picus  wrote:

> Done. Thanks for the release.
> Matti
>

Thanks Matti.

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.2 released

[Charles R Harris]

Hi All

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
2.0.2. NumPy 2.0.2 is a maintenance release that fixes bugs and regressions
discovered after the 2.0.1 release. 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 13 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.

   - Bruno Oliveira +
   - Charles Harris
   - Chris Sidebottom
   - Christian Heimes +
   - Christopher Sidebottom
   - Mateusz Sokół
   - Matti Picus
   - Nathan Goldbaum
   - Pieter Eendebak
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Sebastian Berg
   - Yair Chuchem +


*Pull requests merged*

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

   - #27000: REL: Prepare for the NumPy 2.0.1 release [wheel build]
   - #27001: MAINT: prepare 2.0.x for further development
   - #27021: BUG: cfuncs.py: fix crash when sys.stderr is not available
   - #27022: DOC: Fix migration note for ``alltrue`` and ``sometrue``
   - #27061: BUG: use proper input and output descriptor in
   array_assign_subscript...
   - #27073: BUG: Mirror VQSORT_ENABLED logic in Quicksort
   - #27074: BUG: Bump Highway to latest master
   - #27077: BUG: Off by one in memory overlap check
   - #27122: BUG: Use the new ``npyv_loadable_stride_`` functions for ldexp
   and...
   - #27126: BUG: Bump Highway to latest
   - #27128: BUG: add missing error handling in public_dtype_api.c
   - #27129: BUG: fix another cast setup in array_assign_subscript
   - #27130: BUG: Fix building NumPy in FIPS mode
   - #27131: BLD: update vendored Meson for cross-compilation patches
   - #27146: MAINT: Scipy openblas 0.3.27.44.4
   - #27151: BUG: Do not accidentally store dtype metadata in ``np.save``
   - #27195: REV: Revert undef I and document it
   - #27213: BUG: Fix NPY_RAVEL_AXIS on backwards compatible NumPy 2 builds
   - #27279: BUG: Fix array_equal for numeric and non-numeric scalar types


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: Adding `P.coef_natural` property to polynomials

[Charles R Harris]

On Sun, Sep 1, 2024 at 6:48 AM Rakshit Singh 
wrote:

> Best Wishes
>
> I am really hesitant of changing the api, some packages might be dependent
> on it.
>
> Regards
> Rakshit Kr. Singh
>
> On Sun, Sep 1, 2024, 5:54 PM oc-spam66--- via NumPy-Discussion <
> numpy-discussion@python.org> wrote:
>
>> I can summarize the different possibilities/proposals:
>> (A) Create new properties: add a `P.coef_natural` property, with a
>> suitable documentation ; maybe also add a `P.coef_internal` property. There
>> would be no change to the existing code (only addition of properties).
>> (B) Change `P.coef` attribute into a property, with a suitable
>> documentation. Hide `P.coef` attribute into `P._coef` (change existing
>> code). Do not create more properties (unlike A).
>>
>> - About (A), I don't think that adding `P.coef_natural` would add a risk.
>> - About (B), it may be appreciated that the API does not change (does not
>> occupy more namespace)
>> - Both (A) and (B) would help basic users to get out of the `P.coef`
>> attribute confusion.
>>
>> Side remark (not important):
>> > "natural" coefficients make very little if any sense for some of the
>> other polynomial subclasses, such as Chebyshev -- for those, there's
>> nothing natural about them!
>> Are you sure? Can they not be the weights at different order of
>> approximation of a solution?
>> ___
>> 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: rakshitsingh...@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: charlesr.har...@gmail.com


Chebyshev polynomials have two important properties over the interval [-1,
1]:

   1. They are equiripple, consequently the coefficients of high power fits
   are a good approximation of the maximum error if the series is truncated at
   that point, i.e., they provide something close to an min-max fit.
   2.  High power fits are practical because the polynomials are more
   independent (in the L2 norm). The design matrix is generally
   well-conditioned.

Chebyshev polynomials are quite wonderful, but only if the domain of the
data is in the range [-1, 1]. Similar arguments apply to Legendre
polynomials, but in that case the coefficients approximate the L2 error
when the series is truncated and properly normalized. In both cases, the
coefficients are a good guide to the power needed to fit the underlying
data with minimum influence from noise.

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] What should remain on PyPi

[Charles R Harris]

Hi All,

I just got through deleting a bunch of pre-releases on PyPi and it
occurred to me that we should have a policy as to what releases should be
kept. I think that reproducibility requires that we keep all the major and
micro versions, but if so, we should make that an official guarantee.
Perhaps a short NEP? This might even qualify for an SPEC. 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] NumPy 2.1.1 release

[Charles R Harris]

Hi All,

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

This release supports Python 3.10-3.13. 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.

   - Andrew Nelson
   - Charles Harris
   - Mateusz Sokół
   - Maximilian Weigand +
   - Nathan Goldbaum
   - Pieter Eendebak
   - Sebastian Berg



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

   - #27236: REL: Prepare for the NumPy 2.1.0 release [wheel build]
   - #27252: MAINT: prepare 2.1.x for further development
   - #27259: BUG: revert unintended change in the return value of
   set_printoptions
   - #27266: BUG: fix reference counting bug in __array_interface__
   implementation…
   - #27267: TST: Add regression test for missing descr in array-interface
   - #27276: BUG: Fix #27256 and #27257
   - #27278: BUG: Fix array_equal for numeric and non-numeric scalar types
   - #27287: MAINT: Update maintenance/2.1.x after the 2.0.2 release
   - #27303: BLD: cp311- macosx_arm64 wheels [wheel build]
   - #27304: BUG: f2py: better handle filtering of public/private
   subroutines


Cheers,

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] Line lengths for Python file increased to 88 characters

[Charles R Harris]

Hi All,

Just a heads up that the maximum line length for NumPy Python files has
been increased to 88 characters ,
you may want to change some editor settings. This makes us compatible with
Black and other auto-formatters, and seems to be the developing standard.
Increasing line length seems to be a thing 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] Re: What should remain on PyPi

[Charles R Harris]

On Tue, Sep 3, 2024 at 10:46 AM Sean Gillies  wrote:

> Hi Chuck,
>
> I've got a version of a package on PyPI that requires Numpy 2.0.0rc1 at
> build time. Not the best decision in hindsight, but I assumed that Numpy
> was the kind of project that wouldn't remove published distributions unless
> there were security issues. It had not up today, right? Would it be
> possible to restore 2.0.0rc1?
>

No. Once deleted it is always deleted, that is enforced by PyPi. I do plan
to keep the latest rc versions around for a while because some folks may
still be testing against them, but stable releases should not be built
against them. Making that explicit should help avoid problems in the
future. The reason I deleted what I did was to keep our PyPi disk usage
down, it is currently about 30 GB, with an upper limit of 40 GB. We have 52
wheels and one sdist for the 2.,1.1 release, and that will go up when we
start having wheels for WASM and Microsoft arm64. I did delete a bunch
before when we hit the disk limit.

Sorry about that, I should have posted before deleting. HIndsight and all
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

Re: [Numpy-discussion] Fwd: SciPy2017 Sprints FinAid for sprint leaders/core devs

[Charles R Harris]

On Tue, Mar 28, 2017 at 5:16 PM, Nathaniel Smith  wrote:

> In case anyone is interested in helping run a NumPy sprint at SciPy this
> year:
>

I haven't found numpy sprints to be very productive. However, I think it
would be useful if we could have a developers meeting sometime this year.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] __array_ufunc__ counting down to launch, T-24 hrs.

[Charles R Harris]

Hi All,

Just a note that the __array_ufunc__ PR is ready to merge. If you are
interested, you can review here .

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: [numfocus] Grants up to $3k available to NumFOCUS projects (sponsored & affiliated)

[Charles R Harris]

On Fri, Mar 31, 2017 at 8:07 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:

> On 31.03.2017 15:51, Nathaniel Smith wrote:
> > On Mar 31, 2017 1:15 AM, "Ralf Gommers"  > > wrote:
> >
> >
> >
> > On Mon, Mar 27, 2017 at 11:42 PM, Ralf Gommers
> > mailto:ralf.gomm...@gmail.com>> wrote:
> >
> >
> >
> > On Mon, Mar 27, 2017 at 11:33 PM, Julian Taylor
> >  > > wrote:
> >
> > I have two ideas under one big important topic: make numpy
> > python3
> > compatible.
> >
> > The first fits pretty well with the grant size and nobody
> > wants to do it
> > for free:
> > - fix our text IO functions under python3 and support
> multiple
> > encodings, not only latin1.
> > Reasonably simple to do, slap encoding arguments on the
> > functions,
> > generate test cases and somehow keep backward compatibility.
> > Some
> > prelimary unfinished work is in
> > https://github.com/numpy/numpy/pull/4208
> > 
> >
> >
> > I like that idea, it's a recurring pain point. Are you
> > interested to work on it, or are you thinking to advertise the
> > idea here to see if anyone steps up?
> >
> >
> > More thoughts on this anyone? Or preferences for this idea or the
> > numpy.org  one? Submission deadline is April 3rd
> > and we can only put in one proposal this time, so we need to (a)
> > make a choice between these ideas, and (b) write up a proposal.
> >
> > If there's not enough replies to this so the choice is clear cut, I
> > will send out a poll to the core devs.
> >
> >
> > Do we have anyone interested in doing the work in either case? That
> > seems like the most important consideration to me...
> >
> > -n
> >
>
> I could do the textio thing if no one shows up for numpy.org. I can
> probably check again what is required in the next few days and write a
> proposal.
> The change will need reviewing in the end too, should that be
> compensated too? It feels weird if not.
>

Note that we would also like to bring over the text input implementation
from pandas. There was general agreement back when we met in (2015?) that
that would be desirable, but it has never come to pass.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Fwd: SciPy2017 Sprints FinAid for sprint leaders/core devs

[Charles R Harris]

On Fri, Mar 31, 2017 at 12:39 AM, Ralf Gommers 
wrote:

>
>
> On Fri, Mar 31, 2017 at 11:59 AM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
>
>> On Thu, 2017-03-30 at 22:46 +1300, Ralf Gommers wrote:
>> >
>> 
>> >
>> > Agreed, and I would call that productive. Getting even one new
>> > maintainer involved is worth organizing multiple sprints for.
>> >
>> > That said, also +1 to a developer meeting this year. It'd be good if
>> > we could combine it with the NumFOCUS summit or a relevant conference
>> > in the second half of the year.
>>
>> Would be good, even if there is nothing big going on.
>>
>> Can we gather possible dates and possible (personal) preferences? Here
>> is a start:
>>
>> * SciPy (Austin, TX): July 10-16
>> * EuroScipy (Germany): August 23-27
>> * NumFocus Summit?
>>
>
> Austin, October (exact date TBD). I intend to plan a longer trip to the US
> around this summit, and I think at least one other core dev should go
> there. So this one has my preference.
>
>
>> * PyData Events??
>>
>
> Sticking to the ones in the second half of the year and in the US or
> Western Europe:
>
> PyData Berlin, June 30 - July 2
> PyData Seattle July 5 -7
>
> Other options:
>
> JupyterCon, New York, August 22-25
> Strata Data Conference, September 25-28
>
>
>>
>> Personally, I probably can't make longer trips until some time in July.
>>  time around then).
>
>
> Same here.
>

I'm flexible, anytime that works for others will probably work for me.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] __array_ufunc__

[Charles R Harris]

Hi All,

After a week of review and rework, the new and improved __array_ufunc__ has
turned the corner and is headed down the homestretch. Now is the time for
interested parties to give it a final lookover at
https://github.com/numpy/numpy/pull/8247.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Long term plans for dropping Python 2.7

[Charles R Harris]

Hi All,

It may be early to discuss dropping support for Python 2.7, but there is a
disturbance in the force that suggests that it might be worth looking
forward to the year 2020 when Python itself will drop support for 2.7.
There is also a website, http://www.python3statement.org, where several
projects in the scientific python stack have pledged to be Python 2.7 free
by that date.  Given that, a preliminary discussion of the subject might be
interesting, if only to gather information of where the community currently
stands.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Long term plans for dropping Python 2.7

[Charles R Harris]

On Fri, Apr 14, 2017 at 11:47 PM, Ralf Gommers 
wrote:

>
>
> On Sat, Apr 15, 2017 at 5:19 PM, Nathaniel Smith  wrote:
>
>> On Fri, Apr 14, 2017 at 5:19 PM, Charles R Harris
>>  wrote:
>> > Hi All,
>> >
>> > It may be early to discuss dropping support for Python 2.7, but there
>> is a
>> > disturbance in the force that suggests that it might be worth looking
>> > forward to the year 2020 when Python itself will drop support for 2.7.
>> There
>> > is also a website, http://www.python3statement.org, where several
>> projects
>> > in the scientific python stack have pledged to be Python 2.7 free by
>> that
>> > date.  Given that, a preliminary discussion of the subject might be
>> > interesting, if only to gather information of where the community
>> currently
>> > stands.
>>
>> One reasonable position would that numpy releases that happen while
>> 2.7 is supported upstream will also support 2.7, and releases after
>> that won't.
>>
>> From numpy's perspective, I feel like the most important reason to
>> continue supporting 2.7 is our ability to convince people to keep
>> upgrading. (Not the only reason, but the most important.) What I mean
>> is: if we dropped 2.7 support tomorrow then it wouldn't actually make
>> numpy unavailable on python 2.7; it would just mean that lots of users
>> stayed at 1.12 indefinitely. Which is awkward, but it wouldn't be the
>> end of the world – numpy is mature software and 1.12 works pretty
>> well. The big problem IMO would be if this then meant that lots of
>> downstream projects felt that they had to continue supporting 1.12
>> going forward, which makes it very difficult for us to effectively
>> ship new features or even bug fixes – I mean, we can ship them, but
>> no-one will use them. And if a downstream project finds a bug in numpy
>> and can't upgrade numpy, then the tendency is to work around it
>> instead of reporting it upstream. I think this is the main thing we
>> want to avoid.
>>
>
> +1
>
>
>>
>> This kind of means that we're at the mercy of downstream projects,
>> though – if scipy/pandas/etc. decide they want to support 2.7 until
>> 2022, it might be in our best interest to do the same. But there's a
>> collective action problem here: we want to keep supporting 2.7 so long
>> as they do, but at the same time they may feel they need to keep
>> supporting 2.7 as long as we do. And all of us would prefer to drop
>> 2.7 support sooner rather than later, but we might all get stuck
>>
> because we're waiting for someone else to move first.
>>
>
> I don't quite agree about being stuck. These kind of upgrades should and
> usually do go top of stack to bottom. Something like Jupyter which is
> mostly an end user tool goes first (they announced 2020 quite a while ago),
> domain specific packages go at a similar time, then scipy & co, and only
> after that numpy. Cython will be even later I'm sure - it still supports
> Python 2.6.
>
>
>>
>> So my suggestion would be that numpy make some official announcement
>> that our plan is to drop support for python 2 immediately after
>> cpython upstream does.
>
>
> Not quite sure CPython schedule is relevant - important bug fixes haven't
> been making it into 2.7 for a very long time now, so the only change is the
> rare security patch.
>
>
>> If worst comes to worst we can always decide to
>> extend it at the time... but if we make the announcement now, then
>> it's less likely that we'll need to :-).
>>
>
> I'd be in favor of putting out a schedule in coordination with
> scipy/pandas/etc, but it probably should look more like
> - 2020: what's on http://www.python3statement.org/ now
> - 2021: scipy / pandas / scikit-learn / etc.
> - 2022: numpy
>
>

I think things will move faster than one might think. In any case, we are
probably about 5 releases away from 2020. As Nathaniel points out, numpy is
mature and 1.12 is pretty good already, so hopefully 1.17 would be even
better. I think dropping Python 2.7 support at that point would not cause
much in the way of problems as 1.17 should be good for a number of years
after that and would be easily installed from PyPI.

A bigger driver long term might be uptake by distros, although the impact
of that might be harder to estimate. I suspect it will affect developers
more than end users, who will more likely be using Anaconda, Canopy, or
similar to manage their development environment.

Another thing to consider is that future developers will likely have

[Numpy-discussion] Relaxed stride checking fixup

[Charles R Harris]

Hi All,

Currently numpy master has a bogus stride that will cause an error when
downstream projects misuse it. That is done in order to help smoke out
errors. Previously that bogus stride has been fixed up for releases, but
that requires a special patch to be applied after each version branch is
made. At this point I'd like to pick one or the other option and make the
development and release branches the same in this regard. The question is:
which option to choose? Keeping the fixup in master will remove some code
and keep things simple, while not fixing up the release will possibly lead
to more folks finding errors. At this point in time I am favoring applying
the fixup in master.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Relaxed stride checking fixup

[Charles R Harris]

On Thu, Apr 20, 2017 at 4:21 AM, Ralf Gommers 
wrote:

>
>
> On Thu, Apr 20, 2017 at 6:28 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> Currently numpy master has a bogus stride that will cause an error when
>> downstream projects misuse it. That is done in order to help smoke out
>> errors. Previously that bogus stride has been fixed up for releases, but
>> that requires a special patch to be applied after each version branch is
>> made. At this point I'd like to pick one or the other option and make the
>> development and release branches the same in this regard. The question is:
>> which option to choose? Keeping the fixup in master will remove some code
>> and keep things simple, while not fixing up the release will possibly lead
>> to more folks finding errors. At this point in time I am favoring applying
>> the fixup in master.
>>
>> Thoughts?
>>
>
> If we have to pick then keeping the fixup sounds reasonable. Would there
> be value in making the behavior configurable at compile time? If there are
> more such things and they'd be behind a __NUMPY_DEBUG__ switch, then people
> may want to test that in their own CI.
>

Interesting thought. I wonder what else might be a good candidate for such
a switch?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Thu, Apr 20, 2017 at 12:53 PM, Robert Kern  wrote:

> On Thu, Apr 20, 2017 at 6:15 AM, Julian Taylor <
> jtaylor.deb...@googlemail.com> wrote:
>
> > Do you have comments on how to go forward, in particular in regards to
> > new dtype vs modify np.unicode?
>
> Can we restate the use cases explicitly? I feel like we ended up with the
> current sub-optimal situation because we never really laid out the use
> cases. We just felt like we needed bytestring and unicode dtypes, more out
> of completionism than anything, and we made a bunch of assumptions just to
> get each one done. I think there may be broad agreement that many of those
> assumptions are "wrong", but it would be good to reference that against
> concretely-stated use cases.
>
> FWIW, if I need to work with in-memory arrays of strings in Python code,
> I'm going to use dtype=object a la pandas. It has almost no arbitrary
> constraints, and I can rely on Python's unicode facilities freely. There
> may be some cases where it's a little less memory-efficient (e.g.
> representing a column of enumerated single-character values like 'M'/'F'),
> but that's never prevented me from doing anything (compare to the
> uniform-length restrictions, which *have* prevented me from doing things).
>
> So what's left? Being able to memory-map to files that have string data
> conveniently laid out according to numpy assumptions (e.g. FITS). Being
> able to work with C/C++/Fortran APIs that have arrays of strings laid out
> according to numpy assumptions (e.g. HDF5). I think it would behoove us to
> canvass the needs of these formats and APIs before making any more
> assumptions.
>
> For example, to my understanding, FITS files more or less follow numpy
> assumptions for its string columns (i.e. uniform-length). But it enforces
> 7-bit-clean ASCII and pads with terminating NULLs; I believe this was the
> singular motivating use case for the trailing-NULL behavior of np.string.
>
> I don't know of a format off-hand that works with numpy uniform-length
> strings and Unicode as well. HDF5 (to my recollection) supports arrays of
> NULL-terminated, uniform-length ASCII like FITS, but only variable-length
> UTF8 strings.
>
> We should look at some of the newer formats and APIs, like Parquet and
> Arrow, and also consider the cross-language APIs with Julia and R.
>
> If I had to jump ahead and propose new dtypes, I might suggest this:
>
> * For the most part, treat the string dtypes as temporary communication
> formats rather than the preferred in-memory working format, similar to how
> we use `float16` to communicate with GPU APIs.
>
> * Acknowledge the use cases of the current NULL-terminated np.string
> dtype, but perhaps add a new canonical alias, document it as being for
> those specific use cases, and deprecate/de-emphasize the current name.
>
> * Add a dtype for holding uniform-length `bytes` strings. This would be
> similar to the current `void` dtype, but work more transparently with the
> `bytes` type, perhaps with the scalar type multiply-inheriting from `bytes`
> like `float64` does with `float`. This would not be NULL-terminated. No
> encoding would be implied.
>
> * Maybe add a dtype similar to `object_` that only permits `unicode/str`
> (2.x/3.x) strings (and maybe None to represent missing data a la pandas).
> This maintains all of the flexibility of using a `dtype=object` array while
> allowing code to specialize for working with strings without all kinds of
> checking on every item. But most importantly, we can serialize such an
> array to bytes without having to use pickle. Utility functions could be
> written for en-/decoding to/from the uniform-length bytestring arrays
> handling different encodings and things like NULL-termination (also working
> with the legacy dtypes and handling structured arrays easily, etc.).
>
>
A little history, IIRC, storing null terminated strings in fixed byte
lengths was done in Fortran, strings were  usually stored in
integers/integer_arrays.

If memory mapping of arbitrary types is not important, I'd settle for ascii
or latin-1, utf-8 fixed byte length, and arrays of fixed python object
type. Using one byte encodings and utf-8 avoids needing to deal with
endianess.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] __array_ufunc__ final review

[Charles R Harris]

Hi All,

The __array_ufunc__  PR is ready
for final review. If there are no complaints, I plan to put it in tomorrow.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Tue, Apr 25, 2017 at 11:34 AM, Anne Archibald 
wrote:

>
> On Tue, Apr 25, 2017 at 7:09 PM Robert Kern  wrote:
>
>> * HDF5 supports fixed-length and variable-length string arrays encoded in
>> ASCII and UTF-8. In all cases, these strings are NULL-terminated (despite
>> the documentation claiming that there are more options). In practice, the
>> ASCII strings permit high-bit characters, but the encoding is unspecified.
>> Memory-mapping is rare (but apparently possible). The two major HDF5
>> bindings are waiting for a fixed-length UTF-8 numpy dtype to support that
>> HDF5 option. Compression is supported for fixed-length string arrays but
>> not variable-length string arrays.
>>
>> * FITS supports fixed-length string arrays that are NULL-padded. The
>> strings do not have a formal encoding, but in practice, they are typically
>> mostly ASCII characters with the occasional high-bit character from an
>> unspecific encoding. Memory-mapping is a common practice. These arrays can
>> be quite large even if each scalar is reasonably small.
>>
>> * pandas uses object arrays for flexible in-memory handling of string
>> columns. Lengths are not fixed, and None is used as a marker for missing
>> data. String columns must be written to and read from a variety of formats,
>> including CSV, Excel, and HDF5, some of which are Unicode-aware and work
>> with `unicode/str` objects instead of `bytes`.
>>
>> * There are a number of sometimes-poorly-documented,
>> often-poorly-adhered-to, aging file format "standards" that include string
>> arrays but do not specify encodings, or such specification is ignored in
>> practice. This can make the usual "Unicode sandwich" at the I/O boundaries
>> difficult to perform.
>>
>> * In Python 3 environments, `unicode/str` objects are rather more common,
>> and simple operations like equality comparisons no longer work between
>> `bytes` and `unicode/str`, making it difficult to work with numpy string
>> arrays that yield `bytes` scalars.
>>
>
> It seems the greatest challenge is interacting with binary data from other
> programs and libraries. If we were living entirely in our own data world,
> Unicode strings in object arrays would generally be pretty satisfactory. So
> let's try to get what is needed to read and write other people's formats.
>
> I'll note that this is numpy, so variable-width fields (e.g. CSV) don't
> map directly to numpy arrays; we can store it however we want, as
> conversion is necessary anyway.
>
> Clearly there is a need for fixed-storage-size zero-padded UTF-8; two
> other packages are waiting specifically for it. But specifying this
> requires two pieces of information: What is the encoding? and How is the
> length specified? I know they're not numpy-compatible, but FITS header
> values are space-padded; does that occur elsewhere? Are there other ways
> existing data specifies string length within a fixed-size field? There are
> some cryptographic length-specification tricks - ANSI X.293, ISO 10126,
> PKCS7, etc. - but they are probably too specialized to need? We should make
> sure we can support all the ways that actually occur.
>

Agree with the UTF-8 fixed byte length strings, although I would tend
towards null terminated.

For  byte strings, it looks like we need a parameterized type. This is for
two uses, display and conversion to (Python) unicode. One could handle the
display and conversion using view and astype methods. For instance, we
already have

In [1]: a = array([1,2,3], uint8) + 0x30

In [2]: a.view('S1')
Out[2]:
array(['1', '2', '3'],
  dtype='|S1')

In [3]: a.view('S1').astype('U')
Out[3]:
array([u'1', u'2', u'3'],
  dtype='___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Tue, Apr 25, 2017 at 12:52 PM, Robert Kern  wrote:

> On Tue, Apr 25, 2017 at 11:18 AM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
> >
> > On Tue, Apr 25, 2017 at 11:34 AM, Anne Archibald <
> peridot.face...@gmail.com> wrote:
>
> >> Clearly there is a need for fixed-storage-size zero-padded UTF-8; two
> other packages are waiting specifically for it. But specifying this
> requires two pieces of information: What is the encoding? and How is the
> length specified? I know they're not numpy-compatible, but FITS header
> values are space-padded; does that occur elsewhere? Are there other ways
> existing data specifies string length within a fixed-size field? There are
> some cryptographic length-specification tricks - ANSI X.293, ISO 10126,
> PKCS7, etc. - but they are probably too specialized to need? We should make
> sure we can support all the ways that actually occur.
> >
> >
> > Agree with the UTF-8 fixed byte length strings, although I would tend
> towards null terminated.
>
> Just to clarify some terminology (because it wasn't originally clear to me
> until I looked it up in reference to HDF5):
>
> * "NULL-padded" implies that, for a fixed width of N, there can be up to N
> non-NULL bytes. Any extra space left over is padded with NULLs, but no
> space needs to be reserved for NULLs.
>
> * "NULL-terminated" implies that, for a fixed width of N, there can be up
> to N-1 non-NULL bytes. There must always be space reserved for the
> terminating NULL.
>
> I'm not really sure if "NULL-padded" also specifies the behavior for
> embedded NULLs. It's certainly possible to deal with them: just strip
> trailing NULLs and leave any embedded ones alone. But I'm also sure that
> there are some implementations somewhere that interpret the requirement as
> "stop at the first NULL or the end of the fixed width, whichever comes
> first", effectively being NULL-terminated just not requiring the reserved
> space.
>

Thanks for the clarification. NULL-padded is what I meant.

I'm wondering how much of the desired functionality we could get by simply
subclassing ndarray in python. I think we mostly want to be able to view
byte strings and convert to unicode if needed.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Tue, Apr 25, 2017 at 1:30 PM, Charles R Harris  wrote:

>
>
> On Tue, Apr 25, 2017 at 12:52 PM, Robert Kern 
> wrote:
>
>> On Tue, Apr 25, 2017 at 11:18 AM, Charles R Harris <
>> charlesr.har...@gmail.com> wrote:
>> >
>> > On Tue, Apr 25, 2017 at 11:34 AM, Anne Archibald <
>> peridot.face...@gmail.com> wrote:
>>
>> >> Clearly there is a need for fixed-storage-size zero-padded UTF-8; two
>> other packages are waiting specifically for it. But specifying this
>> requires two pieces of information: What is the encoding? and How is the
>> length specified? I know they're not numpy-compatible, but FITS header
>> values are space-padded; does that occur elsewhere? Are there other ways
>> existing data specifies string length within a fixed-size field? There are
>> some cryptographic length-specification tricks - ANSI X.293, ISO 10126,
>> PKCS7, etc. - but they are probably too specialized to need? We should make
>> sure we can support all the ways that actually occur.
>> >
>> >
>> > Agree with the UTF-8 fixed byte length strings, although I would tend
>> towards null terminated.
>>
>> Just to clarify some terminology (because it wasn't originally clear to
>> me until I looked it up in reference to HDF5):
>>
>> * "NULL-padded" implies that, for a fixed width of N, there can be up to
>> N non-NULL bytes. Any extra space left over is padded with NULLs, but no
>> space needs to be reserved for NULLs.
>>
>> * "NULL-terminated" implies that, for a fixed width of N, there can be up
>> to N-1 non-NULL bytes. There must always be space reserved for the
>> terminating NULL.
>>
>> I'm not really sure if "NULL-padded" also specifies the behavior for
>> embedded NULLs. It's certainly possible to deal with them: just strip
>> trailing NULLs and leave any embedded ones alone. But I'm also sure that
>> there are some implementations somewhere that interpret the requirement as
>> "stop at the first NULL or the end of the fixed width, whichever comes
>> first", effectively being NULL-terminated just not requiring the reserved
>> space.
>>
>
> Thanks for the clarification. NULL-padded is what I meant.
>
> I'm wondering how much of the desired functionality we could get by simply
> subclassing ndarray in python. I think we mostly want to be able to view
> byte strings and convert to unicode if needed.
>
>
And I think the really tricky part is sorting and rich comparison.
Unfortunately, the comparison function is currently located in the c
structure. I suppose we could define a c wrapper function to go in the slot.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Tue, Apr 25, 2017 at 5:50 PM, Robert Kern  wrote:

> On Tue, Apr 25, 2017 at 3:47 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
> >> Presumably you're getting byte strings (with  unknown encoding.
> >
> > No -- thus is for creating and using mostly ascii string data with
> python and numpy.
> >
> > Unknown encoding bytes belong in byte arrays -- they are not text.
>
> You are welcome to try to convince Thomas of that. That is the status quo
> for him, but he is finding that difficult to work with.
>
> > I DO recommend Latin-1 As a default encoding ONLY for  "mostly ascii,
> with a few extra characters" data. With all the sloppiness over the years,
> there are way to many files like that.
>
> That sloppiness that you mention is precisely the "unknown encoding"
> problem. Your previous advocacy has also touched on using latin-1 to decode
> existing files with unknown encodings as well. If you want to advocate for
> using latin-1 only for the creation of new data, maybe stop talking about
> existing files? :-)
>
> > Note: the primary use-case I have in mind is working with ascii text in
> numpy arrays efficiently-- folks have called for that. All I'm saying is
> use Latin-1 instead of ascii -- that buys you some useful extra characters.
>
> For that use case, the alternative in play isn't ASCII, it's UTF-8, which
> buys you a whole bunch of useful extra characters. ;-)
>
> There are several use cases being brought forth here. Some involve file
> reading, some involve file writing, and some involve in-memory
> manipulation. Whatever change we make is going to impinge somehow on all of
> the use cases. If all we do is add a latin-1 dtype for people to use to
> create new in-memory data, then someone is going to use it to read existing
> data in unknown or ambiguous encodings.
>


The maximum length of an UTF-8 character is 4 bytes, so we could use that
to size arrays by character length. The advantage over UTF-32 is that it is
easily compressible, probably by a factor of 4 in many cases. That doesn't
solve the in memory problem, but does have some advantages on disk as well
as making for easy display. We could compress it ourselves after encoding
by truncation.

Note that for terminal display we will want something supported by the
system, which is another problem altogether. Let me break the problem down
into four categories


   1. Storage -- hdf5, .npy, fits, etc.
   2. Display -- ?
   3. Modification -- editing
   4. Parsing -- fits, etc.

There is probably no one solution that is optimal for all of those.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] proposal: smaller representation of string arrays

[Charles R Harris]

On Wed, Apr 26, 2017 at 3:15 AM, Julian Taylor <
jtaylor.deb...@googlemail.com> wrote:

> On 26.04.2017 03:55, josef.p...@gmail.com wrote:
> > On Tue, Apr 25, 2017 at 9:27 PM, Charles R Harris
> >  wrote:
> >>
> >>
> >> On Tue, Apr 25, 2017 at 5:50 PM, Robert Kern 
> wrote:
> >>>
> >>> On Tue, Apr 25, 2017 at 3:47 PM, Chris Barker - NOAA Federal
> >>>  wrote:
> >>>
> >>>>> Presumably you're getting byte strings (with  unknown encoding.
> >>>>
> >>>> No -- thus is for creating and using mostly ascii string data with
> >>>> python and numpy.
> >>>>
> >>>> Unknown encoding bytes belong in byte arrays -- they are not text.
> >>>
> >>> You are welcome to try to convince Thomas of that. That is the status
> quo
> >>> for him, but he is finding that difficult to work with.
> >>>
> >>>> I DO recommend Latin-1 As a default encoding ONLY for  "mostly ascii,
> >>>> with a few extra characters" data. With all the sloppiness over the
> years,
> >>>> there are way to many files like that.
> >>>
> >>> That sloppiness that you mention is precisely the "unknown encoding"
> >>> problem. Your previous advocacy has also touched on using latin-1 to
> decode
> >>> existing files with unknown encodings as well. If you want to advocate
> for
> >>> using latin-1 only for the creation of new data, maybe stop talking
> about
> >>> existing files? :-)
> >>>
> >>>> Note: the primary use-case I have in mind is working with ascii text
> in
> >>>> numpy arrays efficiently-- folks have called for that. All I'm saying
> is use
> >>>> Latin-1 instead of ascii -- that buys you some useful extra
> characters.
> >>>
> >>> For that use case, the alternative in play isn't ASCII, it's UTF-8,
> which
> >>> buys you a whole bunch of useful extra characters. ;-)
> >>>
> >>> There are several use cases being brought forth here. Some involve file
> >>> reading, some involve file writing, and some involve in-memory
> manipulation.
> >>> Whatever change we make is going to impinge somehow on all of the use
> cases.
> >>> If all we do is add a latin-1 dtype for people to use to create new
> >>> in-memory data, then someone is going to use it to read existing data
> in
> >>> unknown or ambiguous encodings.
> >>
> >>
> >>
> >> The maximum length of an UTF-8 character is 4 bytes, so we could use
> that to
> >> size arrays by character length. The advantage over UTF-32 is that it is
> >> easily compressible, probably by a factor of 4 in many cases. That
> doesn't
> >> solve the in memory problem, but does have some advantages on disk as
> well
> >> as making for easy display. We could compress it ourselves after
> encoding by
> >> truncation.
> >>
> >> Note that for terminal display we will want something supported by the
> >> system, which is another problem altogether. Let me break the problem
> down
> >> into four categories
> >>
> >> Storage -- hdf5, .npy, fits, etc.
> >> Display -- ?
> >> Modification -- editing
> >> Parsing -- fits, etc.
> >>
> >> There is probably no one solution that is optimal for all of those.
> >>
> >> Chuck
> >>
> >>
> >>
> >> ___
> >> NumPy-Discussion mailing list
> >> NumPy-Discussion@python.org
> >> https://mail.python.org/mailman/listinfo/numpy-discussion
> >>
> >
> >
> > quoting Julian
> >
> > '''
> > I probably have formulated my goal with the proposal a bit better, I am
> > not very interested in a repetition of which encoding to use debate.
> > In the end what will be done allows any encoding via a dtype with
> > metadata like datetime.
> > This allows any codec (including truncated utf8) to be added easily (if
> > python supports it) and allows sidestepping the debate.
> >
> > My main concern is whether it should be a new dtype or modifying the
> > unicode dtype. Though the backward compatibility argument is strongly in
> > favour of adding a new dtype that makes the np.unicode type redundant.
> > '''
> >
> > I don't quite understand why this discussion

[Numpy-discussion] Ready to branch 1.13

[Charles R Harris]

Hi All,

I am getting ready to branch 1.13 after updating the release notes and
.mailmap. If there is something that you think is essential to get into
1.13 that is not there, comment.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Numpy 1.13.x branched

[Charles R Harris]

Hi All,

Just a quck note that 1.13.x has been branched and master is open for
1.14.0 development.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy v1.13.0rc1 released.

[Charles R Harris]

Hi All,

I'm please to announce the NumPy 1.13.0rc1 release. This release supports
Python 2.7 and 3.4-3.6 and contains many new features. It is one of the
most ambitious releases in the last several years. Some of the highlights
and new functions are

*Highlights*

   - Operations like ``a + b + c`` will reuse temporaries on some
   platforms, resulting in less memory use and faster execution.
   - Inplace operations check if inputs overlap outputs and create
   temporaries to avoid problems.
   - New __array_ufunc__ attribute provides improved ability for classes to
   override default ufunc behavior.
   -  New np.block function for creating blocked arrays.


*New functions*

   - New ``np.positive`` ufunc.
   - New ``np.divmod`` ufunc provides more efficient divmod.
   - New ``np.isnat`` ufunc tests for NaT special values.
   - New ``np.heaviside`` ufunc computes the Heaviside function.
   - New ``np.isin`` function, improves on ``in1d``.
   - New ``np.block`` function for creating blocked arrays.
   - New ``PyArray_MapIterArrayCopyIfOverlap`` added to NumPy C-API.

Wheels for the pre-release are available on PyPI. Source tarballs,
zipfiles, release notes, and the Changelog are available on github
.

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

   - A. Jesse Jiryu Davis +
   - Alessandro Pietro Bardelli +
   - Alex Rothberg +
   - Alexander Shadchin
   - Allan Haldane
   - Andres Guzman-Ballen +
   - Antoine Pitrou
   - Antony Lee
   - B R S Recht +
   - Baurzhan Muftakhidinov +
   - Ben Rowland
   - Benda Xu +
   - Blake Griffith
   - Bradley Wogsland +
   - Brandon Carter +
   - CJ Carey
   - Charles Harris
   - Danny Hermes +
   - Duke Vijitbenjaronk +
   - Egor Klenin +
   - Elliott Forney +
   - Elliott M Forney +
   - Endolith
   - Eric Wieser
   - Erik M. Bray
   - Eugene +
   - Evan Limanto +
   - Felix Berkenkamp +
   - François Bissey +
   - Frederic Bastien
   - Greg Young
   - Gregory R. Lee
   - Importance of Being Ernest +
   - Jaime Fernandez
   - Jakub Wilk +
   - James Cowgill +
   - James Sanders
   - Jean Utke +
   - Jesse Thoren +
   - Jim Crist +
   - Joerg Behrmann +
   - John Kirkham
   - Jonathan Helmus
   - Jonathan L Long
   - Jonathan Tammo Siebert +
   - Joseph Fox-Rabinovitz
   - Joshua Loyal +
   - Juan Nunez-Iglesias +
   - Julian Taylor
   - Kirill Balunov +
   - Likhith Chitneni +
   - Loïc Estève
   - Mads Ohm Larsen
   - Marein Könings +
   - Marten van Kerkwijk
   - Martin Thoma
   - Martino Sorbaro +
   - Marvin Schmidt +
   - Matthew Brett
   - Matthias Bussonnier +
   - Matthias C. M. Troffaes +
   - Matti Picus
   - Michael Seifert
   - Mikhail Pak +
   - Mortada Mehyar
   - Nathaniel J. Smith
   - Nick Papior
   - Oscar Villellas +
   - Pauli Virtanen
   - Pavel Potocek
   - Pete Peeradej Tanruangporn +
   - Philipp A +
   - Ralf Gommers
   - Robert Kern
   - Roland Kaufmann +
   - Ronan Lamy
   - Sami Salonen +
   - Sanchez Gonzalez Alvaro
   - Sebastian Berg
   - Shota Kawabuchi
   - Simon Gibbons
   - Stefan Otte
   - Stefan Peterson +
   - Stephan Hoyer
   - Søren Fuglede Jørgensen +
   - Takuya Akiba
   - Tom Boyd +
   - Ville Skyttä +
   - Warren Weckesser
   - Wendell Smith
   - Yu Feng
   - Zixu Zhao +
   - Zè Vinícius +
   - aha66 +
   - davidjn +
   - drabach +
   - drlvk +
   - jsh9 +
   - solarjoe +
   - zengi +

Cheers,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] UC Berkeley hiring developers to work on NumPy

[Charles R Harris]

On Sat, May 13, 2017 at 11:45 PM, Nathaniel Smith  wrote:

> Hi all,
>
> As some of you know, I've been working for... quite some time now to
> try to secure funding for NumPy. So I'm excited that I can now
> officially announce that BIDS [1] is planning to hire several folks
> specifically to work on NumPy. These will full time positions at UC
> Berkeley, postdoc or staff, with probably 2 year (initial) contracts,
> and the general goal will be to work on some of the major priorities
> we identified at the last dev meeting: more flexible dtypes, better
> interoperation with other array libraries, paying down technical debt,
> and so forth. Though I'm sure the details will change as we start to
> dig into things and engage with the community.
>
> More details soon; universities move slowly, so nothing's going to
> happen immediately. But this is definitely happening and I wanted to
> get something out publicly before the conference season starts – so if
> you're someone who might be interested in coming to work with me and
> the other awesome folks at BIDS, then this is a heads-up: drop me a
> line and we can chat! I'll be at PyCon next week if anyone happens to
> be there. And feel free to spread the word.
>

Excellent news. Do you have any sort of timeline in mind?

It will be interesting to see what changes this leads to, both in the code
and in the project sociology.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.13.0rc2 released

[Charles R Harris]

Hi All,

I'm pleased to announce the NumPy 1.13.0rc2 release. This release supports
Python 2.7 and 3.4-3.6 and contains many new features. It is one of the
most ambitious releases in the last several years. Some of the highlights
and new functions are

*Highlights*

   - Operations like ``a + b + c`` will reuse temporaries on some
   platforms, resulting in less memory use and faster execution.
   - Inplace operations check if inputs overlap outputs and create
   temporaries to avoid problems.
   - New __array_ufunc__ attribute provides improved ability for classes to
   override default ufunc behavior.
   - New np.block function for creating blocked arrays.


*New functions*

   - New ``np.positive`` ufunc.
   - New ``np.divmod`` ufunc provides more efficient divmod.
   - New ``np.isnat`` ufunc tests for NaT special values.
   - New ``np.heaviside`` ufunc computes the Heaviside function.
   - New ``np.isin`` function, improves on ``in1d``.
   - New ``np.block`` function for creating blocked arrays.
   - New ``PyArray_MapIterArrayCopyIfOverlap`` added to NumPy C-API.

Wheels for the pre-release are available on PyPI. Source tarballs,
zipfiles, release notes, and the changelog are available on github
.

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

   - A. Jesse Jiryu Davis +
   - Alessandro Pietro Bardelli +
   - Alex Rothberg +
   - Alexander Shadchin
   - Allan Haldane
   - Andres Guzman-Ballen +
   - Antoine Pitrou
   - Antony Lee
   - B R S Recht +
   - Baurzhan Muftakhidinov +
   - Ben Rowland
   - Benda Xu +
   - Blake Griffith
   - Bradley Wogsland +
   - Brandon Carter +
   - CJ Carey
   - Charles Harris
   - Christoph Gohlke
   - Danny Hermes +
   - David Hagen +
   - David Nicholson +
   - Duke Vijitbenjaronk +
   - Egor Klenin +
   - Elliott Forney +
   - Elliott M Forney +
   - Endolith
   - Eric Wieser
   - Erik M. Bray
   - Eugene +
   - Evan Limanto +
   - Felix Berkenkamp +
   - François Bissey +
   - Frederic Bastien
   - Greg Young
   - Gregory R. Lee
   - Importance of Being Ernest +
   - Jaime Fernandez
   - Jakub Wilk +
   - James Cowgill +
   - James Sanders
   - Jean Utke +
   - Jesse Thoren +
   - Jim Crist +
   - Joerg Behrmann +
   - John Kirkham
   - Jonathan Helmus
   - Jonathan L Long
   - Jonathan Tammo Siebert +
   - Joseph Fox-Rabinovitz
   - Joshua Loyal +
   - Juan Nunez-Iglesias +
   - Julian Taylor
   - Kirill Balunov +
   - Likhith Chitneni +
   - Loïc Estève
   - Mads Ohm Larsen
   - Marein Könings +
   - Marten van Kerkwijk
   - Martin Thoma
   - Martino Sorbaro +
   - Marvin Schmidt +
   - Matthew Brett
   - Matthias Bussonnier +
   - Matthias C. M. Troffaes +
   - Matti Picus
   - Michael Seifert
   - Mikhail Pak +
   - Mortada Mehyar
   - Nathaniel J. Smith
   - Nick Papior
   - Oscar Villellas +
   - Pauli Virtanen
   - Pavel Potocek
   - Pete Peeradej Tanruangporn +
   - Philipp A +
   - Ralf Gommers
   - Robert Kern
   - Roland Kaufmann +
   - Ronan Lamy
   - Sami Salonen +
   - Sanchez Gonzalez Alvaro
   - Sebastian Berg
   - Shota Kawabuchi
   - Simon Gibbons
   - Stefan Otte
   - Stefan Peterson +
   - Stephan Hoyer
   - Søren Fuglede Jørgensen +
   - Takuya Akiba
   - Tom Boyd +
   - Ville Skyttä +
   - Warren Weckesser
   - Wendell Smith
   - Yu Feng
   - Zixu Zhao +
   - Zè Vinícius +
   - aha66 +
   - drabach +
   - drlvk +
   - jsh9 +
   - solarjoe +
   - zengi +

Cheers,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] SciPy 2017 attendence

[Charles R Harris]

Hi All,

Just curious as to who may be attending SciPy 2017.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Future of ufuncs

[Charles R Harris]

Hi All,

This post is to open a discussion of the future of ufuncs. There are two
contradictory ideas that have floated about regarding ufuncs evolution. One
is to generalize ufuncs to operate on buffers, essentially separating them
from their current entanglement with ndarrays. The other is to accept that
they are fundamentally part of the ndarray universe and move them into the
multiarray module, thus avoiding the odd overloading of functions in the
multiarray module. The first has been a long time proposal that I once
thought sounded good, but I've come to prefer the second. That change of
mind was driven by the resulting code simplification and the removal of a
dependence on a Python feature, buffers, that we cannot easily modify to
adapt to changing needs and new dtypes. Because I'd like to move the
ufuncs, if we decide to move them, sometime after NumPy 1.14 is released,
now seems a good time to decide the issue.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Future of ufuncs

[Charles R Harris]

On Mon, May 29, 2017 at 12:32 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:

> Hi Chuck,
>
> Like Sebastian, I wonder a little about what level you are talking
> about. Presumably, it is the actual implementation of the ufunc? I.e.,
> this is not about the upper logic that decides which `__array_ufunc__`
> to call, etc.
>
> If so, I agree with you that it would seem to make most sense to move
> the implementation to `multiarray`; the current structure certainly is
> a major hurdle to understanding how things work!
>
> Indeed, I guess in terms of my earlier suggestion to make much of a
> ufunc happen in `ndarray.__array_ufunc__`, one could seem the type
> resolution and iteration happening there. If one were to expose the
> inner loops, anyone working with buffers could then use the ufuncs by
> defining their own __array_ufunc__.
>

The idea of separating ufuncs from ndarray was put forward many years ago,
maybe five or six. What I seek here is a record that we have given up on
that ambition, so do not need to take it into consideration in the future.
In particular, we can feel free to couple ufuncs even more tightly with
ndarray.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.13.0 release

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I amn pleased to announce the NumPy 1.13.0
release. This release supports Python 2.7 and 3.4-3.6 and contains many new
features. It is one of the most ambitious releases in the last several
years. Some of the highlights and new functions are

*Highlights*

   - Operations like ``a + b + c`` will reuse temporaries on some
   platforms, resulting in less memory use and faster execution.
   - Inplace operations check if inputs overlap outputs and create
   temporaries to avoid problems.
   - New __array_ufunc__ attribute provides improved ability for classes to
   override default ufunc behavior.
   - New np.block function for creating blocked arrays.


*New functions*

   - New ``np.positive`` ufunc.
   - New ``np.divmod`` ufunc provides more efficient divmod.
   - New ``np.isnat`` ufunc tests for NaT special values.
   - New ``np.heaviside`` ufunc computes the Heaviside function.
   - New ``np.isin`` function, improves on ``in1d``.
   - New ``np.block`` function for creating blocked arrays.
   - New ``PyArray_MapIterArrayCopyIfOverlap`` added to NumPy C-API.

Wheels for the pre-release are available on PyPI. Source tarballs,
zipfiles, release notes, and the changelog are available on github
.

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

   - A. Jesse Jiryu Davis +
   - Alessandro Pietro Bardelli +
   - Alex Rothberg +
   - Alexander Shadchin
   - Allan Haldane
   - Andres Guzman-Ballen +
   - Antoine Pitrou
   - Antony Lee
   - B R S Recht +
   - Baurzhan Muftakhidinov +
   - Ben Rowland
   - Benda Xu +
   - Blake Griffith
   - Bradley Wogsland +
   - Brandon Carter +
   - CJ Carey
   - Charles Harris
   - Christoph Gohlke
   - Danny Hermes +
   - David Hagen +
   - David Nicholson +
   - Duke Vijitbenjaronk +
   - Egor Klenin +
   - Elliott Forney +
   - Elliott M Forney +
   - Endolith
   - Eric Wieser
   - Erik M. Bray
   - Eugene +
   - Evan Limanto +
   - Felix Berkenkamp +
   - François Bissey +
   - Frederic Bastien
   - Greg Young
   - Gregory R. Lee
   - Importance of Being Ernest +
   - Jaime Fernandez
   - Jakub Wilk +
   - James Cowgill +
   - James Sanders
   - Jean Utke +
   - Jesse Thoren +
   - Jim Crist +
   - Joerg Behrmann +
   - John Kirkham
   - Jonathan Helmus
   - Jonathan L Long
   - Jonathan Tammo Siebert +
   - Joseph Fox-Rabinovitz
   - Joshua Loyal +
   - Juan Nunez-Iglesias +
   - Julian Taylor
   - Kirill Balunov +
   - Likhith Chitneni +
   - Loïc Estève
   - Mads Ohm Larsen
   - Marein Könings +
   - Marten van Kerkwijk
   - Martin Thoma
   - Martino Sorbaro +
   - Marvin Schmidt +
   - Matthew Brett
   - Matthias Bussonnier +
   - Matthias C. M. Troffaes +
   - Matti Picus
   - Michael Seifert
   - Mikhail Pak +
   - Mortada Mehyar
   - Nathaniel J. Smith
   - Nick Papior
   - Oscar Villellas +
   - Pauli Virtanen
   - Pavel Potocek
   - Pete Peeradej Tanruangporn +
   - Philipp A +
   - Ralf Gommers
   - Robert Kern
   - Roland Kaufmann +
   - Ronan Lamy
   - Sami Salonen +
   - Sanchez Gonzalez Alvaro
   - Sebastian Berg
   - Shota Kawabuchi
   - Simon Gibbons
   - Stefan Otte
   - Stefan Peterson +
   - Stephan Hoyer
   - Søren Fuglede Jørgensen +
   - Takuya Akiba
   - Tom Boyd +
   - Ville Skyttä +
   - Warren Weckesser
   - Wendell Smith
   - Yu Feng
   - Zixu Zhao +
   - Zè Vinícius +
   - aha66 +
   - drabach +
   - drlvk +
   - jsh9 +
   - solarjoe +
   - zengi +

Cheers,

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Add changelogs to repo

[Charles R Harris]

Hi All,

I've made a PR  adding the NumPy
`1.13.0-changelog.rst` to a new `doc/changelog` directory. The idea is to
keep the lengthy changelogs separate from the release notes, but still
easily accessible and permanently part to the NumPy history. If you hit the
`rich diff` tag at the PR, you can see the rendered rst version.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.diff on boolean arrays now raises

[Charles R Harris]

On Thu, Jun 15, 2017 at 4:35 AM, Ralf Gommers 
wrote:

>
>
> On Thu, Jun 15, 2017 at 7:08 PM, Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> There is an ongoing discussion on github:
>>
>> https://github.com/numpy/numpy/issues/9251
>>
>> In 1.13 np.diff has started raising on boolean arrays, since subtraction
>> of  boolean arrays is now deprecated.
>>
>> A decision has to be made whether:
>>
>>- raising an error is the correct thing to do, and only the docstring
>>needs updating, or
>>- backwards compatibility is more important and diff should still
>>work on boolean arrays.
>>
>>
> The issue is bigger than np.diff. For example, there's a problem with the
> scipy.ndimage morphology functions (https://github.com/scipy/
> scipy/issues/7493) that looks pretty serious. All ndimage.binary_*
> functions (7 of them) for example return boolean arrays, and chaining those
> is now broken. Unfortunately it seems that that wasn't covered by the
> ndimage test suite.
>
> Possibly reverting the breaking change in 1.13.1 is the best way to fix
> this.
>

There were two related deprecations of boolean operators: subtraction and
negative. I haven't heard any complaints about the second, which I think is
less controversial, but I think reversion is the way to go for subtraction,
at least for 1.13.1. The main virtue of the deprecations is clarity, xor is
more informative when applied to boolean values than `-`, although the
latter is certainly correct in F_2.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.diff on boolean arrays now raises

[Charles R Harris]

On Thu, Jun 15, 2017 at 6:16 AM, Charles R Harris  wrote:

>
>
> On Thu, Jun 15, 2017 at 4:35 AM, Ralf Gommers 
> wrote:
>
>>
>>
>> On Thu, Jun 15, 2017 at 7:08 PM, Jaime Fernández del Río <
>> jaime.f...@gmail.com> wrote:
>>
>>> There is an ongoing discussion on github:
>>>
>>> https://github.com/numpy/numpy/issues/9251
>>>
>>> In 1.13 np.diff has started raising on boolean arrays, since
>>> subtraction of  boolean arrays is now deprecated.
>>>
>>> A decision has to be made whether:
>>>
>>>- raising an error is the correct thing to do, and only the
>>>docstring needs updating, or
>>>- backwards compatibility is more important and diff should still
>>>work on boolean arrays.
>>>
>>>
>> The issue is bigger than np.diff. For example, there's a problem with the
>> scipy.ndimage morphology functions (https://github.com/scipy/scip
>> y/issues/7493) that looks pretty serious. All ndimage.binary_* functions
>> (7 of them) for example return boolean arrays, and chaining those is now
>> broken. Unfortunately it seems that that wasn't covered by the ndimage test
>> suite.
>>
>> Possibly reverting the breaking change in 1.13.1 is the best way to fix
>> this.
>>
>
> There were two related deprecations of boolean operators: subtraction and
> negative. I haven't heard any complaints about the second, which I think is
> less controversial, but I think reversion is the way to go for subtraction,
> at least for 1.13.1. The main virtue of the deprecations is clarity, xor is
> more informative when applied to boolean values than `-`, although the
> latter is certainly correct in F_2.
>
>
See reversion at https://github.com/numpy/numpy/pull/9255.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Boolean binary '-' operator

[Charles R Harris]

Hi All,

The boolean binary '-' operator was deprecated back in NumPy 1.9 and
changed to an error in 1.13. This caused a number of failures in downstream
projects. The choices now are to continue the deprecation for another
couple of releases, or simply give up on the change. For booleans,  `a - b`
was implemented as `a xor b`, which leads to the somewhat unexpected
identity `a - b == b - a`, but it is a handy operator that allows
simplification of some functions, `numpy.diff` among therm. At this point
I'm inclined to give up on the deprecation and retain the old behavior. It
is a bit impure but perhaps we can consider it a feature rather than a bug.

The unary `-` operator for booleans, now an error, was also deprecated in
1.9 and changed to an error in 1.13. There have been no complaints about
that (yet), and it seems like a reasonable thing to do, so I am inclined to
leave that error in place.

What do others think the correct way forward is?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Boolean binary '-' operator

[Charles R Harris]

On Mon, Jun 26, 2017 at 6:14 PM, Juan Nunez-Iglesias 
wrote:

> OMG deprecating + would be a nightmare. I can’t even begin to count the
> number of times I’ve used e.g. np.sum(arr == num)… Originally with a dtype
> cast but generally I’ve removed it because it worked.
>
> … But I just saw the behaviour of `sum` is different from that of adding
> arrays together (where it indeed means `or`), which I agree is confusing.
> As long as the sum and mean behaviours are unchanged, I won’t raise too
> much of a fuss. =P
>
> Generally, although one might expect xor, what *I* would expect is for the
> behaviour to match the Python bool type, which is not the case right now.
> So my vote would be to modify ***in NumPy 2.0*** the behaviour of + and -
> to match Python’s built-in bool (ie upcasting to int).
>
> And, in general, I’m in favour of something as foundational as NumPy, in
> version 1.x, to follow semantic versioning and not break APIs until 2.x.
>
> Juan.
>
> On 27 Jun 2017, 9:25 AM +1000, Nathaniel Smith , wrote:
>
> On Sun, Jun 25, 2017 at 9:45 AM, Stefan van der Walt
>  wrote:
>
> Hi Chuck
>
> On Sun, Jun 25, 2017, at 09:32, Charles R Harris wrote:
>
> The boolean binary '-' operator was deprecated back in NumPy 1.9 and
> changed
> to an error in 1.13. This caused a number of failures in downstream
> projects. The choices now are to continue the deprecation for another
> couple
> of releases, or simply give up on the change. For booleans, `a - b` was
> implemented as `a xor b`, which leads to the somewhat unexpected identity
> `a
> - b == b - a`, but it is a handy operator that allows simplification of
> some
> functions, `numpy.diff` among therm. At this point I'm inclined to give up
> on the deprecation and retain the old behavior. It is a bit impure but
> perhaps we can consider it a feature rather than a bug.
>
>
>
> What was the original motivation behind the deprecation? `xor` seems like
> exactly what one would expect when subtracting boolean arrays.
>
> But, in principle, I'm not against the deprecation (we've had to fix a few
> problems that arose in skimage, but nothing big).
>
>
> I believe that this happened as part of a review of the whole
> arithmetic system for np.bool_. Traditionally, we have + is "or",
> binary - is "xor", and unary - is "not".
>
> Here are some identities you might expect, if 'a' and 'b' are np.bool_
> objects:
>
> a - b = a + (-b)
> a + b - b = a
> bool(a + b) = bool(a) + bool(b)
> bool(a - b) = bool(a) - bool(b)
> bool(-a) = -bool(a)
>
> But in fact none of these identities hold. Furthermore, the np.bool_
> arithmetic operations are all confusing synonyms for operations that
> could be written more clearly using the proper boolean operators |, ^,
> ~, so they violate TOOWTDI. So I think the general idea was to
> deprecate all of this nonsense.
>
> It looks like what actually happened is that binary - and unary - got
> deprecated a while back and are now raising errors in 1.13.0, but +
> did not. This is sort of unfortunate, because binary - is the only one
> of these that's somewhat defensible (it doesn't match the builtin bool
> type, but it does at least correspond to subtraction in Z/2, so
> identities like 'a - (b - b) = a' do hold).
>
>
That's because xor corresponds to addition in Z/2 and every element is its
own additive inverse.


> I guess my preference would be:
> 1) deprecate +
> 2) move binary - back to deprecated-but-not-an-error
> 3) fix np.diff to use logical_xor when the inputs are boolean, since
> that seems to be what people expect
> 4) keep unary - as an error
>
> And if we want to be less aggressive, then a reasonable alternative would
> be:
> 1) deprecate +
> 2) un-deprecate binary -
> 3) keep unary - as an error
>
>
Using '+' for 'or' and '*' for 'and' is pretty common and the variation of
'+' for 'xor' was common back in the day because 'and' and 'xor' make
boolean algebra a ring, which appealed to mathematicians as opposed to
everyone else ;) You can see the same progression in measure theory where
eventually intersection and xor (symmetric difference) was replaced with
union and complement. Using '-' for xor is something I hadn't seen outside
of numpy, but I suspect it must be standard somewhere.  I would leave '*'
and '+' alone, as the breakage and inconvenience from removing them would
be significant.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

Hi All,

I will be running the NumPy sprint at Scipy 2017 and I'm trying to put
together a suitable list of things to sprint on. In my experience,
sprinting on NumPy is hard, enhancements generally need lengthy review and
even finding and doing simple bug fixes can take time. What I have in mind
at this point, apart from what might be a getting started tutorial, could
mostly be classified as janitorial work.


   1.  Triage issues and close those that no longer apply. This is mind
   numbing work, but it has been almost three years since the last pass.
   2.  Move the contents of `numpy/doc` into `doc/source` and make them
   normal *.rst files.
   3.  Convert the doctest in `numpy/lib/tests/test_polynomial.py` to
   regular tests. Might be tricky as it mostly checks print formatting.
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

On Thu, Jun 29, 2017 at 12:07 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:

> Hi All,
>
> I will be running the NumPy sprint at Scipy 2017 and I'm trying to put
> together a suitable list of things to sprint on. In my experience,
> sprinting on NumPy is hard, enhancements generally need lengthy review and
> even finding and doing simple bug fixes can take time. What I have in mind
> at this point, apart from what might be a getting started tutorial, could
> mostly be classified as janitorial work.
>
>
>1.  Triage issues and close those that no longer apply. This is mind
>numbing work, but it has been almost three years since the last pass.
>2.  Move the contents of `numpy/doc` into `doc/source` and make them
>normal *.rst files.
>3.  Convert the doctest in `numpy/lib/tests/test_polynomial.py` to
>regular tests. Might be tricky as it mostly checks print formatting.
>
>
> Oops, sent prematurely by accident.

Anyway, I'm looking for suggestions and comments as to things to do that
would be useful.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

On Thu, Jun 29, 2017 at 12:15 PM, Stefan van der Walt 
wrote:

> On Thu, Jun 29, 2017, at 11:09, Charles R Harris wrote:
>
>
> On Thu, Jun 29, 2017 at 12:07 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
> I will be running the NumPy sprint at Scipy 2017 and I'm trying to put
> together a suitable list of things to sprint on. In my experience,
> sprinting on NumPy is hard, enhancements generally need lengthy review and
> even finding and doing simple bug fixes can take time. What I have in mind
> at this point, apart from what might be a getting started tutorial, could
> mostly be classified as janitorial work.
>
>
> Here's a random idea: how about building a NumPy gallery?
> scikit-{image,learn} has it, and while those projects may have more visual
> datasets, I can imagine something along the lines of Nicolas Rougier's
> beautiful book:
>
> http://www.labri.fr/perso/nrougier/from-python-to-numpy/
>

So that would be added in the  numpy <https://github.com/numpy>/numpy.org
<https://github.com/numpy/numpy.org> repo?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Vector stacks

[Charles R Harris]

Hi All,

The  '@' operator works well with stacks of matrices, but not with stacks
of vectors. Given the recent addition of '__array_ufunc__',  and the intent
to make `__matmul__` use a ufunc, I've been wondering is it would make
sense to add ndarray subclasses 'rvec' and 'cvec' that would override that
operator so as to behave like stacks of row/column vectors. Any other ideas
for the solution to stacked vectors are welcome.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

Updated list below.

On Sat, Jul 1, 2017 at 7:08 PM, Benjamin Root  wrote:

> Just a heads-up. There is now a sphinx-gallery plugin. Matplotlib and a
> few other projects have migrated their docs over to use it.
>
> https://sphinx-gallery.readthedocs.io/en/latest/
>
> Cheers!
> Ben Root
>
>
> On Sat, Jul 1, 2017 at 7:12 AM, Ralf Gommers 
> wrote:
>
>>
>>
>> On Fri, Jun 30, 2017 at 6:50 AM, Pauli Virtanen  wrote:
>>
>>> Charles R Harris kirjoitti 29.06.2017 klo 20:45:
>>> > Here's a random idea: how about building a NumPy gallery?
>>> > scikit-{image,learn} has it, and while those projects may have more
>>> > visual datasets, I can imagine something along the lines of Nicolas
>>> > Rougier's beautiful book:
>>> >
>>> > http://www.labri.fr/perso/nrougier/from-python-to-numpy/
>>> > <http://www.labri.fr/perso/nrougier/from-python-to-numpy/>
>>> >
>>> >
>>> > So that would be added in the  numpy
>>> > <https://github.com/numpy>/numpy.org
>>> > <https://github.com/numpy/numpy.org> repo?
>>>
>>> Or https://scipy-cookbook.readthedocs.io/  ?
>>> (maybe minus bitrot and images added :)
>>> _
>>
>>
>> I'd like the numpy.org one. numpy.org is now incredibly sparse and ugly,
>> a gallery would make it look a lot better.
>>
>> Another idea, from the "deprecate np.matrix" discussion: add numpy
>> documentation describing the preferred way to handle matrices, extolling
>> the virtues of @, and move np.matrix documentation to a deprecated section.
>>
>>
 Putting things together with a few new ideas,


   1. add gallery to numpy.org,
   2. add extended documentation of '@' operator,
   3. make Numpy tests Pytest compatible,
   4. add matrix multiplication ufunc.

 Any more ideas?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

On Sun, Jul 2, 2017 at 9:33 AM, Sebastian Berg 
wrote:

> On Sun, 2017-07-02 at 10:49 -0400, Allan Haldane wrote:
> > On 07/02/2017 10:03 AM, Charles R Harris wrote:
> > > Updated list below.
> > >
> > > On Sat, Jul 1, 2017 at 7:08 PM, Benjamin Root  > >
> > > <mailto:ben.v.r...@gmail.com>> wrote:
> > >
> > > Just a heads-up. There is now a sphinx-gallery plugin.
> > > Matplotlib
> > > and a few other projects have migrated their docs over to use
> > > it.
> > >
> > > https://sphinx-gallery.readthedocs.io/en/latest/
> > > <https://sphinx-gallery.readthedocs.io/en/latest/>
> > >
> > > Cheers!
> > > Ben Root
> > >
> > >
> > > On Sat, Jul 1, 2017 at 7:12 AM, Ralf Gommers  > > l.com
> > > <mailto:ralf.gomm...@gmail.com>> wrote:
> > >
> > >
> > >
> > > On Fri, Jun 30, 2017 at 6:50 AM, Pauli Virtanen  > > <mailto:p...@iki.fi>> wrote:
> > >
> > > Charles R Harris kirjoitti 29.06.2017 klo 20:45:
> > > > Here's a random idea: how about building a NumPy
> > > gallery?
> > > > scikit-{image,learn} has it, and while those
> > > projects may have more
> > > > visual datasets, I can imagine something along
> > > the lines of Nicolas
> > > > Rougier's beautiful book:
> > > >
> > > > http://www.labri.fr/perso/nrougier/from-python-to
> > > -numpy/
> > > <http://www.labri.fr/perso/nrougier/from-python-to-nump
> > > y/>
> > > > <http://www.labri.fr/perso/nrougier/from-python-t
> > > o-numpy/
> > > <http://www.labri.fr/perso/nrougier/from-python-to-nump
> > > y/>>
> > > >
> > > >
> > > > So that would be added in the  numpy
> > > > <https://github.com/numpy>/numpy.org
> > > <http://numpy.org>
> > > > <https://github.com/numpy/numpy.org
> > > <https://github.com/numpy/numpy.org>> repo?
> > >
> > > Or https://scipy-cookbook.readthedocs.io/
> > > <https://scipy-cookbook.readthedocs.io/>  ?
> > > (maybe minus bitrot and images added :)
> > > _
> > >
> > >
> > > I'd like the numpy.org <http://numpy.org> one. numpy.org
> > > <http://numpy.org> is now incredibly sparse and ugly, a
> > > gallery
> > > would make it look a lot better.
> > >
> > > Another idea, from the "deprecate np.matrix" discussion:
> > > add
> > > numpy documentation describing the preferred way to handle
> > > matrices, extolling the virtues of @, and move np.matrix
> > > documentation to a deprecated section.
> > >
> > >
> > >   Putting things together with a few new ideas,
> > >
> > >  1. add gallery to numpy.org <http://numpy.org>,
> > >  2. add extended documentation of '@' operator,
> > >  3. make Numpy tests Pytest compatible,
> > >  4. add matrix multiplication ufunc.
> > >
> > >   Any more ideas?
> >
> > The new doctest runner suggested in the printing thread? This is to
> > ignore whitespace and precision in ndarray output.
> >
> > I can see an argument for distributing it in numpy if it is designed
> > to
> > be specially aware of ndarrays or numpy scalars (eg to test equality
> > between 'wants' and 'got')
> >
>
> I don't really feel it is very numpy specific or should be under the
> numpy umbrella (I mean if there is no other spot, I guess it could live
> on the numpy github page). Its about as numpy specific, as the gallery
> sphinx extension is probably matplotlib specific
>
> That doesn't mean that it might not be a good sprint, though :).
>
> The question to me is a bit what those who actually go there want from
> it or do a few people who know numpy/scipy already plan to come? Two
> years ago, we did not have much of a plan, so it was mostly giving
> three people or so a bit of a tutorial of how numpy worked internally
> leading to some bug fixes.
>
> One quick

Re: [Numpy-discussion] New python/numpy user

[Charles R Harris]

On Tue, Jul 4, 2017 at 1:32 AM,  wrote:

> Hi Brian
>
>
> First of all thanks for the answer, the explanations and the advices; as
> mentioned I've to think differently in order to code with efficiency.
>
> 1.: yes 'mat[:,0]=vect0' works fine and I understand why :-)
>
> 2. more generally, I've read some tutorials or presentations saying that
> Numpy is faster than the native Python; regarding the (huge) size of my
> matrices, vectorization, Numpy (and others) + optimzation of calls are the
> basics
>
> Thanks
>
>
>
Note that NumPy is not the best for large text files, for instance, pandas
is faster.

Also note that the custom here is bottom posting.  And welcome to Python ;)



Chuck

>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Scipy 2017 NumPy sprint

[Charles R Harris]

Lots of good ideas here. It would help if issues were opened for them and
flagged with the sprint label. I'll be doing some myself, but I'm not as
intimately familiar with some of the topics as the proposers are.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Making a 1.13.2 release

[Charles R Harris]

Hi All,

I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show up
fixing #29943   so we can close #9272
, but the Python release has
been delayed to July 11 (expected). The Python problem means that NumPy
compiled with Python 3.6.1 will not run in Python 3.6.0. However, I've also
been asked to have a bugfixed version of 1.13 available for Scipy 2017 next
week. At this point it looks like the best thing to do is release 1.13.1
compiled with Python 3.6.1 and ask folks to upgrade Python if they have a
problem, and then release 1.13.2 as soon as 3.6.2 is released.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Making a 1.13.2 release

[Charles R Harris]

On Thu, Jul 6, 2017 at 7:15 AM, Matthew Brett 
wrote:

> Hi,
>
> On Thu, Jul 6, 2017 at 2:10 PM, Charles R Harris
>  wrote:
> > Hi All,
> >
> > I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show up
> > fixing #29943  so we can close #9272, but the Python release has been
> > delayed to July 11 (expected). The Python problem means that NumPy
> compiled
> > with Python 3.6.1 will not run in Python 3.6.0. However, I've also been
> > asked to have a bugfixed version of 1.13 available for Scipy 2017 next
> week.
> > At this point it looks like the best thing to do is release 1.13.1
> compiled
> > with Python 3.6.1 and ask folks to upgrade Python if they have a problem,
> > and then release 1.13.2 as soon as 3.6.2 is released.
>
> I think this problem only applies to Windows.  We might be able to
> downgrade the Appveyor Python 3.6.1 to 3.6.0 for that - I can look
> into it today if it would help.
>
> While I'm at it - how about switching to OpenBLAS wheels on Windows
> for this release?
>
> Cheers,
>
> Matthew
>

Haste makes waste ;) I'd rather put off the move to OpenBlas to 1.14 to
allow more time for it to settle, and compiling against Python 3.6.0 seems
like more work than it is worth, It should be easy to upgrade to 3.6.1 for
those affected once they are aware of the problem, and it should not be too
long before Python 3.6.2 is out. I'll call it the Scipy2017 release.

Chuck

>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Making a 1.13.2 release

[Charles R Harris]

On Thu, Jul 6, 2017 at 9:53 AM, Matthew Brett 
wrote:

> On Thu, Jul 6, 2017 at 3:37 PM, Charles R Harris
>  wrote:
> >
> >
> > On Thu, Jul 6, 2017 at 7:15 AM, Matthew Brett 
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Jul 6, 2017 at 2:10 PM, Charles R Harris
> >>  wrote:
> >> > Hi All,
> >> >
> >> > I've delayed the NumPy 1.13.2 release hoping for Python 3.6.2 to show
> up
> >> > fixing #29943  so we can close #9272, but the Python release has been
> >> > delayed to July 11 (expected). The Python problem means that NumPy
> >> > compiled
> >> > with Python 3.6.1 will not run in Python 3.6.0. However, I've also
> been
> >> > asked to have a bugfixed version of 1.13 available for Scipy 2017 next
> >> > week.
> >> > At this point it looks like the best thing to do is release 1.13.1
> >> > compiled
> >> > with Python 3.6.1 and ask folks to upgrade Python if they have a
> >> > problem,
> >> > and then release 1.13.2 as soon as 3.6.2 is released.
> >>
> >> I think this problem only applies to Windows.  We might be able to
> >> downgrade the Appveyor Python 3.6.1 to 3.6.0 for that - I can look
> >> into it today if it would help.
> >>
> >> While I'm at it - how about switching to OpenBLAS wheels on Windows
> >> for this release?
> >>
> >> Cheers,
> >>
> >> Matthew
> >
> >
> > Haste makes waste ;) I'd rather put off the move to OpenBlas to 1.14 to
> > allow more time for it to settle,
>
> I'd only say that I don't know of any settling that is likely to
> happen.  I suspect that not many people have tried the experimental
> wheels.   I've automated the build process both for OpenBLAS and the
> OpenBLAS wheels, and I believe those are solid now.
>

But it does add risk. We can deal with that in a regular release because of
the betas and release condidates, but I'm not counting on any of those for
1.13.1 (2).

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.13.1 released

[Charles R Harris]

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of NumPy
1.13.1. This is a bugfix release for problems found in 1.13.0. The major
changes are:


   - fixes for the new memory overlap detection,
   - fixes for the new temporary elision capability,
   - reversion of the removal of the boolean binary ``-`` operator.


It is recommended that users of 1.13.0 upgrade to 1.13.1. Wheels can be
found on PyPI .  Source tarballs,
zipfiles, release notes, and the changelog are available on github
.

Note that the wheels for Python 3.6 are built against 3.6.1, hence will not
work when used with 3.6.0 due to Python bug #29943
. The plan is to release NumPy 1.13.2
shortly after the release of Python 3.6.2 is out with a fix that problem.
If you are using 3.6.0, the workaround is to upgrade to 3.6.1 or use an
earlier Python version.




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

* #9240 DOC: BLD: fix lots of Sphinx warnings/errors.
* #9255 Revert "DEP: Raise TypeError for subtract(bool_, bool_)."
* #9261 BUG: don't elide into readonly and updateifcopy temporaries for...
* #9262 BUG: fix missing keyword rename for common block in numpy.f2py
* #9263 BUG: handle resize of 0d array
* #9267 DOC: update f2py front page and some doc build metadata.
* #9299 BUG: Fix Intel compilation on Unix.
* #9317 BUG: fix wrong ndim used in empty where check
* #9319 BUG: Make extensions compilable with MinGW on Py2.7
* #9339 BUG: Prevent crash if ufunc doc string is null
* #9340 BUG: umath: un-break ufunc where= when no out= is given
* #9371 DOC: Add isnat/positive ufunc to documentation
* #9372 BUG: Fix error in fromstring function from numpy.core.records...
* #9373 BUG: ')' is printed at the end pointer of the buffer in numpy.f2py.
* #9374 DOC: Create NumPy 1.13.1 release notes.
* #9376 BUG: Prevent hang traversing ufunc userloop linked list
* #9377 DOC: Use x1 and x2 in the heaviside docstring.
* #9378 DOC: Add $PARAMS to the isnat docstring
* #9379 DOC: Update the 1.13.1 release notes



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

* Andras Deak +
* Bob Eldering +
* Charles Harris
* Daniel Hrisca +
* Eric Wieser
* Joshua Leahy +
* Julian Taylor
* Michael Seifert
* Pauli Virtanen
* Ralf Gommers
* Roland Kaufmann
* Warren Weckesser
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] pytest and degrees of separation.

[Charles R Harris]

Hi All,

Just looking for opinions and feedback on the need to keep NumPy from
having a hard nose/pytest dependency. The options as I see them are:


   1. pytest is never imported until the tests are run -- current practice
   with nose
   2. pytest is never imported unless the testfiles are imported -- what I
   would like
   3. pytest is imported together when numpy is -- what we need to avoid.

Currently the approach has been 1), but I think 2) makes more sense and
allows more flexibility.

Thoughts?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] pytest and degrees of separation.

[Charles R Harris]

On Wed, Jul 12, 2017 at 1:26 AM, Ralf Gommers 
wrote:

>
>
> On Wed, Jul 12, 2017 at 11:06 AM, Chris Barker 
> wrote:
>
>>
>>
>> On Tue, Jul 11, 2017 at 5:04 PM, Thomas Caswell 
>> wrote:
>>
>>> Going with option 2 is probably the best option so that you can use
>>> pytest fixtures and parameterization.
>>>
>>
>> I agree -- those are worth a lot!
>>
>
> Maybe I'm dense, but I don't quite see the difference between 1 and 2.
> Test files should never be imported unless tests are run, they're not part
> of any public API nor do they currently have __init__.py files.
>
> Ralf
>

In practice, that would generally be true, but the nose testing tools were
1, all nose imports were buried in functions that ran during testing.
Whether or not that was by intent I don't know. But having an explicit
consensus on 2, which seems to be the case here, is helpful because it
allows better use of pytest fixtures.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] quantile() or percentile()

[Charles R Harris]

On Thu, Aug 10, 2017 at 3:08 PM, Eric Wieser 
wrote:

> Let’s try and keep this on topic - most replies to this message has been
> about #9211, which is an orthogonal issue.
>
> There are two main questions here:
>
>1. Would the community prefer to use np.quantile(x, 0.25) instead of 
> np.percentile(x,
>25), if they had the choice
>2. Is this desirable enough to justify increasing the API surface?
>
> The general consensus on the github issue answers yes to 1, but is neutral
> on 2. It would be good to get more opinions.
>

I think a quantile function would be natural and desirable.



Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Tensor Contraction (HPTT) and Tensor Transposition (TCL)

[Charles R Harris]

On Tue, Aug 15, 2017 at 10:26 AM, Paul  wrote:

> Hi all,
>
> I recently spent some time adding python interfaces to my tensor libraries:
>   * Tensor Contraction Library (TCL): https://github.com/springer13/tcl
>   * Tensor Transposition Library (HPTT): https://github.com/springer13/
> hptt
>
> Both libraries tend to give very significant speedups over what is
> currently offered by NumPY; Speedups
> typically range from 5x - 20x w.r.t. HPTT and >>20x for TCL (see
> attached, Host: 2x Intel Haswell-EP E5-2680 v3 (24 threads)).
> Thus, I was curious if some of you would benefit from those speedups and
> if you want it to
> be integrated into NumPY.
>
> The HPTT and TCL libraries are respectively similar to numpy.transpose()
> and numpy.einsum().
>
> I welcome you to give the packages a try and see if they can help you to
> speedup some of your tensor-related operations.
>
> Finally: Which steps would be required to integrate those libraries into
> NumPY? Which problems do you anticipate?
>
>
What version of Numpy are you comparing to? Note that in 1.13 you can
enable some optimization in einsum, and the coming 1.14 makes that the
default and uses CBLAS when possible.

If you want to get it into Numpy, it would be worth checking if the
existing functions can be improved before adding new ones.

Note that Numpy transposition method just rearranges the indices, so the
advantage of actual transposition is to have better cache performance or
allow direct use of CBLAS. I assume TCL uses some tricks to do
transposition in a way that is more cache friendly?

Might check the license if your work uses code from a publication.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Tensor Contraction (HPTT) and Tensor Transposition (TCL)

[Charles R Harris]

On Thu, Aug 17, 2017 at 10:15 AM, Chris Barker 
wrote:

> On Thu, Aug 17, 2017 at 12:55 AM, Sebastian Berg <
> sebast...@sipsolutions.net> wrote:
>
>> > How would the process look like if NumPY is distributed as a
>> > precompiled binary?
>>
>>
>> Well, numpy is BSD, and the official binaries will be BSD, someone else
>> could do less free binaries of course.
>
>
> Indeed, if you want it to be distributed as a binary with numpy, then the
> license needs to be compatible -- do you have a substantial objection to
> BSD? The BSD family is pretty much the standard for Python -- Python (and
> numpy) are very broadly used in proprietary software.
>
> I doubt we can have a hard
>> dependency unless it is part of the numpy source
>
>
> and no reason to -- if it is a hard dependency, it HAS to be compatible
> licensed, and it's a lot easier to keep the source together.
>
> However, it _could_ be a soft dependency, like LAPACK/BLAS -- I've
> honestly lost track, but numpy used come with a lapack-lite (or some such),
> so that it could be compiled and work with no external LAPACK
> implementation -- you wouldn't get the best performance, but it would work.
>
>  I doubt including the source
>> itself is going to happen quickly since we would first have to decide
>> to actually use a modern C++ compiler (I have no idea if that is
>> problematic or not).
>>
>
> could it be there as a conditional compilation? There is a lot of push to
> support C++11 elsewhere, so a compiled-with-a-modern-compiler numpy is
> not SO far off..
>
> (for py3 anyway...)
>

It would take a fair amount of grunge work to get there. Variables would
need renaming, for instance `new`, and other such things. Nothing mind
bending, but not completely trivial either.


>
> * Use TCL if you need faster einsum(like) operations
>>
>
> That is, of course, the other option -- distribute it on its own or maybe
> in scipy, and then users can use it as an optimization for those few core
> functions where speed matters to them -- honestly, it's a pretty small
> fraction of numpy code.
>
> But it sure would be nice if it could be built in, and then folks would
> get better performance without even thinkning about it.
>
>
>> Just a few thoughts, did not think about details really. But yes, it is
>> sounds reasonable to me to re-add support for optional dependencies
>> such as fftw or your TCL. But packagers have to make use of that or I
>> fear it is actually less available than a standalone python module.
>>
>
> true -- though I expect Anaconda / conda forge at least would be likely to
> pick it up if it works well.
>
>
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy default citation

[Charles R Harris]

On Tue, Sep 5, 2017 at 12:36 PM, Stefan van der Walt 
wrote:

> Hi, everyone
>
> I see that the NumPy homepage does not have a "Citation" section.
> Furthermore, on scipy.org, the default NumPy citation points to a short
> summary paper that I wrote with Gael V & Stephen C.  While it's a
> reasonable introduction to three core concepts behind NumPy, attribution
> should certainly go to Travis & the community.
>
> Shall we add a citation to Travis's "Guide to NumPy (2nd ed.)" on both
>

What is the citation for?

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] New distribution

[Charles R Harris]

Hi All,

This is a heads up that there is a pull request
 adding a univariate complex_normal
distribution.
Anyone interested in this should take a look at the PR. I'd also be
interested if there was a desire for the multivariate version.

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] ANN: SciPy 1.0 beta release

[Charles R Harris]

On Sun, Sep 17, 2017 at 4:48 AM, Ralf Gommers 
wrote:

> Hi all,
>
> I'm excited to be able to announce the availability of the first beta
> release of Scipy 1.0. This is a big release, and a version number that
> has been 16 years in the making. It contains a few more deprecations and
> backwards incompatible changes than an average release. Therefore please do
> test it on your own code, and report any issues on the Github issue tracker
> or on the scipy-dev mailing list.
>
> Sources: https://github.com/scipy/scipy/releases/tag/v1.0.0b1
> Binary wheels: will follow tomorrow, I'll announce those when ready
> (TravisCI is under maintenance right now)
>
> Thanks to everyone who contributed to this release!
>

Congratulations to all, and an extra congratulations to Matthew and
everyone else involved in getting the scipy wheels building on all the
supported platforms.

For those unfamiliar with the history, Ralf became release manager for
NumPy 1.4.1 back in early 2010 and switched to full time SciPy release
manager in 2011. It has been a long, productive, seven years.



Chuck

>
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.13.2 released.

[Charles R Harris]

HI All,

On behalf of the NumPy team, I am pleased to annouce the release of Numpy
1.13.2. This is a bugfix release for some problems found since 1.13.1. The
most important fixes are for CVE-2017-12852 and temporary elision. Users of
earlier versions of 1.13 should upgrade.

The Python versions supported are 2.7 and 3.4 - 3.6. The Python 3.6 wheels
available from PIP are built with Python 3.6.2 and should be compatible
with all previous versions of Python 3.6. The Windows wheels are now built
with OpenBlas instead ATLAS, which should improve the performance of the
linearalgebra functions.

Contributors


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

* Allan Haldane
* Brandon Carter
* Charles Harris
* Eric Wieser
* Iryna Shcherbina +
* James Bourbeau +
* Jonathan Helmus
* Julian Taylor
* Matti Picus
* Michael Lamparski +
* Michael Seifert
* Ralf Gommers

Pull requests merged


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

* #9390 BUG: Return the poly1d coefficients array directly
* #9555 BUG: Fix regression in 1.13.x in distutils.mingw32ccompiler.
* #9556 BUG: Fix true_divide when dtype=np.float64 specified.
* #9557 DOC: Fix some rst markup in numpy/doc/basics.py.
* #9558 BLD: Remove -xhost flag from IntelFCompiler.
* #9559 DOC: Removes broken docstring example (source code, png, pdf)...
* #9580 BUG: Add hypot and cabs functions to WIN32 blacklist.
* #9732 BUG: Make scalar function elision check if temp is writeable.
* #9736 BUG: Various fixes to np.gradient
* #9742 BUG: Fix np.pad for CVE-2017-12852
* #9744 BUG: Check for exception in sort functions, add tests
* #9745 DOC: Add whitespace after "versionadded::" directive so it
actually...
* #9746 BUG: Memory leak in np.dot of size 0
* #9747 BUG: Adjust gfortran version search regex
* #9757 BUG: Cython 0.27 breaks NumPy on Python 3.
* #9764 BUG: Ensure `_npy_scaled_cexp{,f,l}` is defined when needed.
* #9765 BUG: PyArray_CountNonzero does not check for exceptions
* #9766 BUG: Fixes histogram monotonicity check for unsigned bin values
* #9767 BUG: Ensure consistent result dtype of count_nonzero
* #9771 BUG, MAINT: Fix mtrand for Cython 0.27.

Enjoy

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion