[Python-ideas] [RFC] draft PEP: Dedicated infix operators for matrix multiplication and matrix power

[Andrew Barnert]

From: Nathaniel Smith <njs at pobox.com>
Sent: Thursday, March 13, 2014 10:05 PM


>On Fri, Mar 14, 2014 at 4:03 AM, Andrew Barnert <abarnert at yahoo.com> wrote:


[snip, here and elsewhere]

>The numeric community has many talents, but crossing the cultural
>divide with upstream is not really a speciality...

Well, you've fixed that here.

>> One thing that always comes up is a suggestion for using Unicode.
>
>We don't really have a strong opinion on which character is used. It
>is nice if it's easy to type, though -- esp. because in many ways it's
>already beginners who suffer the brunt of the elmul/matmul issues, and
>beginners are exactly the people for whom figuring out how to type
>some stupid character is a prohibitive speed bump. (Scientific python
>has a very large ongoing stream of newbie programmers.) And I don't
>know that any of the Unicode characters are actually better. In real
>math the two operations are distinguished by context, so there's no
>existing character with the right meaning that we can steal. In some
>ways having an unusual character for this is better, because it
>indicates a special-case operation. If the two multiplication
>characters are * and ×, then how do you remember which is which? But
>if they're * and @, then it's easy to remember that * is the
>general-use one, and @ is the special non-commutative matrix
>multiplication one.

Honestly, that sounds like a strong negative opinion, with good motivations, not no opinion,

The argument for Unicode is generally "readability is more important than writability," all things being equal. The traditional counter to that is that all things aren't equal, as it's still way too hard for novices to write Unicode characters. But adding the additional rationale that there is no obvious Unicode character for this operator certainly strengthens the case for @.

>It's not like new operators are being added to Python every week and
>we need to start scraping the bottom of the barrel for new characters.
>ASCII gets the job done, has some minor upsides, and no real
>downsides.

Well, we have just about two ASCII characters left, @ and ?, so we really are scraping the bottom of the barrel. But you made a good argument why this is worthy of one of those two characters.

>> Also, how do other general purpose programming languages solve this? Surely people do matrix math in Haskell and C++, at least? Do they just use separate types for matrices and arrays because they don't have to worry about duck typing (being statically-typed languages)? Do they just avoid mixing libraries together to avoid the problem? Or have people attempted to reuse % or other operators? Or (doesn't apply to C++, but does to Haskell) do they use spelled-out infix functions like `mmul` instead of trying to come up with symbolic operators? A lot of those answers wouldn't tell us anything more than "their experience isn't relevant to Python", but it would be nice to know that at least.
>
>I'm not an expert on Haskell and C++ matrix libraries -- perhaps
>someone else will speak up -- but Haskell's extensible infix system
>and static typing do seem like they put them in a pretty different
>design space. And I'm skeptical that there exist Haskell libraries
>with anything like numpy's maturity, though I'll be delighted to be
>proven wrong.

From what I can tell, it's more common to implement matrix libraries in Haskell than to use them. Probably because Haskell is more of a research and/or teaching language than a language you'd expect, say, physicists to use. But I was hoping someone would actually know that, rather than just guess…

>Eigen is maybe the most popular C++ matrix/array library right now,
>and AFAICT from their docs they use a system where there's one "array"
>type that *only* supports elementwise multiplication, and one "matrix"
>type that *only* supports matrix multiplication, and if you want both
>operations you have to cast back and forth. This seems a bit annoying
>to me, but not as deadly as it is in Python -- in C++ the static type
>system means they can at least fob off the work of keeping track of
>which variables are which type, and doing conversions at function
>boundaries, onto the compiler. In Python these conversions have to
>happen by hand, and the two-type solution is just not workable.


Yes, that's why I suspected that C++ experience would not be applicable to Python. Assigning a matrix value to an array variable, or passing it to an array function, can be an implicit (but still obvious) conversion. And the way they'd solve the same problems Python solves with duck typing would be would generic functions, which is pretty different from duck-typed functions. And I'd expect that most other static languages are similar. But it might be worth adding to the PEP if you actually know the answer rather than just suspecting.

>In general, I doubt there's huge amounts of experience to steal from
>other languages, because Python is in a unique place: AFAICT it's the
>only general purpose language that has ever made serious inroads
>against the specialized numeric languages (Matlab, R, GAUSS, IDL,
>etc.) on their home territory. So we're breaking new ground here. (All
>those languages do have separate infix operators for elementwise and
>matrix multiplication; they all involve horrible names like ".*" or
>"%*%" and all kinds of weird inconsistencies.)

You could be right. Most of the core low-level libraries are in C, and C++ programmers have a habit of just using C libraries with their C APIs rather than wrapping them in generic/OO C++ APIs… (Honestly, I think automatic C compatibility is one of the biggest problems with C++, not its biggest strength. In Python, it's easy to wrap a C library, and you have to do it, so you do it and end up with a great API; in C++, it's easy to wrap a C library, but you don't have to, so you end up using it C-style and losing all the benefits of C++.)