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

> On Sat, Mar 15, 2014 at 6:33 PM, Joe Kington <joferking...@gmail.com>
> wrote:
> > On Sat, Mar 15, 2014 at 1:28 PM, Nathaniel Smith <n...@pobox.com> wrote:
> >>
> >> On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith <n...@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.
>
> Because tight-left doesn't seem to have much to recommend it over
> 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
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to