Great! Minor quibble: the underlying method names should not mention `mat` (e.g. `__matmul__`); instead mentioning the shape of the operator (e.g. `__atmul__`).
We could even have a reverse mnemonic: AlTernate Multiplication
11–20 of 42 posts
Great! Minor quibble: the underlying method names should not mention `mat` (e.g. `__matmul__`); instead mentioning the shape of the operator (e.g. `__atmul__`).
We could even have a reverse mnemonic: AlTernate Multiplication
That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
Great! Minor quibble: the underlying method names should not mention `mat` (e.g. `__matmul__`); instead mentioning the shape of the operator (e.g. `__atmul__`).
many existing python infix boolean operators resolve to method names based on the meaning, rather than the symbol. e.g. `a + b` resolves to `a.__add__(b)` rather than `a.__plus__(b)`, `x * * y` resolves to `x.__pow__(y)` rather than `x.__asteriskasterisk__(y)`, say. so arguably it would be consistent to name @ after the common meaning also.
http://docs.python.org/2/reference/datamodel.html#emulating-...
on the other hand, "consistency is not necessarily a virtue: one can be consistently obnoxious" - C.A.B. Smith
that said, i like the idea that @ should be more general than just for matrices. an arbitrary infix boolean operation, neither necessarily commutative nor invertible.
even when talking about matrix multiplication, generalising slightly from arrays to abstract elements of vector spaces, and from matrices to linear transformations between vector spaces leaves you writing the same kinds of expressions that compose linear transformations without anything necessarily being represented as a matrix.
That's funny. If there is one thing that Python users do more after than diss R - it's steal from R.
Matlab is a horror but one thing they do do well is .* and * for the two multiplies.
If you're really determined, you can use `.` as an operator via __getattr__ and inspect :p
very loosely related, this reminds me of calling R functions from python that take keyword arguments with dots in their names.
>>> f(hello.world=123)
File "", line 1
SyntaxError: keyword can't be an expression
so instead: >>> f(**{'hello.world':123})Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Calling R a DSL is like insisting that Python is just a scripting language.
R is “ for statistical computing and graphics ”¹. 1) http://www.r-project.org/