Am 10.03.2014 15:40, schrieb Nathaniel Smith:
No-one uses elementwise multiplication to implement the scalar
product, they just call np.dot or whatever the local equivalent is.
It's just that the scalar product is the only use case presented in the PEP.
Nonetheless, every single numeric language I know of has a dedicated
1-or-2-character infix operator for elementwise multiplication; the
only debate is whether it or matrix multiplication get more prominent
billing.
Seems like both are too useful to not implement them.
What I think you may be missing is that the whole "zen of arrays" is
that they give you a coherent, composable system for writing simple
scalar code that works over lots of scalars at once.
Yes, that's useful from a programming perspective.
It's just that this principle of "make scalar code work for arrays"
carries you only so far, the principle breaks quite soon - for example
in the form that multiplication simply isn't transferrable to vectors,
let alone matrices, multiplication bifurcates and has multiple
interpretations when going to scalars.
The utility of elementwise multiplication just isn't a controversial
point anywhere in the broader numeric ecosystem.
Okay, accepted.
Of course. I only bring it up because it's totally possible that
there's some way of tweaking what's in the PEP to make it more useful
to everybody, and if so then I hope you guys will help me think of it.
Okay.
From SymPy's perspective, being as close to mathematical formalisms as
possible is good.
So @ is bad because mathematicians don't write @ for elementwise
multiplication - they use * (or juxtaposition) if in a context where
elementwise multiplication is prominent and matrix multiplication isn't.
Fortunately, we don't need to really oppose @ as long as we can support
* for matrix multiplication, and I doubt we'll ever switch to * as
elementwise multiplication simply because we's break existing code if we
did.
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).
The day that I see 20% of PyCon tutorials are on the topic of "how to
manipulate ipaddr objects",
Networking is MUCH more than ip addresses :-)
But that was half-humorous anyway.
Right, this is the point of the sections called "But isn't matrix
multiplication a pretty niche requirement?" and "So ``@`` is good for
matrix formulas, but how common are those really?". I actually do feel
that @ is more useful to Python as a whole than some of the existing
operators.
Doesn't mean that Python should repeat that mistake.
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.
AFAICT his most recent comment on user-defined operators is:
"I encourage the numpy folks to think about a language preprocessor
that adds extra operators and perhaps other syntax."
(https://plus.google.com/115212051037621986145/posts/hZVVtJ9bK3u)
...which doesn't give me much hope on this account. AFAICT the
possibilities are: (1) no new operators, (2) one new very
well-motivated operator like @, (3) there is no possibility 3.
It rejects that specific @ operator.
It does not reject user-defined operators as a concept.
I personally don't see how to make user-defined operators work in
Python at all -- among other issues, they would totally break the
current compile/eval separation.
Only if you do it wrongly.
An operator definition is just syntactic sugar; essentially, for an
operator #, a # b should be a shorthand for a.#(b).
You need to assign precedence levels. These need to be tied to the
operator symbols to make unambiguous parses - or at least the importing
module needs to be able to override precedence levels.
No or conflicting precedence levels -> add parentheses, dammit, that's
what they're for.
The issue where I simply don't know how to best do it is the alphabet
for operators.
- What symbols can be operators? Only ASCII, or do we allow NLS
characters like §?
- Multi-character operators?
- If yes: Do we allow letters and digits in operators? E.g. any name
with a + inside is an operator?
I can't answer these because I'm not that far into Python's syntactic
details.
Another question is whether prefix and postfix operators should be
allowed, too.
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.
I didn't go into details here because AFAICT they're trivial -- am I
missing something? Annotation-@ is only legal as the first token in a
statement; matmul-@ is a binary operator, so it's only legal when
*not* the first token in a statement. This is pretty unambiguous,
Hm... well, I'd say it might close the road for other syntactic
extensions in the future.
One question that wasn't answered is whether asdf@ is the name asdf
followed by the operator symbol @, or a single name asdf@.
This might be answered by Python's syntax though. As I said, I'm not a
syntax expert; maybe a link to background information on the parsing
issues around @-as-annotation would help non-Python-syntax-experts
understand the issues, and it would also demonstrate that you have
indeed taken a good look at these issues.
> and
Python has lots of parsing issues that are more subtle than this ("is
not", "if" in comprehensions, etc.).
Sure.
Doesn't mean that @ as an operator can't have its own subtleties.
--
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/531DDC09.8070609%40durchholz.org.
For more options, visit https://groups.google.com/d/optout.
