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
[email protected]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
