[Numpy-discussion] Status of Numeric

Arthur ajsiegel at optonline.com
Wed Jan 21 21:06:41 EST 2004


On Wed, 21 Jan 2004 16:22:43 -0700, Tim Hochberg
<tim.hochberg at ieee.org> wrote:

>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. 

Its easy to accept that I am wrong, since I wasn't partiuclarly trying
to be right about anything.

>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.

Couldn't one argue that - for example - in 3d graphic applications the
performance as to short arrays is crucial.

Not that I really care to argue.  I will be happy (and privileged) to
work with whatever is decided and created.  Understanding that I am
out of my league in trying to understand the implications of the
trade-offs  involved.  

But hoping that in fact numarray does come to be accepted as the
"standard".  

>
>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.

Good for me.  I'll be able to understand more of it.

> 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.

I was indeed making an assumption here.  Ifs its wrong, its indeed
wrong.

>
>> 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.
>

The original post was a request for feedback from the wider community.

My only intent was to feedback.  I think the issue is important. 

For reasons that are non-technical, I believe it much to the best that
the community continue to look to one package of the sort as a
standard.  To me. even better if it makes it into the core
distribution.

And I could even be wrong about that.

Art



More information about the Python-list mailing list