PEP 465: A dedicated infix operator for matrix multiplication
Hi all, I've just finished updating PEP 465 with resolutions to the various issues that were raised during the python-ideas thread about it. (The main changes since that thread are that @@ has been removed, and we now definitely propose that @ have the same precedence and associativity as *.) 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. So, I guess as far as I'm concerned, this is ready to go. Feedback welcome: http://legacy.python.org/dev/peps/pep-0465/ -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On Sun, Apr 6, 2014, at 18:41, Nathaniel Smith wrote:
Hi all,
I've just finished updating PEP 465 with resolutions to the various issues that were raised during the python-ideas thread about it. (The main changes since that thread are that @@ has been removed, and we now definitely propose that @ have the same precedence and associativity as *.)
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? :)
On Sun, Apr 6, 2014 at 11:13 PM, Benjamin Peterson <benjamin@python.org>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. There is also a way to introduce PyArrayMethods at no cost to current implementation: we can rename tp_reserved (formerly known as tp_compare) to tp_as_array.
On Mon, Apr 7, 2014, at 9:52, Alexander Belopolsky wrote:
On Sun, Apr 6, 2014 at 11:13 PM, Benjamin Peterson <benjamin@python.org>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 1:11 PM, Benjamin Peterson <benjamin@python.org> 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.
On Mon, Apr 7, 2014, at 14:22, Alexander Belopolsky wrote:
On Mon, Apr 7, 2014 at 1:11 PM, Benjamin Peterson <benjamin@python.org> 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 5:23 PM, Benjamin Peterson <benjamin@python.org>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.
On Mon, Apr 7, 2014, at 14:33, Alexander Belopolsky wrote:
On Mon, Apr 7, 2014 at 5:23 PM, Benjamin Peterson <benjamin@python.org>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.
Alexander Belopolsky wrote:
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.
That much is probably true.
Numpy arrays, IIRC, allocate all three. A dedicated PyArrayMethods struct can replace some if not all of these allocations.
I don't see how. NumPy arrays allocate all three because they override just about every method in existence. Adding another struct isn't going to eliminate the need for the existing ones. -- Greg
So, I guess as far as I'm concerned, this is ready to go. Feedback
welcome:
Hi, just curiosity: why is the second parameter 'o2' in: PyObject* PyObject_MatrixMultiply(PyObject *o1, PyObject o2) not a pointer to PyObject? Thanks in advance! francis
On Mon, Apr 7, 2014 at 7:54 PM, francis <francismb@email.de> wrote:
So, I guess as far as I'm concerned, this is ready to go. Feedback
welcome:
Hi, just curiosity: why is the second parameter 'o2' in:
PyObject* PyObject_MatrixMultiply(PyObject *o1, PyObject o2)
not a pointer to PyObject?
Because typo. Thanks for the catch :-) -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
On 2014-04-07 19:54, francis wrote:
So, I guess as far as I'm concerned, this is ready to go. Feedback
welcome:
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
Hi, 2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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")
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.) -- 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). You may mention Perl 6 meta operators, but it's not directly related: http://en.wikibooks.org/wiki/Perl_6_Programming/Meta_Operators Victor
2014-04-07 22:46 GMT+02:00 Antoine Pitrou <solipsis@pitrou.net>:
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".
I proposed to support both syntaxes, so you can write "@" if you are unable to write ×. It's not because I'm unable to write chinese that Python should no allow chinese characters in Python identifiers :-) Victor
On Mon, Apr 7, 2014 at 4:55 PM, Victor Stinner <victor.stinner@gmail.com>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 04/07/2014 01:38 PM, Victor Stinner wrote:
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 :-)
That ship has already sailed. Features have already been added at the behest of the numerical community. -- ~Ethan~
On Mon, Apr 7, 2014 at 9:38 PM, Victor Stinner <victor.stinner@gmail.com> wrote:
Hi,
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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 <njs@pobox.com> wrote:
no-one uses the pip -r requirements.txt system for deployment...
I must be among "no-one" then. :-) Yet my systems don't leave much of a footprint on PyPI because we use PIP_DOWNLOAD_CACHE and internal PyPI mirrors.
On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith <njs@pobox.com> 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 04/07/2014 02:47 PM, Alexander Belopolsky wrote:
On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith <njs@pobox.com <mailto:njs@pobox.com>> 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.
Right, and <> was removed because TOOWTDI. I am -1**3001 on adding redundant non-ASCII operators to the language. Python != APL. /arry
On 04/07/2014 03:16 PM, Alexander Belopolsky wrote:
On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings <larry@hastings.org <mailto:larry@hastings.org>> 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/
I'm now accepting the PEP, so you all can stop joking around. On Mon, Apr 7, 2014 at 3:37 PM, Larry Hastings <larry@hastings.org> wrote:
On 04/07/2014 03:16 PM, Alexander Belopolsky wrote:
On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings <larry@hastings.org> 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 8 April 2014 18:32, cjw <fn681@ncf.ca> wrote:
Guido,
I am sorry to read this.
I shall be responding more completely in a day or two.
In my view, @ and @@ are completely redundant. Both operations are already provided, * and **, in numpy.matrix.
PEP 465 provides no clear indication as to how the standard operators fail.
Note that numpy.matrix is specifically discussed in http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-n... (it's the first rejected alternative listed). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2014-04-09 12:12, Nick Coghlan wrote:
On 8 April 2014 18:32, cjw <fn681@ncf.ca> wrote:
Guido,
I am sorry to read this.
I shall be responding more completely in a day or two.
In my view, @ and @@ are completely redundant. Both operations are already provided, * and **, in numpy.matrix.
PEP 465 provides no clear indication as to how the standard operators fail.
Note that numpy.matrix is specifically discussed in http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-n... (it's the first rejected alternative listed).
To be fair to Colin, the PEP asserts that the community at large would prefer an operator to the status quo but only alludes to the reason why it does so rather than explaining it fully. Personally, I think that's a reasonable allocation of Nathaniel's time, but then I happen to have agreed with the PEP's position before it was written, and I personally witnessed all of the history myself so I don't need it repeated back to me. -- 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
On 9 Apr 2014 12:34, "Robert Kern" <robert.kern@gmail.com> wrote:
On 2014-04-09 12:12, Nick Coghlan wrote:
On 8 April 2014 18:32, cjw <fn681@ncf.ca> wrote:
Guido,
I am sorry to read this.
I shall be responding more completely in a day or two.
In my view, @ and @@ are completely redundant. Both operations are
provided, * and **, in numpy.matrix.
PEP 465 provides no clear indication as to how the standard operators fail.
Note that numpy.matrix is specifically discussed in
http://www.python.org/dev/peps/pep-0465/#rejected-alternatives-to-adding-a-n...
(it's the first rejected alternative listed).
To be fair to Colin, the PEP asserts that the community at large would
already prefer an operator to the status quo but only alludes to the reason why it does so rather than explaining it fully. Personally, I think that's a reasonable allocation of Nathaniel's time, but then I happen to have agreed with the PEP's position before it was written, and I personally witnessed all of the history myself so I don't need it repeated back to me. It could doubtless be clearer or signposted better, but the most explicit explanation of why the two type solution doesn't work is in the first section, search for "network effects". -n
On 4/8/2014 6:32 PM, cjw wrote:
Larry Hastings <https://mail.python.org/pipermail/python-dev/2014-April/133818.html> wasn't far from the truth.
Larry's note was about adding (redundant) *NON-ascii* unicode symbols, in particular × == \xd7, as in A × B, as a synonym for '@'. Various people have suggested adding various symbol synonyms, such as the Greek letter lambda for 'lambda', or a middle dot for '*'. -- Terry Jan Reedy
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: % python3 Python 3.4.0 (default, Mar 22 2014, 22:51:25) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information.
from __future__ import barry_as_FLUFL 'flufl' <> 'bdfl' True 'flufl' != 'bdfl' File "<stdin>", line 1 'flufl' != 'bdfl' ^ SyntaxError: invalid syntax
(And no, I am not recommending you actually *use* that in live code. :) flufl-ly y'rs, -Barry
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 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. 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 :-) -- Steven
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 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> -Barry
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<>?
On Apr 07, 2014, at 06:13 PM, Benjamin Peterson wrote:
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<>?
Now you get it! :) -Barry
So what? Aren't we allowed to have fun? :-) On Mon, Apr 7, 2014 at 6:06 PM, Benjamin Peterson <benjamin@python.org>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 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!
On Mon, Apr 7, 2014 at 6:06 PM, Benjamin Peterson <benjamin@python.org <mailto:benjamin@python.org>> 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.
On 7 Apr 2014 21:58, "MRAB" <python@mrabarnett.plus.com> 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 Tue, Apr 8, 2014 at 12:08 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 7 Apr 2014 21:58, "MRAB" <python@mrabarnett.plus.com> 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 :)
@ [1]
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
On Tue, Apr 8, 2014 at 12:02 PM, Steven D'Aprano <steve@pearwood.info> wrote:
You can't be serious.
I can't? Would it help if I sprinkle smileys and *winks* throughout my post?
You can be serious, Steven, but it's more likely to happen if you *don't* use smileys... *not very serious* ChrisA
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 Wed, Apr 9, 2014 at 2:49 AM, Antoine Pitrou <solipsis@pitrou.net> 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
Is it a joke, or is it serious? Where do you draw the line between wit for the purpose of making a point, and a joke that bears a kernel of truth? I've wisdom from the East and from the West, That's subject to no academic rule; You may find it in the jeering of a jest, Or distil it from the folly of a fool. I can teach you with a quip, if I've a mind; I can trick you into learning with a laugh; Oh, winnow all my folly, and you'll find A grain or two of truth among the chaff! -- WS Gilbert, via Jack Point the jester, in "Yeomen of the Guard" To many people, the concept of a benevolent dictator for life whom nobody has to obey is a joke. And yet that's exactly the truth; Guido *is* dictator, because Python is his project. But on the other hand (I'm running out of hands here), he wants his project to be useful to people, so he has to follow the paradoxical plan of Jim Hacker: "I'm their leader! I must follow them!". Joke? Truth? Neither? Both? It's really hard to say... It's even harder to draw the line when you have, for instance, Monty Python references being used as metasyntactic variables. A perfectly serious document needs to explain how to split a string into words:
"Nobody expects the Spanish Inquisition!".split() ['Nobody', 'expects', 'the', 'Spanish', 'Inquisition!']
Is that a joke, or a serious example of an important string operation? Or perchance a brilliant combination of both... and there I go quoting another jester, in this case "The Court Jester" starring Danny Kaye. Am I joking around because I'm citing four different comedies, or am I making a completely serious point? ChrisA
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
2014-04-08 3:04 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
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
Ooooh...that stings. Victor Stinner <victor.stinner@gmail.com> wrote:
2014-04-08 3:04 GMT+02:00 Steven D'Aprano <steve@pearwood.info>:
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.
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! -- Greg
On 9 Apr 2014 00:15, "Greg Ewing" <greg.ewing@canterbury.ac.nz> 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-09 1:13 GMT+02:00 Greg Ewing <greg.ewing@canterbury.ac.nz>:
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!
Oh, apparently you are not aware. It's no more an april fool, Python 3.4 has support for base85! https://docs.python.org/3.4/library/base64.html#base64.b85encode Victor PS: No, I didn't kept my base85 codec for IPv6 written in C.
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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! -- mvh/best regards Björn Lindqvist
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. Sturla
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. -- mvh/best regards Björn Lindqvist
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 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
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) -
# 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
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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? ;-) See also: https://mail.python.org/pipermail/python-ideas/2014-March/027077.html -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
2014-04-08 14:52 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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
On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-08 14:52 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
2014-04-09 17:37 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
On Wed, Apr 9, 2014 at 4:25 PM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-08 14:52 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
On Tue, Apr 8, 2014 at 9:58 AM, Björn Lindqvist <bjourne@gmail.com> wrote:
2014-04-07 3:41 GMT+02:00 Nathaniel Smith <njs@pobox.com>:
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
participants (23)
-
Alexander Belopolsky -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Björn Lindqvist -
Chris Angelico -
cjw -
Daniel Holth -
Ethan Furman -
francis -
Greg Ewing -
Guido van Rossum -
Larry Hastings -
MRAB -
Nathaniel Smith -
Nick Coghlan -
Robert Kern -
Ryan -
Steven D'Aprano -
Sturla Molden -
Terry Reedy -
Thomas Wouters -
Victor Stinner