<div dir="ltr"><div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On Jun 26, 2017 6:56 PM, "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail-m_-3364961268249511159quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail-m_-3364961268249511159elided-text"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><div><div class="gmail-m_-3364961268249511159m_7082068897801396468h5"><br>
On 27 Jun 2017, 9:25 AM +1000, Nathaniel Smith <<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>>, wrote:</div></div></div></div></blockquote></div><div class="gmail-m_-3364961268249511159quoted-text"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div name="messageReplySection" style="font-size:14px;font-family:-apple-system,BlinkMacSystemFont,sans-serif"><blockquote type="cite" style="margin:5px;padding-left:10px;border-left:thin solid rgb(26,188,156)"><div><div class="gmail-m_-3364961268249511159m_7082068897801396468h5">
I guess my preference would be:<br>
1) deprecate +<br>
2) move binary - back to deprecated-but-not-an-error<br>
3) fix np.diff to use logical_xor when the inputs are boolean, since<br>
that seems to be what people expect<br>
4) keep unary - as an error<br>
<br>
And if we want to be less aggressive, then a reasonable alternative would be:<br>
1) deprecate +<br>
2) un-deprecate binary -<br>
3) keep unary - as an error<br>
<br></div></div></blockquote></div></div></blockquote></div></div><br></div><div class="gmail_extra">Using '+' for 'or' and '*' for 'and' is pretty common and the variation of '+' for 'xor' was common back in the day because 'and' and 'xor' make boolean algebra a ring, which appealed to mathematicians as opposed to everyone else ;)</div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">'+' for 'xor' and '*' for 'and' is perfectly natural; that's just + and * in Z/2. It's not only a ring, it's a field! '+' for 'or' is much weirder; why would you use '+' for an operation that's not even invertible? I guess it's a semi-ring. But we have the '|' character right there; there's no expectation that every weird mathematical notation will be matched in numpy... The most notable is that '*' doesn't mean matrix multiplication.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-3364961268249511159quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"> </div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-3364961268249511159quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">You can see the same progression in measure theory where eventually intersection and xor (symmetric difference) was replaced with union and complement. Using '-' for xor is something I hadn't seen outside of numpy, but I suspect it must be standard somewhere.  I would leave '*' and '+' alone, as the breakage and inconvenience from removing them would be significant.<br></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">'*' doesn't bother me, because it really does have only one sensible behavior; even built-in bool() effectively uses 'and' for '*'.</div><div dir="auto"><br></div><div dir="auto">But, now I remember... The major issue here is that some people want dot(a, b) on Boolean matrices to use these semantics, right? Because in this particular case it leads to some useful connections to the matrix representation for logical relations [1]. So it's sort of similar to the diff() case. For the basic operation, using '|' or '^' is fine, but there are these derived operations like 'dot' and 'diff' where people have different <span class="sewfzhilarlhqtr"></span><span class="sewud5soinmlg6u"></span>expectations.</div><div dir="auto"><br></div><div dir="auto">I guess Juan's example of 'sum' is relevant here too. It's pretty weird that if 'a' and 'b' are one-dimensional boolean arrays, 'a @ b' and 'sum(a * b)' give totally different results.<br><br></div><div>So that's the fundamental problem: there are a ton of possible conventions that are each appealing in one narrow context, and they all contradict each other, so trying to shove them all into numpy simultaneously is messy.<br></div><div dir="auto"><br></div><div>I'm glad we at least seem to have succeeded in getting rid of unary '-', that one was particularly indefensible in the context of everything else :-). For the rest, I'm really not sure whether it's better to deprecate everything and tell people to use specialized tools for specialized purposes (e.g. add a 'logical_dot'), or to special case the high-level operations people want (make 'dot' and 'diff' continue to work, but deprecate + and -), or just leave the whole incoherent mish-mash alone.<br></div><div dir="auto"><br></div><div dir="auto">-n<br><br>[1] <a href="https://en.wikipedia.org/wiki/Logical_matrix">https://en.wikipedia.org/wiki/Logical_matrix</a><br></div></div>
</div>