7:07 a.m.
I now have several 'py4gretl' functions calculating some extra VECM
stuff. A problem I encountered during debugging is that generated
matrices "disappear" after redefining the function (without calling them!).
Example:
I run the following command:
matrix weakexo = p4g_vecm_weakexo(endo, 2, 1, 3, 0, 0, rexo, 0, uexo)
...and yes, it's there:
? weakexo
weakexo
3.1524 1.0000 0.075816
6.2215 1.0000 0.012621
BUT when I run the script with the function definition p4g_vecm_weakexo
again (and nothing else!), the previous output disappears:
? weakexo
command 'weakexo' not recognized
Bug or feature? (I vote for bug.)
-sven
9:43 a.m.
On Wed, 10 Jan 2007, Sven Schreiber wrote:
I run the following command:
matrix weakexo = p4g_vecm_weakexo(endo, 2, 1, 3, 0, 0, rexo, 0, uexo)
...and yes, it's there:
? weakexo
weakexo
3.1524 1.0000 0.075816
6.2215 1.0000 0.012621
BUT when I run the script with the function definition p4g_vecm_weakexo
again (and nothing else!), the previous output disappears:
? weakexo
command 'weakexo' not recognized
The action of running a script clears out gretl's workspace.
I suspect it might be non-trivial to change that behaviour, though
this is something to think about.
However, you can "include" a file that defines a function without
the clearout effect.
Allin
4:24 p.m.
Allin Cottrell wrote:
The action of running a script clears out gretl's workspace.
I suspect it might be non-trivial to change that behaviour, though this
is something to think about.
I see. Then my question would be, how can one achieve persistence of
generated matrices? Correct me if I'm wrong, but I presume the answer is
that the foundation for that is there (given what you said about the C
functions that add matrices to session files), but that the
corresponding user interface awaits implementation.
-s
6:52 p.m.
On Wed, January 10, 2007 13:07, Sven Schreiber wrote:
I now have several 'py4gretl' functions calculating some
extra VECM
stuff.
This sound very cool indeed. Could you post some examples of functions calling
python and carrying the results back into gretl? We may
1) get a taste of what's in store
2) check if there's anything tricky to set to get python working properly
3) start hacking on python (something I've wanted to do for a long time)
The more trivial the better, like for example take two matrices, use python to
multply them and shuffle the result back into gretl.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
8:37 p.m.
On Wed, 10 Jan 2007, Sven Schreiber wrote:
Allin Cottrell wrote:
> The action of running a script clears out gretl's workspace.
> I suspect it might be non-trivial to change that behaviour, though this
> is something to think about.
I see. Then my question would be, how can one achieve persistence of
generated matrices?
Actually, on second thoughts that shouldn't be difficult. Right
now, when you run a script, gretl goes through a checklist of
stuff to clear out, including undefining all existing user
matrices. It would be easy enough to skip the "clear out
matrices" step. Is that generally desirable?
Allin.
6:05 a.m.
Riccardo (Jack) Lucchetti schrieb:
On Wed, January 10, 2007 13:07, Sven Schreiber wrote:
This sound very cool indeed. Could you post some examples of functions calling
python and carrying the results back into gretl? We may
1) get a taste of what's in store
2) check if there's anything tricky to set to get python working properly
3) start hacking on python (something I've wanted to do for a long time)
The more trivial the better, like for example take two matrices, use python to
multply them and shuffle the result back into gretl.
Sure. I have attached a script with a stripped-down "hello world"
version. It has the python stuff embedded in it. In principle you just
have to open and run it and it should work cross-platform, but so far
it's only tested on my own (Ubuntu) system.
You need to have Python and the NumPy extension (>=1.0) installed, see
new.scipy.org. (For Windows there are binary installers, for Linux
compilation of numpy is pretty easy.)
You might have to adjust the python calls (in the 19th and 13th lines
from bottom) if the command or version is different for you. (E.g. I
need to call python2.5 because that's where numpy is installed.)
It exports data from gretl, not matrices, because that's what I needed
and what I have ready. But it imports matrices from python.
As I already mentioned, after some testing and extensions I will upload
the py4gretl_vecm package to the function package server, after 1.6.1 is
out. Then people can test some more, if they find it useful. When
approx. will 1.6.1 be released?
cheers,
sven
6:19 a.m.
Allin Cottrell schrieb:
On Wed, 10 Jan 2007, Sven Schreiber wrote:
>
> I see. Then my question would be, how can one achieve persistence of
> generated matrices?
Actually, on second thoughts that shouldn't be difficult. Right now,
when you run a script, gretl goes through a checklist of stuff to clear
out, including undefining all existing user matrices. It would be easy
enough to skip the "clear out matrices" step. Is that generally desirable?
Well, just skipping matrices doesn't seem like a clean solution. To be
honest, I don't understand why anything has to be cleared out at all,
except maybe to avoid memory leaks. But in principle I had expected
scripts to work in a "cumulative" fashion, meaning that I can run
several scripts in a row and then have _all_ results available.
What about the following solution (sketch):
- When a script is run, append the existing objects (results from
previous scripts or whatever) to the session file, and clear their
contents from RAM (but keep an accessible list of them in memory).
- when the user requests one of the "old" objects, reload it from the
session file
- alternatively (but more complicated I guess) have an upper memory
limit for objects, and dynamically move the oldest (stalest) objects out
of the working memory to the session file if that limit is hit.
-sven
3:19 p.m.
Sven Schreiber wrote:
As I already mentioned, after some testing and extensions I will
upload
the py4gretl_vecm package to the function package server, after 1.6.1 is
out. Then people can test some more, if they find it useful. When
approx. will 1.6.1 be released?
I had intended to do so by now but since people have been coming
up with various squashable bugs lately I've held off. I'm also
wondering if it's worth doing one more iteration of the .pot
file first, since some of the bugs were missing translation
markers.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
5:30 a.m.
Allin Cottrell schrieb:
I had intended to do so by now but since people have been coming
up with various squashable bugs lately I've held off. I'm also
wondering if it's worth doing one more iteration of the .pot
file first, since some of the bugs were missing translation
markers.
Sure, sounds good.
Since you're in "bug-fixing mode", here's a really trivial thing:
'funcerr', 'return', 'bool', 'for', 'null' are not
syntax color-coded
-sven
8:13 a.m.
New subject: bug calling Gnuplot
This is only to report that in the gretl Windows snapshot (downloaded
yesterday), running in Spanish, there is a problem with gnuplot graphs.
All the gnuplot graphs called from the GUI respond with the error:
"command gnuplot failed"
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
9:11 a.m.
New subject: bug calling Gnuplot
On Fri, 12 Jan 2007, Ignacio Díaz-Emparanza wrote:
This is only to report that in the gretl Windows snapshot
(downloaded
yesterday), running in Spanish, there is a problem with gnuplot graphs.
All the gnuplot graphs called from the GUI respond with the error:
"command gnuplot failed"
Oof. I'll take a look at that, thanks for the report.
Allin.
11:57 a.m.
New subject: bug calling Gnuplot
On Fri, 12 Jan 2007, Ignacio Díaz-Emparanza wrote:
This is only to report that in the gretl Windows snapshot
(downloaded
yesterday), running in Spanish, there is a problem with gnuplot graphs.
All the gnuplot graphs called from the GUI respond with the error:
"command gnuplot failed"
I can't reproduce this. I tried the latest gretl build on Windows
XP, running from a console window after setting LANG=es, and with
the preference set to use the locale decimal separator. Graphs
were OK.
Can you give any more details -- and check that under
Preferences/Programs, the gnuplot executable is set to the
wgnuplot.exe that's supplied with the gretl distribution?
Thanks.
Allin.
12:20 p.m.
New subject: bug calling Gnuplot
El Viernes, 12 de Enero de 2007 17:57, Allin Cottrell escribió:
On Fri, 12 Jan 2007, Ignacio Díaz-Emparanza wrote:
> This is only to report that in the gretl Windows snapshot (downloaded
> yesterday), running in Spanish, there is a problem with gnuplot graphs.
> All the gnuplot graphs called from the GUI respond with the error:
>
> "command gnuplot failed"
I can't reproduce this. I tried the latest gretl build on Windows
XP, running from a console window after setting LANG=es, and with
the preference set to use the locale decimal separator. Graphs
were OK.
Can you give any more details -- and check that under
Preferences/Programs, the gnuplot executable is set to the
wgnuplot.exe that's supplied with the gretl distribution?
Thanks.
Allin.
Well, please forget it. I just downloaded the current installer and the graphs
are ok.
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
2:58 p.m.
New subject: bug calling Gnuplot
Ignacio Díaz-Emparanza schrieb:
El Viernes, 12 de Enero de 2007 17:57, Allin Cottrell escribió:
> On Fri, 12 Jan 2007, Ignacio Díaz-Emparanza wrote:
>> This is only to report that in the gretl Windows snapshot (downloaded
>> yesterday), running in Spanish, there is a problem with gnuplot graphs.
>> All the gnuplot graphs called from the GUI respond with the error:
Well, please forget it. I just downloaded the current installer and the graphs
are ok.
I remember having this problem a while ago, too, and it seemed to have
something to do with write permissions. Did you install both times
exactly the same way, or maybe one as administrator and the other
somewhat differently?
-sven
3:11 p.m.
On Fri, 12 Jan 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> I had intended to do so by now but since people have been coming
> up with various squashable bugs lately I've held off. I'm also
> wondering if it's worth doing one more iteration of the .pot
> file first, since some of the bugs were missing translation
> markers.
Sure, sounds good.
OK, I've remade the .pot file in CVS.
Since you're in "bug-fixing mode", here's a really
trivial thing:
'funcerr', 'return', 'bool', 'for', 'null' are
not syntax color-coded
These are now handled.
Allin.
6479
days inactive
6481
days old
14 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Díaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber