11:57 a.m.
Hello everybody,
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.¹
1) Has there been any development in this direction? If not, was it
because of lack of time/interest or because of unexpected obstacles in
the process?
2) In general, could it be feasible to apply structural changes on
gretl's dataset (i.e. remove/collapse observations) from foreign blocks?
Or will "append" remain the only reasonable channel of communication
from foreign blocks to gretl?
thanks
Pietro
¹ http://lists.wfu.edu/pipermail/gretl-devel/2010-February/002547.html
² Though not necessarily less efficient than many of my collegues'
STATA-bundled workflow.
12:58 p.m.
On Sat, 26 Jan 2013, Pietro Battiston wrote:
Hello everybody,
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.¹
1) Has there been any development in this direction? If not, was it
because of lack of time/interest or because of unexpected obstacles in
the process?
Lack of manpower, I would say. I'm not overly familiar with python,
but it certainly is a language worth supporting.
2) In general, could it be feasible to apply structural changes on
gretl's dataset (i.e. remove/collapse observations) from foreign blocks?
Or will "append" remain the only reasonable channel of communication
from foreign blocks to gretl?
No, there's no way to modify the current dataset from a foreign block.
However, you could use the foreign block to write the data you need to
temporary files (as .mat files for matrices, presumably csv files for a
whole dataset) and then, after "end foreign", do a "dataset clear"
plus
open/join/append/mread()/whatever you need.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
2:41 p.m.
On Sat, Jan 26, 2013 at 7:58 AM, Riccardo (Jack) Lucchetti <
r.lucchetti(a)univpm.it> wrote:
On Sat, 26 Jan 2013, Pietro Battiston wrote:
Hello everybody,
>
> 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.¹
>
> 1) Has there been any development in this direction? If not, was it
> because of lack of time/interest or because of unexpected obstacles in
> the process?
>
Lack of manpower, I would say. I'm not overly familiar with python, but it
certainly is a language worth supporting.
Curious what level of integration `foreign` provides. This is the first
I've heard of it. Is the idea that you want to put gretl data into a numpy
array, do some operation in Python, and then move the results back to a
gretl data structure? NumPy provides a C-API, so you wouldn't actually have
to write any Python code to make the data ferrying possible.
As an aside, I've often wanted to wrap the gretl library code in Python
using Cython, so I could use the gretl C/C++ model code from Python, but
much of the numerical python stack is BSD-compatible and this makes me wary
to introduce a GPL library. (No license flame war comments intended.)
Skipper
2) In general, could it be feasible to apply structural changes on
> gretl's dataset (i.e. remove/collapse observations) from foreign blocks?
> Or will "append" remain the only reasonable channel of communication
> from foreign blocks to gretl?
>
No, there's no way to modify the current dataset from a foreign block.
However, you could use the foreign block to write the data you need to
temporary files (as .mat files for matrices, presumably csv files for a
whole dataset) and then, after "end foreign", do a "dataset clear"
plus
open/join/append/mread()/**whatever you need.
------------------------------**-------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/**servizi/hpp/lucchetti<http://www2.econ.un...
------------------------------**-------------------------
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
3:31 p.m.
On Sat, 26 Jan 2013, Skipper Seabold wrote:
As an aside, I've often wanted to wrap the gretl library code in
Python
using Cython, so I could use the gretl C/C++ model code from Python, but
much of the numerical python stack is BSD-compatible and this makes me wary
to introduce a GPL library. (No license flame war comments intended.)
You may find the following link helpful:
http://ideas.repec.org/h/ehu/ehucha/01-14.html
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:01 p.m.
On Sat, Jan 26, 2013 at 10:31 AM, Riccardo (Jack) Lucchetti <
r.lucchetti(a)univpm.it> wrote:
On Sat, 26 Jan 2013, Skipper Seabold wrote:
As an aside, I've often wanted to wrap the gretl library code in Python
> using Cython, so I could use the gretl C/C++ model code from Python, but
> much of the numerical python stack is BSD-compatible and this makes me
> wary
> to introduce a GPL library. (No license flame war comments intended.)
>
You may find the following link helpful:
http://ideas.repec.org/h/ehu/**ehucha/01-14.html<http://ideas.repec.or...
Interesting. Thanks. Cython had made great strides since this was written
and might make a nice addendum to this note. f2py is more or less
abandonware now to be superseded (eventually) by fwrap, though it does work
well for what it does. If I can find some spare cycles, I'd like to play
around with this idea.
Skipper
4:08 p.m.
On Sat, 26 Jan 2013, Skipper Seabold wrote:
Curious what level of integration `foreign` provides. This is the
first
I've heard of it.
See part III of the Gretl User's Guide for details on
interacting with R, Ox, Octave and Stata via the "foreign"
mechanism.
Is the idea that you want to put gretl data into a numpy
array, do some operation in Python, and then move the results back to a
gretl data structure?
I presume that's the sort of thing people would want to do.
NumPy provides a C-API, so you wouldn't actually have to
write any Python code to make the data ferrying possible.
In relation to the other instances of "foreign" support, the
"natural" way of supporting Python would be to write a few I/O
functions in Python (as we've done for R and Octave). But
using the NumPy C-API would be another possibility.
Allin Cottrell
5:02 p.m.
On Sat, Jan 26, 2013 at 11:08 AM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Sat, 26 Jan 2013, Skipper Seabold wrote:
> Curious what level of integration `foreign` provides. This is the first
> I've heard of it.
See part III of the Gretl User's Guide for details on
interacting with R, Ox, Octave and Stata via the "foreign"
mechanism.
> Is the idea that you want to put gretl data into a numpy
> array, do some operation in Python, and then move the results back to a
> gretl data structure?
I presume that's the sort of thing people would want to do.
> NumPy provides a C-API, so you wouldn't actually have to
> write any Python code to make the data ferrying possible.
In relation to the other instances of "foreign" support, the
"natural" way of supporting Python would be to write a few I/O
functions in Python (as we've done for R and Octave). But
using the NumPy C-API would be another possibility.
Thanks for the pointers. Will have a look at the R code.
Skipper
7:18 p.m.
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
7:27 p.m.
On Sat, Jan 26, 2013 at 2:18 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
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:
Cool. Thanks. Is there any way to browse this changeset in the repository
through the web interface? Git/github has eroded all of my other version
control skills.
<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.
This is the preferred import convention for numpy, so there's no reason to
not like it from a style standpoint. Are you concerned with this or the
importing the kitchen sink aspect?
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
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
7:34 p.m.
On Sat, Jan 26, 2013 at 2:27 PM, Skipper Seabold <jsseabold(a)gmail.com>wrote:
On Sat, Jan 26, 2013 at 2:18 PM, Allin Cottrell
<cottrell(a)wfu.edu> wrote:
> 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:
>
Cool. Thanks. Is there any way to browse this changeset in the repository
through the web interface? Git/github has eroded all of my other version
control skills.
Nevermind. I see it in my local checkout.
>
> <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.
>
This is the preferred import convention for numpy, so there's no reason to
not like it from a style standpoint. Are you concerned with this or the
importing the kitchen sink aspect?
>
> 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
>
>
>
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-users
>
7:38 p.m.
On Sat, 26 Jan 2013, Skipper Seabold wrote:
On Sat, Jan 26, 2013 at 2:18 PM, Allin Cottrell
<cottrell(a)wfu.edu> wrote:
> 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:
>
Cool. Thanks. Is there any way to browse this changeset in the repository
through the web interface? Git/github has eroded all of my other version
control skills.
The main changes are here:
http://gretl.cvs.sourceforge.net/viewvc/gretl/gretl/lib/src/gretl_foreign...
Allin Cottrell
8:47 p.m.
On Sat, 26 Jan 2013, Allin Cottrell wrote:
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:
Just crossed my mind: the "foreign" construct has evolved incrementally
over time. In the beginning, we only had diplomatic contacts with R, which
have evolved over times to comprise exchange of matrices etc. Then came
other foreigners, such as Ox, Octave/Matlab, etc. As a consequence, the
issue of passing stuff back and forth was dealt with quite
unsystematically, according to what the state of gretl was back then.
Now that we have the bundle data type, we may want to spent some time
thinking about revisting a few ideas: just like hansl has bundles, R has
lists, Matlab has structures, Python has dictionaries. It'd be
inordinately cool to be able to do something like
<hansl>
capsule["foo"] = 3
capsule["bar"] = "WOW!"
capsule["baz"] = mnormal(20,4)
foreign language=Octave --import=capsule --export=chest
temp = capsule.foo + 1
chest.blip = temp
end foreign
scalar whatever = chest["blip"]
</hansl>
In other words, use the fact that most of our foreign correspondents also
have associative arrays to define the idea of a wrapper structure to deal
with the import/export problems. Ideally, this would have to be done in
RAM (shared memory, perhaps?), but I could live with temporary files.
What do you guys think?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3 p.m.
Jack said
"...It'd be
inordinately cool to be able to do something like
<hansl>
capsule["foo"] = 3
capsule["bar"] = "WOW!"
capsule["baz"] = mnormal(20,4)
foreign language=Octave --import=capsule --export=chest
temp = capsule.foo + 1
chest.blip = temp
end foreign
scalar whatever = chest["blip"]
</hansl>
In other words, use the fact that most of our foreign correspondents also
have associative arrays to define the idea of a wrapper structure to deal
with the import/export problems. Ideally, this would have to be done in
RAM (shared memory, perhaps?), but I could live with temporary files.
What do you guys think?"
I agree this would be way cool!
PS
1:56 p.m.
Am 26.01.2013 20:18, schrieb Allin Cottrell:
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:
This is wonderful, thank you Allin!
<hansl>
matrix M = I(5)
mwrite(M, "(a)dotdir/pytest.mat")
foreign language=python
Not a big issue, but this treats Python as somehow equivalent to Numpy.
I wonder whether this should be made explicit, also given that the
"import numpy" line is hidden. So maybe 'language=numpy' or
'nppython'?
...
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.
There is certainly nothing wrong with this import statement, but it is a
"secret" in some sense, even though it will be in the docs. Maybe
introduce an argument where the abbreviation can be set, as in 'foreign
language=numpy --as="np"'?
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?
Well if you're begging for feature request, you can have them :-)
One comment though: Instead of introducing new functions, maybe it would
be better to modify the existing mwrite() and mread() functions to
prepend @dotdir by default if the string is recognized as a relative
path. (Caveat: The directory lookup stuff is tricky, and I haven't
thought this through. There could be some interference with workdir.
Maybe need to introduce another optional argument in the functions.)
Again, many thanks for python support!
cheers,
sven
4:47 p.m.
On Sun, 27 Jan 2013, Sven Schreiber wrote:
Am 26.01.2013 20:18, schrieb Allin Cottrell:
> 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:
This is wonderful, thank you Allin!
Glad you like it!
> <hansl>
> matrix M = I(5)
> mwrite(M, "(a)dotdir/pytest.mat")
> foreign language=python
Not a big issue, but this treats Python as somehow equivalent to Numpy.
I wonder whether this should be made explicit, also given that the
"import numpy" line is hidden. So maybe 'language=numpy' or
'nppython'?
I'd be OK with 'language=numpy' if people think that's better,
although I'd say the _language_ is python.
> 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.
There is certainly nothing wrong with this import statement, but it is a
"secret" in some sense, even though it will be in the docs. Maybe
introduce an argument where the abbreviation can be set, as in 'foreign
language=numpy --as="np"'?
Giving the user the choice of "as" would be a bit fiddly,
since we need the numpy namespace for basic I/O. But maybe a
python guru could suggest a way to conditionalize our calls
to the numpy functions? If so, I'd suggest the invocation
might be
language=python --numpy="np"
> 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?
[...] Instead of introducing new functions, maybe it would
be better to modify the existing mwrite() and mread() functions to
prepend @dotdir by default if the string is recognized as a relative
path. (Caveat: The directory lookup stuff is tricky, and I haven't
thought this through. There could be some interference with workdir.
Too messy, I think.
Maybe need to introduce another optional argument in the functions.)
OK, that's the route I've taken in current CVS. Now mread()
has an optional second (scalar) argument, "import"; if that's
non-zero we read from @dotdir. And mwrite has an optional
third (scalar) argument, "export"; if non-zero we write into
@dotdir.
Allin
5:37 p.m.
Am 27.01.2013 17:47, schrieb Allin Cottrell:
On Sun, 27 Jan 2013, Sven Schreiber wrote:
> Not a big issue, but this treats Python as somehow equivalent to
Numpy.
> I wonder whether this should be made explicit, also given that the
> "import numpy" line is hidden. So maybe 'language=numpy' or
'nppython'?
I'd be OK with 'language=numpy' if people think that's better,
although I'd say the _language_ is python.
Sure, but Python doesn't speak arrays without numpy, so it's both
together that form the numerical language. So "python-numpy"? (which is
also the name of the debian package BTW).
>> 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.
>
> There is certainly nothing wrong with this import statement, but it is a
> "secret" in some sense, even though it will be in the docs. Maybe
> introduce an argument where the abbreviation can be set, as in 'foreign
> language=numpy --as="np"'?
Giving the user the choice of "as" would be a bit fiddly,
since we need the numpy namespace for basic I/O. But maybe a
python guru could suggest a way to conditionalize our calls
to the numpy functions? If so, I'd suggest the invocation
might be
language=python --numpy="np"
Well I don't want to call myself a guru, especially given the few hours
I have spent with Python in recent months/years, but the namespace alias
is optional. So you can always do 'import numpy' and then just use
'numpy.loadtxt' etc. For the few functions that gretl uses for it's
tricks behind the scenes you could also write:
'from numpy import loadtxt, savetxt'
without having to specify any new namespace label, then you just use
'loadtxt' and 'savetxt' directly (which is bad style in bigger contexts,
but here I think it should be ok). It's no problem to do both this
'from' form for gretl's own needs, and then 'import numpy as
<whatever>'
for further use by the user in the foreign block.
> Maybe need to introduce another optional argument in the functions.)
OK, that's the route I've taken in current CVS. Now mread()
has an optional second (scalar) argument, "import"; if that's
non-zero we read from @dotdir. And mwrite has an optional
third (scalar) argument, "export"; if non-zero we write into
@dotdir.
Great, thanks.
-sven
5:48 p.m.
On Sun, 27 Jan 2013, Sven Schreiber wrote:
Am 27.01.2013 17:47, schrieb Allin Cottrell:
> Giving the user the choice of "as" would be a bit fiddly,
> since we need the numpy namespace for basic I/O. But maybe a
> python guru could suggest a way to conditionalize our calls
> to the numpy functions? If so, I'd suggest the invocation
> might be
>
> language=python --numpy="np"
Well I don't want to call myself a guru, especially given the few hours
I have spent with Python in recent months/years, but the namespace alias
is optional. So you can always do 'import numpy' and then just use
'numpy.loadtxt' etc. For the few functions that gretl uses for it's
tricks behind the scenes you could also write:
'from numpy import loadtxt, savetxt'
without having to specify any new namespace label, then you just use
'loadtxt' and 'savetxt' directly (which is bad style in bigger contexts,
but here I think it should be ok). It's no problem to do both this
'from' form for gretl's own needs, and then 'import numpy as
<whatever>'
for further use by the user in the foreign block.
OK, that sounds like a good approach.
Allin
6:51 p.m.
Am 27.01.2013 18:48, schrieb Allin Cottrell:
On Sun, 27 Jan 2013, Sven Schreiber wrote:
> Well I don't want to call myself a guru, especially given the
few hours
> I have spent with Python in recent months/years, but the namespace alias
> is optional. So you can always do 'import numpy' and then just use
> 'numpy.loadtxt' etc. For the few functions that gretl uses for it's
> tricks behind the scenes you could also write:
> 'from numpy import loadtxt, savetxt'
> without having to specify any new namespace label, then you just use
> 'loadtxt' and 'savetxt' directly (which is bad style in bigger
contexts,
> but here I think it should be ok). It's no problem to do both this
> 'from' form for gretl's own needs, and then 'import numpy as
<whatever>'
> for further use by the user in the foreign block.
OK, that sounds like a good approach.
BTW, it occurs to me that in the python spirit of "explicit is better
than implicit" it could also be just left to the user to do the 'import
numpy as <whatever>'. Then gretl doesn't have to bother at all with the
style that the user prefers, and the user-written python code in the
foreign block would be more self-contained (and explicit, as I said).
-sven
9:50 p.m.
On Sun, 27 Jan 2013, Sven Schreiber wrote:
Am 27.01.2013 18:48, schrieb Allin Cottrell:
> On Sun, 27 Jan 2013, Sven Schreiber wrote:
>> Well I don't want to call myself a guru, especially given the few hours
>> I have spent with Python in recent months/years, but the namespace alias
>> is optional. So you can always do 'import numpy' and then just use
>> 'numpy.loadtxt' etc. For the few functions that gretl uses for it's
>> tricks behind the scenes you could also write:
>> 'from numpy import loadtxt, savetxt'
>> without having to specify any new namespace label, then you just use
>> 'loadtxt' and 'savetxt' directly (which is bad style in bigger
contexts,
>> but here I think it should be ok). It's no problem to do both this
>> 'from' form for gretl's own needs, and then 'import numpy as
<whatever>'
>> for further use by the user in the foreign block.
>
> OK, that sounds like a good approach.
BTW, it occurs to me that in the python spirit of "explicit is better
than implicit" it could also be just left to the user to do the 'import
numpy as <whatever>'. Then gretl doesn't have to bother at all with the
style that the user prefers, and the user-written python code in the
foreign block would be more self-contained (and explicit, as I said).
Fair enough, we could go with that.
Allin Cottrell
1:08 a.m.
Allin, thanks a lot, that's great news.
Il giorno dom, 27/01/2013 alle 18.37 +0100, Sven Schreiber ha scritto:
Am 27.01.2013 17:47, schrieb Allin Cottrell:
> On Sun, 27 Jan 2013, Sven Schreiber wrote:
>
>> Not a big issue, but this treats Python as somehow equivalent to Numpy.
>> I wonder whether this should be made explicit, also given that the
>> "import numpy" line is hidden. So maybe 'language=numpy' or
'nppython'?
>
> I'd be OK with 'language=numpy' if people think that's better,
> although I'd say the _language_ is python.
Sure, but Python doesn't speak arrays without numpy, so it's both
together that form the numerical language. So "python-numpy"? (which is
also the name of the debian package BTW).
I personally do not agree. The language you will write is simply python,
which, for an implementational detail, uses numpy. I don't think the
user is even necessarily assumed to know this is happening, until she
just reads the docs. Unless there really are any reason why we should
want an additional python "flavour" supported, I think the simplest
alternative, "language=python", is the best.
The user can, moreover, do "import numpy" again, or even "import numpy
as whatever", as suggested, without any damage.
If we really want to be very picky (and in my opinion we don't really
need to), probably the cleanest solution would be to move the "import
numpy as np" line _inside_ each function, so that the "np" name is not
used outside them. This is not exactly nice Python code, but I can't
think of a better solution.
While I'm at it: I guess that now most of the work needed to also have a
python console running in gretl is done? Let me point out that if that
was the case, it would be great to be able to choose _which_ console to
use (for instance "ipython" instead than simple "python").
thanks
Pietro
2:17 a.m.
On Mon, 28 Jan 2013, Pietro Battiston wrote:
Allin, thanks a lot, that's great news.
Il giorno dom, 27/01/2013 alle 18.37 +0100, Sven Schreiber ha scritto:
> Am 27.01.2013 17:47, schrieb Allin Cottrell:
>> On Sun, 27 Jan 2013, Sven Schreiber wrote:
>>
>
>>> Not a big issue, but this treats Python as somehow equivalent to Numpy.
>>> I wonder whether this should be made explicit, also given that the
>>> "import numpy" line is hidden. So maybe 'language=numpy' or
'nppython'?
>>
>> I'd be OK with 'language=numpy' if people think that's better,
>> although I'd say the _language_ is python.
>
> Sure, but Python doesn't speak arrays without numpy, so it's both
> together that form the numerical language. So "python-numpy"? (which is
> also the name of the debian package BTW).
I personally do not agree. The language you will write is simply python,
which, for an implementational detail, uses numpy. I don't think the
user is even necessarily assumed to know this is happening, until she
just reads the docs. Unless there really are any reason why we should
want an additional python "flavour" supported, I think the simplest
alternative, "language=python", is the best.
I'm with you on that, Pietro.
The user can, moreover, do "import numpy" again, or even
"import numpy
as whatever", as suggested, without any damage.
If we really want to be very picky (and in my opinion we don't really
need to), probably the cleanest solution would be to move the "import
numpy as np" line _inside_ each function, so that the "np" name is not
used outside them. This is not exactly nice Python code, but I can't
think of a better solution.
Here's what's in current CVS, following Sven's recent suggestions:
1) In the convenience python functions gretl_loadmat() and
gretl_export() -- for shuttling matrices between gretl and python --
we do this sort of thing:
<python>
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
</python>
That is, we import locally the functionality we need from numpy.
2) We leave it up to the user to import from numpy and/or scipy,
with the user's preferred namespace, for more general usage.
Point 1) means that gretl's python support depends on the user
having numpy installed, but I suppose that really goes without
saying: how could you do anything useful in terms of gretl/python
interaction without numpy?
While I'm at it: I guess that now most of the work needed to also
have a
python console running in gretl is done? Let me point out that if that
was the case, it would be great to be able to choose _which_ console to
use (for instance "ipython" instead than simple "python").
Hmm. We currently have the ability to edit/run python scripts in the
gretl gui (with appropriate syntax highlighting) in the same sort of
way as we support Ox programs and R or Octave scripts. As for
providing a "console" (by which I understand an interactive
command-line interface), I'm not sure that is gretl's job.
Allin Cottrell
7:17 a.m.
Am 28.01.2013 03:17, schrieb Allin Cottrell:
On Mon, 28 Jan 2013, Pietro Battiston wrote:
>>>
>>> I'd be OK with 'language=numpy' if people think that's
better,
>>> although I'd say the _language_ is python.
>>
>> Sure, but Python doesn't speak arrays without numpy, so it's both
>> together that form the numerical language. So "python-numpy"? (which
is
>> also the name of the debian package BTW).
>
> I personally do not agree. The language you will write is simply python,
> which, for an implementational detail, uses numpy. I don't think the
> user is even necessarily assumed to know this is happening, until she
> just reads the docs. Unless there really are any reason why we should
> want an additional python "flavour" supported, I think the simplest
> alternative, "language=python", is the best.
I'm with you on that, Pietro.
As I said, it's not a big thing, so go ahead, especially given the
solution chosen below, where the user must make her imports explicit.
Even though I do not agree (a language not only consists of syntax, but
of course of vocabulary as well, which is coming from numpy here), I
guess you can make the point that the Python spirit is always "import
this", and numpy is just one more (complex) module then.
Here's what's in current CVS, following Sven's recent suggestions:
1) In the convenience python functions gretl_loadmat() and
gretl_export() -- for shuttling matrices between gretl and python --
we do this sort of thing:
<python>
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
</python>
That is, we import locally the functionality we need from numpy.
2) We leave it up to the user to import from numpy and/or scipy,
with the user's preferred namespace, for more general usage.
The scipy thing is actually also a good reason not to use numpy blindly,
because a user may want to work with stuff which is only in scipy.
Point 1) means that gretl's python support depends on the user
having numpy installed, but I suppose that really goes without
saying: how could you do anything useful in terms of gretl/python
interaction without numpy?
Yes; OTOH gretl could try to catch the resulting import error:
<python>
try:
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
except ImportError:
<somehow signal the absence of numpy to gretl>
</python>
> While I'm at it: I guess that now most of the work needed to also have a
> python console running in gretl is done? Let me point out that if that
> was the case, it would be great to be able to choose _which_ console to
> use (for instance "ipython" instead than simple "python").
Hmm. We currently have the ability to edit/run python scripts in the
gretl gui (with appropriate syntax highlighting) in the same sort of
way as we support Ox programs and R or Octave scripts. As for
providing a "console" (by which I understand an interactive
command-line interface), I'm not sure that is gretl's job.
I agree, or at least I don't see the use case.
thanks,
sven
1:04 p.m.
On Mon, Jan 28, 2013 at 2:17 AM, Sven Schreiber <svetosch(a)gmx.net> wrote:
Am 28.01.2013 03:17, schrieb Allin Cottrell:
> 2) We leave it up to the user to import from numpy and/or scipy,
> with the user's preferred namespace, for more general usage.
The scipy thing is actually also a good reason not to use numpy blindly,
because a user may want to work with stuff which is only in scipy.
Numpy is a hard dependency of scipy, so I don't think this is really an
issue. Even if I want to work only with, say, scipy.stats, I'm (almost all
the time) going to be using numpy arrays to do so.
>
> Point 1) means that gretl's python support depends on the user
> having numpy installed, but I suppose that really goes without
> saying: how could you do anything useful in terms of gretl/python
> interaction without numpy?
Yes; OTOH gretl could try to catch the resulting import error:
<python>
try:
def gretl_loadmat(fname):
from numpy import loadtxt
dname = gretl_dotdir()
M = loadtxt(dname + fname, skiprows=1)
return M
except ImportError:
<somehow signal the absence of numpy to gretl>
</python>
Catching the import error would indeed be nice for users.
Perhaps this is off-topic, but what happens with something like time-series
or panel data?
>
>> While I'm at it: I guess that now most of the work needed to also have a
>> python console running in gretl is done? Let me point out that if that
>> was the case, it would be great to be able to choose _which_ console to
>> use (for instance "ipython" instead than simple "python").
>
> Hmm. We currently have the ability to edit/run python scripts in the
> gretl gui (with appropriate syntax highlighting) in the same sort of
> way as we support Ox programs and R or Octave scripts. As for
> providing a "console" (by which I understand an interactive
> command-line interface), I'm not sure that is gretl's job.
I agree, or at least I don't see the use case.
FWIW I tend to agree. As I already mentioned, I think it would be great to
expose the gretl library code to the Python side of things, for those that
prefer to work mainly in Python.
Skipper
11:39 a.m.
Il giorno dom, 27/01/2013 alle 21.17 -0500, Allin Cottrell ha scritto:
On Mon, 28 Jan 2013, Pietro Battiston wrote:
[...]
> While I'm at it: I guess that now most of the work needed to also have a
> python console running in gretl is done? Let me point out that if that
> was the case, it would be great to be able to choose _which_ console to
> use (for instance "ipython" instead than simple "python").
Hmm. We currently have the ability to edit/run python scripts in the
gretl gui (with appropriate syntax highlighting) in the same sort of
way as we support Ox programs and R or Octave scripts. As for
providing a "console" (by which I understand an interactive
command-line interface), I'm not sure that is gretl's job.
I was thinking to a console just analogous to what is already present
for R under "Tools -> Start GNU R" (but possibly to be disabled by
default): basically, just call the interpreter and make it load the
series. I would like it a lot - but if that's less trivial than doing a
sort of copypaste from R's case, I perfectly understand that I'm a niche
and this is not urgent.
Pietro
4346
days inactive
4348
days old
23 comments
6 participants
participants (6)
-
Allin Cottrell -
Pietro Battiston -
Riccardo (Jack) Lucchetti -
Skipper Seabold -
Summers, Peter -
Sven Schreiber