[Numpy-discussion] is ndarray.base the closest base or the ultimate base?

Citi, Luca lciti@essex.ac...
Wed Sep 23 13:30:16 CDT 2009

> Lacking a robust use case, I would prefer to keep the current
> behavior. It is likely that nothing would break if we changed it, but
> without a use case, I would prefer to be conservative.

Fair enough.

>> When working on
>> http://projects.scipy.org/numpy/ticket/1085
>> I had to walk the chain of bases to establish whether any of the inputs and the outputs were views of the same data.
>> If "base" were the ultimate base, one would only need to check whether any of the inputs have the same base of any of the outputs.

> This is not reliable. You need to check memory addresses and extents
> for overlap (unfortunately, slices complicate this;
> numpy.may_share_memory() is a good heuristic, though). When
> nterfacing with other systems using __array_interface__ or similar
> APIs, the other system may have multiple objects that point to the
> same data. If you create ndarrays from each of these objects, their
> .base attributes would all be different although they all point to the
> same memory.

Lesson learned.
I always make the mistake to think of numpy in terms of arrays while instead
many users use it to access to external data.

>> http://projects.scipy.org/numpy/ticket/1085
But I think in that case it was still an improvement w.r.t. the current implementation
which is buggy. At least it shields 95% of users from unexpected results.
Using memory addresses and extents might be overkilling (and expensive) in that case.


More information about the NumPy-Discussion mailing list