[Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

[Nick Coghlan]

On 8 April 2014 21:24, Björn Lindqvist <bjourne at gmail.com> wrote:
> 2014-04-08 12:23 GMT+02:00 Sturla Molden <sturla.molden at gmail.com>:
>> Björn Lindqvist <bjourne at gmail.com> wrote:
>>
>>> import numpy as np
>>> from numpy.linalg import inv, solve
>>>
>>> # Using dot function:
>>> S = np.dot((np.dot(H, beta) - r).T,
>>>            np.dot(inv(np.dot(np.dot(H, V), H.T)), np.dot(H, beta) - r))
>>>
>>> # Using dot method:
>>> S = (H.dot(beta) - r).T.dot(inv(H.dot(V).dot(H.T))).dot(H.dot(beta) - r)
>>>
>>> Don't keep your reader hanging! Tell us what the magical variables H,
>>> beta, r and V are. And why import solve when you aren't using it?
>>> Curious readers that aren't very good at matrix math, like me, should
>>> still be able to follow your logic. Even if it is just random data,
>>> it's better than nothing!
>>
>> Perhaps. But you don't need to know matrix multiplication to see that those
>> expressions are not readable. And by extension, you can still imagine that
>> bugs can easily hide in unreadable code.
>>
>> Matrix multiplications are used extensively in anything from engineering to
>> statistics to computer graphics (2D and 3D). This operator will be a good
>> thing for a lot of us.
>
> All I ask for is to be able to see that with my own eyes. Maybe there
> is some drastic improvement I can invent to make the algorithm much
> more readable? Then the PEP:s motivation falls down. I don't want to
> have to believe that the code the pep author came up with is the most
> optimal. I want to prove that for myself.

Note that the relationship between the CPython core development team
and the Numeric Python community is based heavily on trust - we don't
expect them to teach us to become numeric experts, we just expect them
to explain themselves well enough to persuade us that a core language
or interpreter change is the only realistic way to achieve a
particular goal. This does occasionally result in quirky patterns of
feature adoption, as things like extended slicing, full rich
comparison support, ellipsis support, rich buffer API support, and now
matrix multiplication support, were added for the numeric community's
benefit without necessarily offering any immediately obvious benefit
for those not using the numeric Python stack - it was only later that
they became pervasively adopted throughout the standard library (with
matmul, for example, a follow on proposal to allow tuples, lists and
arrays to handle vector dot products may make sense).

This particular problem has been kicking around long enough, and is
sufficiently familiar to several of us, that what's in the PEP already
presents a compelling rationale for the *folks that need to be
convinced* (which is primarily Guido, but if enough of the other core
devs think something is a questionable idea, we can often talk him out
of it - that's not the case here though).

Attempting to condense that preceding 10+ years of history *into the
PEP itself* wouldn't be a good return on investment - the links to the
earlier PEPs are there, as are the links to these discussion threads.

Cheers,
Nick.

P.S. We've been relatively successful in getting a similar trust based
dynamic off the ground for the packaging and distribution community
over the past year or so. The next big challenge in trust based
delegation for the core development team will likely be around a
Python 3.5+ only WSGI 2.0 (that can assume the Python 3 text model,
the restoration of binary interpolation, the availability of asyncio,
etc), but most of the likely principals there are still burned out
from the WSGI 1.1 debate and the Python 3 transition in general :(

>
>
> --
> mvh/best regards Björn Lindqvist
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia