Just as a quick note, I find it *very* common and handy to do something like:
someCount = (x > 5).sum() which requires implicit upcasting of np.bool_ to integer. Just making sure that usecase isn't forgotten, as it had to be mentioned the last time this subject came up. On Mon, Mar 21, 2022 at 2:19 PM Sebastian Berg <sebast...@sipsolutions.net> wrote: > 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 > > > > _______________________________________________ > 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: ben.v.r...@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
