[Numpy-discussion] Speeding up numarray -- questions on its design

[Ralf Juengling]

On Mon, 2005-01-17 at 11:12, Perry Greenfield wrote:
> Travis Oliphant wrote:
> > 3) There seem to be too many files to define the array.  The mixture of
> > Python and C makes trying to understand the source very difficult.  I
> > thought one of the reasons for the re-write was to simplify the source
> > code.
> >
> I think this reflects the transitional nature of going from mostly 
> Python
> to a hybrid. We agree that the current state is more convoluted than it
> ought to be. If NDarray were all C, much of this would ended (though in
> some respects, being all in C will make it larger, harder to understand
> as well). The original hope was that most of the array setup computation
> could be kept in Python but that is what made it slow for small arrays
> (but it did allow us to implement it reasonably quickly with big array
> performance so that we could start using for our own projects without
> a long development effort). Unfortunately, the simplification in the
> rewrite is offset by handling the more complex cases (byte-swapping,
> etc.) and extra array indexing capabilities.

I took a cursory look at the C API the other day and learned about
this capability to process byte-swapped data. I am wondering why 
this is a good thing to have. Wouldn't it be enough and much easier 
to drop this feature and instead equip numarray IO  routines with 
the capability to convert to and from a foreign endian to the host
endian encoding?
 
ralf