Dear all,
I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods,
scipy.linalg.eigh and numpy.linalg.eigh give significantly different result.
The results from two methods are different within 10^-4 order. One of them
is inaccurate or both two of them are inaccurate within that
On 2014-10-27 10:37:58, Sunghwan Choi sunghwancho...@gmail.com wrote:
I am now diagonalizing a 200-by-200 symmetric matrix. But the two methods,
scipy.linalg.eigh and numpy.linalg.eigh give significantly different result.
The results from two methods are different within 10^-4 order. One of
Thanks Julian,
Just confirming that this (as expected) solves the issues that we have seen
with gradient in Matplotlib with 1.9.0
best regards
Jens
On Sun, Oct 26, 2014 at 5:13 PM, Julian Taylor
jtaylor.deb...@googlemail.com wrote:
Hi,
We have finally finished the first release
On 27 October 2014 09:37, Sunghwan Choi sunghwancho...@gmail.com wrote:
One of them is inaccurate or both two of them are inaccurate within that
range. Which one is more accurate?
You can check it yourself using the eigenvectors. The cosine distance
between v and M.dot(v) will give you the
The multi-dimensional c++ stuff is interesting (about time!)
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf
--
-- Those who don't understand recursion are doomed to repeat it
___
NumPy-Discussion mailing list
A recent post raised a question about differences in results obtained
with numpy.linalg.eigh() and scipy.linalg.eigh(), documented at
http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.eigh.html#numpy.linalg.eigh
and
Hello,
I was very excited to learn about numpy.i for easy numpy+swigification of C
code -- it's really handy.
Knowing that swig wraps C code, I wasn't too surprised that there was the issue
with complex data types (as described at
Glen Mabey gma...@swri.org wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I
overestimate the number of numpy users who use complex data (let your
voice be heard!) and who also end up using std::complex in C++ land.
I don't think you do. But perhaps you
I’ve implemented support for numpy.arrays for the arguments of
numpy.testing.assert_approx_equal() and have issued a pull-request
https://github.com/numpy/numpy/pull/5219 on Github.
I don’t know if I should be sending the message to the list to notify about
this, but since I’m new to the
On Oct 27, 2014, at 10:45 AM, Sturla Molden sturla.mol...@gmail.com
wrote:
Glen Mabey gma...@swri.org wrote:
I'd really like for this to be included alongside numpy.i -- but maybe I
overestimate the number of numpy users who use complex data (let your
voice be heard!) and who also end up
Glen,
Supporting std::complex was just low enough priority for me that I decided to
wait until someone expressed interest ... and now, many years later, someone
finally has.
I would be happy to include this into numpy.i, but I would like to see some
tests in the numpy repository demonstrating
Python is its own language, but it allows you to import C and C++ code, thus
creating an interface to these languages. Just as with SWIG, you would import
a module written in Cython that gives you access to underlying C/C++ code.
Cython is very nice for a lot of applications, but it is not the
Oops, I meant 'Cython is its own language,' not Python (although Python
qualifies, too, just not in context).
Also, Pyrex, listed in the c-info.python-as-glue.html page, was the pre-cursor
to Cython.
-Bill
On Oct 27, 2014, at 10:20 AM, Bill Spotz wfsp...@sandia.gov wrote:
Python is its own
Glen Mabey gma...@swri.org wrote:
I chose swig after reviewing the options listed here, and I didn't see cython
on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
It's because that list is old and has not been updated. It has the
predecessor to Cython, Pyrex, but
Bill Spotz wfsp...@sandia.gov wrote:
Oops, I meant 'Cython is its own language,' not Python (although
Python qualifies, too, just not in context).
Also, Pyrex, listed in the c-info.python-as-glue.html page, was the
pre-cursor to Cython.
But when it comes to interfacing NumPy, they are
It's been too long since I have done differential equations and I am not
sure the best tools to solve this problem.
I am starting with a basic kinematic equation for the balance of forces.
P\v - ((A*Cw*Rho*v^2)/2 + m*g*Crl + m*g*slope) = m*a
P: power
x: position
v: velocity, x'
a: acceleration x
On 27/10/14 13:14, Neal Becker wrote:
The multi-dimensional c++ stuff is interesting (about time!)
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3851.pdf
OMG, that API is about as awful as it gets. Obviously it is written by
two computer scientists who do not understand what
It's because that list is old and has not been updated. It has the
predecessor to Cython, Pyrex, but they are very different now.
Both SciPy and NumPy has Cython as a build dependency, and also projects
like scikit-learn, scikit-image, statsmodels.
If you find C++ projects which use Swig
The same occurred to me when reading that question. My personal opinion is
that such functionality should be deprecated from numpy. I don't know who
said this, but it really stuck with me: but the power of numpy is first and
foremost in it being a fantastic interface, not in being a library.
On Mon, Oct 27, 2014 at 4:27 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Glen Mabey gma...@swri.org wrote:
I chose swig after reviewing the options listed here, and I didn't see
cython on the list:
http://docs.scipy.org/doc/numpy/user/c-info.python-as-glue.html
It's because that list
Robert Kern robert.k...@gmail.com wrote:
Please stop haranguing the new guy for not knowing things that you
know.
I am not doing any of that. You are the only one haranguing here. I usually
ignore your frequent inpolite comments, but I will do an exception this
time and ask you to shut up.
Given an n-dim array x, I can do
1. x.flat
2. x.flatten()
3. x.ravel()
4. x.reshape(-1)
Each of these expressions returns a flat version of x with some
variations. Why does NumPy implement four different ways to do essentially
the same thing?
___
Hi Alexander,
In my opinion - because they don't do the same thing, especially when
you think in terms in lower-level.
ndarray.flat returns an iterator; ndarray.flatten() returns a copy;
ndarray.ravel() only makes copies when necessary; ndarray.reshape() is
more general purpose, even though you
On Mon, Oct 27, 2014 at 2:24 PM, Eelco Hoogendoorn
hoogendoorn.ee...@gmail.com wrote:
The same occurred to me when reading that question. My personal opinion is
that such functionality should be deprecated from numpy. I don't know who
said this, but it really stuck with me: but the power of
josef.p...@gmail.com wrote:
For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft,
partially?)
No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy
uses a smaller C library called fftpack_lite. Algorithmically they are are
similar, but fftpack_lite has fewer
Sturla Molden sturla.mol...@gmail.com wrote:
If we really need a
kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or
Apple's Accelerate Framework,
I should perhaps also mention FFTS here, which claim to be faster than FFTW
and has a BSD licence:
On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
josef.p...@gmail.com wrote:
For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft,
partially?)
No. SciPy uses the Fortran library FFTPACK (wrapped with f2py) and NumPy
uses a smaller C library
On Mon, Oct 27, 2014 at 11:31 PM, josef.p...@gmail.com wrote:
On Mon, Oct 27, 2014 at 10:50 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
josef.p...@gmail.com wrote:
For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft,
partially?)
No. SciPy uses the Fortran
Hi,
On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Sturla Molden sturla.mol...@gmail.com wrote:
If we really need a
kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or
Apple's Accelerate Framework,
I should perhaps also mention FFTS here,
On 28 Oct 2014 04:07, Matthew Brett matthew.br...@gmail.com wrote:
Hi,
On Mon, Oct 27, 2014 at 8:07 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Sturla Molden sturla.mol...@gmail.com wrote:
If we really need a
kick-ass fast FFT we need to go to libraries like FFTW, Intel MKL or
josef.p...@gmail.com wrote:
ahref=https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13;https://github.com/scipy/scipy/blob/e758c482efb8829685dcf494bdf71eeca3dd77f0/scipy/signal/signaltools.py#L13/a
doesn't seem to mind mixing numpy and
Matthew Brett matthew.br...@gmail.com wrote:
Is this an option for us? Aren't we a little behind the performance
curve on FFT after we lost FFTW?
It does not run on Windows because it uses POSIX to allocate executable
memory for tasklets, as i understand it.
By the way, why did we loose
32 matches
Mail list logo
