On Apr 8, 2014 2:39 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
>
> On 8 April 2014 21:24, Björn Lindqvist <bjourne@gmail.com> wrote:
> > 2014-04-08 12:23 GMT+02:00 Sturla Molden <sturla.molden@gmail.com>:
> >> Björn Lindqvist <bjourne@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

Just to give an indication how long, this came up in the discussion around PEP 203, too. Fourteen years ago. In fact, augmented assignment could be listed as one of the features added for the benefit of numeric array folks.

At the time, the discussions were not as focused and the proposals much more pie-in-the-sky (the idea to have all of @*, @+, @-, @%, etc, as individual operators specifically stuck in my mind.) This is a much more grounded proposal.

> 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@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@gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/thomas%40python.org