On Wed, 2022-03-16 at 18:14 +0000, Jacob Reinhold wrote: > Hi Sebastian and Chuck, > > Thanks for the response! (Sorry about the formatting in my original > post, I wasn't familiar with how to display code in this setting). > > I think keeping + as "logical or" and * as "logical and" on np.bool_ > types is fine, although redundant given that | and & provide this > functionality and potentially misleading given the different behavior > from the native Python bool; however, I could see it being too > painful of a migration within v1.* numpy. > > I think my main point of contention is that division and > exponentiation aren't well defined operations on np.bool_, at least > as currently defined, and they should raise errors like subtraction. > Raising those errors would have caught the problem I ran into when > trying to taking the mean of multiple ndarrays of dtype=np.bool_. I'm > not sure what the realistic use case is to have division/exp. return > a float/int, especially when +/* return np.bool_ and subtraction > throws an error.
Sorry for the slow followup. Maybe aiming for that (or at least
attempting it) can be formalized a bit easier.
In principle, I do agree that we should error out in all of these
cases. Forcing the user to write `dtype=...` if they so wish.
If we keep some of these (i.e. + and *), that change might not be very
controversial (I am not sure).
>
> Sebastian, you stated:
> "N.B.: I have changed that logic. "Future" ufuncs are now reversed.
> They will default to an error rather than using the `int8`
> implementation."
>
> So is the division/exp. issue that I described with np.bool_ solved
> in future releases?
>
No, unfortunately not. It would be solved for future (new) ufuncs, but
that doesn't necessary help us much.
There is a bit of a parallel thing going on, due to us trying to get
rid of value-based casting:
np.uint8([1]) + np.int64(1000) # should not return a uint16
Once we pull that off, that new design may help. Until then, it may
make things a bit more confusing.
However, I don't think that should stop us from going ahead. It should
not be a big hassle in practice.
> Happy to help out on implementation/formalizing a proposal!
The most formal thing would be to draft a (brief!) NEP:
https://numpy.org/neps/nep-0000.html
but I am not sure I want to ask for that quite yet :). Maybe the
decision isn't actually big enough to warrant a NEP at all.
I have to think about the implementation (and if we start on a NEP, I
can fill it in). I suspect it is actually straight forward, so long we
apply it to all ufuncs (even those in SciPy, etc.!).
But there may well be some trickier parts I am missing right now.
>
> FWIW, I suppose you could change + to XOR. Then np.bool_ would be a
> field (isomorphic to Z/2Z) and then you could reasonably define - and
> /. (Although + would be equivalent to - and * would be equivalent to
> /, which would probably be confusing to most users.)
>
Yeah, I think we removed `-` because it didn't even follow the Z/2Z
behavior.
Cheers,
Sebastian
> Best,
> Jacob
> _______________________________________________
> 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: sebast...@sipsolutions.net
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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
