perry at stsci.edu
Thu Feb 10 11:29:27 CST 2005
I don't recall if I've made any mention of our (STScI's)
stance on Numeric3 publicly. From what Travis describes,
his goals do appear to encompass all the important goals
we had for numarray (of course, we need to keep on top of
the details to make sure we haven't overlooked anything).
Should he be able to accomplish this and achieve the
performance goals for small arrays, it would be silly for
us not to take advantage of such a unification.
If the long-term future of numarray is that it served to
identify various improvements to the behavior of numeric arrays
for Numeric3, particularly by providing an illustration of
its practicality and usefulness as well as reusable code,
we think that is fine. We are not wedded to our particular
implementation of these capabilities, nor even to all details
of the interface. We do have a strong need for the ability to
handle misaligned and byte-swapped arrays (which are crucial
for handling memory-mapped arrays and heterogeneous record arrays.)
In our view the issue isn't who owns the array package but
getting one that satisfies the needs of the great majority.
We are not sure how feasible the approach Travis is using is
so we are taking a wait-and-see position on it. We hope he
is successful in achieving these goals.
On the other hand, that point isn't here yet, so we'll
continue doing what we are doing with numarray and making
it work with scipy. If and when the time comes when Numeric3
looks like a viable alternative to numarray (or is clearly
close enough to illustrate that it will be viable), then we
would begin the effort to substitute Numeric3 for numarray.
And if it doesn't work out, it is in our plan to look at
small array performance improvements in numarray.
We intend to stay engaged in design and interface discussions
with Travis, and encourage any others that have a stake in
numarray capabilities to do so as well.
More information about the Numpy-discussion