On Sat, Jan 13, 2007 at 09:54:02PM -0500, Allin Cottrell wrote: I'm fine with that; perhaps it could be useful to document this in /gretl/doc/notes.tex Cri -- GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc Free software, free society - http://www.fsfeurope.org

Is there any relevant reason to restrict "append" for not using in a loop? (I need it in a "foreach ..." loop). and, do we have a command to pause the execution of a gretl script? (as "sleep" or "wait" in other languages) -- Ignacio Díaz-Emparanza Dpto. de Economía Aplicada III (Econometría y Estadística) UPV-EHU

El Miércoles, 17 de Enero de 2007 17:39, Allin Cottrell escribió: Now I need the first one, but probably it would be good to have the second one as well. You may see my problem in the script below. The function tries to linearize automatically a list os series (interpolate missing observations and correct outliers) trough TRAMO. (It is not finished yet as it has some problems with missing data and unadjusted series). Gretl processes the line "append" some miliseconds before the previous Windows command has finished, so I need a way to slow down the execution of the "append" command. Uncommenting the three lines of the (unnneded) ARIMA loop pauses gretl a bit and works for me. [to run it, you will have to correct the Windows paths] ---- open data9-9 set echo off set messages off scalar nobser = nobs(nocars) scalar anyo=1959 #startp: start period scalar startp=1 #period: periodicity scalar period=4 #list xlist = nocars pop Y price primert list xlist = price function tramolin clear function tramolin(list xlist, scalar nobser, scalar anyo, scalar startp, scalar period) if nelem(xlist) = 0 funcerr "The list of variables cannot be empty" end if loop foreach i xlist --quiet outfile --write "C:\Archivos de programa\gretl\tramo\$i" printf "%s\n", "$i" printf "%.8g %.8g %.8g %.8g\n", nobser, anyo, startp, period loop j=1..nobser --quiet scalar jj=j scalar dato = $i[jj] printf "%.8g\n", dato endloop printf "$INPUT RSA=3 $\n" printf "\n" outfile --close ! cmd /c "cd tramo && tramo -i $i -k $i.ser " outfile --write "C:\Archivos de programa\gretl\tramo\graph\series\$i-lin.txt" printf "%s\n", "$i_lin" outfile --close ! cmd /c "cd tramo\graph\series && more +6 xlin.t >> $i-lin.txt" # loop i=1..2 # arima 0 0 2 ; $i # endloop endloop end function tramolin(xlist, nobser, anyo, startp, period) append "C:\Archivos de programa\gretl\tramo\graph\series\price-lin.txt" -- Ignacio Díaz-Emparanza Dpto. de Economía Aplicada III (Econometría y Estadística) UPV-EHU

Allin Cottrell schrieb: I worried about that, too, but I have never had any problems so far. And returning from the external call sometimes takes quite a while, so I thought that synchronicity had been taken care of. So I'm actually quite surprised to hear the opposite. Or is it something platform-specific? (Only tested on linux so far.) -sven

Allin Cottrell schrieb: Waiting! In principle I can also see the use for non-waiting (like start a pdf viewer, and don't wait until it is closed again), but until somebody requests it I wouldn't bother (if I were you). But getting the waiting to work on Windows would be very nice, otherwise I lose the cross-platformness of my py4gretl... Unfortunately I don't know anything about that stuff. -sven

On Thu, 18 Jan 2007, Ignacio Díaz-Emparanza wrote: You now have (in CVS and the Windows snapshot) these things: * You can do "set shell_sync on" to make the shell command work synchronously. This is tested on Linux. Windows requires different code to do that and I've added what I think is suitable code but it's not yet tested. * You can use the "append" command inside a loop. However, these things by themselves will not make the script do all you want it to. The structure of your script is function (list, etc) loop across list members generate transformation using tramo add to dataset with "append" end loop end function # main open data set form list call function on list OK, here's the problem: as you go through the loop inside the function the various linearized series will be added OK, but then when the function exits they will all be destroyed, since they are variables local to the function and are not returned. There are a few possible work-arounds for this, 2 of which I'll mention for reference, and then a "proper fix" which is in place but not yet well tested. workaround 1: have the function process just one series, and return the new series. The caller assigns the new series to an "outside" variable. workaround 2: the function processes several series, packs them into a matrix, and returns the matrix. OK, except that this puts the burden of dealing with a matrix onto the caller. "Proper fix": a function can return a list. As the new series are generated they're added to a list, which is then returned. Up till now functions could not return lists, but it turns out this is not very difficult to implement, so I've done it. When a variable inside a function is referenced in a list that is returned and assigned, that variable is _not_ destroyed on exit from the function. Here's a simple example of how things should be structured. function make_cubes (list xlist) list retlist = null loop foreach i xlist --quiet series $i3 = $i^3 list retlist = retlist $i3 end loop return list retlist end function open data4-1 list xlist = 3 4 list cubelist = make_cubes(xlist) print xlist cubelist --byobs Allin.

In case it's of interest I'm attaching a revised version of Ignacio's script that interfaces with tramo. This version uses some experimental features (they're in CVS and the snapshot), designed to make this sort of thing easier -- in particular the ability to define string variables (which can then be accessed using a prefix of "@"). It checks for missing values when writing the tramo data file, and ensures that the variable names for the transformed variables will not overflow the 15-character limit. The script is tested on Linux (only). Allin.