Personally I did not like @@ in the first place.
Sturla
Nathaniel Smith n...@pobox.com wrote:
Hi all,
Here's the second thread for discussion about Guido's concerns about
PEP 465. The issue here is that PEP 465 as currently written proposes
two new operators, @ for matrix multiplication
On Sat, Mar 15, 2014 at 4:32 AM, Nathaniel Smith n...@pobox.com wrote:
For this discussion let's assume @ can be taken for granted, and that
we can freely choose to either add @@ or not add @@ to the language.
The question is: which do we think makes Python a better language (for
us and in
On Mon, Mar 17, 2014 at 11:53 AM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 15, 2014 at 4:32 AM, Nathaniel Smith n...@pobox.com wrote:
For this discussion let's assume @ can be taken for granted, and that
we can freely choose to either add @@ or not add @@ to the language.
The question
On Sat, Mar 15, 2014 at 7:01 PM, Alexander Belopolsky ndar...@mac.com wrote:
On Sat, Mar 15, 2014 at 2:25 PM, Alexander Belopolsky ndar...@mac.com
wrote:
On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith n...@pobox.com wrote:
Here's the main blocker for adding a matrix multiply operator '@'
On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith n...@pobox.com wrote:
One more question that I think should be answered by the PEP and may
influence the associativity decision is what happens if in an A @ B @ C
expression, each operand has its own type that defines __matmul__ and
On Mon, Mar 17, 2014 at 3:48 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 15, 2014 at 7:01 PM, Alexander Belopolsky ndar...@mac.com wrote:
One more question that I think should be answered by the PEP and may
influence the associativity decision is what happens if in an A @ B @ C
On Mon, Mar 17, 2014 at 4:09 PM, Alexander Belopolsky ndar...@mac.com wrote:
On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith n...@pobox.com wrote:
One more question that I think should be answered by the PEP and may
influence the associativity decision is what happens if in an A @ B @ C
On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith n...@pobox.com wrote:
In practice all
well-behaved classes have to make sure that they implement __special__
methods in such a way that all the different variations work, no
matter which class ends up actually handling the operation.
On Mon, Mar 17, 2014 at 7:53 AM, Nathaniel Smith n...@pobox.com wrote:
The thread so far, it sounds like the consensus answer is meh,
whatever. So I'm thinking we should just drop @@ from the PEP, and if
it turns out that this is a problem we can always revisit it in the
~3.6/3.7 timeframe.
On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky ndar...@mac.comwrote:
On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith n...@pobox.com wrote:
In practice all
well-behaved classes have to make sure that they implement __special__
methods in such a way that all the different variations
On Mon, Mar 17, 2014 at 10:01 AM, Aron Ahmadia a...@ahmadia.net wrote:
On Mon, Mar 17, 2014 at 7:53 AM, Nathaniel Smith n...@pobox.com wrote:
The thread so far, it sounds like the consensus answer is meh,
whatever. So I'm thinking we should just drop @@ from the PEP, and if
it turns out
On Mon, Mar 17, 2014 at 1:18 PM, josef.p...@gmail.com wrote:
On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky ndar...@mac.comwrote:
On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith n...@pobox.com wrote:
In practice all
well-behaved classes have to make sure that they implement
On Mon, Mar 17, 2014 at 2:55 PM, josef.p...@gmail.com wrote:
I'm again in favor of left, because it's the simplest to understand
A.dot(B).dot(C)
+1
Note that for many years to come the best option for repeated matrix
product will be A.dot(B).dot(C) ...
People who convert their
In article
CAPJVwBkLww7-ysZB76LMRZ+mmbyN_5T=ym_vu1pjgakrlbq...@mail.gmail.com,
Nathaniel Smith n...@pobox.com wrote:
OPTION 1 FOR @:
Precedence: same as *
Associativity: left
My shorthand name for it: same-left (yes, very creative)
This means that if you don't use parentheses, you get:
Hello,
and what about something like that ?
a @ b @ c - (a @ b) @ c
a * b @ c - (a * b) @ c
a @ b * c - a @ (b * c)
Easy to remember. The *-product has priority to @-product, and then we just
to @-product from left to right.
An advantage of this is that parsers do job from left to right
Sorry for all the misspellings...
2014-03-17 22:32 GMT+01:00 Christophe Bal projet...@gmail.com:
Hello,
and what about something like that ?
a @ b @ c - (a @ b) @ c
a * b @ c - (a * b) @ c
a @ b * c - a @ (b * c)
Easy to remember. The *-product has priority to @-product, and then
Here is the translation. ;-)
Hello,
and what about something like that ?
*a @ b @ c - (a @ b) @ c*
*a * b @ c - (a * b) @ c*
*a @ b * c - a @ (b * c)*
Easy to remember: the *-product has priority regarding to the @-product,
and we just do @-product from left to right.
An advantage of
On Mon, Mar 17, 2014 at 9:38 PM, Christophe Bal projet...@gmail.com wrote:
Here is the translation. ;-)
Hello,
and what about something like that ?
a @ b @ c - (a @ b) @ c
a * b @ c - (a * b) @ c
a @ b * c - a @ (b * c)
Easy to remember: the *-product has priority regarding to the
On 12.03.2014 17:52, Leo Mao wrote:
Hi,
The attachment is my draft of proposal. The project is vector math
library integration.
I think I need some feedback to make it solider.
Any comment will be appreciated.
Thanks in advance.
hi,
I finally had some time too properly look at your
I think that weak-left is a little strange, just think a little of the
operators used by mathematicians that always follow a hierarchy.
A parser is mostly done using grammars : see
http://docs.python.org/3.1/reference/grammar.html.
Defining *-product to have stronger priority than the @-product,
On Mon, Mar 17, 2014 at 6:33 PM, Christophe Bal projet...@gmail.com wrote:
Defining *-product to have stronger priority than the @-product, and this
last having stronger priority than +, will make the changes in the grammar
easier.
The easiest is to give @ the same precedence as *. This
I'm now convinced of the usefulness of @ and @@ too but I also think that
you must think of other uses than only for numpy. In other words, numpy is
a the good argument for this new operators, but this can also open new
perspectives for other uses.
Speaking of `@@`, would the relative
First of all I'm must be very tired because I've written *I think that
weak-left is a little strange...* instead of *I think that same-left is a
little strange...*. It is the night in french... ;-)
So I'm definitely for the weak-left !
Here is my answer to Alexander Belopolsky.
You are right
If you see the operators as following a hierarchy, the answer is simply yes.
2014-03-18 0:16 GMT+01:00 Bago mrb...@gmail.com:
I'm now convinced of the usefulness of @ and @@ too but I also think that
you must think of other uses than only for numpy. In other words, numpy is
a the good
On Mon, Mar 17, 2014 at 11:16 PM, Bago mrb...@gmail.com wrote:
Speaking of `@@`, would the relative precedence of @ vs * be the same as @@
vs **?
This is one of the concerns that made Guido leery of @@ (but only one
of them). Since we seem to be dropping @@:
On Mon, Mar 17, 2014 at 10:33 PM, Christophe Bal projet...@gmail.com wrote:
I think that weak-left is a little strange, just think a little of the
operators used by mathematicians that always follow a hierarchy.
Not sure what you mean -- I don't think most mathematicians think that
scalar and
On Mon, Mar 17, 2014 at 6:33 PM, Christophe Bal projet...@gmail.com wrote:
I think that weak-left is a little strange, just think a little of the
operators used by mathematicians that always follow a hierarchy.
A parser is mostly done using grammars : see
This follows the principle that it's better to be great
at some things than to be mediocre at everything.
You're right.
I think that weak-left is a little strange, just think
a little of the operators used by mathematicians that
always follow a hierarchy.
Not sure what you mean -- I
On Tue, Mar 18, 2014 at 12:16 AM, Christophe Bal projet...@gmail.com wrote:
I think that weak-left is a little strange, just think
a little of the operators used by mathematicians that
always follow a hierarchy.
Not sure what you mean -- I don't think most mathematicians
think that scalar
On Sat, Mar 15, 2014 at 6:28 PM, Nathaniel Smith n...@pobox.com wrote:
Mathematica: instead of having an associativity, a @ b @ c gets
converted into mdot([a, b, c])
So, I've been thinking about this (thanks to @rfateman for pointing it
out), and wondering if Mathematica's approach is worth
On Mon, Mar 17, 2014 at 8:37 PM, Russell E. Owen ro...@uw.edu wrote:
After seeing all the traffic on this thread, I am in favor of
same-left because it is easiest to remember:
- It introduces no new rules.
- It is unambiguous. If we pick option 2 or 3 we have no strong reason
to favor one
On Mon, Mar 17, 2014 at 8:54 PM, Nathaniel Smith n...@pobox.com wrote:
Currently Python has 3 different kinds of ops: left-associative (most
of them), right-associative (**), and chaining. Chaining is used for
comparison ops. Example:
a b c
gets parsed to something like
On Mar 17, 2014 5:54 PM, Nathaniel Smith n...@pobox.com wrote:
On Sat, Mar 15, 2014 at 6:28 PM, Nathaniel Smith n...@pobox.com wrote:
Mathematica: instead of having an associativity, a @ b @ c gets
converted into mdot([a, b, c])
So, I've been thinking about this (thanks to @rfateman for
Julian,
I can see the need to recognize both column and row vectors, but why not
with np.matrix?
I can see no need for a new operator and hope to be able to comment more
fully on PEP 465 in a few days.
Colin W.
On 17-Mar-2014 7:19 PM, numpy-discussion-requ...@scipy.org wrote:
Send
On Mon, Mar 17, 2014 at 8:54 PM, Nathaniel Smith n...@pobox.com wrote:
But, this is actually a feature! Because obviously what *should* be
returned in this case is *not* (Mat @ vec) @ Mat, *or* Mat @ (vec @
Mat). Both of those answers are terrible; it's just, if you have an
ordinary
35 matches
Mail list logo
