Mailman 3 May 2010 - NumPy-Discussion

loadtxt raises an exception on empty file
by Maria Liukis 25 May '10

25 May '10

Hello everybody, I'm using numpy V1.3.0 and ran into a case when numpy.loadtxt('foo.txt') raised an exception: >>>import numpy as np >>>np.loadtxt('foo.txt') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy/lib/io.py", line 456, in loadtxt raise IOError('End-of-file reached before encountering data.') IOError: End-of-file reached before encountering data. >>> if provided file 'foo.txt' is empty. Would anybody happen to know if it's a feature or a bug? I would expect it to return an empty array. numpy.fromfile() handles empty text files: >>> np.fromfile('foo.txt', sep='\t\n ') array([], dtype=float64) >>> Would anybody suggest a graceful way of handling empty files with numpy.loadtxt() (except for catching an IOError exception)? Many thanks, Masha -------------------- liukis(a)usc.edu

3 2

Tickets for review involving build problems, attn Ralf Gommers
by Charles R Harris 25 May '10

25 May '10

Hi Ralf, As one of the official build gurus in training, could you look over the tickets for review that fix build problems on various platforms? TIA, Chuck

2 1

Can not compile numpy with python2.7 onl linux
by Nadav Horesh 24 May '10

24 May '10

I think that line 3405 in _capi.c (svn 8386) should be: #if PY_VERSION_HEX >= 0x03010000 (At least it looks reasonable considering line 3375, and it solves my problem) Nadav

2 2

Summation of large float32/float64 arrays
by Matthew Turk 24 May '10

24 May '10

Hi all, I have a possibly naive question. I don't really understand this particular set of output: In [1]: import numpy In [2]: a1 = numpy.random.random((512,512,512)).astype("float32") In [3]: a1.sum(axis=0).sum(axis=0).sum(axis=0) Out[3]: 67110312.0 In [4]: a1.sum() Out[4]: 16777216.0 I recognize that the intermediate sums may accumulate error differently than a single call to .sum(), but I guess my concern is that it's accumulating a lot faster than I anticipated. (Interesting to note that a1.sum() returns 0.5*512^3, down to the decimal; is it summing up the mean, which should be ~0.5?) However, with a 256^3 array: In [1]: import numpy In [2]: a1 = numpy.random.random((256,256,256)).astype("float32") In [3]: a1.sum(axis=0).sum(axis=0).sum(axis=0) Out[3]: 8389703.0 In [4]: a1.sum() Out[4]: 8389245.0 The errors are much more reasonable. Is there an overflow or something that occurs with the 512^3? These problems all go completely away with a float64 array, but the issue originally showed up when trying to normalize an on-disk float32 array of size 512^3, where the normalization factor was off by a substantial factor (>2x) depending on the mechanism used to sum. My suspicion is that perhaps I have a naive misconception about intermediate steps in summations, or there is a subtlety I'm missing here. I placed a sample script I used to test this here: http://pastebin.com/dGbHwFPK Thanks for any insight anybody can provide, Matt

4 7

The labeled array package at a glance
by Keith Goodman 23 May '10

23 May '10

For those not familiar with the la package and its labeled array, larry, here's a table that gives you a quick overview: http://bazaar.launchpad.net/~kwgoodman/larry/trunk/annotate/head:/doc/sourc…

1 0

Build failure at rev8246
by T J 21 May '10

21 May '10

Hi, I tried upgrading today and had trouble building numpy (after rm -rf build). My full build log is here: http://www.filedump.net/dumped/build1274454454.txt If someone can point me in the right direction, I'd appreciate it very much. To excerpts from the log file: Running from numpy source directory.numpy/core/setup_common.py:86: MismatchCAPIWarning: API mismatch detected, the C API version numbers have to be updated. Current C api version is 4, with checksum 59750b518272c8987f02d66445afd3f1, but recorded checksum for C API version 4 in codegen_dir/cversions.txt is 3d8940bf7b0d2a4e25be4338c14c3c85. If functions were added in the C API, you have to update C_API_VERSION in numpy/core/setup_common.pyc. MismatchCAPIWarning) In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:36: numpy/core/src/multiarray/buffer.c: At top level: numpy/core/src/multiarray/buffer.c:715: error: conflicting types for ‘_descriptor_from_pep3118_format’ numpy/core/src/multiarray/common.c:221: note: previous implicit declaration of ‘_descriptor_from_pep3118_format’ was here numpy/core/src/multiarray/buffer.c: In function ‘_descriptor_from_pep3118_format’: numpy/core/src/multiarray/buffer.c:751: warning: assignment from incompatible pointer type In file included from numpy/core/src/multiarray/multiarraymodule_onefile.c:45: numpy/core/src/multiarray/multiarraymodule.c: In function ‘initmultiarray’: numpy/core/src/multiarray/multiarraymodule.c:3062: warning: implicit declaration of function ‘_numpymemoryview_init’ error: Command "gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -Inumpy/core/include -Ibuild/src.linux-i686-2.6/numpy/core/include/numpy -Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/include -I/usr/include/python2.6 -Ibuild/src.linux-i686-2.6/numpy/core/src/multiarray -Ibuild/src.linux-i686-2.6/numpy/core/src/umath -c numpy/core/src/multiarray/multiarraymodule_onefile.c -o build/temp.linux-i686-2.6/numpy/core/src/multiarray/multiarraymodule_onefile.o" failed with exit status 1 Hope this helps.

2 2

Numpy doc string license
by Keith Goodman 21 May '10

21 May '10

I'd like to include modified numpy doc strings in my package. Do I just put a note in my license file that says my package contains numpy doc strings and then paste in the numpy license? My package is distributed under a Simplifed BSD license, if that matters.

2 2

astype None
by Keith Goodman 21 May '10

21 May '10

While automating some unit tests for my labeled array class, larry, I assumed that np.array([1, 2], dtype=dtype) would give the same result as np.array([1, 2]).astype(dtype) But it doesn't for dtype=None: >> np.array([1, 2, 3], dtype=None) array([1, 2, 3]) >> np.array([1, 2, 3]).astype(None) array([ 1., 2., 3.]) I prefer the behavior of array where dtype=None is a no-op.

2 2

Problem in swig
by Steven Nien 21 May '10

21 May '10

I want to pass 1 integer and 2 numpy array into the C function as followings: void update_incident_field(int k, float *a, int na, float *b, int nb) { for (i=0; i<na; i ++) { a[i] = a[i] + b[i] * k; } } But I don't know how to write the interface code (***.i) Can someone help me? Thanks! The swig interface code I written(did't work, strange output) %module example %{ #define SWIG_FILE_WITH_INIT #include "example.h" %} %include "numpy.i" %init %{ import_array(); %} %apply (float* INPLACE_ARRAY1, int DIM1) {(float *a, int na), (float *b, int nb)}; %include "example.h"

3 3

dtype and array creation
by Keith Goodman 21 May '10

21 May '10

Why do the follow expressions give different dtype? >> np.array([1, 2, 3], dtype=str) array(['1', '2', '3'], dtype='|S1') >> np.array(np.array([1, 2, 3]), dtype=str) array(['1', '2', '3'], dtype='|S8')

3 5

NumPy-Discussion May 2010