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 <cgmar...@andrew.cmu.edu> > 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
