[Numpy-discussion] nasty bug in 1.8.0??

Neal Becker ndbecker2 at gmail.com
Mon Dec 2 19:05:41 EST 2013

Jim Bosch wrote:

>> If your arrays are contiguous, you don't really need the strides (use the
> itemsize instead). How is ndarray broken by this?
> ndarray is broken by this change because it expects the stride to be a
> multiple of the itemsize (I think; I'm just looking at code here, as I
> haven't had time to build NumPy 1.8 yet to test this); it has a slightly
> more restricted model for what data can look like than NumPy has, and it's
> easier to always just look at the stride for all sizes rather than
> special-case for size=1.  I think that means the bug is ndarray's (indeed,
> it's probably the kind of bug this new behavior was intended to catch, as I
> should be handling the case of non-itemsize-multiple strides more
> gracefully even when size > 1), and I'm working on a fix for it there now.
> Thanks, Neil, for bringing this to my attention, and to all the NumPy dev's
> for help in explaining what's going on.
> Jim

The problem I encountered, is that canonical generic c++ code looks like:

template<typename in_t>
void F (in_t in) {
  int size = boost::size (in);

This fails when "in" is nd::Array<T,1,0>.  In that case, the iterator is 
strided_iterator.  And here, I find (via gdb), that stride==0.

The failure occurs here:


    template <typename U>
    int distance_to(StridedIterator<U> const & other) const {
        return std::distance(_data, other._data) / _stride; 

How it happens that stride==0, and how to fix it, I don't know.

More information about the NumPy-Discussion mailing list