Not sure how much time it's worth spending on coming up with new definitions for boolean subtraction, since even if we deprecate the current behavior now we won't be able to implement any of them for a year+, and then we'll end up having to go through these debates again then anyway.
-n On Fri, Dec 6, 2013 at 2:29 PM, <josef.p...@gmail.com> wrote: > On Fri, Dec 6, 2013 at 4:14 PM, <josef.p...@gmail.com> wrote: >> On Fri, Dec 6, 2013 at 3:50 PM, Sebastian Berg >> <sebast...@sipsolutions.net> wrote: >>> On Fri, 2013-12-06 at 15:30 -0500, josef.p...@gmail.com wrote: >>>> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith <n...@pobox.com> wrote: >>>> > On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky <ndar...@mac.com> >>>> > wrote: >>>> >> >>>> >> >>>> >> >>>> >> On Fri, Dec 6, 2013 at 1:46 PM, Alan G Isaac <alan.is...@gmail.com> >>>> >> wrote: >>>> >>> >>>> >>> On 12/6/2013 1:35 PM, josef.p...@gmail.com wrote: >>>> >>> > unary versus binary minus >>>> >>> >>>> >>> Oh right; I consider binary `-` broken for >>>> >>> Boolean arrays. (Sorry Alexander; I did not >>>> >>> see your entire issue.) >>>> >>> >>>> >>> >>>> >>> > I'd rather write ~ than unary - if that's what it is. >>>> >>> >>>> >>> I agree. So I have no objection to elimination >>>> >>> of the `-`. >>>> >> >>>> >> >>>> >> It looks like we are close to reaching a consensus on the following >>>> >> points: >>>> >> >>>> >> 1. * is well-defined on boolean arrays and may be used in preference of >>>> >> & in >>>> >> code that is designed to handle 1s and 0s of any dtype in addition to >>>> >> booleans. >>>> >> >>>> >> 2. + is defined consistently with * and the only issue is the absence of >>>> >> additive inverse. This is not a problem as long as presence of - does >>>> >> not >>>> >> suggest otherwise. >>>> >> >>>> >> 3. binary and unary minus should be deprecated because its use in >>>> >> expressions where variables can be either boolean or numeric would lead >>>> >> to >>>> >> subtle bugs. For example -x*y would produce different results from >>>> >> -(x*y) >>>> >> depending on whether x is boolean or not. In all situations, ^ is >>>> >> preferable to binary - and ~ is preferable to unary -. >>>> >> >>>> >> 4. changing boolean arithmetics to auto-promotion to int is precluded >>>> >> by a >>>> >> significant use-case of boolean matrices. >>>> > >>>> > +1 >>>> >>>> +0.5 >>>> (I would still prefer a different binary minus, but it would be >>>> inconsistent with a logical unary minus that negates.) >>>> >>> >>> The question is if the current xor behaviour can make sense? It doesn't >>> seem to make much sense mathematically? Which only leaves that `abs(x - >>> y)` is actually what a (python) programmer might expect. >>> I think I would like to deprecate at least the unary one. The ~ kind of >>> behaviour just doesn't fit as far as I can see. >> >> I haven't seen any real use cases for xor yet. >> My impression is that both plus and minus are just overflow accidents >> and not intentional. plus works in a useful way, minus as xor might be >> used once per century. >> >> I would deprecate both unary and binary minus. >> >> (And when nobody is looking in two versions from now, I would add a >> binary minus that overflows to the clipped version, so I get a set >> subtraction. :) > > Actually minus works as expected if we avoid negative overflow: > >>>> m1 - m1*m2 > array([False, False, True, False], dtype=bool) >>>> m1 * ~m2 > array([False, False, True, False], dtype=bool) >>>> m1 & ~m2 > array([False, False, True, False], dtype=bool) > > I find the first easy to read, but m1 - m2 would be one operation > less, and chain more easily m1 - m2 - m3 > m1 are mailing list subscribers, take away > m2 owners of apples, take away > m3 users of Linux > = exotic developers > > Josef > > > > > >> >>> >>>> 5. `/` is useless >>>> 6 `**` follows from 1. >> >>>>> m1 ** m2 >> array([1, 0, 1, 1], dtype=int8) >>>>> m1 ** 2 >> array([False, False, True, True], dtype=bool) >>>>> m1 ** 3 >> array([0, 0, 1, 1]) >> >> but I'm using python with an old numpy right now >>>>> np.__version__ >> '1.6.1' >> >>> >>> Both of these are currently not defined, they will just cause upcast to >>> int8. I suppose it would be possible to deprecate that upcast though >>> (same goes for most all other ufuncs/operators in principle). >> >> We would have to start the discussion again for all other >> operators/ufuncs to see if they are useful in some cases. >> For most treating as int will make sense, I guess. >> >> Josef >> >>> >>>> >>>> Josef >>>> >>>> >>>> > >>>> > -- >>>> > Nathaniel J. Smith >>>> > Postdoctoral researcher - Informatics - University of Edinburgh >>>> > http://vorpus.org >>>> > _______________________________________________ >>>> > NumPy-Discussion mailing list >>>> > NumPy-Discussion@scipy.org >>>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> _______________________________________________ >>>> NumPy-Discussion mailing list >>>> NumPy-Discussion@scipy.org >>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion >>>> >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
