some function suggestions/questions
by Sven Schreiber
Hi,
in light of the recent discussion concerning mreverse() --for example we
don't want too many different functions for doing similar things-- I
would like to raise the following issues:
1) sort() and dsort(); IMHO it would be good to unify them into one
function with an optional argument to specify descending sorting, like so:
sort(a) or sort(a,0) : sorts ascending
sort(a,1): sorts descending
2) strcmp(): would it be possible to handle this with a comparison
operator like mystr1 == mystr2 and scrap the function?
3) if not, at least unify strcmp() and strncmp(), again using an
optional argument:
strcmp(a,b,5) would work just like strncmp(a,b,5)
Actually, this looks very straightforward, or am I missing something?
I'm aware these are backward-incompatible changes, so of course this
needs to be carefully discussed and thought through. These are just some
things I stumbled upon recently, I guess there are similar issues that
could be found if done systematically.
And one last thing: I may have asked this before, but having a function
similar to the command 'pergm' would be useful I think.
thanks,
sven
16 years
Capital and small letters - Preferences Menu
by Henrique
Dear developers,
Today I realize that gretl preferences menu (Tools -> Preferences ->
General -> Programs) shows small letters only for the last three options
("path to..."). I think it could be better to use capital letters for all
options (to keep homogeneity), what do you think?
Best regards,
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
16 years
new function debugger
by Allin Cottrell
Now that Chris is back from holiday, I'll mention this: I've
merged his function debugger code.
It's very nice. If you want to debug your user-defined function
foo, you construct a script that calls it (well, this is one way
of doing it). Within that script you say
debug foo
Then you run the script using gretlcli. [Comment on the GUI
appears below.]
The "debug" command should come after foo is defined but before
it's called. Then when a call to foo is reached, you get an
interactive prompt at which you can:
- type "n" or "next" to execute the next gretl command in foo
- type another gretl command (most likely a "print" to see
what's happening with some variable)
- type "c" or "continue" to allow foo to continue unimpeded
It would be nice to enable this behaviour within the GUI console
but that's not trivial. The code in gui2/console.c would have to
be re-written quite substantially to allow it to work. I've made
one false start on this myself (since erased from CVS) and I need
to think about it more carefully before trying again.
Allin.
16 years
a few Rlib problems
by Riccardo (Jack) Lucchetti
I just tried the new Rlib thing on one of Lee Adkins'
(http://www.learneconometrics.com/gretl/ebook.pdf) examples; attached
you'll find a simple script and the dataset to replicate Lee's section
16.9.2 (coditional logit). A couple of things that need to be fixed
appeared when you use the new mechanism:
1) If you run the script through the GUI client, the output of the R
foreign block isn't included in the output window; the cli client is ok.
2) More worryingly, it seems that the R computations are done _twice_. If
you run the script with Rlib on, you'll see the output
Calculating MLEs and large sample var-cov matrix.
This may take a moment...
Inverting Hessian to get large sample var-cov matrix.
before the output is displayed _and_ after. This is not a simple output
redirection issue, the R function is actually called twice. On my machine,
the output to
time gretlcli -b LA-cola.inp
is
real 0m16.775s
user 0m16.697s
sys 0m0.052s
with Rlib off and
real 0m32.201s
user 0m32.074s
sys 0m0.036s
with Rlib on.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
16 years
mread broken in cvs?
by Klein, Christoph
Hi,
I just came back from a two weeks vacation and had to find out that all my scripts no longer work. It seems like "mread" no longer parses string variables. The following test script fails on current cvs:
<script>
nulldata 10
series y=t
matrix y2=y
mwrite(y2,"test.mat")
matrix y3=mread("test.mat")
string fileName="test.mat"
matrix y4=mread(fileName)
</script>
but did work on old gretl versions. The error is
? matrix y4=mread(fileName)
fileName: No such file or directory
Error executing script: halting
> matrix y4=mread(fileName)
It seems like mread tries to use filename directly as a string, although it is not quoted.
Christoph
16 years
new command line options
by Allin Cottrell
In testing various gretl features using gretlcli I've sometimes
wished for a way of setting a value within a script automatically
via the command line (i.e. without having to edit the script).
One can do that via environment variables, given gretl's getenv()
function, but this can be a bit clunky.
There's now a new command-line option "--switch=<value>".
An integer value registered in this way is accessible via
the internal variable $switch.
In addition, since we have the GUI language selector now, the
option -q or --basque seems redundant; now -q is paired with
--quiet and gives less verbose program information on start-up.
Illustration:
waverley:~$ cat switch.inp
scalar uselib = $switch
waverley:~$ gretlcli -b switch.inp -q
gretl version 1.8.2cvs
Current session: 2009-07-17 12:13
? run switch.inp
/home/cottrell/switch.inp
? scalar uselib = $switch
Generated scalar uselib = 0
Done
waverley:~$ gretlcli -b switch.inp -q --switch=3
gretl version 1.8.2cvs
Current session: 2009-07-17 12:13
? run switch.inp
/home/cottrell/switch.inp
? scalar uselib = $switch
Generated scalar uselib = 3
Done
Allin
16 years
ctrl-x in scripts
by Sven Schreiber
Hi,
in the current Windows snapshot I just noticed that hitting ctrl-x in a
script window closes the script -- what was intended was to cut a
selection for pasting, probably one of the most widespread keyboard
shortcuts around.
cheers,
sven
16 years
Rlib daily update!
by Allin Cottrell
I'm not trying to pre-empt further discussion of gretl/R
interaction, but I'd like to get the Rlib material into a state
where I'm reasonably comfortable with it, on a provisional and
still hidden basis. So I've been doing a bit more.
First, re. Talha's "freak of nature" comment
http://lists.wfu.edu/pipermail/gretl-devel/2009-July/001967.html ,
I admit I'm not very comfortable with hard-linking a build of
gretl to libR (so that if one decided to remove R for some reason,
gretl would stop working). That's a bit too much like Siamese
twins. Since I've now figured out how to access libR via dlopen
(or equivalent), I think that's the way to do it: open libR on
demand.
Anyway, here's the state of play. First a brief reminder: for
some time we have supported R via the GUI menu item for launching
R and the script "foreign" command. These are enabled in all
builds of gretl (there's no configure option for disabling these
things), but whether they actually work or not obviously depends
on whether an R installation is accessible.
Now for Rlib (which I'll use as a generic label for libR.so on
*nix and R.dll on Windows). Since we're opening the library on
demand we don't need to have it available at compile time, though
we do need the R headers. Gretl's configure script now has an
option, --with-libR/--without-libR. The default is "auto": we
test for the R headers using pkg-config and build in Rlib support
if they're found. But if you don't want this support (even if you
have R installed), use --without-libR.
Chris's patch added a language to the "foreign" command, namely
"RLib". I've now removed that: the language is just plain "R",
and whether the "foreign" mechanism uses the R executable or Rlib
depends on thwo things. First, obviously, on whether Rlib support
is compiled into gretl (it is, in the current Windows snapshot).
Second, there's another "set" variable, "R_lib". Right now, if
this is unset, we use the R excutable, if it's set "on" we use
Rlib.
If you try to "set R_lib on" and there's no Rlib support in gretl,
you get a warning:
Warning: setting ignored: 'R_lib' not supported.
At some point it may be worth reversing the default: in other
words, using Rlib automatically for "foreign language=R" if it's
supported by the build, unless the user does "set Rlib off".
Or we could trash the option. For the moment I want it there for
testing purposes.
Then there's the last point: look-up of R functions. For the
present I've left this as I last described it. You have to "set
R_functions" on to get this. This depends on compiled-in Rlib
support, but it does not depend on setting "R_lib" on. And you
need to prepend "R_" to the function names to have them found.
If anyone's still reading: I've also implemented support for
"foreign language=ox" (and editing/running of Ox programs via the
GUI). But this is not enabled by default in the gretl build:
you have to select --with-ox when configuring gretl to get it.
Allin.
16 years, 1 month
Re: [Gretl-users] reversing / flipping a matrix
by Riccardo (Jack) Lucchetti
On Fri, 10 Jul 2009, Sven Schreiber wrote:
> Am 10.07.2009 12:49, Riccardo (Jack) Lucchetti schrieb:
>> On Fri, 10 Jul 2009, Sven Schreiber wrote:
>>
>>
>>>> Oh, sorry, I should have said: the rev() function reverses the order of
>>>> the _rows_ of the matrix (from the example above, it could have been the
>>>> columns).
>>>
>>> Would it be worthwhile to generalize this to columns as well? Maybe
>>> using an optional second argument or so. I'm not sure about it, and I'm
>>> aware of rev(A')', just asking as long as it's still in "design stage".
>>
>> If you ask me, I'd rather have one function with the user in charge of
>> transposing things twice, rather than two and save the user the
>> inconvenience. IMHO, all other things being equal, the fewer functions
>> the better. But of course I'm open to change my mind on this.
>>
>
> I agree that two separate functions would not be good. What I meant was
> something like:
>
> rev(A,1) -- reverses row-wise
> rev(A,2) -- reverses col-wise (or maybe rev(A,'c'))
> rev(A) -- defaults to /alias for rev(A,1)
>
> But I don't have a strong opinion, given gretl's short transposition syntax.
(I'm sending this to gretl-dev too, since it's a bit technical)
This may make sense, with a slight modification: instead of 1/2, I'd
rather use 0/1, so it becomes easy to decide on a logical condition (eg.
rev(A, foo>bar)). Besides, reversing columns would probably be more
CPU-efficient, since we could use memcpy() for that, as in
----- C code -----------------------------------------------------
gretl_matrix *gretl_matrix_reverse_cols (const gretl_matrix *m)
{
int i, r, c;
gretl_matrix *ret;
if (m == NULL) {
return NULL;
}
if (gretl_is_null_matrix(m)) {
return gretl_null_matrix_new();
}
r = m->rows;
c = m->cols;
ret = gretl_matrix_alloc(r, c);
if (ret == NULL) {
return NULL;
}
double *x = m->val;
double *y = ret->val;
int size = r * sizeof *x;
y += r*(c-1);
for (i=0; i<c; i++) {
memcpy(y, x, size);
x += r;
y -= r;
}
return ret;
}
----- end C code -------------------------------------------------
Allin, what do you think?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
16 years, 1 month
note on Rlib
by Allin Cottrell
I've committed a few more changes to the gretl Rlib code. You can
now (if you're set up right) call native R functions directly, as
in
<gretlscript>
scalar c = choose(10,4)
</gretlscript>
That is, "choose" is recognized as an R function and (thanks to
Christoph) is called via libR.
At present this works only if the function arguments and return
value are either scalars or matrices. That could be extended
somewhat if we find this valuable.
Allin.
16 years, 1 month
