[Numpy-discussion] np.ndenumerate doesn't obey mask?

[Neal Becker via NumPy-Discussion]

I was using ndenuerate with a masked array, and it seems that the mask is
ignored.  Is this true?  If so, isn't that a bug?
___
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.2.0 Released

[Neal Becker via NumPy-Discussion]

Where can I find more information on improvements to stringdtype?

On Sun, Dec 8, 2024, 11:25 AM Charles R Harris via NumPy-Discussion <
numpy-discussion@python.org> wrote:

> Hi All,
>
> On behalf of the NumPy team, I'm pleased to announce the release of NumPy
> 2.2.0. The NumPy 2.2.0 release is a short release that brings us back
> into sync with the usual twice yearly release cycle. There have been a
> number of small cleanups, as well as work bringing the new StringDType to
> completion and improving support for free threaded Python. Highlights are:
>
>- New functions `matvec` and `vecmat`, see below.
>- Many improved annotations.
>- Improved support for the new StringDType.
>- Improved support for free threaded Python
>- Fixes for f2py
>
> 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
> .
>
> 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: ndbeck...@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: ENH: Add saturating arithmetic functions

[Neal Becker via NumPy-Discussion]

On Mon, Apr 28, 2025 at 4:52 AM Ralf Gommers via NumPy-Discussion <
numpy-discussion@python.org> wrote:

>
>
> On Sun, Apr 27, 2025 at 7:31 AM Carlos Martin 
> wrote:
>
>> Saturating arithmetic (
>> https://en.wikipedia.org/wiki/Saturation_arithmetic) is important in
>> digital signal processing and other areas.
>>
>> Feature request: Add saturating arithmetic functions for the following
>> basic operations:
>>
>> - addition (C++ counterpart:
>> https://en.cppreference.com/w/cpp/numeric/add_sat)
>> - subtraction (C++ counterpart:
>> https://en.cppreference.com/w/cpp/numeric/sub_sat)
>> - multiplication (C++ counterpart:
>> https://en.cppreference.com/w/cpp/numeric/mul_sat)
>> - division (C++ counterpart:
>> https://en.cppreference.com/w/cpp/numeric/div_sat)
>> - casting (C++ counterpart:
>> https://en.cppreference.com/w/cpp/numeric/saturate_cast)
>> - negation
>>
>> I've implemented these for JAX at
>> https://gist.github.com/carlosgmartin/b32fa6fed3aa82f83dfbaac4b6345672.
>>
>> Corresponding issue: https://github.com/jax-ml/jax/issues/26566.
>>
>
> Thanks for the proposal Carlos. On
> https://github.com/numpy/numpy/issues/28837 Matti suggested that it may
> be possible to implement this as a casting mode. If so, then it may be
> feasible to have this functionality inside NumPy. If it would require new
> API beyond that, it seems a bit niche for NumPy, but if the amount of extra
> code/maintenance is reasonable and it's only one extra casting mode, then
> it does seem reasonable to me.
>
> Cheers,
> Ralf
>

I have worked in this area (DSP hardware) and have developed and used tools
for such algorithms.   I think this is part of a larger topic of fixed
point arithmetic.  There are 2 aspects to fixed point arithmetic that we
can consider.  One is the interpretation of a binary point.  The other
aspect is the handling of arithmetic overflow for a finite field of bits.
It is this latter aspect that I think is currently being discussed.  When
studying overflow effects in DSP algorithms it is useful to be able to
choose between at least 3 different behaviors: 1) wraparound 2) saturation
3) throw error.  In hardware design saturation logic has a cost (in both
space and time) and so should only be added when needed.  In my own work I
have implemented (in c++) data types that allow switching overflow behavior
as a parameter of the class, allowing the designer to study the effect of
the different choices.  The "throw error" exists to find whether the
potential exists for overflow and so indicate whether there is a need for
any additional circuitry.

Perhaps this should be considered as a part of a more comprehensive effort
to implement fixed-point arithmetic?

Thanks,
Neal
___
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