On Fri, Apr 6, 2012 at 1:56 AM, Christoph Groth wrote:
> I noticed that numpy.linalg.eigvalsh returns a complex array, even
> though mathematically the resulting eigenvalues are guaranteed to be
> real.
>
> Looking at the source code, the underlying zheevd routine of LAPACK
> indeed returns an ar
Hi,
On Fri, Apr 6, 2012 at 3:50 PM, cgraves wrote:
>
> It seems that the speed of append_fields() in numpy.lib.recfunctions is much
> slower than rec_append_fields() in matplotlib.mlab. See the following code:
As I remember it (Pierre M can probably correct me) the recfunctions
are not ports of
Now I am clear. I guess the vectorized notation speeds up difference
equations describing FIR structures, whereas IIR ones won't benefit.
Francesco Barale wrote:
>
> Hello everyone,
>
> After reading the very good post
> http://technicaldiscovery.blogspot.com/2011/06/speeding-up-python-numpy-cy
It seems that the speed of append_fields() in numpy.lib.recfunctions is much
slower than rec_append_fields() in matplotlib.mlab. See the following code:
import numpy as np
import matplotlib.mlab as mlab
import numpy.lib.recfunctions as nprf
import time
# Set up recarray
nr_pts = 1E6
dt = np.dtype
Hi,
I added a simple enhancement patch to provide vectorize with simple
keyword argument support. (I added a new kwvectorize decorator, but
suspect this could/should easily be rolled into the existing vectorize.)
http://projects.scipy.org/numpy/ticket/2100
This just reorders any kwargs into
On Saturday 07 April 2012 02:51 AM, Francesco Barale wrote:
> Hello Sameer,
>
> Thank you very much for your reply. My goal was to try to speed up the loop
> describing the accumulator. In the (excellent) book I was mentioning in my
> initial post I could find one example that seemed to match what
Hello Sameer,
Thank you very much for your reply. My goal was to try to speed up the loop
describing the accumulator. In the (excellent) book I was mentioning in my
initial post I could find one example that seemed to match what I was trying
to do. Basically, it is said that a loop of the followi
On Saturday 07 April 2012 12:14 AM, francesco82 wrote:
Hello everyone,
After reading the very good post
http://technicaldiscovery.blogspot.com/2011/06/speeding-up-python-numpy-cython-and.html
and the book by H. P. Langtangen 'Python scripting for computational
science' I was trying to speed up t
Hi,
On Fri, Apr 6, 2012 at 1:12 PM, Tony Yu wrote:
>
>
> On Fri, Apr 6, 2012 at 8:54 AM, Benjamin Root wrote:
>>
>>
>>
>> On Friday, April 6, 2012, Val Kalatsky wrote:
>>>
>>>
>>> The only slicing short-cut I can think of is the Ellipsis object, but
>>> it's not going to help you much here.
>>>
On Fri, Apr 6, 2012 at 8:54 AM, Benjamin Root wrote:
>
>
> On Friday, April 6, 2012, Val Kalatsky wrote:
>
>>
>> The only slicing short-cut I can think of is the Ellipsis object, but
>> it's not going to help you much here.
>> The alternatives that come to my mind are (1) manipulation of shape
>>
Hello everyone,
After reading the very good post
http://technicaldiscovery.blogspot.com/2011/06/speeding-up-python-numpy-cython-and.html
and the book by H. P. Langtangen 'Python scripting for computational
science' I was trying to speed up the execution of a loop on numpy arrays
being used to des
Good morning all-- didn't realize this would generate quite such a buzz.
To answer a direct question, I'm using the github master. A few thoughts (from
a fairly heavy numpy user for numerical simulations and analysis):
The current behavior is confusing and (as far as i can tell) undocumented.
S
On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith wrote:
> On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant
> wrote:
> > That is an interesting point of view. I could see that point of view.
> > But, was this discussed as a bug prior to this change occurring?
> >
> > I just heard from a very h
On Fri, Apr 6, 2012 at 7:06 AM, mark florisson wrote:
> Could someone please ban this person from the mailing list, he keeps
> sending spam.
>
> On 6 April 2012 12:41, Jean-Baptiste Rudant wrote:
>
>> http://alumnos.digicap.cl/images/rmngl.html
>>
>>
They should be gone now.
Ognen
___
On Friday, April 6, 2012, Val Kalatsky wrote:
>
> The only slicing short-cut I can think of is the Ellipsis object, but it's
> not going to help you much here.
> The alternatives that come to my mind are (1) manipulation of shape
> directly and (2) building a string and running eval on it.
> Your
Le 06/04/2012 14:06, mark florisson a écrit :
> Could someone please ban this person from the mailing list, he keeps
> sending spam.
I was about to ask the same thing.
In the mean time, I googled the name of this gentleman and found a
possible match with a person working for the French national in
Could someone please ban this person from the mailing list, he keeps
sending spam.
On 6 April 2012 12:41, Jean-Baptiste Rudant wrote:
> http://alumnos.digicap.cl/images/rmngl.html
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> h
http://alumnos.digicap.cl/images/rmngl.html";>
http://alumnos.digicap.cl/images/rmngl.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hi Wes,
I believe that Mark rewrote a bunch of the fancy-indexing-related code
from scratch in the masked-NA branch. I don't know if it affects
anything you're talking about here, but just as a heads up, you might
want to benchmark master, since it may have a different performance
profile.
-- Nat
On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant wrote:
> That is an interesting point of view. I could see that point of view.
> But, was this discussed as a bug prior to this change occurring?
>
> I just heard from a very heavy user of NumPy that they are nervous about
> upgrading because of
I noticed that numpy.linalg.eigvalsh returns a complex array, even
though mathematically the resulting eigenvalues are guaranteed to be
real.
Looking at the source code, the underlying zheevd routine of LAPACK
indeed returns an array of real numbers which is than converted to
complex in the numpy
21 matches
Mail list logo
