Native numpy support

I see that revision #31 in the development trunk adds numpy support, but my question is still relevant. Is this expected to be a "also supports numpy", or a "natively uses numpy"?

I see that revision #31 in the development trunk adds numpy support, but my question is still relevant. Is this expected to be a "also supports numpy", or a "natively uses numpy"?

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

There is no plan to replace Numeric arrays with the NumPy API. I'm curious, how dated would you rate Numeric arrays to be? Is Numpy something that a majority uses? Would it be wise to remove Numeric array support, or should both NumPy and Numeric array be supported?

Numeric's last release was in 2005, and is the ancestor of NumPy. Much of the API is the same between the two (technically, most of Numeric's API has been replicated in numpy, numpy has newer features).

I would say the majority of projects that I look at (scipy in particular) use numpy now.
To be honest, I don't think there would be much benefit in removing Numeric support (it obviously helps you for one), given that it is already there.

I would like to see numpy arrays used as the default, but the benefit is purely an aesthetic one and probably not worth the hassle.

Well, I only interface Octave. I don't do any computations with NumPy or Numeric. So it really doesn't matter to me. Supporting both would just mean extra work.

 If I'm supporting both Numeric and NumPy, I would have to have two test suites and separate build options.

Ah, in that case, I would recommend moving solely to numpy, and have Numeric supported only through the user converting the arrays (as I said earlier, the conversion itself is simple, just a pain to keep doing).

Right now, NumPy is supported by its oldnumeric interface. Numeric is still very common. For instance, OpenSUSE (which I use at work) still provides only Numeric in its main repo. For may user, the more lightweight Numeric will be far enough, because they will only want to extract the results from Octave for their further processing, which may not use Numeric/NumPy at all.

On the other hand, Numeric is not maintained any more, and contains bugs (I know at least one) which will probably never be fixed.
I think NumPy is one example where the Python community was moving forward too fast for the rest of the world :) Luckily they realized this might be the case and provided excellent backward compatibility.

Currently, the situation is such that if you build pytave with --enable-numpy, and you have NumPy, NumPy will be used for the array interface. Some new features of NumPy will be exploited, such as logical (bool) arrays.

When you import pytave, there will be pytave.Numeric variable pointing to the numpy.oldnumeric module. This is done so that you (and we) can (relatively) easily write code that will work with both configurations. Of course, you can also work with the passed in/out NumPy arrays via the normal NumPy interface.

Right now, this is by far the easiest way to support both modules (I mean, support both configurations with *only* Numeric and *only* NumPy installed), which I consider important. In the future, when we realize Numeric is no longer being actually used, the code may transition to use exclusively NumPy.

I'm not sure if using the old interface brings any significant negative performance impacts. If yes, it should be considered whether and when they outweigh the benefit of supporting Numeric.

Thanks for the detailed input.

I would think (and I could be wrong here), that if someone was *really* worried about performance, they wouldn't keep making calls through pytave (or any other 'bridge' to another process) and instead remake the files so that these calls are minimised.

True. For instance, I make use of Pytave to employ computational scripts in Octave in a web application written in Python (Django) - there's mostly a few setup calls (add paths, load Octave packages) and then a main call to the core function. I hope users will realize that the conversions are not zero cost, and they should organize the work reasonably.

On the other hand, if someone finds out that copy_octarray_to_pyarrobj or copy_pyarrobj_to_octarray can be made, say, 3x faster by using a newer C API for NumPy, then switching to NumPy will be instantly worth more, at least for me. But as I said, Numeric is bound to fade away, only it's probably happening much slower than the NumPy community expected.