[Numpy-discussion] Re: Adding bit_count ufunc

2023-08-13 Thread Doug Turnbull
Hi all,

Thanks for all the great work on this PR on using the CPU instruction for
bitcounts. This will be really useful for hamming distance like
calculations.

I wanted to check if there was anything else needed to merge this PR? It
seems like there was a lot of good feedback addressed.

https://github.com/numpy/numpy/pull/21429

Thanks
-Doug

On Sun, Dec 4, 2022 at 10:00 PM Ganesh Kathiresan 
wrote:

>  as long as the correspondence is mentioned in the docstring this should
>> be discoverable enough
>
>
> Ah ok, that's a good point. I will make the change. Thanks!
>
> ~Ganesh
>
> On Mon, Dec 5, 2022 at 3:21 AM Ralf Gommers 
> wrote:
>
>>
>>
>> On Sun, Dec 4, 2022 at 6:30 PM Ganesh Kathiresan 
>> wrote:
>>
>>> Hi all,
>>>
>>> Thanks for the suggestions! I have gotten the PR to a working state with
>>> UT on top of the latest main (PR
>>> ).
>>>
>>> So it looks to me like this new ufunc should be called `bitwise_count`
 rather than `bit_count`.
>>>
>>>
>>> This does sound like a good idea, but would it confuse the users given
>>> the scalar version is called `bit_count`? We could change/add an alias for
>>> scalar bit_count to `bitwise_count` but that would be different from the
>>> Python `bit_count
>>> ` added
>>> in 3.10. Any idea on how to proceed? I'm ok with calling it `bitwise_count`
>>> or `bit_count`.
>>>
>>
>> I don't think it would confuse users. This is not a feature for the
>> beginner/average user, it will have few users right now, and as long as the
>> correspondence is mentioned in the docstring this should be discoverable
>> enough. I'd much prefer no alias, we already have way too many of those and
>> most of them are only noise at this point.
>>
>> Cheers,
>> Ralf
>>
>>
>>> Thanks,
>>> Ganesh
>>>
>>> On Thu, Dec 1, 2022 at 3:20 AM Ralf Gommers 
>>> wrote:
>>>


 On Fri, Nov 25, 2022 at 9:55 PM Serge Guelton 
 wrote:

> On Fri, Nov 25, 2022 at 08:09:02PM +0100, Sebastian Berg wrote:
> > Thanks for bringing this up again.  The Python method exists and it
> > seems like relatively basic functionality.
> >
> > Overall, I am slightly in favor of adding the ufunc.  So if nobody
> > voices an opinion that it doesn't seem a good fit for NumPy, I would
> be
> > happy to move forward with it.
>

 It seems like there is enough demand, so +0.5 from me.


> > PS: One of my main concern would be if we were to add many bitwise
> > functions, in which case a `bitwise` namespace might be nice.  But I
> am
> > not convinced that should stop us here.
>
> Technically speaking, bitwise_and, birwise_or, bitwise_xor and
> bitwise_not
> already exist and popcount is widely spread, it already has its
> compiler builtin
> under the name of __builtin_popcount
>

 Those four `bitwise_*` functions also came to mind for me. I'll also
 add that Python has six bit-wise operators (
 https://wiki.python.org/moin/BitwiseOperators), and because of that
 the array API standard implements `bitwise_left_shift` and
 `bitwise_right_shift` in addition to the four functions that NumPy has.

 So it looks to me like this new ufunc should be called `bitwise_count`
 rather than `bit_count`.

 Cheers,
 Ralf

 ___
 NumPy-Discussion mailing list -- numpy-discussion@python.org
 To unsubscribe send an email to numpy-discussion-le...@python.org
 https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
 Member address: ganesh3...@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: ralf.gomm...@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: ganesh3...@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: softwared...@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: Next Documentation team meeting

2023-08-13 Thread Mukulika Pahari
Our next Documentation Team meeting will happen on *Monday, August 14* at *12PM 
UTC*.

All are welcome - you don't need to already be a contributor to join. If you 
have questions or are curious about what we're doing, we'll be happy to meet 
you!

If you wish to join on Zoom, use this (updated) link:
https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ...

Here's the permanent hackmd document with the meeting notes (still being
updated):
https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg

Hope to see you around!
___
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.0b1 released

2023-08-13 Thread Charles R Harris
Hi All,

On behalf of the NumPy team, I'm pleased to announce the release of NumPy
1.26.0b1. 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

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

   - Bas van Beek
   - Charles Harris
   - Matti Picus
   - Melissa Weber Mendonça
   - Ralf Gommers
   - Sayed Adel
   - Sebastian Berg
   - Stefan van der Walt
   - Tyler Reddy
   - Warren Weckesser


*Pull requests merged*

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

   - #24305: MAINT: Prepare 1.26.x branch for development
   - #24308: MAINT: Massive update of files from main for numpy 1.26
   - #24322: CI: fix wheel builds on the 1.26.x branch
   - #24326: BLD: update openblas to newer version
   - #24327: TYP: Trim down the ``_NestedSequence.__getitem__`` signature
   - #24328: BUG: fix choose refcount leak
   - #24337: TST: fix running the test suite in builds without BLAS/LAPACK
   - #24338: BUG: random: Fix generation of nan by dirichlet.
   - #24340: MAINT: Dependabot updates from main
   - #24342: MAINT: Add back NPY_RUN_MYPY_IN_TESTSUITE=1
   - #24353: MAINT: Update ``extbuild.py`` from main.
   - #24356: TST: fix distutils tests for deprecations in recent
   setuptools...
   - #24375: MAINT: Update cibuildwheel to version 2.15.0
   - #24381: MAINT: Fix codespaces setup.sh script
   - #24403: ENH: Vendor meson for multi-target build support
   - #24404: BLD: vendor meson-python to make the Windows builds with
   SIMD...
   - #24405: BLD, SIMD: The meson CPU dispatcher implementation
   - #24406: MAINT: Remove versioneer



*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`` b