To see if this is an effect of numpy using C-order by default instead of
Fortran-order, try measuring eig(x.T) instead of eig(x)?
-n
On Apr 1, 2012 2:28 PM, Kamesh Krishnamurthy kames...@gmail.com wrote:
Hello all,
I profiled NumPy EIG and MATLAB EIG on the same Macbook pro, and both were
Changing the array to Fortran order using numpy.ndarray.T does not help
much in my machine. But, this may be important since the LAPACK routines
are written in Fortran 90.
On 2 April 2012 12:25, Nathaniel Smith n...@pobox.com wrote:
To see if this is an effect of numpy using C-order by default
On Sun, Apr 1, 2012 at 2:28 PM, Kamesh Krishnamurthy kames...@gmail.comwrote:
Hello all,
I profiled NumPy EIG and MATLAB EIG on the same Macbook pro, and both were
linking to the Accelerate framework BLAS. NumPy turns out to be ~4x slower.
I've posted details on Stackoverflow:
a href=http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html;
http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html/a___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Hello,
My email server went down.
Did anyone respond to this post?
Thanks,
William Johnston
-Original Message-
From: William Johnston
Sent: Thursday, March 29, 2012 5:59 PM
To: Discussion of Numerical Python
Subject: \*\*\*\*\*SPAM\*\*\*\*\* Re: [Numpy-discussion]
On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith n...@pobox.com wrote:
To see if this is an effect of numpy using C-order by default instead of
Fortran-order, try measuring eig(x.T) instead of eig(x)?
Just to be clear, .T re-arranges the strides (Making it Fortran
order), butyou'll have to make
On 4/2/12 10:46 AM, William Johnston wrote:
Hello,
My email server went down.
Did anyone respond to this post?
You can check the mail archive here:
http://mail.scipy.org/pipermail/numpy-discussion
--
Francesc Alted
___
NumPy-Discussion mailing
On Mon, Apr 2, 2012 at 4:45 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith n...@pobox.com wrote:
To see if this is an effect of numpy using C-order by default instead of
Fortran-order, try measuring eig(x.T) instead of eig(x)?
Just to be
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up this
particular PR.
I like the suggestion of Nathaniel. Let's get the PR committed with a
single-function interface. I like having the array as the
On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant tra...@continuum.iowrote:
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up
this particular PR.
I like the suggestion of Nathaniel. Let's get the PR
numpy.random are not optimized. If matlab use the random number from
mkl, they will be much faster.
Fred
On Mon, Apr 2, 2012 at 12:04 PM, David Cournapeau courn...@gmail.com wrote:
On Mon, Apr 2, 2012 at 4:45 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Mon, Apr 2, 2012 at 2:25 AM,
Le 2 avril 2012 18:36, Frédéric Bastien no...@nouiz.org a écrit :
numpy.random are not optimized. If matlab use the random number from
mkl, they will be much faster.
In that case this is indeed negligible:
In [1]: %timeit np.random.randn(2000, 2000)
1 loops, best of 3: 306 ms per loop
--
On Sun, Apr 1, 2012 at 8:28 AM, Kamesh Krishnamurthy kames...@gmail.com wrote:
Hello all,
I profiled NumPy EIG and MATLAB EIG on the same Macbook pro, and both were
linking to the Accelerate framework BLAS. NumPy turns out to be ~4x slower.
I've posted details on Stackoverflow:
On Mon, Apr 2, 2012 at 10:36 AM, Tim Cera t...@cerazone.net wrote:
On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant tra...@continuum.iowrote:
The idea of using constants instead of strings throughout NumPy is an
interesting one, but should be pushed to another thread and not hold up
this
I like the strings, maybe that is not the best, but yes I would like to defer
that discussion. Having the string representation does allow 'pad()' to make
some checks on inputs to the built in functions.
About whether to have pad('mean', a, 5) or pad(a, 'mean', 5) - I don't
care. It
On Mon, Apr 2, 2012 at 6:18 PM, Aronne Merrelli
aronne.merre...@gmail.com wrote:
On Sun, Apr 1, 2012 at 8:28 AM, Kamesh Krishnamurthy kames...@gmail.com
wrote:
Hello all,
I profiled NumPy EIG and MATLAB EIG on the same Macbook pro, and both were
linking to the Accelerate framework BLAS.
I think the suggestion is pad(a, 5, mode='mean'), which would be
consistent with common numpy signatures. The mode keyword should probably
have a default, something commonly used. I'd suggest 'mean', Nathaniel
suggests 'zero', I think either would be fine.
I can't type fast enough. :-) I
On the one hand it is nice to be explicit. On the other hand it is nice to
have keyword arguments.
In this case it is very true that pad(a) would not be very clear. Most clear,
though, would be: pad(a, width=5, mode='mean'). You could use keyword
arguments with None as the default and
The plan is use a different issue tracker. We are trying out YouTrack right
now and hope to export the Trac database into YouTrack.
-Travis
the plOn Apr 2, 2012, at 3:16 PM, Pauli Virtanen wrote:
31.03.2012 18:19, Pauli Virtanen kirjoitti:
I moved projects.scipy.org Tracs to run on
Hi,
02.04.2012 22:47, Travis Oliphant kirjoitti:
The plan is use a different issue tracker.
We are trying out YouTrack right now and hope to
export the Trac database into YouTrack.
Certainly, I'm aware :)
However, was the plan to also migrate the Scipy Trac? I understood the
answer to
Dear Python-users,
I am currently very confused about the Scipy routine to obtain the eigenvectors
of a complex matrix.In attached you find two files to diagonalize a 2X2 complex
Hermitian matrix, however, on my computer,
If I run python, I got:
[[ 0.80322132+0.j
Sorry, I saw the cross-posting to the NumPy list and wondered if we were on
the same page.
I don't know of any plans to migrate SciPy Trac at this time: perhaps later.
Thanks for the clarification.
Best,
-Travis
I don'tOn Apr 2, 2012, at 3:58 PM, Pauli Virtanen wrote:
Hi,
2012/4/2 Hongbin Zhang hongbin_zhan...@hotmail.com:
Dear Python-users,
I am currently very confused about the Scipy routine to obtain the
eigenvectors of a complex matrix.
In attached you find two files to diagonalize a 2X2 complex Hermitian
matrix, however, on my computer,
If I run
Both results are correct.
There are 2 factors that make the results look different:
1) The order: the 2nd eigenvector of the numpy solution corresponds to the
1st eigenvector of your solution,
note that the vectors are written in columns.
2) The phase: an eigenvector can be multiplied by an
Hi,
2012/4/2 Hongbin Zhang hongbin_zhan...@hotmail.com:
Dear Python-users,
I am currently very confused about the Scipy routine to obtain the
eigenvectors of a complex matrix.
In attached you find two files to diagonalize a 2X2 complex Hermitian
matrix, however, on my computer,
If I run
Hi,
On Mon, Apr 2, 2012 at 5:38 PM, Val Kalatsky kalat...@gmail.com wrote:
Both results are correct.
There are 2 factors that make the results look different:
1) The order: the 2nd eigenvector of the numpy solution corresponds to the
1st eigenvector of your solution,
note that the vectors
BTW this extra degree of freedom can be used to rotate the eigenvectors
along the unit circle (multiplication by exp(j*phi)). To those of physical
inclinations
it should remind of gauge fixing (vector potential in EM/QM).
These rotations can be used to make one (any) non-zero component of each
27 matches
Mail list logo