Le 22/03/2014 19:13, Nathaniel Smith a écrit : > Hi all, > > After 88 emails we don't have a conclusion in the other thread (see > [1] for background). But we have to come to some conclusion or another > if we want @ to exist :-). So I'll summarize where the discussion > stands and let's see if we can find some way to resolve this. > > The fundamental question is whether a chain like (a @ b @ c) should be > evaluated left-to-right (left-associativity) or right-to-left > (right-associativity). > > DATA SOURCE 1: > > This isn't a democratic vote, but it's useful to get a sense of > people's intuitions. Counting messages in the other thread, opinion > seems to be pretty evenly split: > > == "Votes" for right-associativity == > Weak-right: [2] [3] [5] > Tight-right: [4] [6] > Same-right: [11] > > == "Votes" for left-associativity == > Same-left: [7] [8] [14] [15] [16] > Tight-left: [9] > Weak-left: [12] > > There's also the "grouping" option (described in [10]), but that's > received very little support (just [13]). > > DATA SOURCE 2: > > Several people have suggested that performance considerations mean > that right-to-left evaluation is more common in practice than > left-to-right evaluation. But, if we look at actual usage in Python > code, that's not what we find: when people call dot() in chains, then > they're about evenly split, and actually use the left-to-right, > left-associative order slightly more often than the right-to-left, > right-associative order: > http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069578.html > > DATA SOURCE 3: > > And if we look at other languages, then we find: > > == "Votes" for right-associativity == > <none> > > == "Votes" for left-associativity == > Same-left: Matlab, Julia, IDL, GAUSS > Tight-left: R
This is a very strong point. Lots of people come to python with a background and would be surprised if python behaves differently than other mainstream frameworks. I'll add that simpler is better, multiplications should behave the same way, and vote for same-left. > > And Mathematica uses the "grouping" approach. > > ARGUMENTS: > > The final outcome of this is that I need to write a piece of text that > says what our (at least rough) consensus is, and lays out the reasons. > So long as the "vote" is so evenly split, I can't really do this. But > I can imagine what the different pieces of text might look like. > > THE CASE FOR LEFT-ASSOCIATIVITY: > > If I were writing this text in favor of left-associativity, I'd point out: > > - "Special cases aren't special enough to break the rules". Every > single operator in Python besides ** is left-associative (and ** has > very compelling arguments for right associativity). @ does not have > similarly compelling arguments. If we were having this debate about > "*", then it'd probably be much more lopsided towards > left-associativity. So sure, there's something about @ that makes > right-associativity *more* appealing than for most other operators. > But not *much* more appealing -- left-associativity still comes out at > least slightly ahead in all of the above measures. And there are a lot > of benefits to avoiding special cases -- it gives fewer rules to > memorize, fewer rules to remember, etc. So @ may be a special case, > but it's not special enough. > > - Other languages with @ operators almost overwhelmingly use the > "same-left" rule, and I've never heard anyone complain about this, so > clearly nothing horrible will happen if we go this way. We have no > comparable experience for right-associativity. > > - Given left-associativity, then there's good agreement about the > appropriate precedence. If we choose right-associativity then it's > much less clear (which will then make things harder for experts to > remember, harder for non-experts to guess, etc.). Note that one of the > votes for right-associativity even preferred the "same-right" rule, > which is not even technically possible... > > This strikes me as a nice solid case. > > THE CASE FOR RIGHT-ASSOCIATIVITY: > > If I were writing this text in favor of right-associativity, I'd point out: > > - Because matrix multiplication has a tight conceptual association > with function application/composition, many mathematically > sophisticated users have an intuition that a matrix expression like > R S x > proceeds from right-to-left, with first S transforming x, and then R > transforming the result. This isn't universally agreed, but at the > least this intuition is more common than for other operations like 2 * > 3 * 4 that everyone reads as going from left-to-right. > > - There might be some speed argument, if people often write things > like "Mat @ Mat @ vec"? But no-one has found any evidence that people > actually do write such things often. > > - There's been discussion of how right-associativity might maybe > perhaps be nice for non-matmul applications? But I can't use those > arguments [17] [18]. > > - ...... I got nothin'. > > I am fine with any outcome here. (I'm actually listed under *both* > tight-right and same-left in the straw poll above ;-).) I'm totally > happy to go back to Guido et al and argue for right-associativity. BUT > if you all want me to do that then you need to give me some better > arguments to use :-). > > One way to do this might be to go through the ((a @ b) @ c) and (a @ > (b @ c)) examples I found (the scripts are available [19], and I can > help modify them to spit out more details), look at the actual code, > and demonstrate that the left-to-right ((a @ b) @ c) cases are mostly > ones where evaluation order doesn't matter (i.e., they could have just > as well been written the other way), and the right-to-left (a @ (b @ > c)) ones are ones where right-to-left really is better than > left-to-right. I have no idea if this is true, and it'll require some > reading of the surrounding code to figure out what the matrix shapes > are, but if it *is* true then at least that'd be something solid that > right-associativity advocates could point to. > > WHAT NOW: > > If seeing this summary laid out caused you to change your mind one way > or the other, then please reply and say so! > > If you think of some way to get more data that could favor one or the > other option (running some kind of usability experiment on people? > [20]), then please share! > > If you think of some other arguments in favor of left-associativity, > then please share! > > If you think of some other arguments in favor of right-associativity, > especially ones that are based on something besides your gut feeling, > then PLEASE PLEASE share! > > Thanks, > -n > > [1] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069444.html > [2] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069446.html > [3] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069450.html > [4] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069452.html > [5] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069455.html > [6] https://mail.python.org/pipermail/python-ideas/2014-March/027124.html > [7] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069512.html > [8] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069513.html > [9] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069467.html > [10] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069530.html > [11] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069537.html > [12] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069540.html > [13] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069571.html > [14] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069514.html > [15] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069531.html > [16] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069567.html > [17] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069527.html > [18] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069584.html > [19] https://gist.github.com/njsmith/9157645 > [20] http://mail.scipy.org/pipermail/numpy-discussion/2014-March/069584.html > --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
