PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
1–10 of 42 posts
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#2That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#3That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
Immature computer language designers borrow; mature designers steal.
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#4Great! Minor quibble: the underlying method names should not mention `mat` (e.g. `__matmul__`); instead mentioning the shape of the operator (e.g. `__atmul__`).
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#5That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
I have not witnessed this behavior, but it would be perfectly logical to dismiss R while absorbing its features – R is a domain-specific language (statistics) while Python is a general purpose programming language. A GP language will always have a larger useful scope than a DSL.
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#6That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
I have not witnessed this behavior, but it would be perfectly logical to dismiss R while absorbing its features – R is a domain-specific language (statistics) while Python is a general purpose programming language. A GP language will always have a larger useful scope than a DSL.
Calling R a DSL is like insisting that Python is just a scripting language.
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#7That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
A %*% B != A @ B
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#8If you're really determined, you can use `.` as an operator via __getattr__ and inspect :p
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#9Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matrices, and if I do, in Eigenproblem I can just call mat.array() to get an ArrayView.
Really, the problem is that NumPy is a crappily designed library primarily intended for array ops, and is just not well suited for linear algebra.
Re: PEP 465 – Dedicated infix operators for matrix multiplication and matrix power
#10Huh? Isn't it a question of whether you are doing matrix or array ops, so the type system is the issue? I have rarely needed to do elementwide multiply on matrices, and if I do, in Eigenproblem I can just call mat.array() to get an ArrayView. Really, the problem is that NumPy is a crappily designed library primarily intended for array ops, and is just not well suited for linear algebra.
This is addressed in the proposal:
Use a second type that defines __mul__ as matrix multiplication:
As discussed above (Background: What's wrong with the status quo?), this has been tried this for many years via the numpy.matrix type (and its predecessors in Numeric and numarray). The result is a strong consensus among both numpy developers and developers of downstream packages that numpy.matrix should essentially never be used, because of the problems caused by having conflicting duck types for arrays. (Of course one could then argue we should only define __mul__ to be matrix multiplication, but then we'd have the same problem with elementwise multiplication.) There have been several pushes to remove numpy.matrix entirely; the only counter-arguments have come from educators who find that its problems are outweighed by the need to provide a simple and clear mapping between mathematical notation and code for novices (see Transparent syntax is especially crucial for non-expert programmers). But, of course, starting out newbies with a dispreferred syntax and then expecting them to transition later causes its own problems. The two-type solution is worse than the disease.