Arthur wrote:
[SNIP]
> Which, to me, seems like a worthy goal.
>> On the other hand, it would seem that the goal of something to move
> into the core would be performance optimized at the range of array
> size most commonly encountered. Rather than for the extraodrinary,
> which seems to be the goal of numarray, responding to specific needs
> of the numarray development team's applications.
I'm not sure where you came up with this, but it's wrong on at least two
counts. The first is that last I heard the crossover point where
Numarray becomes faster than Numeric is about 2000 elements. It would be
nice if that becomes smaller, but I certainly wouldn't call it extreme.
In fact I'd venture that the majority of cases where numeric operations
are a bottleneck would already be faster under Numarray. In my
experience, while it's not uncommon to use short arrays, it is rare for
them to be a bottleneck.
The second point is the relative speediness of Numeric at low array
sizes is the result that nearly all of it is implemented in C, whereas
much of Numarray is implemented in Python. This results in a larger
overhead for Numarray, which is why it's slower for small arrays. As I
understand it, the decision to base most of Numarray in Python was
driven by maintainability; it wasn't an attempt to optimize large arrays
at the expense of small ones.
> Has the core Python development team given out clues about their
> feelings/requirements for a move of either Numeric or numarray into
> the core?
I believe that one major requirement was that the numeric community come
to a consensus on an array package and be willing to support it in the
core. There may be other stuff.
> It concerns me that this thread isn't trafficked.
I suspect that most of the exchange has taken place on
numpy-discussion at lists.sourceforge.net.
[SNIP]
-tim