Mailman 3 January 2008 - NumPy-Discussion

[OT] Which version of svn does svn.scipy.org run ?
by David Cournapeau Jan. 4, 2008

Jan. 4, 2008

Hi, Is it possible to know which version of subversion is used by the svn.scipy.org server ? I am trying to use svnsync on it, without any success, and wanted to know if this was coming from svn.scipy.org or from something else ? cheers, David

2 2

Numpy code coverage
by Stefan van der Walt Jan. 3, 2008

Jan. 3, 2008

Hi all, I read about Titus Brown's Figleaf code coverage tool [1] on the Planet SciPy aggregator [2]. The results of running figleaf on the numpy test-suite [3] covers Python code only. What the best way of discovering the C and C++ code coverage as well? Regards Stéfan [1] http://darcs.idyll.org/~t/projects/figleaf/README.html [2] http://planet.scipy.org [3] http://mentat.za.net/refer/numpy_figleaf/

2 1

non-intuitive behaviour in numpy.array([list], numpy.object_)
by Garnet Chan Jan. 3, 2008

Jan. 3, 2008

When constructing an numpy object array from a list of numpy arrays, one observes the following behaviour >>> import numpy as N >>> a=[N.zeros([2,2], N.object_), N.zeros([2,2], N.object_)] >>> b=N.array(a, N.object_) >>> print b.shape (2, 2, 2) >>> a=[N.zeros([2,2], N.object_), N.zeros([2,1], N.object_)] >>> b=N.array(a, N.object_) >>> print b.shape (2,) I understand that this is because in the 1st instance, numpy is trying to be clever and recognises that the list of arrays "a" can be reshaped into a 3-d array. But surely, if we are constructing an array with the object_ dtype, the first should also be converted into a shape (2,) array?

2 2

need inverse of PyArray_ITER_GOTO1D
by Neal Becker Jan. 2, 2008

Jan. 2, 2008

I need a function that is the inverse of PyArray_ITER_GOTO1D. A bit of guesswork brought me to this, can anyone please tell me if it looks correct? inline npy_intp as_linear (PyArrayIterObject const* it) { if (it->nd_m1 == 0) return (it->dataptr - it->ao->data)/it->strides[0]; else if (it->contiguous) return (it->dataptr - it->ao->data)/it->ao->descr->elsize; else { npy_intp loc = 0; npy_intp offset = (it->dataptr - it->ao->data)/it->ao->descr->elsize; for (int i = 0; i <= it->nd_m1; ++i) { loc += offset / it->factors[i]; offset %= it->factors[i]; } return loc; } }

1 1

Travis and the NumPy Documentation
by Bill Baxter Jan. 2, 2008

Jan. 2, 2008

I just read the blog post about Travis switching jobs Enthought. Was that posted here? If so I'm surprised I missed it. Anyway that sounds like great news for the NumPy/SciPy communities. I hope it also is great news for you and your family, Travis. I have to say that I took some amount of inspiration from seeing how much you were able to do with the open source community while being a tenure track prof, since I've thought about going to academia myself, but would hate to give up involvement with open source projects. Maybe I need to rethink the academia thing now, though. My real question though -- I was wondering whether this move would have any impact on the NumPy documentation? I purchased my copy, and am glad to have been able to contribute to your efforts by doing so, but I know not everyone feels the same. If I recall, part of the incentive given for making the documentation for-fee was that your day-job didn't compensate you for writing such documentation or other NumPy efforts, so charging for documentation was one way to get back a little something. But if I understand correctly, your current employer is very enthusiastic about your work on NumPy. So how about opening up the vault on the documentation a couple of years early? Or is there some sort of contractual agreement with Tregol that prevents that? Just wondering. --bb

2 1

fast iteration (I think I've got it)
by Neal Becker Jan. 1, 2008

Jan. 1, 2008

This is a c-api question. I'm trying to get iterators that are both fast and reasonably general. I did confirm that iterating using just the general PyArrayIterObject protocol is not as fast as using c-style pointers for contiguous arrays. Please confirm if my understanding is correct. There are 2 cases to consider. There are plain old dense arrays, which will be contiguous, and there are array 'views' or 'slices'. The views will not be contiguous. However, in all cases, the strides between elements in one dimension are constant. This last point is key. As long as the stride in the last dimension is a constant, a fast iterator is possible. I put together a small test, which seems to work for the cases I tried. The idea is to use the general iterator (via PyArray_IterAllButAxis), but iteration over the last dimension is done with a c-style pointer. I have tested it with these cases, and the results appear correct: a = array ((xrange(4),xrange(4,8),xrange(8,12)), int) b = a[:,::2] c = a[:,1::2] d = a[:,-1::-1] sum3(a) 0 1 2 3 4 5 6 7 8 9 10 11 sum3(b) 0 2 4 6 8 10 sum3(c) 1 3 5 7 9 11 sum3 (d) 3 2 1 0 7 6 5 4 11 10 9 8 template<typename T> inline T sum3 (object const& o) { PyArrayObject* arr = (PyArrayObject*)(o.ptr()); int last_dim = arr->nd - 1; PyArrayIterObject* it = (PyArrayIterObject*)(PyArray_IterAllButAxis (o.ptr(), &last_dim)); for (int i = 0 ; i < arr->nd; ++i) std::cout << arr->dimensions[i] << ' '; std::cout << '\n'; while (it->index < it->size) { T * dptr = (T*)(it->dataptr); const int stride = arr->strides[last_dim]; for (int i = 0; i < arr->dimensions[last_dim]; ++i) { std::cout << *dptr << ' '; dptr += stride/sizeof(T); } std::cout << '\n'; PyArray_ITER_NEXT(it); } return 0; }

3 3