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
Hi,
On Mon, Apr 2, 2012 at 5:38 PM, Val Kalatsky 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 are written in c
Hi,
2012/4/2 Hongbin Zhang :
> 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:
>
> [[
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 arbitra
2012/4/2 Hongbin Zhang :
> 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.80
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,
>
> 02.0
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 0.59500941+0.02827207j]
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 t
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 mo
31.03.2012 18:19, Pauli Virtanen kirjoitti:
> I moved projects.scipy.org Tracs to run on mod_python (instead of CGI),
> in order to try to combat the present performance issues. Let's see if
> this helps with the "database is locked" problem.
>
> Please drop me a message if something stops working
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
>
>
> 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.
On Mon, Apr 2, 2012 at 6:18 PM, Aronne Merrelli
wrote:
> On Sun, Apr 1, 2012 at 8:28 AM, Kamesh Krishnamurthy
> 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 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
> car
On Mon, Apr 2, 2012 at 10:36 AM, Tim Cera wrote:
>
>
> On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant wrote:
>
>> 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
On Sun, Apr 1, 2012 at 8:28 AM, Kamesh Krishnamurthy 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:
> http://stackoverflow.com/q
Le 2 avril 2012 18:36, Frédéric Bastien 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
--
Olivier
http://tw
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 wrote:
>
>
> On Mon, Apr 2, 2012 at 4:45 PM, Chris Barker wrote:
>>
>> On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith wrote:
>> > To see i
On Mon, Apr 2, 2012 at 12:09 PM, Travis Oliphant wrote:
> 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
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 4:45 PM, Chris Barker wrote:
> On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith 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
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 mai
On Mon, Apr 2, 2012 at 2:25 AM, Nathaniel Smith 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 sure your ari
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]
\*\*\*\*\*SPAM\*\
http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html";>
http://motovideo.cl/videos/website_2.0/wp-content/02efpk.html___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Apr 1, 2012 at 2:28 PM, Kamesh Krishnamurthy 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:
> http://stackoverflow.com/q
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 wrote:
> To see if this is an effect of numpy using C-order by default instead of
> F
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" wrote:
> Hello all,
>
> I profiled NumPy EIG and MATLAB EIG on the same Macbook pro, and both were
> linking to the
28 matches
Mail list logo
