On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant tra...@continuum.iowrote:
As of 1.5.1 this worked:
numpy.__version__
1.5.1
numpy.uint64(5) 3
1L
So, this is a regression and a bug. It should be fixed so that it
doesn't raise an error. I believe the scalars were special cased so
On Apr 6, 2012, at 1:01 AM, Charles R Harris wrote:
On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant tra...@continuum.io wrote:
As of 1.5.1 this worked:
numpy.__version__
1.5.1
numpy.uint64(5) 3
1L
So, this is a regression and a bug. It should be fixed so that it doesn't
On Fri, Apr 6, 2012 at 12:01 AM, Charles R Harris charlesr.har...@gmail.com
wrote:
On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant tra...@continuum.iowrote:
As of 1.5.1 this worked:
numpy.__version__
1.5.1
numpy.uint64(5) 3
1L
So, this is a regression and a bug. It should be
Although 1.5.1 also gives
np.uint(3) + 4
7.0
i.e., a float, which certainly doesn't look right either. Whereas
np.int(3) + 4
7
The float promotion is still there in 1.6.1
In [4]: uint64(1) + 2
Out[4]: 3.0
So I suppose there is the larger question is how combining numpy
On Fri, Apr 6, 2012 at 12:19 AM, Travis Oliphant tra...@continuum.iowrote:
On Apr 6, 2012, at 1:01 AM, Charles R Harris wrote:
On Thu, Apr 5, 2012 at 11:57 PM, Travis Oliphant tra...@continuum.iowrote:
As of 1.5.1 this worked:
numpy.__version__
1.5.1
numpy.uint64(5) 3
1L
So,
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
On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant tra...@continuum.io 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
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.
--
a href=http://alumnos.digicap.cl/images/rmngl.html;
http://alumnos.digicap.cl/images/rmngl.html/a___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Could someone please ban this person from the mailing list, he keeps
sending spam.
On 6 April 2012 12:41, Jean-Baptiste Rudant boogalo...@yahoo.fr wrote:
http://alumnos.digicap.cl/images/rmngl.html
___
NumPy-Discussion mailing list
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
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
On Fri, Apr 6, 2012 at 7:06 AM, mark florisson markflorisso...@gmail.comwrote:
Could someone please ban this person from the mailing list, he keeps
sending spam.
On 6 April 2012 12:41, Jean-Baptiste Rudant boogalo...@yahoo.fr wrote:
http://alumnos.digicap.cl/images/rmngl.html
They should
On Fri, Apr 6, 2012 at 3:57 AM, Nathaniel Smith n...@pobox.com wrote:
On Fri, Apr 6, 2012 at 7:19 AM, Travis Oliphant tra...@continuum.io
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
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.
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
On Fri, Apr 6, 2012 at 8:54 AM, Benjamin Root ben.r...@ou.edu 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
Hi,
On Fri, Apr 6, 2012 at 1:12 PM, Tony Yu tsy...@gmail.com wrote:
On Fri, Apr 6, 2012 at 8:54 AM, Benjamin Root ben.r...@ou.edu 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
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
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
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 I
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
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 =
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
Hi,
On Fri, Apr 6, 2012 at 3:50 PM, cgraves christoph.gra...@gmail.com 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
On Fri, Apr 6, 2012 at 1:56 AM, Christoph Groth c...@falma.de 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
26 matches
Mail list logo
