Re: [Numpy-discussion] Thoughts on getting "something" in the Python core
I'm still very committed to Numeric3 as I want to bring the numarray and Numeric people together behind a single array object for scientific computing.
Notice that regardless of what I said about what goes into standard Python, something like Numeric3 will always exist for use by scientific users. It may just be a useful add on package like Numeric has always been. There is no way I'm going to abandon use of a more capable Numeric.
Right. I believe that, among all libraries related with numeric array, eventually only one library in the Python core will survive no matter how much advanced functions are available, because of the strong compatibility with other packages.
I don't think this is true. Things will survive based on utility. What we are trying to do with the Python core is define a standard protocol that is flexible enough to handle anybody's concept of an advanced array (in particular the advanced array that will be in scipy.base).
Totally agree. I doubt that Guido will accept a large and complex library into the standard Python core. I think Numeric is already too complex, and numarray is far more complex to be a standard lib in the Python core. Numeric3 must shift its focus from better Numeric to scale-downed Numeric.
I disagree about "shifting focus." Personally, I'm not going to work on something like that until we have a single array package that fulfills the needs of all Numeric and most numarray users. I'm just pointing out that what goes in to the Python core should probably be a scaled down object with a souped-up "protocol" so that the array object in scipy.base can be used through the array protocol by any other package without worrying about having scipy_core at compile time.
For example, how many Python users care about masked arrays? How many Python users want the advanced type from the Python core? I think the advanced array type should in some extension lib, not in core array lib.
Perhaps you do see my point of view. Not all Python users care about an advanced array object but nearly all technical (scientific and engineering users) will. We just need interoperability.
If we make clear our target – becoming a standard library in the Python core, we may have no problem in determining what functions should be in the core array lib and what functions should be in extension libraries using the core array type.
Today, the array type in the Python core is almost useless. If Numeric3 offers just much faster performance on numeric types, many Python users will start to use new array type in their applications. Once it happens, we can create a bunch of extension libraries for more advanced operations on the new array type.
The "bunch of extension libraries" is already happening and is already in progress. I think we've overshot the mark for the Python core, however. No need to wait "til something happens"
With all my heart I hope that Numeric3 gears to this direction before
we get the tragedy to have Numeric4, Numeric5, and so on.
I'm coming to see that what is most important for the Python core is "protocols". Then, there can be a "million" different array types that can all share each other's memory without hassle and much overhead. I'm still personally interested in a better Numeric, however, and so won't be abandoning the concept of Numeric3 (notice I now call it scipy.base --- not a change of focus just a change of name). I just wanted to encourage some discussion on the array protocol. -Travis
On Apr 1, 2005 8:07 PM, Travis Oliphant
I disagree about "shifting focus." Personally, I'm not going to work on something like that until we have a single array package that fulfills the needs of all Numeric and most numarray users. I'm just pointing out that what goes in to the Python core should probably be a scaled down object with a souped-up "protocol" so that the array object in scipy.base can be used through the array protocol by any other package without worrying about having scipy_core at compile time.
Would you tell me what exactly you means by "protocol"? Do you mean a standard defintion of a series of "interfaces" for array type in Python? -- Daehyok Shin Geography Department University of North Carolina-Chapel Hill USA
Daehyok Shin wrote:
On Apr 1, 2005 8:07 PM, Travis Oliphant
wrote: snip
I disagree about "shifting focus." Personally, I'm not going to work on something like that until we have a single array package that fulfills the needs of all Numeric and most numarray users. I'm just pointing out that what goes in to the Python core should probably be a scaled down object with a souped-up "protocol" so that the array object in scipy.base can be used through the array protocol by any other package without worrying about having scipy_core at compile time.
Would you tell me what exactly you means by "protocol"? Do you mean a standard defintion of a series of "interfaces" for array type in Python?
Yes, pretty much. I would even go so far as to say a set of hooks in the typeobject (like the sequence, mapping, and buffer protocols). -Travis
First, thanks for doing this Travis. Travis Oliphant wrote:
I'm coming to see that what is most important for the Python core is "protocols". Then, there can be a "million" different array types that can all share each other's memory without hassle and much overhead. I'm still personally interested in a better Numeric, however, and so won't be abandoning the concept of Numeric3 (notice I now call it scipy.base --- not a change of focus just a change of name). I just wanted to encourage some discussion on the array protocol.
Your array protocol protocol idea sounds good. It should not only make it easier to interoperate with other Python packages, but foreign entities like APL/J, Matlab, and LabVIEW. Regards, Steve -- Steven H. Rogers, Ph.D., steve@shrogers.com Weblog: http://shrogers.com/weblog "Reach low orbit and you're half way to anywhere in the Solar System." -- Robert A. Heinlein
participants (3)
-
Daehyok Shin
-
Steven H. Rogers
-
Travis Oliphant