[Numpy-discussion] Deprecate boolean math operators?

josef.pktd at gmail.com josef.pktd at gmail.com
Sun Dec 8 09:40:39 EST 2013


On Fri, Dec 6, 2013 at 11:25 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
>
> On Fri, Dec 6, 2013 at 2: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.
>
>
> Using it instead of '+' yields a boolean ring instead of semi-ring. Papers
> from the first quarter of the last century used it pretty often on that
> account, hence 'sigma-rings', etc. Eventually the simplicity of the
> inclusive or overcame that tendency.
>
>> 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.
>
>
> It's certainly weird given that '+' means the inclusive or. I think '^' is
> much preferable.
> Although it makes some sense if one can keep the semantics straight.
> Complicated, though.

I'm looking at the test failure with allclose

Looks like - as xor still makes sense in some cases, because it
doesn't need special cases for equality checks for example.
x - y == 0 iff x == y

What happens to np.diff?

>>> np.diff(m1)
array([False,  True, False], dtype=bool)

I'm using code like that to get the length of runs in a runstest.

But in my current code, I actually have astype(int) and also use
floats later on.
If I read my (incompletely documented) code correctly, I needed also
the sign not just the run length.

Just another argument what minus could be.

Josef

>
>>
>> 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. :)
>
>
> Where is '\' when you need it?
>
> <snip>
>
> Chuck
>
> _______________________________________________
> 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