[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