On Fri, Dec 6, 2013 at 5:45 PM, Nathaniel Smith <n...@pobox.com> wrote: > 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.
I didn't argue against deprecation of the boolean minuses. I'm fine with that. Just some early lobbying, and so I can save my examples where I can google them in case I'm still around if or when we can revisit the issue. Once I turn of the python interpreter that I used for the examples, I will forget everything about weird boolean operations. One advantage of this thread is that I had to look up the math for indicator functions, and that I have a better idea where I could use logical operators instead of (linear) algebra. Josef > > -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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
