Re: [Numpy-discussion] [SciPy-Dev] ANN: SciPy 0.11.0 release candidate 1
Hi,
I am pleased to announce the availability of the first release candidate
of
SciPy 0.11.0. For this release many new features have been added, and over
120 tickets and pull requests have been closed. Also noteworthy is that
the
number of contributors for this release has risen to over 50. Some of the
highlights are:
- A new module, sparse.csgraph, has been added which provides a number
of
common sparse graph algorithms.
- New unified interfaces to the existing optimization and root finding
functions have been added.
Sources and binaries can be found at
https://sourceforge.net/projects/scipy/files/scipy/0.11.0rc1/, release
notes are copied below.
Please try this release candidate and report any problems on the scipy
mailing lists.
Failure on Archlinux 64bit, Python 2.7.3, Numpy 1.6.1:
This is what I did:
mkvirtualenv --system-site-packages --distribute scipy_test_rc1
cd ~/.virtualenvs/scipy_test_rc1
mkdir src
wget -O src/scipy-0.11.0rc1.tar.gz
http://downloads.sourceforge.net/project/scipy/scipy/0.11.0rc1/scipy-0.11.0rc1.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fscipy%2Ffiles%2Fscipy%2F0.11.0rc1%2Fts=1342772081use_mirror=netcologne;
cd src
tar xzf scipy-0.11.0rc1.tar.gz
cd scipy-0.11.0rc1
python setup.py build
python setup.py install
cd
python -c import scipy; scipy.test('full')
Running unit tests for scipy
NumPy version 1.6.1
NumPy is installed in /usr/lib/python2.7/site-packages/numpy
SciPy version 0.11.0rc1
SciPy is installed in
/home2/hilboll/.virtualenvs/scipy_test_rc1/lib/python2.7/site-packages/scipy
Python version 2.7.3 (default, Apr 24 2012, 00:00:54) [GCC 4.7.0 20120414
(prerelease)]
nose version 1.1.2
[...]
==
FAIL: test_basic.TestNorm.test_stable
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File
/home2/hilboll/.virtualenvs/scipy_test_rc1/lib/python2.7/site-packages/scipy/linalg/tests/test_basic.py,
line 585, in test_stable
assert_almost_equal(norm(a) - 1e4, 0.5)
File /usr/lib/python2.7/site-packages/numpy/testing/utils.py, line
468, in assert_almost_equal
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 7 decimals
ACTUAL: 0.0
DESIRED: 0.5
--
FAILED (KNOWNFAIL=16, SKIP=42, failures=1)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.fromfunction() doesn't work as expected?
On Thu, Jul 19, 2012 at 5:52 AM, Cheng Li scrappedprince...@gmail.comwrote: Hi All, ** ** I have spot a strange behavior of numpy.fromfunction(). The sample codes are as follows: import numpy as np def myOnes(i,j): return 1.0 a = np.fromfunction(myOnes,(2000,2000)) a 1.0 ** ** Actually what I expected is that the function will return a 2000*2000 2d array with unit value. The returned single float value really confused me. Is this a known bug? The numpy version I used is 1.6.1. ** Your function will be called *once*, with arguments that are *arrays* of coordinate values. It must handle these arrays when it computes the values of the array to be created. To see what is happening, print the values of i and j from within your function, e.g.: In [57]: def ijsum(i, j): : print i =, i : print j =, j : return i + j : In [58]: fromfunction(ijsum, (3, 4)) i = [[ 0. 0. 0. 0.] [ 1. 1. 1. 1.] [ 2. 2. 2. 2.]] j = [[ 0. 1. 2. 3.] [ 0. 1. 2. 3.] [ 0. 1. 2. 3.]] Out[58]: array([[ 0., 1., 2., 3.], [ 1., 2., 3., 4.], [ 2., 3., 4., 5.]]) Your `myOnes` function will work if you modify it something like this: In [59]: def myOnes(i, j): : return np.ones(i.shape) : In [60]: fromfunction(myOnes, (3, 4)) Out[60]: array([[ 1., 1., 1., 1.], [ 1., 1., 1., 1.], [ 1., 1., 1., 1.]]) The bug is in the docstring for fromfunction. In the description of the `function` argument, it says `function` must be capable of operating on arrays, and should return a scalar value. But the function should *not* return a scalar value. It should return an array of values appropriate for the given arguments. Warren ** Regards, Cheng ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [SciPy-Dev] ANN: SciPy 0.11.0 release candidate 1
On 20-Jul-2012 11:34, Andreas Hilboll wrote:
Hi,
I am pleased to announce the availability of the first release candidate
of
SciPy 0.11.0. For this release many new features have been added, and over
120 tickets and pull requests have been closed. Also noteworthy is that
the
number of contributors for this release has risen to over 50. Some of the
highlights are:
- A new module, sparse.csgraph, has been added which provides a number
of
common sparse graph algorithms.
- New unified interfaces to the existing optimization and root finding
functions have been added.
Sources and binaries can be found at
https://sourceforge.net/projects/scipy/files/scipy/0.11.0rc1/, release
notes are copied below.
Please try this release candidate and report any problems on the scipy
mailing lists.
Failure on Archlinux 64bit, Python 2.7.3, Numpy 1.6.1:
This is what I did:
mkvirtualenv --system-site-packages --distribute scipy_test_rc1
cd ~/.virtualenvs/scipy_test_rc1
mkdir src
wget -O src/scipy-0.11.0rc1.tar.gz
http://downloads.sourceforge.net/project/scipy/scipy/0.11.0rc1/scipy-0.11.0rc1.tar.gz?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fscipy%2Ffiles%2Fscipy%2F0.11.0rc1%2Fts=1342772081use_mirror=netcologne;
cd src
tar xzf scipy-0.11.0rc1.tar.gz
cd scipy-0.11.0rc1
python setup.py build
python setup.py install
cd
python -c import scipy; scipy.test('full')
Running unit tests for scipy
NumPy version 1.6.1
NumPy is installed in /usr/lib/python2.7/site-packages/numpy
SciPy version 0.11.0rc1
SciPy is installed in
/home2/hilboll/.virtualenvs/scipy_test_rc1/lib/python2.7/site-packages/scipy
Python version 2.7.3 (default, Apr 24 2012, 00:00:54) [GCC 4.7.0 20120414
(prerelease)]
nose version 1.1.2
[...]
==
FAIL: test_basic.TestNorm.test_stable
--
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/nose/case.py, line 197, in runTest
self.test(*self.arg)
File
/home2/hilboll/.virtualenvs/scipy_test_rc1/lib/python2.7/site-packages/scipy/linalg/tests/test_basic.py,
line 585, in test_stable
assert_almost_equal(norm(a) - 1e4, 0.5)
File /usr/lib/python2.7/site-packages/numpy/testing/utils.py, line
468, in assert_almost_equal
raise AssertionError(msg)
AssertionError:
Arrays are not almost equal to 7 decimals
ACTUAL: 0.0
DESIRED: 0.5
--
FAILED (KNOWNFAIL=16, SKIP=42, failures=1)
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
But when I use
pip install --upgrade SciPy
Installation of vers. 0.10.1 is attempted.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Finished maintenance/1.7.x branch
On Wed, Jul 18, 2012 at 8:09 AM, Travis Oliphant tra...@continuum.io wrote: Hey all, We are going to work on a beta release on the 1.7.x branch.The master is open again for changes for 1.8.x. There will be some work on the 1.7.x branch to fix bugs including bugs that are already reported but have not yet been addressed (like the regression against data-type detection for Sage). It would be great if 1.7.x gets as much testing as possible so that we can discover regressions that may have occurred. But, it was important to draw the line for 1.7.0 features. I think we need to fix the MinGW build problems before the release: https://github.com/numpy/numpy/pull/363 Ondrej ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Problems understanding histogram2d
Hi, I have a problem using histogram2d: from numpy import linspace, histogram2d bins_x = linspace(-180., 180., 360) bins_y = linspace(-90., 90., 180) data_x = linspace(-179.96875, 179.96875, 5760) data_y = linspace(-89.96875, 89.96875, 2880) histogram2d(data_x, data_y, (bins_x, bins_y)) AttributeError: The dimension of bins must be equal to the dimension of the sample x. I would expect histogram2d to return a 2d array of shape (360,180), which is full of 256s. What am I missing here? Cheers, Andreas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems understanding histogram2d
I think since its a joint histogram, you need to have equal no. of data points and bins in both x and y. On Fri, Jul 20, 2012 at 5:11 PM, Andreas Hilboll li...@hilboll.de wrote: Hi, I have a problem using histogram2d: from numpy import linspace, histogram2d bins_x = linspace(-180., 180., 360) bins_y = linspace(-90., 90., 180) data_x = linspace(-179.96875, 179.96875, 5760) data_y = linspace(-89.96875, 89.96875, 2880) histogram2d(data_x, data_y, (bins_x, bins_y)) AttributeError: The dimension of bins must be equal to the dimension of the sample x. I would expect histogram2d to return a 2d array of shape (360,180), which is full of 256s. What am I missing here? Cheers, Andreas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Regards Yogesh Karpate ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray
On Fri, Jul 20, 2012 at 12:24 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: So I have tried the MinGW-5.0.3.exe in Wine, but it tries to install from some wrong url and it fails to install. I have unpacked the tarballs by hand into ~/.wine/drive_c/MinGW: Not surprising, that MinGW is really getting old. It's still the last available one with gcc 3.x as IIRC. To make things reproducible, I've put all my packages in this repository: https://github.com/certik/numpy-vendor binutils-2.17.50-20070129-1.tar.gz w32api-3.7.tar.gz gcc-g77-3.4.5-20051220-1.tar.gz gcc-g++-3.4.5-20051220-1.tar.gz gcc-core-3.4.5-20051220-1.tar.gz mingw-runtime-3.10.tar.gz also in the same directory, I had to do: cp ../windows/system32/msvcr90.dll lib/ Looks like I have an older Wine, not sure if it makes a difference: $ locate msvcr90.dll /Users/rgommers/.wine/drive_c/windows/winsxs/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll /Users/rgommers/__wine/drive_c/windows/winsxs/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll $ locate msvcr71.dll /Users/rgommers/.wine/drive_c/windows/system32/msvcr71.dll /Users/rgommers/Code/wine/dlls/msvcr71/msvcr71.dll.fake /Users/rgommers/Code/wine/dlls/msvcr71/msvcr71.dll.so /Users/rgommers/__wine/drive_c/windows/system32/msvcr71.dll /Users/rgommers/wine/build/wine-1.1.39/dlls/msvcr71/msvcr71.dll.fake /Users/rgommers/wine/build/wine-1.1.39/dlls/msvcr71/msvcr71.dll.so /Users/rgommers/wine/wine-1.1.39/lib/wine/fakedlls/msvcr71.dll /Users/rgommers/wine/wine-1.1.39/lib/wine/msvcr71.dll.so /usr/local/lib/wine/fakedlls/msvcr71.dll /usr/local/lib/wine/msvcr71.dll.so Actually, I made a mistake --- the one in drive_c/windows/system32/msvcr90.dll does not work for me. The one I use is installed by the Python installer (as I found out) and it is in: drive_c/windows/winsxs/x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_d08d0375/msvcr90.dll Which seems to be the same as the one that you use. Just in case, I've put it here: https://github.com/certik/numpy-vendor/blob/master/msvcr90.dll Also I've added the bin directory to PATH using the following trick: $ cat tmp EOF REGEDIT4 [HKEY_CURRENT_USER\Environment] PATH=C:MinGWbin EOF $ wine regedit tmp Then I build and installed numpy using: wine C:\Python27\python setup.py build --compiler=mingw32 install And now there is no segfault when constructing a complex array! So newer (newest) mingw miscompiles NumPy somehow... Anyway, running tests, it gets much farther then before, now it hangs at: test_multiarray.TestIO.test_ascii ... err:ntdll:RtlpWaitForCriticalSection section 0x785b7428 ? wait timed out in thread 0009, blocked by , retrying (60 sec) fixme:keyboard:X11DRV_ActivateKeyboardLayout 0x4090409, : semi-stub! err:ntdll:RtlpWaitForCriticalSection section 0x785b7428 ? wait timed out in thread 0009, blocked by , retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x785b7428 ? wait timed out in thread 0009, blocked by , retrying (60 sec) ... Not sure what this problem is yet. This however is a big problem. I've tested it on the actual Windows 64bit XP box, and the test simply segfaults at this place. Ralf, I should note, that your latest scipy RC tests also segfault on my Windows machine, so maybe something is wrong with the machine... I have some good news for numpy, but bad news for you :) - first, building numpy and testing mostly work for me (tried the last commit from 1.7.x branch) with mingw 5.0.4 with python 2.7.3 and *without* any change in the code (i.e. I did not commented out the part to build msgcr90 import library). - I don't know what the issue is in your environment for msvc90, but I can confirm that it is required. gcc 3.x which was built around 2005/2006 cannot possibly provide the import library for msvcr90, and the build works ok - I strongly suspect some issues because you started with mingw / gcc 4.x. If you moved some libraries in system directories, I suggest you start fresh from a clean state in your VM (or rm -rf .wine :) ). I noticed that when VS 2008 is available, distutils does the configuration with MS compilers, which is broken. I will test later on a machine wo vs 2008. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Segfault in mingw in test_arrayprint.TestComplexArray
On Thu, Jul 19, 2012 at 4:58 PM, Ondřej Čertík ondrej.cer...@gmail.com wrote: So I have tried the MinGW-5.0.3.exe in Wine, but it tries to install from some wrong url and it fails to install. I have unpacked the tarballs by hand into ~/.wine/drive_c/MinGW: binutils-2.17.50-20070129-1.tar.gz w32api-3.7.tar.gz gcc-g77-3.4.5-20051220-1.tar.gz gcc-g++-3.4.5-20051220-1.tar.gz gcc-core-3.4.5-20051220-1.tar.gz mingw-runtime-3.10.tar.gz also in the same directory, I had to do: cp ../windows/system32/msvcr90.dll lib/ I think that's your problem right there. You should not need to do that, and doing so will likely result in having multiple copies of the DLL in your process (you can confirm with process dependency walker). This should be avoided at all cost, as the python C API is not designed to deal with this, and your crashes are pretty typical of what happens in those cases. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] numpy.complex
The syntax numpy.complex(A) seems to be the most natural and obvious thing a user would want for casting an array A to complex values. Expressions like A.astype(complex), array(A, dtype=complex), numpy.complex128(A) are less obvious, especially the last two ones, which look a bit far-fetched. Of course, these tricks can be learned. But Python is a language where natural and obvious things most often work as expected. Here, it is not the case. It also breaks the Principle of Least Astonishment, by comparison with numpy.real(A). numpy.complex is just a reference to the built in complex, so only works on scalars: In [5]: numpy.complex is complex Out[5]: True Thank you for pointing this out. What is the use of storing the complex() built-in function in the numpy namespace, when it is already accessible from everywhere? Best regards, -- O.C. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
On Fri, Jul 20, 2012 at 1:17 PM, OC oc-spa...@laposte.net wrote: numpy.complex is just a reference to the built in complex, so only works on scalars: What is the use of storing the complex() built-in function in the numpy namespace, when it is already accessible from everywhere? for consitancy with teh rest of the numpy types. When I create a numpy array, I might do: np.zeros( (3,4), dtype=np.float32 ) so for the numpy types that have a direct relationship with the python types, we put the type in the numpy namespace as well. But, since in numpy, you generally really want to control your types closely, Id tend to use: np.zeros( (3,4), dtype=np.complex128 ) (or np.complex64) anyway. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] ANN: PyTables 2.4.0 released
== Announcing PyTables 2.4.0 == We are happy to announce PyTables 2.4.0. This is an incremental release which includes many changes to prepare for future Python 3 support. What's new == This release includes support for the float16 data type and read-only support for variable length string attributes. The handling of HDF5 errors has been improved. The user will no longer see HDF5 error stacks dumped to the console. All HDF5 error messages are trapped and attached to a proper Python exception. Now PyTables only supports HDF5 v1.8.4+. All the code has been updated to the new HDF5 API. Supporting only HDF5 1.8 series is beneficial for future development. Documentation has been improved. As always, a large amount of bugs have been addressed and squashed as well. In case you want to know more in detail what has changed in this version, please refer to: http://pytables.github.com/release_notes.html You can download a source package with generated PDF and HTML docs, as well as binaries for Windows, from: http://sourceforge.net/projects/pytables/files/pytables/2.4.0 For an online version of the manual, visit: http://pytables.github.com/usersguide/index.html What it is? === PyTables is a library for managing hierarchical datasets and designed to efficiently cope with extremely large amounts of data with support for full 64-bit file addressing. PyTables runs on top of the HDF5 library and NumPy package for achieving maximum throughput and convenient use. PyTables includes OPSI, a new indexing technology, allowing to perform data lookups in tables exceeding 10 gigarows (10**10 rows) in less than a tenth of a second. Resources = About PyTables: http://www.pytables.org About the HDF5 library: http://hdfgroup.org/HDF5/ About NumPy: http://numpy.scipy.org/ Acknowledgments === Thanks to many users who provided feature improvements, patches, bug reports, support and suggestions. See the ``THANKS`` file in the distribution package for a (incomplete) list of contributors. Most specially, a lot of kudos go to the HDF5 and NumPy (and numarray!) makers. Without them, PyTables simply would not exist. Share your experience = Let us know of any bugs, suggestions, gripes, kudos, etc. you may have. **Enjoy data!** -- The PyTables Team ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.complex
20.07.2012 22:17, OC kirjoitti: The syntax numpy.complex(A) seems to be the most natural and obvious thing a user would want for casting an array A to complex values. I think I disagree here -- that something like that works at all is rather surprising. Remember that numpy.complex, complex64, complex128, float64, ... et al. are types that represent scalar numbers, not arrays. That you get an array out from `float64(some_array)` rather than a ValueError is un-Pythonic. Happens to work, but probably for the wrong reasons. -- Pauli Virtanen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems understanding histogram2d
Hi, On Fri, Jul 20, 2012 at 6:42 PM, yogesh karpate yogeshkarp...@gmail.comwrote: I think since its a joint histogram, you need to have equal no. of data points and bins in both x and y. Makes sense that number of elements of data points (x, y) is equal. Perhaps the documentation like http://docs.scipy.org/doc/numpy-1.6.0/reference/generated/numpy.histogram2d.html could make this aspect more clearer. Especially confused is the requirement that *x* : array_like, shape(N,) and *y* : array_like, shape(M,), may indicate that N!= M could be a feasible case. A slightly better way would just state that x and y must be one dimensional and they must be equal length. My 2 cents, -eat On Fri, Jul 20, 2012 at 5:11 PM, Andreas Hilboll li...@hilboll.de wrote: Hi, I have a problem using histogram2d: from numpy import linspace, histogram2d bins_x = linspace(-180., 180., 360) bins_y = linspace(-90., 90., 180) data_x = linspace(-179.96875, 179.96875, 5760) data_y = linspace(-89.96875, 89.96875, 2880) histogram2d(data_x, data_y, (bins_x, bins_y)) AttributeError: The dimension of bins must be equal to the dimension of the sample x. I would expect histogram2d to return a 2d array of shape (360,180), which is full of 256s. What am I missing here? Cheers, Andreas. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- Regards Yogesh Karpate ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems understanding histogram2d
On Fri, Jul 20, 2012 at 10:11 AM, Andreas Hilboll li...@hilboll.de wrote:
Hi,
I have a problem using histogram2d:
from numpy import linspace, histogram2d
bins_x = linspace(-180., 180., 360)
bins_y = linspace(-90., 90., 180)
data_x = linspace(-179.96875, 179.96875, 5760)
data_y = linspace(-89.96875, 89.96875, 2880)
histogram2d(data_x, data_y, (bins_x, bins_y))
AttributeError: The dimension of bins must be equal to the dimension of
the sample x.
I would expect histogram2d to return a 2d array of shape (360,180), which
is full of 256s. What am I missing here?
It is a joint histogram, so the x and y inputs represent each
dimension of a 2-dimensional sample. So, the x and y arrays must be
the same length. (the documentation does appear to be incorrect here).
The bins do not need to have the same length. Here is your example
adjusted (with many fewer bins so I could print it in the console) -
note since you just have two ramps from linspace as the data, most
of the points are near the diagonal.
In [15]: bins_x = linspace(-180,180,6)
In [16]: bins_y = linspace(-90,90,4)
In [17]: data_x = linspace(-179.96875, 179.96875, 2880)
In [18]: data_y = linspace(-89.96875, 89.96875, 2880)
In [19]: H, x_edges, y_edges = np.histogram2d(data_x, data_y, (bins_x, bins_y))
In [20]: H
Out[20]:
array([[ 576.,0.,0.],
[ 384., 192.,0.],
[ 0., 576.,0.],
[ 0., 192., 384.],
[ 0.,0., 576.]])
In [21]: x_edges
Out[21]: array([-180., -108., -36., 36., 108., 180.])
In [22]: y_edges
Out[22]: array([-90., -30., 30., 90.])
So, back to that AttributeError - it is clearly unhelpful. Looking
through the code, it looks like the x,y input arrays are joined into a
2D array with a numpy core function 'atleast_2d'. If this function
sees inputs that are not the same length, it actually produces a
2-element numpy object array:
In [57]: data_x.shape, data_y.shape
Out[57]: ((5760,), (2880,))
In [58]: data_xy = atleast_2d([data_x, data_y])
In [59]: data_xy.shape, data_xy.dtype
Out[59]: ((1, 2), dtype('object'))
In [60]: data_xy[0,0].shape, data_xy[0,1].shape
Out[60]: ((5760,), (2880,))
If the x, y array have the same length this looks a lot more logical:
In [62]: data_x.shape, data_y.shape
Out[62]: ((2880,), (2880,))
In [63]: data_xy = atleast_2d([data_x, data_y])
In [64]: data_xy.shape, data_xy.dtype
Out[64]: ((2, 2880), dtype('float64'))
So, that Assertion error comes up histogramdd (which actually does the
work), expects the data array to be [Ndimension, Nsample], and the
number of dimensions is set by the number of bin arrays that were
input (2). Since it sees that [1,2] shaped object array, it treats
that as a 2-element, 1-dimension dataset; thus, at that level, the
AssertionError actually makes sense.
Hope that helps,
Aronne
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Memory Leak
The attached program leaks about 24 bytes per loop. The comments give a
bit more detail as to when the leak occurs and doesn't. How can I track
down where this leak is actually coming from?
Here is a sample run on my machine:
$ python simple.py
Python Version: 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3]
numpy version: 1.6.1
/etc/lsb-release:
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION=Ubuntu 12.04 LTS
110567424.0 24.465408
135168000.0 24.600576
159768576.0 24.600576
184369152.0 24.600576
208969728.0 24.600576
233570304.0 24.600576
258035712.0 24.465408
282636288.0 24.600576
307236864.0 24.600576
331837440.0 24.600576
import numpy as np
import os
import sys
def get_memsize():
Returns current process memory size in bytes
pagesize = os.sysconf(SC_PAGE_SIZE)
with open('/proc/self/statm') as statm:
mem=float( statm.readline().split()[0] )*pagesize
return mem
print Python Version: , sys.version
print numpy version: , np.__version__
with open(/etc/lsb-release) as rel:
print /etc/lsb-release:
for line in rel:
print , line,
# create numpy arrays
a = np.zeros(dtype=[('f', 'f8')], shape=tuple())
b = np.zeros(shape=(1,))
# create a counter, can be integer or float
f = 0
# create a constant value
i = 0
memory=get_memsize()
while True:
f += 1
# these leak
a['f'] = f
#b[:] = f
# these do not leak
#b[0] = f
#b[:] = 0
#a['f'] = i
#a['f'] = 0
# if there is no assignment to an array
# there is no leak
# this just prints the current memory
# and average per-assignement delta in bytes
if f=1e6:
newmemory = get_memsize()
print newmemory, (newmemory-memory)/f
memory = newmemory
f=0
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
