Re: Octave and Database connectivity

[Jordi Gutiérrez Hermoso]

On 12 September 2012 10:01, ahowe42 <address@hidden> wrote:
>
> Jordi Gutiérrez Hermoso-2 wrote
>>
>> They do one thing and one thing oly well, and that is array-oriented
>> numerical computation.
>> : This, in addition to database access, is exactly what I need.
>
> I have some basic familiarity with Python, and understand it is not
> an array-optimized language like Octave;

Writing an array-optimised library for Python is easy, since it's a
general purpose language. Such library is called Numpy:

    
http://www.scipy.org/Numpy_for_Matlab_Users#head-13d7391dd7e2c57d293809cff080260b46d8e664

Just a heads up, since I was confused by this at first: Numpy is the
numerical library core and Scipy is a collection of higher-level
functions written on top of it, very roughly corresponding to our
Octave and our Octave-Forge division.

> in my opinion, the Octave syntax is also superior (small detail).

I agree that Octave's syntax is superficially superior, but only for
things like writing [1 2 3; 4 5 6] instead of np.mat("1 2 3; 4 5 6").

> but wouldn't Numpy/scipy also use the same BLAS & LAPACK/LINPACK
> libraries?

Yes, they do. But they don't keep the 30-year-old Fortran syntax and
Fortran influence that Matlab and Octave does. The Fortran libraries
themselves aren't the problem. The problem is their influence in the
design of the Matlab language which nowadays looks like a half-Fortran
half-Java deformed monster.

> I'm also aware that Java is not the most efficient, but it seems
> likely that (mysql -> Java -> Octave) will be more efficient than
> (mysql -> don't know the wrapper -> Python -> Octave). What are your
> thoughts on this?

Well, the "wrapper" in the middle that you omitted in Java is probably
JDBC, just another Java library. The one you omitted in Python is
the MySQLdb Python library.

> I agree Python is probably worth looking into as an alternative to
> Octave, but need convincing. I am also researching, but do you know
> of array numerical computation benchmarks on Python, and especially
> comparisons to Octave?

Well, benchmarks should always be taken with a grain of salt, but
Numpy is nothing to sneeze at. You should try it yourself. It's not
slow, and it doesn't suffer the interpreter overhead that the current
Octave release does, e.g.. loops are not as slow as in Octavex.

> Do you know if Pytave actually does a system call to Octave, or just
> links to libraries?

Pytave has a C++ wrapper to Octave libraries. It doesn't fork out to
the OS.

> Long term, I suppose it would be better to just porting existing
> Octave code, as opposed to using Pytave to interpret Octave
> scripts...

Numpy is really nice. It's not a fringe project, but a well-developed
package with a lively community. I'm happy to see it slowly gaining
popularity.

Btw, in all this, I should also mention R as another option. I'm not
able to plug it as well as numpy since I'm not as familiar with R, but
the CRAN repository is a testament to its success. It's certainly
better organised than what we've been able to do so far with
Octave-Forge.

- Jordi G. H.