On Sat, Mar 15, 2014 at 12:40 PM, Nathaniel Smith <njs@pobox.com> wrote:

On Sat, Mar 15, 2014 at 6:33 PM, Joe Kington <joferkington@gmail.com> wrote:Because tight-left doesn't seem to have much to recommend it over

> On Sat, Mar 15, 2014 at 1:28 PM, Nathaniel Smith <njs@pobox.com> wrote:

>>

>> On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith <njs@pobox.com> wrote:

>> > Hi all,

>> >

>> > Here's the main blocker for adding a matrix multiply operator '@' to

>> > Python:

>> > we need to decide what we think its precedence and associativity should

>> > be.

>>

>> Another data point that might be useful:

>>

>> Matlab: same-left

>>

>>

>> R: tight-left

>

>

>

> I was going to ask this earlier, but I was worried I was missing something

> major.

>

> Why was "tight-left" not an option?

>

>

> This means that if you don't use parentheses, you get:

> a @ b @ c -> (a @ b) @ c

> a * b @ c -> a * (b @ c)

> a @ b * c -> (a @ b) * c

>

>

> In my (very inexperienced) opinion, it seems like the most intuitive option.

same-left, and all else being equal having fewer levels of precedence

is usually considered a good thing. Unless I'm missing something. If

we do decide that tight-left is best then we could certainly advocate

for it.

I wouldn't read too much into R's choice; they don't actually define a

separate precedence level for matrix multiplication specifically. They

have a single precedence level for all "special" (user-defined)

operators, and matrix multiplication happens to be one of these.

(Their versions of // and % are also "special", but I don't think

anyone would expect // to bind more tightly than / if one were

choosing precedences on a case-by-case basis.)

Just to throw something new into the mix

u@v@w = u@(v@w) -- u@v is a dyadic matrix

u@v -- is a scalar

It would be nice if u@v@None, or some such, would evaluate as a dyad. Or else we will still need the concept of row and column 1-D matrices. I still think v.T should set a flag so that one can distinguish u@v.T (dyad) from u.T@v (inner product), where 1-D arrays are normally treated as column vectors.

Chuck