On Mon, Apr 7, 2014, at 9:52, Alexander Belopolsky wrote:

On Sun, Apr 6, 2014 at 11:13 PM, Benjamin Peterson wrote:

...

...

I believe this leaves only one open question, which is where exactly to stick the new matmul slots into PyTypeObject. This is the kind of fiddly detail that can easily be settled later if the PEP is accepted, though.

I don't see what it shouldn't be in PyNumberMethods. Surely, we're not going to get a flood of requests for more matrix operators, are we? :)

We may want to introduce say PyArrayMethods even if we don't introduce more array operators. We can populate that struct with array-specific alternatives for PySequence/PyMappingMethods and eliminate the need for dynamically created array types to allocate those.

Why would we want to do that?

On Mon, Apr 7, 2014, at 14:22, Alexander Belopolsky wrote:

On Mon, Apr 7, 2014 at 1:11 PM, Benjamin Peterson wrote:

...

...

We can populate that struct with array-specific alternatives for PySequence/PyMappingMethods and eliminate the need for dynamically created array types to allocate those.

Why would we want to do that?

I assume "that" means "create array types dynamically." There are many reasons to do that in modern array implementations. See for example ctypes. A more practical reason however is that I believe PySequence/PyMappingMethods are cloned whenever a subclass of a sequence/mapping type is created. For better or worse, subclassing of numpy arrays is a popular sport these days.

I can understand why creating new array types is good fun, but how is creating a new struct helpful?

On Mon, Apr 7, 2014, at 14:33, Alexander Belopolsky wrote:

On Mon, Apr 7, 2014 at 5:23 PM, Benjamin Peterson wrote:

...

I can understand why creating new array types is good fun, but how is creating a new struct helpful?

We can start by reviewing the reasons for having separate PyNumber/PySequence/PyMappingMethods structures. I believe that one of the reasons is that many types need to allocate only one of the three. Numpy arrays, IIRC, allocate all three. A dedicated PyArrayMethods struct can replace some if not all of these allocations.

I can't say it seems like a terrible important thing to optimize to me.

On 2014-04-07 19:54, francis wrote:

...

So, I guess as far as I'm concerned, this is ready to go. Feedback

welcome:

...

http://legacy.python.org/dev/peps/pep-0465/

Hi, just curiosity: why is the second parameter 'o2' in:

PyObject* PyObject_MatrixMultiply(PyObject *o1, PyObject o2)

not a pointer to PyObject?

Typo, I'm fairly certain. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Le 07/04/2014 22:38, Victor Stinner a écrit :

It would be nice to support A × B too, because it's much more readable. You can configure a keyword to write arbitrary characters.

Well, IMHO Python code should be writable without having to "configure your keyboard". Regards Antoine.

On Mon, Apr 7, 2014 at 4:55 PM, Victor Stinner wrote:

I proposed to support both syntaxes, so you can write "@" if you are unable to write ×.

It won't be obvious for the readers of the code whether × stands for @ or for *. Both * and @ are ASCII approximations to proper mathematical typesetting. It may be added to the PEP that × is almost never used for dot or scalar product. In vector context it is commonly used for vector product a.k.a. cross product.

On Mon, Apr 7, 2014 at 9:38 PM, Victor Stinner wrote:

Hi,

2014-04-07 3:41 GMT+02:00 Nathaniel Smith :

...

So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/

I'm not convinced yet that there is enough usage of Python in mathematical world to modify the Python language to add a new operator. Python is used for a lot of different use cases, in a lot of domains. I'm not sure that it's a good thing to modify the *language* for a specific domain. But you can do a lot without modify the language :-)

I'm a little bit surprised by the "Count of Python source files on Github matching given search terms" table, it's very different from these statistics: http://python3wos.appspot.com/

Where are six, pytz, mock, webob, etc. in your table? (all modules which come before "numpy" in the "Python 3 Wall of Superpowers")

They'd be down in bottom half, with ~30-50k total. (You can check easily by running the search yourself :-).) PyPI downloads are not a great proxy for usage, for a number of reasons. The way to get really big on PyPI downloads is to be depended on by a lot of projects get deployed often :-). This is very different from being used directly in lots of different files. Consider also that probably a majority of numpy users get numpy (and python, etc.) by using one of the many specialized scientific python distributions that different companies and people maintain: http://www.scipy.org/install.html#scientific-python-distributions and also that using pip to install scientific packages basically never works, so no-one uses the pip -r requirements.txt system for deployment...

...

But isn't it weird to add an operator with no stdlib uses?

I agree that it sounds weird :-) Maybe we should start by putting some parts of numpy/scipy/sage/pylab/panda into the stdlib? (I'm not sure that the new statistics module is such beginning.)

There are many reasons why this is not a great idea in the short term -- including the problem mentioned a few sentences after the one you quoted, which is that @ seems to be a precondition to getting consensus on a numeric array duck type, which in turn would be a precondition to putting an array type into the stdlib ;-). So while putting numpy into the stdlib is probably a bad idea regardless, even if we wanted to do it there's a chicken-and-egg problem.

