Hi all,
just to mention it, there is a PR ready on this:
https://github.com/numpy/numpy/pull/22385
it necessecitates some changes to the NumPy test suite and will do
similar at least for SciPy downstream
I currently suspect we will give it a shot soon, but am not opposed at
all with discussing especially allowing:
np.uint8(-1)
i.e. using the negative range of the corresponding signed integer
explicitly for the `np.uint8`, `np.uint16`. But still disallow it for
other operations like `np.array([-1], dtype=np.uint8)`.
As I said, my main interest is pushing NEP 50 related change:
https://github.com/numpy/numpy/pull/21875
which this will simplify. If this PR seems tricky to move forward,
that is fine, but I would like to push that PR without the
simplification. (Decoupling this change from NEP 50 at some complexity
cost.)
Cheers,
Sebastian
On Tue, 2022-10-04 at 17:24 +0200, Ralf Gommers wrote:
> On Thu, Sep 29, 2022 at 10:10 AM Sebastian Berg
> <[email protected]>
> wrote:
>
> > On Wed, 2022-09-28 at 16:44 -0700, Stefan van der Walt wrote:
> > > Hi Sebastian,
> > >
> > > On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote:
> > > > np.array([1, 2], dtype="uint8") + (-1)
> > > >
> > > > which currently returns an "int16" array must raise an error.
> > > > This
> > > > is
> > > > because we want to return a uint8 array but the -1 cannot be
> > > > represented well by -1.
> > >
> > > Did you mean: the -1 is not representable in uint8?
> >
> > Sorry yes. With NEP 50, we do not look at the value (initially) so
> > determine that the operation must be handled as:
> >
> > uint8 + uint8 -> uint8
> >
> > We then try to convert the -1 to uint8. That conversion would
> > raise an
> > error, because previously the result was an int16.
> > (This is to prevent silent unexpected result changes and seemed
> > like
> > the more reasonable behavior.)
> >
> > On the other hand, assignments like:
> >
> > uint8_arr[0] = -1
> > np.array([-1], dtype=np.uint8)
> >
> > do happily convert the -1 to `uint8`, currently. If we keep
> > allowing
> > these, we have two slightly different conversions: one that fails
> > and
> > one that does not.
> >
> > This is fine, but maybe we actually want it to always fail in the
> > future?
> >
>
> It seems better to always raise an exception indeed. So if it
> simplifies
> your PR to do that now, I'd say go for it.
>
> Cheers,
> Ralf
> _______________________________________________
> NumPy-Discussion mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: [email protected]
_______________________________________________
NumPy-Discussion mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: [email protected]
