[Numpy-discussion] NumPy re-factoring project

Hans Meine meine@informatik.uni-hamburg...
Fri Jun 11 03:52:52 CDT 2010


On Friday 11 June 2010 10:38:28 Pauli Virtanen wrote:
> Fri, 11 Jun 2010 10:29:28 +0200, Hans Meine wrote:
> > Ideally, algorithms would get wrapped in between two additional
> > pre-/postprocessing steps:
> > 
> > 1) Preprocessing: After broadcasting, transpose the input arrays such
> > that they become C order.  More specifically, sort the strides of one
> > (e.g. the first/the largest) input array decreasingly, and apply the
> > same transposition to the other arrays (in + out if given).
> > 
> > 2) Perform the actual algorithm, producing a C-order output array.
> > 
> > 3) Apply the reverse transposition to the output array.
> 
> [clip]
> 
> The post/preprocessing steps are fairly easy to implement in the ufunc
> machinery.
> 
> The problem here was that this would result to a subtle semantic change,
> as output arrays from ufuncs would no longer necessarily be in C order.

I don't see it as a problem, really.  People who rely on C order will also 
give C order input arrays to the algorithms.

> We need to explicitly to *decide* to make this change, before proceeding.
> I'd say that we should simply do this, as nobody should depend on this
> assumption.

+1

I seem to recall that even Travis, or at least David C. gave a similar opinion 
in the mentioned thread in the past.

> I think I there was some code ready to implement this shuffling. I'll try
> to dig it out and implement the shuffling.

That would be great!

Ullrich Köthe has implemented this for our VIGRA/numpy bindings:
  http://tinyurl.com/fast-ufunc
At the bottom you can see that he basically wraps all numpy.ufuncs he can find 
in the numpy top-level namespace automatically.

Looking forward to this,
  Hans


More information about the NumPy-Discussion mailing list