Am 10.03.2014 13:30, schrieb [email protected]:
[...] I also don't want
to forget the Python scientific data processing world, which (a) is where
these problems actually occur (because they make heavy use of both
elementwise and matrix multiplication),
Ack.
> (b) has, after a debate that's been
going on for 15 years back to the early releases of Numeric, overwhelmingly
settled on using * for elementwise multiplication,
I'm very, very sceptical, both of the claim (the PEP certainly does not
make a strong case here) and of the usefulness of that.
The only use case that I see for element-wise multiplication is the
scalar product, which is a very weak case for @ because you still need
the Python loop (or reduce() call) to add the products.
Besides, the number of scalar product implementations you write is very
limited - once per library, possibly with a handful of variants. Hardly
enough to make "a clumsy loop" an argument of any weight.
Prove me wrong if you can :-)
> (c) involves something
like 20-30x more downstream users (judging by metrics like pypi downloads,
github code search for "import numpy" versus "import sympy", number of pypi
packages declaring a dependency on numpy versus sympy, etc.). So I just
don't think I'm going to get very far if I go back to the numpy list and
say "Alright, guys! We're switching * to mean matrix multiplication to make
the mathematicians happy!".
Well, you came here to get our perspective.
No skin off my nose if you dislike it, or ignore it.
I did mention that I'm rather sceptical about the reported "overwhelming
support"; 2 out of 5 projects already implemented it, supposedly one of
them is your own; 2 are reported as "planning to implement it".
"Overwhelming support" and "general consensus" looks quite differently.
And I hate being dragged into a bandwagon by promises of overwhelming
support that has been generated as a self-fulfilling prophecy; that's
politics.
So... no general consensus. In fact, we don't care much about the PEP,
we live with * for multiplication just fine, and while we acknowledge
the usefulness of matrix multiplication, we do think that it's no
service to Python if every Python project promotes its set of pet
operators - I bet the network guys could use some, generating output is
another area (an operator for concatenating into an output stream would
be more generally useful than matrix multiplication).
So the question is, what's the best system that balances between all these
different communities and their constraints? Right now my feeling is that
the PEP's proposal is the best available option, and if that means that
sympy/sage will just ignore the PEP then that's fine, you guys are solving
a different problem. But if you have a better way to balance these
competing needs then I'd love to hear it!
Well, now that you're asking, I'll give my answer even if it's probably
not what you want to read.
Replace your math hat with a Python language designer hat.
With that hat on, the question isn't just whether @ is going to help
math and math-based domains, it's whether it's going to help Python as a
whole.
Given that Python serves not just these domains, the relevance of matrix
multiplication diminishes greatly. Personally, in Guido's place, I'd
outright reject any domain-specific operator, and ask the people to come
up with a better proposal for user-defined operators. What I have seen
of user-defined operators discussion made me suspect that previous
attempts were rejected not because user-defined operators, but because
immature.
Speaking of language design competence, I'm missing a serious discussion
of syntactic ambiguities in your PEP.
Saying "oh it's only used for annotations so no problem" is just
handwaving, you can still run into ambiguities at the lexical level;
also, there's no outline of the changes needed in the parser and how you
can be sure it doesn't misinterpret an annotation for an operator or
vice versa, and how the changes might the accuracy of error messages.
This all in the sense of "do as you wish but that's the points I'd be
asking if I were Guido, so you might want to clarify there before
presenting this to the Python community at large".
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/531DBE2C.6060101%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
