Torch does look pretty nice. Yeh, providing wrappers for torch may be easier (and result in faster code) as long as their data format is relatively sane. I'm not really sure how one goes about interfacing numpy.arrays with external code, but it's certainly possible, since that's how the bulk of SciPy was written (by calling on external fortran or C code, not sure about C++). [info about NumPy and SWIG here if you haven't seen it already:
http://www.scipy.org/Cookbook/SWIG_and_NumPy]
The other problem with my estimate on time to port Matlab code is that a figure like 4200 lines doesn't reveal the real cost if one of those lines happens to be a call to something like Matlab's nonlinear optimization routines or something else for which there is currently no numpy equivalent.
I don't think there are /many/ of those gotchas in Netlab, but eigs() is one of them. As far as I know SciPy has no function to get just a few eigenvalues without having to find them all. Nothing prevents it from being added to SciPy (matlab's eigs is just a wrapper for the freely available ARPACK) it just hasn't been done yet.
Anyway if you're just wrapping existing C++, you know you're not going to run into rats' nests like that.
--bb
On 4/21/06, David Cournapeau
<david@ar.media.kyoto-u.ac.jp> wrote:
Bill Baxter wrote:
> One thing... I'm not sure why you think porting Netlab to SciPy would
> be such a huge task. It's a big task, sure. Porting to C++ would
> definitely be a huge task.
Well, the nice thing with C++ is that you can plug it directly to python
using swig and hand-coded wrapping code. It is actually one reason why I
want to go on python: wrapping C code for matlab is awful (there is no
way to control the memory handler, for example), and things like swig or
python::boost are much better (without even taking into account that C
and python have the same convention for indexing and row major
ordering). As the code is BSD, I think the licenses are compatible with
scipy. I think in a summer internship, you could write good swig or
boost::python extension to have the wrapping mostly automated.
Porting from matlab to scipy involve porting/testing all the code,
whereas using C++ code involve mostly glue-code. But maybe I am
underestimating the difficulty...
David