On Sat, Mar 15, 2014 at 10:53 PM, wrote:
>
>
>
> On Sat, Mar 15, 2014 at 11:30 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>>
>>
>>
>> On Sat, Mar 15, 2014 at 7:20 PM, wrote:
>>
>>>
>>>
>>>
>>> On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
>>>
Hi all,
On Sat, Mar 15, 2014 at 11:30 PM, Charles R Harris <
charlesr.har...@gmail.com> wrote:
>
>
>
> On Sat, Mar 15, 2014 at 7:20 PM, wrote:
>
>>
>>
>>
>> On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
>>
>>> Hi all,
>>>
>>> Here's the main blocker for adding a matrix multiply operator '@' t
On Sat, Mar 15, 2014 at 7:20 PM, wrote:
>
>
>
> On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
>
>> Hi all,
>>
>> Here's the main blocker for adding a matrix multiply operator '@' to
>> Python: we need to decide what we think its precedence and associativity
>> should be. I'll explain
On Sat, Mar 15, 2014 at 1:13 PM, Alan G Isaac wrote:
> On 3/15/2014 12:32 AM, Nathaniel Smith wrote:
>> I know you were worried
>> about losing the .I attribute on matrices if switching to ndarrays for
>> teaching -- given that ndarray will probably not get a .I attribute,
>> how much would the
On Sat, Mar 15, 2014 at 8:47 PM, Warren Weckesser <
warren.weckes...@gmail.com> wrote:
>
> On Sat, Mar 15, 2014 at 8:38 PM, wrote:
>
>> I think I wouldn't use anything like @@ often enough to remember it's
>> meaning. I'd rather see english names for anything that is not **very**
>> common.
>>
>>
On Fri, Mar 14, 2014 at 11:41 PM, Nathaniel Smith wrote:
> Hi all,
>
> Here's the main blocker for adding a matrix multiply operator '@' to
> Python: we need to decide what we think its precedence and associativity
> should be. I'll explain what that means so we're on the same page, and what
> th
On Sat, Mar 15, 2014 at 8:38 PM, wrote:
> I think I wouldn't use anything like @@ often enough to remember it's
> meaning. I'd rather see english names for anything that is not **very**
> common.
>
> I find A@@-1 pretty ugly compared to inv(A)
> A@@(-0.5) might be nice (do we have matrix_sqrt
I think I wouldn't use anything like @@ often enough to remember it's
meaning. I'd rather see english names for anything that is not **very**
common.
I find A@@-1 pretty ugly compared to inv(A)
A@@(-0.5) might be nice (do we have matrix_sqrt ?)
Josef
On Sat, Mar 15, 2014 at 5:11 PM, Stephan
Speaking only for myself (and as someone who has regularly used matrix
powers), I would not expect matrix power as @@ to follow from matrix
multiplication as @. I do agree that matrix power is the only reasonable
use for @@ (given @), but it's still not something I would be confident
enough to know
On Sat, Mar 15, 2014 at 2:12 PM, Alexander Belopolsky wrote:
>
> On Sat, Mar 15, 2014 at 4:00 PM, Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> These days they are usually written as v*w.T, i.e., the outer product of
>> two vectors and are a fairly common occurrence in matrix express
On Sat, Mar 15, 2014 at 4:00 PM, Charles R Harris wrote:
> These days they are usually written as v*w.T, i.e., the outer product of
> two vectors and are a fairly common occurrence in matrix expressions. For
> instance, covariance matrices are defined as E(v * v.T)
With the current numpy, we c
On Sat, Mar 15, 2014 at 1:29 PM, Nathaniel Smith wrote:
> On 15 Mar 2014 19:02, "Charles R Harris"
> wrote:
> > Just to throw something new into the mix
> >
> > u@v@w = u@(v@w) -- u@v is a dyadic matrix
> >
> > u@v -- is a scalar
> >
> > It would be nice if u@v@None, or some such, would evalua
On Sat, Mar 15, 2014 at 3:29 PM, Nathaniel Smith wrote:
> > It would be nice if u@v@None, or some such, would evaluate as a dyad.
> Or else we will still need the concept of row and column 1-D matrices. I
> still think v.T should set a flag so that one can distinguish u@v.T(dyad)
> from u.T@v(in
On 15 Mar 2014 19:02, "Charles R Harris" wrote:
> Just to throw something new into the mix
>
> u@v@w = u@(v@w) -- u@v is a dyadic matrix
>
> u@v -- is a scalar
>
> It would be nice if u@v@None, or some such, would evaluate as a dyad. Or
else we will still need the concept of row and column 1-D m
On Sat, Mar 15, 2014 at 1: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 decide wha
On Sat, Mar 15, 2014 at 12:40 PM, Nathaniel Smith wrote:
> On Sat, Mar 15, 2014 at 6:33 PM, Joe Kington
> wrote:
> > On Sat, Mar 15, 2014 at 1:28 PM, Nathaniel Smith wrote:
> >>
> >> On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith wrote:
> >> > Hi all,
> >> >
> >> > Here's the main blocker fo
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 decide what we think its precedence and associativity
>> should be.
>
>
> I am no
On Sat, Mar 15, 2014 at 6:33 PM, Joe Kington wrote:
> On Sat, Mar 15, 2014 at 1:28 PM, Nathaniel Smith wrote:
>>
>> On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith wrote:
>> > Hi all,
>> >
>> > Here's the main blocker for adding a matrix multiply operator '@' to
>> > Python:
>> > we need to dec
Hi Chris,
On Sat, Mar 15, 2014 at 4:15 AM, Chris Laumann wrote:
> Hi all,
>
> Let me preface my two cents by saying that I think the best part of @ being
> accepted is the potential for deprecating the matrix class — the syntactic
> beauty of infix for matrix multiply is a nice side effect IMHO :
On Sat, Mar 15, 2014 at 1:28 PM, Nathaniel Smith wrote:
> On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith wrote:
> > Hi all,
> >
> > Here's the main blocker for adding a matrix multiply operator '@' to
> Python:
> > we need to decide what we think its precedence and associativity should
> be.
>
On Sat, Mar 15, 2014 at 3:41 AM, Nathaniel Smith wrote:
> Hi all,
>
> Here's the main blocker for adding a matrix multiply operator '@' to Python:
> we need to decide what we think its precedence and associativity should be.
Another data point that might be useful:
Matlab: same-left
R: tight-le
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 decide what we think its precedence and associativity
> should be.
I am not ready to form my own opinion, but I hope the following will help
shapi
On Sat, Mar 15, 2014 at 4:40 PM, Charles R Harris
wrote:
>
> On Sat, Mar 15, 2014 at 9:58 AM, Robert Kern wrote:
>>
>> On Sat, Mar 15, 2014 at 2:49 PM, Charles R Harris
>> wrote:
>> >
>> > I favor the weak right option.
>> >
>> > 1) Giving '*' higher precedence than `@` makes it easier, to my mi
Oops, make that '*' is *left* associative.
Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Mar 15, 2014 at 9:58 AM, Robert Kern wrote:
> On Sat, Mar 15, 2014 at 2:49 PM, Charles R Harris
> wrote:
> >
> > I favor the weak right option.
> >
> > 1) Giving '*' higher precedence than `@` makes it easier, to my mind, to
> > parse out what is going to happen: all the element-wise mul
Because of the license problem, I think I will choose Yeppp as a default
backend.
And if time allows, maybe I can implement other bindings. (Vc library)
Also I found that sleef library is in public domain. But it seems that it
only provides fast math function,
not "vectorized math function". So I
On Sat, Mar 15, 2014 at 11:44 AM, Robert Kern wrote:
> I tend to favor tight-right. The general scheme of precedence more or
> less puts "heavier" operations higher than "lighter" operations (+ < *
> < **) and @ is "heavier" than * in my mind. I think tight (either
> -right or -left) has a good co
2014-03-15 11:18 GMT-04:00 Charles R Harris :
>
>
>
> On Fri, Mar 14, 2014 at 10:32 PM, 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, @ f
On Sat, Mar 15, 2014 at 2:49 PM, Charles R Harris
wrote:
>
> I favor the weak right option.
>
> 1) Giving '*' higher precedence than `@` makes it easier, to my mind, to
> parse out what is going to happen: all the element-wise multiplications,
> followed by the matrix operations. I'd probably stil
On Fri, Mar 14, 2014 at 10:32 PM, 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 matrix power
> (analogous
On Fri, Mar 14, 2014 at 6:51 PM, Nathaniel Smith wrote:
> Well, that was fast. Guido says he'll accept the addition of '@' as an
> infix operator for matrix multiplication, once some details are ironed
> out:
> https://mail.python.org/pipermail/python-ideas/2014-March/027109.html
> http://leg
I favor the weak right option.
1) Giving '*' higher precedence than `@` makes it easier, to my mind, to
parse out what is going to happen: all the element-wise multiplications,
followed by the matrix operations. I'd probably still use parenthesis for
clarity.
2) Right associative has the advantag
On 3/15/2014 12:32 AM, Nathaniel Smith wrote:
> I know you were worried
> about losing the .I attribute on matrices if switching to ndarrays for
> teaching -- given that ndarray will probably not get a .I attribute,
> how much would the existence of @@ -1 affect you?
Not much. Positive integer p
hi all,
I'm glad to inform you about new OpenOpt Suite release 0.53:
Stochastic programming addon now is available for free
Some minor changes
--
Regards, D.
http://openopt.org/Dmitrey
___
N
I tend to favor tight-right. The general scheme of precedence more or
less puts "heavier" operations higher than "lighter" operations (+ < *
< **) and @ is "heavier" than * in my mind. I think tight (either
-right or -left) has a good correspondence with current dot()
expressions, so it will make t
Hello.
Maybe a solution would be to not see @ and @@ only from the matrix point of
view.
Why ? The philosophy of Python is to give total control of the infix
operators +, * and ** for example via the magic methods. So it can be also
the case for @ and @@ that could be use for something else
that
36 matches
Mail list logo
