On Sat, 26 Jan 2013, Pietro Battiston wrote:
I love Gretl's "foreign" code blocks capability, and
would love even
more the possibility of using Python in them, which was at some time
suggested as easy to implement.
Yes, quite easy. In fact, so easy that Python support is now
in gretl CVS and the snapshots for Windows and OS X. Here's a
trivial example:
<hansl>
matrix M = I(5)
mwrite(M, "(a)dotdir/pytest.mat")
foreign language=python
G = gretl_loadmat('pytest.mat')
G *= 5
gretl_export(G, 'pyout.mat')
end foreign
matrix pymat = mread("(a)dotdir/pyout.mat")
print pymat
</hansl>
When you call python via gretl's "foreign" mechanism you have
three gretl_ functions available:
gretl_loadmat(): reads a matrix, as written by gretl's
mwrite(), from gretl's per-user dotdir.
gretl_export(): writes a matrix, readable via gretl's mread(),
into the gretl dotdir.
gretl_dotdir(): in case you need it, gives the dotdir path.
When python is invoked via gretl, one thing that happens
automatically is:
import numpy as np
This is in part because numpy is needed for the implementation
of gretl_loadmat and gretl_export, which use np.loadtxt and
np.savetxt respectively. I'm not a python person, but I
suspect that some users might not like the "import" statement
as I have it. Comments welcome.
Related question: in Python, as in R, Octave and Ox, the
"dotdir" business (which ensures we have a user-writable and
gretl-findable location) is hidden from the matrix read/write
functions, but on the gretl end you have to use @dotdir
explicitly with mwrite and mread when interfacing with
"foreign".
Any sale for a pair of gretl functions mexport() and mimport()
which handle the prepending of dotdir automatically?
Allin Cottrell