[Numpy-discussion] how is y += x computed when y.strides = (0, 8) and x.strides=(16, 8) ?

Sebastian Walter sebastian.walter at gmail.com
Wed Oct 17 05:38:14 EDT 2012


I'd like to have a look at the implementation of iadd in numpy,
but I'm having a real hard time to find the corresponding code.

I'm basically stuck at
https://github.com/numpy/numpy/blob/master/numpy/core/src/multiarray/number.c#L487

Could someone give me a pointer where to find it?
Respectively, could someone point me to some documentation where the
(folder/file) structure of the numpy sources is explained?

Sebastian



On Thu, Sep 6, 2012 at 2:58 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Sep 6, 2012 at 1:41 AM, Sebastian Berg
> <sebastian at sipsolutions.net> wrote:
>> Hey,
>>
>> No idea if this is simply not support or just a bug, though I am
>> guessing that such usage simply is not planned.
>
> I think that's right... currently numpy simply makes no guarantees
> about what order ufunc loops will be performed in, or even if they
> will be performed in any strictly sequential order. In ordinary cases
> this lets it make various optimizations, but it means that you can't
> count on any specific behaviour for the unusual case where different
> locations in the output array are stored in overlapping memory.
>
> Fixing this would require two things:
> (a) Some code to detect when an array may have internal overlaps (sort
> of like np.may_share_memory for axes). Not entirely trivial.
> (b) A "fallback mode" for ufuncs where if the code in (a) detects that
> we are (probably) dealing with one of these arrays, it processes the
> operations in some predictable order without buffering.
>
> I suppose if someone wanted to come up with these two pieces, and it
> didn't look like it would cause slowdowns in common cases, the code in
> (b) avoided creating duplicate code paths that increased maintenance
> burden, etc., then probably no-one would object to making these arrays
> act in a better defined way? I don't think most people are that
> worried about this though. Your original code would be much clearer if
> it just used np.sum...
>
> -n
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



More information about the NumPy-Discussion mailing list