Tim Churches wrote:

Travis Oliphant wrote:

...

I've added a patch to the Porting to NumPy page so that RPy uses NumPy instead of Numeric. It would be very helpful for unification if these package authors would accept these patches. NumPy is far enough along in development that I don't think there is any reason for new releases of packages to continue to support Numeric.

For numarray-support in packages the transition may take a little longer. I know that some think that supporting multiple array packages may be a good idea. I think that is a recipe for long-term headaches. We are moving to get the array interface into Python. Until that happens (hopefully by Python 2.6), third-party code should write to NumPy. You can use the attribute-based array interface if you are willing to alter that at some point in the future when the array interface is moved into Python.

Yes, except that we have quite a lot of code in fielded applications which is written with Numeric, and which also uses RPy. We currently have no funds to do the Numeric to NumPy port in our code. If RPy dropped support for Numeric, we would be forced to use increasing old versions of RPy, which means we would be locked into increasing old versions of R.

I don't see why. RPy will use numpy internally to communicate with R. Your code will use Numeric internally to do whatever you do. As of Numeric 24.2, each can consume the other's arrays seamlessly. You might want to intersperse some Numeric.asarray() and numpy.asarray() calls at the boundaries, but that should be it.

I would argue that it is premature for RPy to drop support for Numeric. Maybe by the time Python 2.6 is out and NumPy is part of Python.

numpy itself will never be part of Python. We're aiming for a standardized array interface and an API for manipulating that interface to become part of Python. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

Tim Churches wrote:

Robert Kern wrote:

...

I don't see why. RPy will use numpy internally to communicate with R. Your code will use Numeric internally to do whatever you do. As of Numeric 24.2, each can consume the other's arrays seamlessly.

OK, if that is the case, then it might be OK for us if RPy dropped Numeric support.

...

You might want to intersperse some Numeric.asarray() and numpy.asarray() calls at the boundaries, but that should be it.

Ah, so not quite seemless consumption of each other's arrays?

No, that's precisely the consumption that I was referring to. Generally, calling a function in Numeric on a numpy array will work just fine and vice versa. The only tricky bit would be code that doesn't "consume" arrays so much as perform operations on them. For example, def f(x): return N.sum(x, axis=0) def g(x): return x.typecode() f() would work fine with either N=Numeric or N=numpy on Numeric x arrays or numpy x arrays or indeed lists of numbers or anything else that could be converted to an array with asarray(). g() would not work with numpy arrays since numpy arrays don't have an .typecode() method. Of course, neither do lists of numbers and all of the other various things that a user might pass in hoping that the author programmed robustly and called asarray().

We'll need to test.

Of course. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco