[Numpy-discussion] Deprecate boolean math operators?

josef.pktd at gmail.com josef.pktd at gmail.com
Fri Dec 6 23:19:21 EST 2013


On Fri, Dec 6, 2013 at 5:45 PM, Nathaniel Smith <njs at 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.pktd at gmail.com> wrote:
>> On Fri, Dec 6, 2013 at 4:14 PM,  <josef.pktd at gmail.com> wrote:
>>> On Fri, Dec 6, 2013 at 3:50 PM, Sebastian Berg
>>> <sebastian at sipsolutions.net> wrote:
>>>> On Fri, 2013-12-06 at 15:30 -0500, josef.pktd at gmail.com wrote:
>>>>> On Fri, Dec 6, 2013 at 2:59 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>>>> > On Fri, Dec 6, 2013 at 11:55 AM, Alexander Belopolsky <ndarray at mac.com> wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Fri, Dec 6, 2013 at 1:46 PM, Alan G Isaac <alan.isaac at gmail.com> wrote:
>>>>> >>>
>>>>> >>> On 12/6/2013 1:35 PM, josef.pktd at 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 at scipy.org
>>>>> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>> _______________________________________________
>>>>> NumPy-Discussion mailing list
>>>>> NumPy-Discussion at scipy.org
>>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> NumPy-Discussion at scipy.org
>>>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



More information about the NumPy-Discussion mailing list