[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