--

It would be nice to support A × B too, because it's much more readable. You can configure a keyword to write arbitrary characters. For example, on Linux you can write × using "Compose x x" if you configured the Compose key. Or sometimes, you can replace "@" with "×" using your favorite text editor (copy-paste from another script, from a webpage, or something else).

Sounds like a pretty major violation of TOOWTDI... -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org

On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith wrote:

...

It would be nice to support A × B too, because it's much more readable. You can configure a keyword to write arbitrary characters. For example, on Linux you can write × using "Compose x x" if you configured the Compose key. Or sometimes, you can replace "@" with "×" using your favorite text editor (copy-paste from another script, from a webpage, or something else).

Sounds like a pretty major violation of TOOWTDI...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings wrote:

I am -1**3001 on adding redundant non-ASCII operators to the language.

...

...

-1**3001 -1

:-)

I'm now accepting the PEP, so you all can stop joking around. On Mon, Apr 7, 2014 at 3:37 PM, Larry Hastings wrote:

On 04/07/2014 03:16 PM, Alexander Belopolsky wrote:

On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings wrote:

...

I am -1**3001 on adding redundant non-ASCII operators to the language.

...

...

...

-1**3001 -1

:-)

http://www.quickmeme.com/img/9c/9cb11f91cfda4d161c44e5b2c18c242c60411ac42dc8...

*/arry*

_______________________________________________ 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/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:

On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote:

...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

PEP 401 to the rescue:

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

On Mon, Apr 7, 2014, at 18:04, Steven D'Aprano wrote:

On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote:

...

On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:

...

On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote:

...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

PEP 401 to the rescue:

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

-1 on removal.

You can't be serious.

It makes a nice Easter Egg, especially now that "import this" has become less of an Easter Egg and more of a standard Python module :-)

It's a terrible Easter Egg because it's basically a CPython core developer in-joke.

On Mon, Apr 7, 2014, at 18:11, Barry Warsaw wrote:

On Apr 07, 2014, at 06:06 PM, Benjamin Peterson wrote:

...

...

...

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

-1 on removal.

You can't be serious.

Hey man, don't break all my code! <wink>

Surely, you mean <>wink<>?

So what? Aren't we allowed to have fun? :-) On Mon, Apr 7, 2014 at 6:06 PM, Benjamin Peterson wrote:

On Mon, Apr 7, 2014, at 18:04, Steven D'Aprano wrote:

...

On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote:

...

On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:

...

On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote:

...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

PEP 401 to the rescue:

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

-1 on removal.

You can't be serious.

...

It makes a nice Easter Egg, especially now that "import this" has become less of an Easter Egg and more of a standard Python module :-)

It's a terrible Easter Egg because it's basically a CPython core developer in-joke. _______________________________________________ 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/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

On 7 Apr 2014 21:58, "MRAB" wrote:

On 2014-04-08 02:45, Guido van Rossum wrote:

...

So what? Aren't we allowed to have fun? :-)

Next thing you know, he'll be threatening people with The Comfy Chair!

You may want to take a look at the packaging metadata 2.0 spec ;) I was also going to add a +1 for the actual topic of this thread, but Guido's acceptance of the PEP rendered that point rather moot :) Cheers, Nick.

On Mon, Apr 07, 2014 at 06:06:17PM -0700, Benjamin Peterson wrote:

On Mon, Apr 7, 2014, at 18:04, Steven D'Aprano wrote:

...

On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote:

...

On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote:

...

On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote:

...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

PEP 401 to the rescue:

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

-1 on removal.

You can't be serious.

I can't? Would it help if I sprinkle smileys and *winks* throughout my post?

...

It makes a nice Easter Egg, especially now that "import this" has become less of an Easter Egg and more of a standard Python module :-)

It's a terrible Easter Egg because it's basically a CPython core developer in-joke.

Are we really going to start arguing about humour and what makes a good easter egg? I suppose next you're going to tell me that Monty Python isn't very funny. It is precisely because it is a subtle in-joke that makes it a good easter egg. It's not difficult to find, just import __future__ as a regular module and call dir(__future__), so the fun is not in discovering the egg, but in working out what it does and what it means. Many, many more people take part in the CPython core developer culture than just the core developers themselves. Look at the readership of this mailing list, which is open to the public and has regular posters who aren't core developers. In-jokes like Guido as the BDFL and Tim Peter's "adverb-phrase-ly 'yrs" signatures have become widely known throughout the Python community. Barry as FLUFL is less well known, but still accessible to anyone willing to put the effort in. These days, when almost any in-joke is only a quick google search away from being explained, that effort is trivial. So yes, I am serious. -- Steven

Le 08/04/2014 04:02, Steven D'Aprano a écrit :

