Perhaps this a bit of a thread hyjack; but this discussion got me thinking
about how to arrive
at a more vectorized/tensorified way of specifying linear algebra
operations, in an elegant manner.
I probably got a little carried away, but what about this syntax?
- indexing/calling an ndarray wit
On Mon, Mar 17, 2014 at 8:54 PM, Nathaniel Smith 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 left-/right-associ
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 NumPy-Di
On Mar 17, 2014 5:54 PM, "Nathaniel Smith" wrote:
>
> On Sat, Mar 15, 2014 at 6:28 PM, Nathaniel Smith 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), a
On Mon, Mar 17, 2014 at 8:54 PM, Nathaniel Smith 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
>
>do_compari
On Mon, Mar 17, 2014 at 8:37 PM, Russell E. Owen 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 over the
On Sat, Mar 15, 2014 at 6:28 PM, Nathaniel Smith 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 following up
mor
On Tue, Mar 18, 2014 at 12:16 AM, Christophe Bal 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 t
>>> 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
On Mon, Mar 17, 2014 at 6:33 PM, Christophe Bal 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
> http://docs.python.org/3.1/reference/grammar.html.
On Mon, Mar 17, 2014 at 10:33 PM, Christophe Bal 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 matrix multiplicati
On Mon, Mar 17, 2014 at 11:16 PM, Bago 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 @@:
http://mail.scipy.org/pipermail/numpy-discussion
If you see the operators as following a hierarchy, the answer is simply yes.
2014-03-18 0:16 GMT+01:00 Bago :
>
>> 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 th
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
>
>
> 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 relati
On Mon, Mar 17, 2014 at 6:33 PM, Christophe Bal 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 will only requir
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 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 you
On Mon, Mar 17, 2014 at 9:38 PM, Christophe Bal 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 @-produ
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 t
Sorry for all the misspellings...
2014-03-17 22:32 GMT+01:00 Christophe Bal :
> 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
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
In article
,
Nathaniel Smith 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:
>a @ b @ c -> (a @ b) @ c
>a * b @ c -> (a * b) @ c
>a @ b
On Mon, Mar 17, 2014 at 2:55 PM, 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 dot(dot(dot('s to more readab
On Mon, Mar 17, 2014 at 1:18 PM, wrote:
>
>
>
> On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky wrote:
>
>>
>> On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith wrote:
>>
>>> In practice all
>>> well-behaved classes have to make sure that they implement __special__
>>> methods in such a w
On Mon, Mar 17, 2014 at 10:01 AM, Aron Ahmadia wrote:
>
> On Mon, Mar 17, 2014 at 7:53 AM, Nathaniel Smith 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
On Mon, Mar 17, 2014 at 12:50 PM, Alexander Belopolsky wrote:
>
> On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith 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 w
On Mon, Mar 17, 2014 at 7:53 AM, Nathaniel Smith 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.
>
+1 from
On Mon, Mar 17, 2014 at 12:13 PM, Nathaniel Smith 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.
>
"Well-behaved cla
On Mon, Mar 17, 2014 at 4:09 PM, Alexander Belopolsky wrote:
>
> On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith 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
On Mon, Mar 17, 2014 at 3:48 PM, Nathaniel Smith wrote:
> On Sat, Mar 15, 2014 at 7:01 PM, Alexander Belopolsky 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 ha
On Mon, Mar 17, 2014 at 11:48 AM, Nathaniel Smith 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
> > __rmatmul__?
On Sat, Mar 15, 2014 at 7:01 PM, Alexander Belopolsky wrote:
>
> On Sat, Mar 15, 2014 at 2:25 PM, Alexander Belopolsky
> wrote:
>>
>> On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
>>>
>>> Here's the main blocker for adding a matrix multiply operator '@' to
>>> Python: we need to decid
On Mon, Mar 17, 2014 at 11:53 AM, Nathaniel Smith wrote:
> On Sat, Mar 15, 2014 at 4:32 AM, Nathaniel Smith 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
On Sat, Mar 15, 2014 at 4:32 AM, Nathaniel Smith 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 general)?
The
Personally I did not like @@ in the first place.
Sturla
Nathaniel Smith 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 and @@ for
36 matches
Mail list logo
