A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué: > Francesc Alted wrote: > > A Thursday 05 March 2009, Dag Sverre Seljebotn escrigué: > >> No, one could do the same thing that NumPy does (I think, never > >> looked into it in detail), i.e: > >> > >> decide on dimension to do innermost dynamically from strides and > >> sizes save the stride in that dimension for each array > >> for loop using n-dimensional iterator with larger per-loop > >> overhead: save offsets > >> for loop on the innermost dimension with lower per-loop > >> overhead: component-wise operation using offsets and innermost > >> strides > > > > I see. Yes, it seems definitely doable. However, I don't > > understand very well when you say that you have to "decide on > > dimension to do innermost dynamically". For me, this dimension > > should always be the trailing dimension, in order to maximize the > > locality of data. Or I'm missing something? > > For a transposed array (or Fortran-ordered one) it will be the > leading.
Good point. I was not aware of this subtlity. In fact, numexpr does not get well with transposed views of NumPy arrays. Filed the bug in: http://code.google.com/p/numexpr/issues/detail?id=18 > Not sure whether it is possible with other kinds of views > (where e.g. a middle dimension varies fastest), but the NumPy model > doesn't preclude it and I suppose it would be possible with > stride_tricks. Middle dimensions varying first? Oh my! :) -- Francesc Alted _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion