Mailman 3 October 2014 - NumPy-Discussion

multi-dimensional c++ proposal
by Neal Becker 28 Oct '14

28 Oct '14

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

2 3

Fwd: numpy.i and std::complex
by Glen Mabey 28 Oct '14

28 Oct '14

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 http://docs.scipy.org/doc/numpy/reference/swig.interface-file.html#other-co…), but still it was pretty disappointing because most of my data is complex, and I'm invoking methods written to use C++'s std::complex class. After quite a bit of puzzling and not much help from previous mailing list posts, I created this very brief but very useful file, which I call numpy_std_complex.i -- /* -*- C -*- (not really, but good for syntax highlighting) */ #ifdef SWIGPYTHON %include "numpy.i" %include <std_complex.i> %numpy_typemaps(std::complex<float>, NPY_CFLOAT , int) %numpy_typemaps(std::complex<double>, NPY_CDOUBLE, int) #endif /* SWIGPYTHON */ 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. Or if anyone wants to improve upon this usage I would be very happy to hear about what I'm missing. I'm sure there's a documented way to submit this file to the git repo, but let me simultaneously ask whether list subscribers think this is worthwhile and ask someone to add+push it for me … Thanks, Glen Mabey

4 11

Why ndarray provides four ways to flatten?
by Alexander Belopolsky 28 Oct '14

28 Oct '14

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?

2 1

Re: [Numpy-discussion] numpy.i and std::complex
by MinRK 28 Oct '14

28 Oct '14

> > 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 (wxPython, PyWin32) or SIP (PyQt) > it is mainly because they are older than Cython. A more recent addition, > PyZMQ, use Cython to wrap C++. > > Just to clarify that, while PyZMQ wraps a library written in C++, libzmq's public API is C, not C++. PyZMQ does not use any of Cython's C++ functionality. I have done other similar (unfortunately not public) projects that wrap actual C++ libraries with Cython, and I have been happy with Cython's C++ support[1]. -MinRK [1] At least as happy as I was with the wrapped C++ code, anyway.

1 0

ODE how to?
by Vincent Davis 28 Oct '14

28 Oct '14

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" (A*Cw*Rho*v^2)/2 : air resistance m*g*Crl : rolling resistance m*g*slope : potential energy (elevation) I am modifying the above equation so that air velocity and slope are dependant on location x. Vair = v + f(x) where f(x) is the weather component and a function of location x. Same goes for slope, slope = g(x) Power is a function I what to optimize/find to minimize time but at this time just simulate. maybe something like: P = 2500/(v+1) I will have restriction on P but not interested in that now. The "course" I what to simulate therefore defines slope and wind speed. and is of a fixed distance. I have played with some of the simple scipy.integrate.odeint examples. I get that I need to define a system of equations but am not really sure the rules for doing so. A little help would be greatly appreciated. Vincent Davis 720-301-3003

1 0

Accept numpy arrays on arguments of numpy.testing.assert_approx_equal()
by Edison Gustavo Muenz 27 Oct '14

27 Oct '14

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 *numpy-dev* list I think it never hurts to say hi :)

1 0

higher accuracy in diagonialzation
by Sunghwan Choi 27 Oct '14

27 Oct '14

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 range. Which one is more accurate? or Are there any ways to control the accuracy for diagonalization? If you have some idea please let me know. Sunghwan Choi Ph. D. candidator Department of Chemistry KAIST (South Korea)

3 2

ANN: NumPy 1.9.1 release candidate
by Julian Taylor 27 Oct '14

27 Oct '14

Hi, We have finally finished the first release candidate of NumOy 1.9.1, sorry for the week delay. The 1.9.1 release will as usual be a bugfix only release to the 1.9.x series. The tarballs and win32 binaries are available on sourceforge: https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ If no regressions show up the final release is planned next week. The upgrade is recommended for all users of the 1.9.x series. Following issues have been fixed: * gh-5184: restore linear edge behaviour of gradient to as it was in < 1.9. The second order behaviour is available via the `edge_order` keyword * gh-4007: workaround Accelerate sgemv crash on OSX 10.9 * gh-5100: restore object dtype inference from iterable objects without `len()` * gh-5163: avoid gcc-4.1.2 (red hat 5) miscompilation causing a crash * gh-5138: fix nanmedian on arrays containing inf * gh-5203: copy inherited masks in MaskedArray.__array_finalize__ * gh-2317: genfromtxt did not handle filling_values=0 correctly * gh-5067: restore api of npy_PyFile_DupClose in python2 * gh-5063: cannot convert invalid sequence index to tuple * gh-5082: Segmentation fault with argmin() on unicode arrays * gh-5095: don't propagate subtypes from np.where * gh-5104: np.inner segfaults with SciPy's sparse matrices * gh-5136: Import dummy_threading if importing threading fails * gh-5148: Make numpy import when run with Python flag '-OO' * gh-5147: Einsum double contraction in particular order causes ValueError * gh-479: Make f2py work with intent(in out) * gh-5170: Make python2 .npy files readable in python3 * gh-5027: Use 'll' as the default length specifier for long long * gh-4896: fix build error with MSVC 2013 caused by C99 complex support * gh-4465: Make PyArray_PutTo respect writeable flag * gh-5225: fix crash when using arange on datetime without dtype set * gh-5231: fix build in c99 mode Source tarballs, windows installers and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.9.1rc1/ Cheers, Julian Taylor

2 1

Subdividing NumPy array into Regular Grid
by Artur Bercik 27 Oct '14

27 Oct '14

I have a rectangle with the following coordinates: import numpy as np ulx,uly = (110, 60) ##uppper left lon, upper left lat urx,ury = (120, 60) ##uppper right lon, upper right lat lrx, lry = (120, 50) ##lower right lon, lower right lat llx, lly = (110, 50) ##lower left lon, lower left lat I want to divide that single rectangle into 100 regular grids inside that, and want to calculate the (ulx, uly), (urx,ury), (lrx, lry), and (llx, lly) for each grid separately: lats = np.linspace(60, 50, 10) lons = np.linspace(110, 120, 10) lats = np.repeat(lats,10).reshape(10,10) lons = np.tile(lons,10).reshape(10,10) I could not imagine what to do then? Is somebody familiar with such kind of problem?

2 1

Re: [Numpy-discussion] Memory efficient alternative for np.loadtxt and np.genfromtxt
by RayS 27 Oct '14

27 Oct '14

At 06:32 AM 10/26/2014, you wrote: >On Sun, Oct 26, 2014 at 1:21 PM, Eelco Hoogendoorn ><hoogendoorn.eelco(a)gmail.com> wrote: > > Im not sure why the memory doubling is necessary. Isnt it possible to > > preallocate the arrays and write to them? > >Not without reading the whole file first to know how many rows to preallocate Seems to me that loadtxt() http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html should have an optional shape. I often know how many rows I have (# of samples of data) from other meta data. Then: - if the file is smaller for some reason (you're not sure and pad your estimate) it could do one of - zero pad array - raise() - return truncated view - if larger - raise() - return data read (this would act like fileObject.read( size ) ) - Ray S

1 0