On Thu, 2013-04-04 at 16:56 +0300, Jaakko Luttinen wrote:
> I don't quite understand how einsum handles broadcasting. I get the
> following error, but I don't understand why:
>
> In [8]: import numpy as np
> In [9]: A = np.arange(12).reshape((4,3))
> In [10]: B = np.arange(6).reshape((3,2))
> In [
I don't quite understand how einsum handles broadcasting. I get the
following error, but I don't understand why:
In [8]: import numpy as np
In [9]: A = np.arange(12).reshape((4,3))
In [10]: B = np.arange(6).reshape((3,2))
In [11]: np.einsum('ik,k...->i...', A, B)
--
On 25 October 2012 22:54, David Warde-Farley wrote:
> On Wed, Oct 24, 2012 at 7:18 AM, George Nurser wrote:
> > Hi,
> >
> > I was just looking at the einsum function.
> > To me, it's a really elegant and clear way of doing array operations,
> which
> > is the core of what numpy is about.
> > It r
On Wed, Oct 24, 2012 at 7:18 AM, George Nurser wrote:
> Hi,
>
> I was just looking at the einsum function.
> To me, it's a really elegant and clear way of doing array operations, which
> is the core of what numpy is about.
> It removes the need to remember a range of functions, some of which I fin
Hi,
I was just looking at the einsum function.
To me, it's a really elegant and clear way of doing array operations, which
is the core of what numpy is about.
It removes the need to remember a range of functions, some of which I find
tricky (e.g. tile).
Unfortunately the present implementation se
On Tue, Jan 24, 2012 at 6:32 AM, Søren Gammelmark wrote:
> Dear all,
>
> I was just looking into numpy.einsum and encountered an issue which might
> be worth pointing out in the documentation.
>
> Let us say you wish to evaluate something like this (repeated indices a
> summed)
>
> D[alpha, alphap
Dear all,
I was just looking into numpy.einsum and encountered an issue which might
be worth pointing out in the documentation.
Let us say you wish to evaluate something like this (repeated indices a
summed)
D[alpha, alphaprime] = A[alpha, beta, sigma] * B[alphaprime, betaprime,
sigma] * C[beta,
Hi,
I was playing around with einsum (which is really cool, by the way!),
and I noticed something strange (or unexpected at least)
performance-wise. Here is an example:
Let x and y be two NxM arrays, and W be a NxN array. I want to compute
f = x^{ik} W_i^j y_{jk}
(I hope the notation is cl
On Wed, Jan 26, 2011 at 8:29 PM, Joshua Holbrook wrote:
> >>
> >> The only disadvantage I see, is that choosing the axes to operate on
> >> in a program or function requires string manipulation.
> >
> >
> > One possibility would be for the Python exposure to accept lists or
> tuples
> > of integer
>>
>> The only disadvantage I see, is that choosing the axes to operate on
>> in a program or function requires string manipulation.
>
>
> One possibility would be for the Python exposure to accept lists or tuples
> of integers. The subscript 'ii' could be [(0,0)], and 'ij,jk->ik' could be
> [(0,1
On Wed, Jan 26, 2011 at 5:23 PM, wrote:
>
> So, if I read the examples correctly we finally get dot along an axis
>
> np.einsum('ijk,ji->', a, b)
> np.einsum('ijk,jik->k', a, b)
>
> or something like this.
>
> the notation might require getting used to but it doesn't look worse
> than figuring o
On Wed, Jan 26, 2011 at 6:41 PM, Jonathan Rocher wrote:
> Nice function, and wonderful that it speeds some tasks up.
>
> some feedback: the following notation is a little counter intuitive to me:
> >>> np.einsum('i...->', a)
> array([50, 55, 60, 65, 70])
> >>> np.sum(a, axis=0)
> a
Nice function, and wonderful that it speeds some tasks up.
some feedback: the following notation is a little counter intuitive to me:
>>> np.einsum('i...->', a)
array([50, 55, 60, 65, 70])
>>> np.sum(a, axis=0)
array([50, 55, 60, 65, 70])
Since there is nothing after the ->, I exp
On Wed, Jan 26, 2011 at 7:35 PM, Benjamin Root wrote:
> On Wednesday, January 26, 2011, Gael Varoquaux
> wrote:
>> On Thu, Jan 27, 2011 at 12:18:30AM +0100, Hanno Klemm wrote:
>>> interesting idea. Given the fact that in 2-d euclidean metric, the
>>> Einstein summation conventions are only a way
On Wed, Jan 26, 2011 at 5:02 PM, Joshua Holbrook
wrote:
>> Ah, sorry for misunderstanding. That would actually be very difficult,
>> as the iterator required a fair bit of fixes and adjustments to the core.
>> The new_iterator branch should be 1.5 ABI compatible, if that helps.
>
> I see. Perhaps
> Ah, sorry for misunderstanding. That would actually be very difficult,
> as the iterator required a fair bit of fixes and adjustments to the core.
> The new_iterator branch should be 1.5 ABI compatible, if that helps.
I see. Perhaps the fixes and adjustments can/should be included with
numpy st
On Wednesday, January 26, 2011, Gael Varoquaux
wrote:
> On Thu, Jan 27, 2011 at 12:18:30AM +0100, Hanno Klemm wrote:
>> interesting idea. Given the fact that in 2-d euclidean metric, the
>> Einstein summation conventions are only a way to write out
>> conventional matrix multiplications, do you co
Am 27.01.2011 um 00:29 schrieb Mark Wiebe:
On Wed, Jan 26, 2011 at 3:18 PM, Hanno Klemm
wrote:
Mark,
interesting idea. Given the fact that in 2-d euclidean metric, the
Einstein summation conventions are only a way to write out
conventional matrix multiplications, do you consider at some po
On Wed, Jan 26, 2011 at 3:18 PM, Hanno Klemm wrote:
>
> Mark,
>
> interesting idea. Given the fact that in 2-d euclidean metric, the
> Einstein summation conventions are only a way to write out
> conventional matrix multiplications, do you consider at some point to
> include a non-euclidean metri
On Wed, Jan 26, 2011 at 3:05 PM, Joshua Holbrook wrote:
> >
> > It think his real question is whether einsum() and the iterator stuff
> > can live in a separate module that *uses* a released version of numpy
> > rather than a development branch.
> >
> > --
> > Robert Kern
> >
>
> Indeed, I would l
On Thu, Jan 27, 2011 at 12:18:30AM +0100, Hanno Klemm wrote:
> interesting idea. Given the fact that in 2-d euclidean metric, the
> Einstein summation conventions are only a way to write out
> conventional matrix multiplications, do you consider at some point to
> include a non-euclidean metr
Mark,
interesting idea. Given the fact that in 2-d euclidean metric, the
Einstein summation conventions are only a way to write out
conventional matrix multiplications, do you consider at some point to
include a non-euclidean metric in this thing? (As you have in special
relativity, for e
>
> It think his real question is whether einsum() and the iterator stuff
> can live in a separate module that *uses* a released version of numpy
> rather than a development branch.
>
> --
> Robert Kern
>
Indeed, I would like to be able to install and use einsum() without
having to install another
On Wed, Jan 26, 2011 at 16:43, Mark Wiebe wrote:
> On Wed, Jan 26, 2011 at 2:01 PM, Joshua Holbrook
> wrote:
>>
>>
>> How closely coupled is this new code with numpy's internals? That is,
>> could you factor it out into its own package? If so, then people could
>> have immediate use out of it wi
On Wed, Jan 26, 2011 at 2:01 PM, Joshua Holbrook wrote:
>
> How closely coupled is this new code with numpy's internals? That is,
> could you factor it out into its own package? If so, then people could
> have immediate use out of it without having to integrate it into numpy
> proper.
The code
On Wed, Jan 26, 2011 at 12:48 PM, Mark Wiebe wrote:
> On Wed, Jan 26, 2011 at 1:36 PM, Joshua Holbrook
> wrote:
>>
>> On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe wrote:
>> > I wrote a new function, einsum, which implements Einstein summation
>> > notation, and I'd like comments/thoughts from pe
On Wed, Jan 26, 2011 at 1:36 PM, Joshua Holbrook wrote:
> On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe wrote:
> > I wrote a new function, einsum, which implements Einstein summation
> > notation, and I'd like comments/thoughts from people who might be
> interested
> > in this kind of thing.
>
> T
On Wed, Jan 26, 2011 at 11:27 AM, Mark Wiebe wrote:
> I wrote a new function, einsum, which implements Einstein summation
> notation, and I'd like comments/thoughts from people who might be interested
> in this kind of thing.
This sounds really cool! I've definitely considered doing something
lik
I wrote a new function, einsum, which implements Einstein summation
notation, and I'd like comments/thoughts from people who might be interested
in this kind of thing.
In testing it, it is also faster than many of NumPy's built-in functions,
except for dot and inner. At the bottom of this email y
29 matches
Mail list logo