Many, many more people take part in the CPython core developer culture than just the core developers themselves. Look at the readership of this mailing list, which is open to the public and has regular posters who aren't core developers. In-jokes like Guido as the BDFL

Is it a joke? I thought Guido was the BDFL for real :-o Regards Antoine.

On Tue, Apr 08, 2014 at 06:49:13PM +0200, Antoine Pitrou wrote:

Le 08/04/2014 04:02, Steven D'Aprano a écrit :

...

Many, many more people take part in the CPython core developer culture than just the core developers themselves. Look at the readership of this mailing list, which is open to the public and has regular posters who aren't core developers. In-jokes like Guido as the BDFL

Is it a joke? I thought Guido was the BDFL for real :-o

The joke is the title, not the role. https://www.artima.com/weblogs/viewpost.jsp?thread=235725 -- Steven

Ooooh...that stings. Victor Stinner wrote:

2014-04-08 3:04 GMT+02:00 Steven D'Aprano :

...

...

...

...

Python used to have an alias <> for != and I for one miss <> in 3.x. I don't think TOOWTDI should be the last word in this debate.

PEP 401 to the rescue:

It occurs to me that since that Aprils' Fools joke is many years old now, we should remove it.

-1 on removal.

It makes a nice Easter Egg, especially now that "import this" has become less of an Easter Egg and more of a standard Python module :-)

I'm also against the removal of jokes! Removing the antigravity module would break the backward compatibility! from __futures__ import braces!

Ten years ago, we asked me to add the "IPv6" feature in a firewall. I started to implement the RFC 1924 to have a full support. In the C language, handling the base 85 is not simple because you need arithmetic operations on large integers (128 bits). https://tools.ietf.org/html/rfc1924

3 days later, when my code was working, I saw the date of the RFC... I was young and naive :-)

Victor _______________________________________________ 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/rymg19%40gmail.com

-- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

On 9 Apr 2014 00:15, "Greg Ewing" wrote:

Victor Stinner wrote:

...

I started to implement the RFC 1924 to have a full support.

3 days later, when my code was working, I saw the date of the RFC...

Do you still have the code? It needn't go to waste -- this would make a fine addition to Python's easter egg basket!

Even if not it would be pretty easy to reimplement - maybe 10-20 loc. If you look the joke is they represent 128 bit ipaddrs in a base that's relatively prime to 2, necessitating a full bignum library just for io. But python has bignums for free... -n

2014-04-08 12:23 GMT+02:00 Sturla Molden :

Björn Lindqvist 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. -- mvh/best regards Björn Lindqvist

On Apr 8, 2014 2:39 PM, "Nick Coghlan" wrote:

On 8 April 2014 21:24, Björn Lindqvist wrote:

...

2014-04-08 12:23 GMT+02:00 Sturla Molden :

...

Björn Lindqvist 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) -

...

...

...

# 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

...

...

expressions are not readable. And by extension, you can still imagine

r)) those 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

2014-04-08 14:52 GMT+02:00 Nathaniel Smith :

On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist wrote:

...

2014-04-07 3:41 GMT+02:00 Nathaniel Smith :

...

So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/

Couldn't you please have made your motivation example actually runnable?

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!

There's a footnote that explains the math in more detail and links to the real code this was adapted from. And solve is used further down in the section. But running it is really what you want, just insert:

beta = np.random.randn(10) H = np.random.randn(2, 10) r = np.random.randn(2) V = np.random.randn(10, 10)

Does that help? ;-)

Thanks! Yes it does help. Then I can see that this expression: np.dot(H, beta) - r Evaluates to a vector. And a vector transposed is the vector itself. So the .T part in this expression np.dot(H, beta) - r).T is unnecessary, isn't it? -- mvh/best regards Björn Lindqvist

2014-04-09 17:37 GMT+02:00 Nathaniel Smith :

On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist wrote:

...

2014-04-08 14:52 GMT+02:00 Nathaniel Smith :

...

On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist wrote:

...

2014-04-07 3:41 GMT+02:00 Nathaniel Smith :

...

So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/

Couldn't you please have made your motivation example actually runnable?

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!

There's a footnote that explains the math in more detail and links to the real code this was adapted from. And solve is used further down in the section. But running it is really what you want, just insert:

beta = np.random.randn(10) H = np.random.randn(2, 10) r = np.random.randn(2) V = np.random.randn(10, 10)

Does that help? ;-)

Thanks! Yes it does help. Then I can see that this expression:

np.dot(H, beta) - r

Evaluates to a vector. And a vector transposed is the vector itself. So the .T part in this expression np.dot(H, beta) - r).T is unnecessary, isn't it?

In univariate regressions r and beta are vectors, and the .T is a no-op. The formula also works for multivariate regression, in which case r and beta become matrices; in this case the .T becomes necessary.

Then what is the shape of those variables supposed to be? The earlier definitions you gave isn't enough for this general case. -- mvh/best regards Björn Lindqvist