[Numpy-discussion] Deprecate boolean math operators?

josef.pktd at gmail.com josef.pktd at gmail.com
Fri Dec 6 17:29:34 EST 2013


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



More information about the NumPy-Discussion mailing list