Re: [Gretl-devel] some function suggestions/questions
Riccardo (Jack) Lucchetti schrieb:
I'd like to voice my opinion on a few things:
1) there are a few cases when a certain function may conceivably behave
in either of two ways: sort up/down, reverse rows/cols etcetera. In all
these cases, having a policy might be nice (although it could also be a
little bureaucratic, but still). Possible policies are:
a) two functions (sort()/dsort())
b) one function with optional boolean switch (sort(a)/sort(a,1))
c) one function with some userland tricks (sort(a)/-sort(-a))
My personal ordering (best to worst) is b-c-a, but I'm open to change my
mind. I'd like to make one exception, though: I like ok() and missing(),
I use them both and scrapping one of the two would imply me having to go
over quite a few scripts. Besides, something like ok(x, 1) yielding 1 if
the corresponding observation is missing strikes me as bizarre to say
the least.
Jack, this really sounds like your stated preference b-c-a and your
revealed preferences are not consistent. Apart from that, I agree w.r.t.
ok() and missing(). In general it seems the boolean switches are not so
popular after all...?
I was just thinking that since gretl in general has very good
documentation, option (c) might be a good choice when examples are
included in the function documentation (not only in the cheat sheet
chapter in the manual). BUT: the resulting code is of course harder to
read because you have to reverse-engineer all those tricks.
All in all, I guess that I like the way it's currently done with
ok()/missing() and sort()/dsort(). This would mean to have reverserows()
and reversecols() or some such instead of the current mreverse()
implementation.
2) pergm: ok, nice to have; we already had fft(), but I agree pergm is
handier if all you need is the periodogram (no lame Beatles jokes,
please). And 2 columns is better than 3. But IMO this is where we must
stop. You don't want all the ordinates? Fine, select the rows you want
from the output. You want Bartlett smoothing? Fine, get column 2 from
the output and pre-multiply it by the appropriate matrix. I'm not overly
enthusiastic of functions that do everything for you. The point of
having a function for something is IMO to take the hard part of the task
and carry it out silenly, efficiently and asking the user as few
questions as possible. The rest is for you to do.
This is really a crucial question I think: what's the aim of gretl's
scripting language? I remember that Allin once wrote that ideally
everything should in the GUI should also be doable via script commands.
To me this seems to be a good design principle, and I think I don't
agree that your competing principle is desirable. Also, it looks to me
that gretl's scripting language would require a big reform then (mostly
removing functionality).
Some more detailed comments/replies about the pergm() issue:
Just having fft() was a long way from the spectrum from a user's point
of view, sorry.
Bartlett smoothing: Are there even functions that return smoothing
windows so that you can construct "the appropriate matrix" easily?
Choosing the (number of) omegas: You said you want a function to be
efficient. How can it be efficient if sometimes it calculates a multiple
of the needed output?
A closing remark, slightly exaggerated, so no offense please: if you're
"not overly enthusiastic of functions that do everything for you", how
do you advocate gretl to the public? You should recommend using Fortran
directly with Lapack or something like that ;-)
cheers,
sven