[Numpy-discussion] Problem with absolute value

[Charles R Harris]

On Wed, Jul 3, 2019 at 11:39 AM Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Wed, Jul 3, 2019 at 9:08 AM Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> >
> > On Wed, Jul 3, 2019 at 9:08 AM Hameer Abbasi <einstein.edison at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> It turns out you're running into a bit-error. In general, the two's
> complement of -2 ** (n-1) with the bit-length being limited to n bits is
> itself... No way around that. And integers don't set hardware exceptions so
> checking for errors like these is hard as well.
> >>
> >> TL;DR: It's an error with how the integer is stored in memory and how
> you're running out of space.
> >>
> >> Regards,
> >> Hameer Abbasi
> >
> >
> > More like the eight bit twos complement of -128 is -128, bytes cannot
> represent 128. Matlab used to (still does?) solve this problem by returning
> 127 instead :) Basically, the data needs more precision. Returning an
> unsigned type would lead to it's own problems with unexpected promotions
> when the result was used. We could, I suppose, raise a warning, although
> that might be considered noisy. If you use `absolute` instead, you can
> specify the dtype.
>
> I still think this is a major wart in numpy's abs.
>
> I'd really like to add a new function, `uabs` which would return an
> unsigned int for integer inputs.  I'm happy to do a pull request if
> that also seems sensible to y'all,
>
>
Seems reasonable, it would provide something for discussion. Note that the
current abs is in the slot provided by Python numeric types. The main
problem is that as soon as the unsigned result is combined with a signed
type it will get promoted. Which would not be much of a problem except
int64 -> double.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190703/745ca9ae/attachment.html>