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: StridedIterator.h: 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. _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion