[Numpy-discussion] NumPy Development Meeting Wednesday - Triage Focus (NOTE: Earlier for most!)
Note: The time is earlier than last ones in UTC (so earlier if you did not just switched to daylight-savings time). The reason was not daylight saving time, but happens to coincide... Hi all, Our bi-weekly triage-focused NumPy development meeting is Wednesday, March 9th at 16:00 UTC (9:00am Pacific Time). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized, discussed, or reviewed. A calendar to can be found at: https://scientific-python.org/calendars/ (For this week, the calendar is updated yet, but should update before the meeting.) Best regards Sebastian 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
[Numpy-discussion] Re: np.bool_ vs Python bool behavior
On Wed, 2022-03-16 at 18:14 +, 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-.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
[Numpy-discussion] Re: np.bool_ vs Python bool behavior
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 wrote: > On Wed, 2022-03-16 at 18:14 +, 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-.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
