Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Nathaniel Smith
On Sun, Mar 9, 2014 at 8:44 PM, William Stein wrote: > On Sun, Mar 9, 2014 at 12:40 PM, wrote: >> On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: >>> >>> I think the following piece should be made more clear, I don't >>> understand what you're trying to say here: >>> >>> The probl

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Jeroen Demeyer
On 2014-03-09 20:40, n...@vorpus.org wrote: Indeed, it's clear from everyone's responses here that I at least need to add a new section talking about these things explicitly, and also about why elementwise-* is actually used so often in practice in numeric computation (as opposed dto symbolic com

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Jeroen Demeyer
On 2014-03-09 20:40, n...@vorpus.org wrote: In brief, the issue is that elementwise-* is a fine convention and you can use it to write useful code, and matrix-multiply-* is a fine convention and you can use it to write useful code, but if you then try to glue those two pieces of code together int

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread William Stein
On Sun, Mar 9, 2014 at 12:40 PM, wrote: > On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: >> >> I think the following piece should be made more clear, I don't >> understand what you're trying to say here: >> >> The problem is that the presence of two different duck-types for numeri

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread njs
On Sunday, March 9, 2014 7:20:50 PM UTC, Jeroen Demeyer wrote: > > I think the following piece should be made more clear, I don't > understand what you're trying to say here: > > The problem is that the presence of two different duck-types for numeric > data -- one where * means matrix multiply,

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Jeroen Demeyer
I think the following piece should be made more clear, I don't understand what you're trying to say here: The problem is that the presence of two different duck-types for numeric data -- one where * means matrix multiply, and one where * means elementwise multiplication -- make it impossible t

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Jeroen Demeyer
On 2014-03-09 18:19, Jeroen Demeyer wrote: In your PEP, you say that using * for matrix multiplication is a bad idea, but without any justification (the only justification is variations on "it's a bad idea" without reasons). From reading your PEP, it's clear that you don't like numpy.matrix but

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread Jeroen Demeyer
On 2014-03-09 16:09, n...@vorpus.org wrote: I definitely want to hear your feedback. I completely agree with John Cremona: please keep * for matrix multiplication. Why not add a new dedicated operator for elementwise multiplication and use * for matrix multiplication? In your PEP, you say tha

Re: [sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread John Cremona
I find it very hard to imagine Sage using anything other than * (as in A*B) for normal matrix multiplication, as anything else would alienate all of its mathematical users. I would have no reason at all ever to have an element-wise matrix product! John Cremona On 9 March 2014 15:09, wrote: > G

[sage-devel] RFC: draft PEP for adding @ as a matrix multiplication operator to Python

2014-03-09 Thread njs
Greetings, Sage Ones, Some of you may have already seen this, but I've started working on a draft PEP for adding a dedicated operator for matrix multiplication to Python: https://github.com/numpy/numpy/pull/4351 https://github.com/njsmith/numpy/blob/matmul-pep/doc/neps/return-of-revenge-of-m