2:19 p.m.
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
9:55 p.m.
On Mon, 20 Jul 2009, Sven Schreiber wrote:
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
Maybe so. My only misgiving is that I prefer not to use magic
numbers (or magic booleans) as function arguments -- though we
already do this to some extent.
2) strcmp(): would it be possible to handle this with a comparison
operator like mystr1 == mystr2 and scrap the function?
Ah, perhaps I had forgotten that we already implement s1 == s1 for
strings, when I added strcmp. So maybe strcmp is redundant.
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?
Well, for "str" functions that have the same names as C functions
I think it's desirable that they have the same syntax as the C
versions.
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.
I agree that's worth looking for useful pruning opportunities.
And one last thing: I may have asked this before, but having a
function
similar to the command 'pergm' would be useful I think.
OK, it's added, though not documented yet: pergm(x) returns a
2-column matrix with omega in column 1 and the spectral density
in column 2.
Allin.
4:40 p.m.
Allin Cottrell schrieb:
On Mon, 20 Jul 2009, Sven Schreiber wrote:
> 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
Maybe so. My only misgiving is that I prefer not to use magic
numbers (or magic booleans) as function arguments -- though we
already do this to some extent.
I can understand both points of view, but what's the priority then? I
tend to think that if sort() and dsort() are better than magic booleans,
then the recently introduced mreverse(a) and mreverse(a,1) should also
be replaced by rowreverse() and colreverse(). Don't know what other
functions have similar issues. Having a mixture of "philosophies" with
respect to function signatures is unnecessarily confusing IMHO.
> 2) strcmp(): would it be possible to handle this with a
comparison
> operator like mystr1 == mystr2 and scrap the function?
Ah, perhaps I had forgotten that we already implement s1 == s1 for
strings, when I added strcmp. So maybe strcmp is redundant.
> 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?
Well, for "str" functions that have the same names as C functions
I think it's desirable that they have the same syntax as the C
versions.
Ok, as you know I don't know much about C. When was strcmp() added, is
it worth discussing further?
cheers,
sven
11:16 p.m.
On Wed, 29 Jul 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Mon, 20 Jul 2009, Sven Schreiber wrote:
>
>> 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
>
> Maybe so. My only misgiving is that I prefer not to use magic
> numbers (or magic booleans) as function arguments -- though we
> already do this to some extent.
I can understand both points of view, but what's the priority then? I
tend to think that if sort() and dsort() are better than magic booleans,
then the recently introduced mreverse(a) and mreverse(a,1) should also
be replaced by rowreverse() and colreverse(). Don't know what other
functions have similar issues. Having a mixture of "philosophies" with
respect to function signatures is unnecessarily confusing IMHO.
You're right on that. I'll have to take a look at what we have in
place and take stock.
>> 2) strcmp(): would it be possible to handle this with a
comparison
>> operator like mystr1 == mystr2 and scrap the function?
>
> Ah, perhaps I had forgotten that we already implement s1 == s1 for
> strings, when I added strcmp. So maybe strcmp is redundant.
>
>> 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?
>
> Well, for "str" functions that have the same names as C functions
> I think it's desirable that they have the same syntax as the C
> versions.
Ok, as you know I don't know much about C. When was strcmp() added, is
it worth discussing further?
Frankly, I would be very surprised if anyone has used gretl's
strcmp(). In CVS I have removed it in favour of strncmp (with the
possibility of the trailing 'n' argument being omitted to give the
behaviour of C's strcmp). If anyone is upset, let us hear from
them!
Allin.
5:18 p.m.
Allin Cottrell schrieb:
On Wed, 29 Jul 2009, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>> On Mon, 20 Jul 2009, Sven Schreiber wrote:
>>
>>> 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
>> Maybe so. My only misgiving is that I prefer not to use magic
>> numbers (or magic booleans) as function arguments -- though we
>> already do this to some extent.
> I can understand both points of view, but what's the priority then? I
> tend to think that if sort() and dsort() are better than magic booleans,
> then the recently introduced mreverse(a) and mreverse(a,1) should also
> be replaced by rowreverse() and colreverse(). Don't know what other
> functions have similar issues. Having a mixture of "philosophies" with
> respect to function signatures is unnecessarily confusing IMHO.
You're right on that. I'll have to take a look at what we have in
place and take stock.
FWIW, if it saves you the effort I could do that (based on the available
documentation).
cheers,
sven
2:41 a.m.
On Thu, 30 Jul 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Wed, 29 Jul 2009, Sven Schreiber wrote:
>
>> Allin Cottrell schrieb:
>>> On Mon, 20 Jul 2009, Sven Schreiber wrote:
>>>
>>>> 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
>>> Maybe so. My only misgiving is that I prefer not to use magic
>>> numbers (or magic booleans) as function arguments -- though we
>>> already do this to some extent.
>> I can understand both points of view, but what's the priority then? I
>> tend to think that if sort() and dsort() are better than magic booleans,
>> then the recently introduced mreverse(a) and mreverse(a,1) should also
>> be replaced by rowreverse() and colreverse(). Don't know what other
>> functions have similar issues. Having a mixture of "philosophies"
with
>> respect to function signatures is unnecessarily confusing IMHO.
>
> You're right on that. I'll have to take a look at what we have in
> place and take stock.
FWIW, if it saves you the effort I could do that (based on the available
documentation).
Thanks, Sven, but it seems there's just one case: mreverse. On
second thoughts I wouldn't mind adding sort() to the list,
hence swallowing dsort().
While on the topic of cleaning up functions, I came across a
couple of candidates for scrapping: makemask() and nobs(). I'm
not sure I understand the doc for makemask, though I suppose I
must have added it once upon a time. And as for nobs, it seems
this could easily be replaced via nobs(y) = sum(ok(y)), for series
argument y (i.e. the number of non-missing observations of y in
the current sample).
And while we're at it, do we need both ok() and missing()?
Strictly speaking, of course not, yet working around missing
observations is a fairly common task and it probably doesn't hurt
to have functions that go both ways, returning 1 for not-missing
and 1 for missing respectively.
Allin.
12:26 a.m.
On Mon, 20 Jul 2009, Sven Schreiber wrote:
And one last thing: I may have asked this before, but having a
function similar to the command 'pergm' would be useful I think.
Revision to what I said before: pergm() takes either one or two
arguments, the first being a series (or conformable matrix) and
the optional second one being an integer bandwidth for use
with the Bartlett kernel. If the second arg is omitted you get
the sample periodogram.
The returned matrix has 3 columns: omega in 1, the "periods" as
printed by the pergm command in col2, and the density in col 3.
Allin.
1:19 p.m.
On Mon, 20 Jul 2009, Allin Cottrell wrote:
Revision to what I said before: pergm() takes either one or two
arguments, the first being a series (or conformable matrix) and
the optional second one being an integer bandwidth for use
with the Bartlett kernel. If the second arg is omitted you get
the sample periodogram.
The returned matrix has 3 columns: omega in 1, the "periods" as
printed by the pergm command in col2, and the density in col 3.
On third thoughts, we probably should not include the "periods"
column in the pergm function output -- omega plus density is
cleaner. Anyone?
Allin.
9:03 a.m.
Allin Cottrell schrieb:
On Mon, 20 Jul 2009, Allin Cottrell wrote:
> Revision to what I said before: pergm() takes either one or two
> arguments, the first being a series (or conformable matrix) and
> the optional second one being an integer bandwidth for use
> with the Bartlett kernel. If the second arg is omitted you get
> the sample periodogram.
>
> The returned matrix has 3 columns: omega in 1, the "periods" as
> printed by the pergm command in col2, and the density in col 3.
On third thoughts, we probably should not include the "periods"
column in the pergm function output -- omega plus density is
cleaner. Anyone?
sorry about the silence, I'm currently mostly offline. I'll return to
the pergm question.
cheers,
sven
4:51 p.m.
Allin Cottrell schrieb:
On Mon, 20 Jul 2009, Allin Cottrell wrote:
> Revision to what I said before: pergm() takes either one or two
> arguments, the first being a series (or conformable matrix) and
> the optional second one being an integer bandwidth for use
> with the Bartlett kernel. If the second arg is omitted you get
> the sample periodogram.
>
> The returned matrix has 3 columns: omega in 1, the "periods" as
> printed by the pergm command in col2, and the density in col 3.
On third thoughts, we probably should not include the "periods"
column in the pergm function output -- omega plus density is
cleaner. Anyone?
I agree, having only one set of the x- and y-values of the corresponding
x/y-graph is more transparent.
On a slightly different point, I'm just wondering whether the number of
distinct omega values to return should be a function argument, too? What
I mean is something like:
pergm(x,10,100) -- would mean that the returned matrix has 100 rows
pergm(x,10) -- gives you the current default value
thanks,
sven
11:30 p.m.
On Wed, 29 Jul 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Mon, 20 Jul 2009, Allin Cottrell wrote:
>
>> Revision to what I said before: pergm() takes either one or two
>> arguments, the first being a series (or conformable matrix) and
>> the optional second one being an integer bandwidth for use
>> with the Bartlett kernel. If the second arg is omitted you get
>> the sample periodogram.
>>
>> The returned matrix has 3 columns: omega in 1, the "periods" as
>> printed by the pergm command in col2, and the density in col 3.
>
> On third thoughts, we probably should not include the "periods"
> column in the pergm function output -- omega plus density is
> cleaner. Anyone?
I agree, having only one set of the x- and y-values of the corresponding
x/y-graph is more transparent.
Thanks. In the absence of disagreement I went ahead and
implemented this in CVS.
On a slightly different point, I'm just wondering whether the
number of distinct omega values to return should be a function
argument, too? What I mean is something like:
pergm(x,10,100) -- would mean that the returned matrix has 100 rows
pergm(x,10) -- gives you the current default value
Sven, I think you're implying that the current default is 10 rows.
In fact it's T/2, where T is the length of the current sample
after adjusting for any missing values. I think this is
reasonable, and if we're going to go further in terms of
user-level customization that might fairly be confined to the
fft() function.
Allin.
5:31 p.m.
Allin Cottrell schrieb:
On Wed, 29 Jul 2009, Sven Schreiber wrote:
> On a slightly different point, I'm just wondering whether the
> number of distinct omega values to return should be a function
> argument, too? What I mean is something like:
>
> pergm(x,10,100) -- would mean that the returned matrix has 100 rows
> pergm(x,10) -- gives you the current default value
Sven, I think you're implying that the current default is 10 rows.
(No, the '10' was for the Bartlett truncation lag. I knew the number of
rows was sample-dependent, but not the exact formula.)
In fact it's T/2, where T is the length of the current sample
after adjusting for any missing values. I think this is
reasonable, and if we're going to go further in terms of
user-level customization that might fairly be confined to the
fft() function.
First, I think it's good to have pergm() as a function mimicking the GUI
functionality, and I have no problem leaving it as it is now.
If it's not just a one- or two-liner to add the optional argument of how
many rows to return it's indeed probably not worth pursuing this thing.
However, in general I'm not sure T/2 is always reasonable. Take
high-frequency financial data for example, where you can have a T of
several thousands easily. Do you want to calculate several thousand
densities then? I would even guess that having more than 314 distinct
frequencies in the [0;\pi] interval (0.01 apart from each other) is
never needed.
thanks,
sven
10:58 a.m.
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.
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.
3) makemask is nice to have IMO. Sometimes you need to convert a series to
a matrix and then back to a series. If there are NAs in the original
series, the matrix will have less rows than $nobs and "makemask"
helps to map it back to a series.
4) string functions: I don't have strong opinions on strcmp vs "==".
strncmp is also fine by me. But what I'd really like to see is the
equivalent of C scanf().
Thus spake the lurker!
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5:16 p.m.
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
10:45 p.m.
Timestamp: I had replied to Jack's posting (to which Sven is
replying) before I read this one of Sven's. Now I'm trying to
catch up.
On Fri, 31 Jul 2009, Sven Schreiber wrote:
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...
Hmm, not sure that's fair. Jack grants one exception to his
preference of b over a, namely the ok/missing thing on which we
all seem to be agreed.
However, we do have a fair number of "paired" functions,
particularly relating to matrices: imaxc/imaxr, iminc/iminr,
maxc/maxr, meanc/meanr, minc/minr, selifc/selifr, sumc/sumr. I
doubt that Jack intends that we scrap these: having to transpose
every time would be a bother to the user, and inefficient to boot.
Does this argue for rreverse/creverse in place of mreverse?
Perhaps, but one might argue that a less-used function can stand
to have a little overhead (i.e. the existing boolean switch) to
avoid cluttering the namespace. I'd say it's a marginal case that
doesn't matter much either way.
Plus, how would one rename, say, minc/minr, in a comprehensible
fashion if one were combining the two functions? "mmin" doesn't
speak to me like "minr" or "minc".
"Consistency" can be assessed at various levels of sophistication,
and something that appears inconsistent at level k may appear
consistent at level k + 1.
I'll have to think a bit more about pergm before responding on
that.
Allin.
12:39 a.m.
OK, here's my considered round-up. I'm thinking that a 1.8.3
release would be good soon, given the number of fixes we've racked
up to date, so that informs my perspective.
* sort-plus-dsort versus a single sort function with an optional
boolean argument to reverse the sort:
Ho-hum. On the one hand everyone knows that sorting can go two
ways, so the boolean option is reasonable. On the other hand, we
have dsort as a separate function historically and does saving one
place in the function namespace merit backward incompatibility?
* mreverse-with-boolean versus rreverse plus creverse:
Again, ho-hum. IMO the specialized nature of this function (we
managed without it for quite some time) means that we're OK with
the boolean switch.
Next, I take it that we don't really want to replace all the
existing m*/r* and *m/*r matrix-function pairs with single
functions having an extra row/column boolean argument. (If we do,
it won't be in gretl 1.8.3!)
Alright, that leaves the pergm() function, which has been added in
CVS since gretl 1.8.2 (so that I can't appeal to history). I think
I hear Jack wanting less options/arguments (scrap the optional
Bartlett window size), and Sven wanting more arguments (add a
parameter to govern the number of rows in the output matrix).
Here I'm tempted to propose the typical wretched British
compromise of leaving things as they are (Bartlett option present,
no other options available). Rationale:
* The Bartlett option may be worth keeping since it's not totally
trivial for the user to reconstruct (as Sven has said).
* But it is fairly trivial to sample the rows of the returned
matrix, if you happen to have a ginormous time series and want a
reduced spectrum matrix. The alternative involves some tedious
error-checking on whatever the user has thrown at us for the
number of rows to be returned. Coder to user: if you're smart
enough to be in the frequency domain, you ought to be smart
enough to figure it out yourself!
Allin.
8:51 a.m.
On Fri, 31 Jul 2009, Allin Cottrell wrote:
OK, here's my considered round-up. I'm thinking that a
1.8.3
release would be good soon, given the number of fixes we've racked
up to date, so that informs my perspective.
* sort-plus-dsort versus a single sort function with an optional
boolean argument to reverse the sort:
Ho-hum. On the one hand everyone knows that sorting can go two
ways, so the boolean option is reasonable. On the other hand, we
have dsort as a separate function historically and does saving one
place in the function namespace merit backward incompatibility?
Of course not. Let's keep dsort.
* mreverse-with-boolean versus rreverse plus creverse:
Again, ho-hum. IMO the specialized nature of this function (we
managed without it for quite some time) means that we're OK with
the boolean switch.
Next, I take it that we don't really want to replace all the
existing m*/r* and *m/*r matrix-function pairs with single
functions having an extra row/column boolean argument. (If we do,
it won't be in gretl 1.8.3!)
I agree.
Alright, that leaves the pergm() function, which has been added in
CVS since gretl 1.8.2 (so that I can't appeal to history). I think
I hear Jack wanting less options/arguments (scrap the optional
Bartlett window size), and Sven wanting more arguments (add a
parameter to govern the number of rows in the output matrix).
Here I'm tempted to propose the typical wretched British
compromise of leaving things as they are (Bartlett option present,
no other options available). Rationale:
* The Bartlett option may be worth keeping since it's not totally
trivial for the user to reconstruct (as Sven has said).
* But it is fairly trivial to sample the rows of the returned
matrix, if you happen to have a ginormous time series and want a
reduced spectrum matrix. The alternative involves some tedious
error-checking on whatever the user has thrown at us for the
number of rows to be returned. Coder to user: if you're smart
enough to be in the frequency domain, you ought to be smart
enough to figure it out yourself!
Fine by me!
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
8:33 a.m.
Allin Cottrell schrieb:
* sort-plus-dsort versus a single sort function with an optional
boolean argument to reverse the sort:
Ho-hum. On the one hand everyone knows that sorting can go two
ways, so the boolean option is reasonable. On the other hand, we
have dsort as a separate function historically and does saving one
place in the function namespace merit backward incompatibility?
no, as Jack said dsort() is fine of course, especially given that (as I
had noted) the boolean switching thing doesn't seem as popular as it
first appeared
* mreverse-with-boolean versus rreverse plus creverse:
Again, ho-hum. IMO the specialized nature of this function (we
managed without it for quite some time) means that we're OK with
the boolean switch.
Also fine with me, especially because it's an optional argument.
However, one thing may be important to repeat (one last time, I
promise): From what I remember from the discussion, this will be the
first function in gretl with a boolean switch, right? Contrary to what
my impression was when Jack first suggested to use that boolean switch
for mreverse(). So, is this function really that special to warrant a
first-time exception to the rules?
(There's also a Python Zen quote about how special cases are never
special enough to break the rules, but then it also says that sometimes
practicality beats purity, so we're back to square one I guess. The way
of the Zen!)
My gut feeling is 'no', so either force the workaround mreverse(a')' on
the user (mentioning it in the docs), or have another function pair for
col/row reversal. But as I said, anything would be ok and I will shut up
about it now.
Alright, that leaves the pergm() function, which has been added in
CVS since gretl 1.8.2 (so that I can't appeal to history). I think
I hear Jack wanting less options/arguments (scrap the optional
Bartlett window size), and Sven wanting more arguments (add a
parameter to govern the number of rows in the output matrix).
* But it is fairly trivial to sample the rows of the returned
matrix, if you happen to have a ginormous time series and want a
reduced spectrum matrix. The alternative involves some tedious
error-checking on whatever the user has thrown at us for the
number of rows to be returned. Coder to user: if you're smart
enough to be in the frequency domain, you ought to be smart
enough to figure it out yourself!
Ok, fair enough. But then I have a related question: You said there will
be T/2 calculated values of the spectrum. But which ones exactly, what's
the formula to determine the spacing? Linear, geometrical etc. etc. Is
it somewhere in the docs?
thanks,
sven
4:18 p.m.
On Tue, 4 Aug 2009, Sven Schreiber wrote:
Allin Cottrell schrieb:
>
> * mreverse-with-boolean versus rreverse plus creverse:
>
> Again, ho-hum. IMO the specialized nature of this function (we
> managed without it for quite some time) means that we're OK with
> the boolean switch.
Also fine with me, especially because it's an optional argument.
However, one thing may be important to repeat (one last time, I
promise): From what I remember from the discussion, this will be
the first function in gretl with a boolean switch, right?
Yes, I think that's right, and I see your point; I'm not very
happy about it. It would definitely be more consistent either to
offer rreverse and creverse, or to require mreverse(a')' for
turning a matrix upside down.
> Alright, that leaves the pergm() function, which has been added
in
> CVS since gretl 1.8.2 (so that I can't appeal to history). I think
> I hear Jack wanting less options/arguments (scrap the optional
> Bartlett window size), and Sven wanting more arguments (add a
> parameter to govern the number of rows in the output matrix).
> * But it is fairly trivial to sample the rows of the returned
> matrix, if you happen to have a ginormous time series and want a
> reduced spectrum matrix. The alternative involves some tedious
> error-checking on whatever the user has thrown at us for the
> number of rows to be returned. Coder to user: if you're smart
> enough to be in the frequency domain, you ought to be smart
> enough to figure it out yourself!
>
Ok, fair enough. But then I have a related question: You said there will
be T/2 calculated values of the spectrum. But which ones exactly, what's
the formula to determine the spacing? Linear, geometrical etc. etc. Is
it somewhere in the docs?
http://gretl.cvs.sourceforge.net/viewvc/*checkout*/gretl/gretl/lib/src/de...
and look for "real_periodogram".
Allin.
9:17 a.m.
On Fri, 31 Jul 2009, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
> 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...?
"Do I contradict myself?
Very well, then, I contradict myself;
(I am large --- I contain multitudes.)"
W. Whitman
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.
Oh yeah?
<script>
nulldata 20
x = normal()
a = pergm(x)
hN = $nobs/2
b = pi/hN*(seq(1,hN)') ~ sumr(fft({x}).^2)[2:hN+1]/($nobs*2*pi)
print a
print b
</script>
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 ;-)
The trouble with functions that try to do everything is that they're hell
to write, hell to maintain and most importantly, hell to use, since you
invariably forget what goes where. One of the reasons why I'm not overly
fond of R is that, for precisely this reason, either you use R all the
time and you have exceptional memory or you end up spending 10% of your
time coding and the remaining 90% browsing the documentation or googling
for stuff. But maybe it's just me.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
8:10 a.m.
Riccardo (Jack) Lucchetti schrieb:
On Fri, 31 Jul 2009, Sven Schreiber wrote:
> 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.
Oh yeah?
<script>
nulldata 20
x = normal()
a = pergm(x)
hN = $nobs/2
b = pi/hN*(seq(1,hN)') ~ sumr(fft({x}).^2)[2:hN+1]/($nobs*2*pi)
print a
print b
</script>
That just proves my point ;-) -- Seriously, if I'm not mistaken this is
the raw periodogram not the smoothed spectrum right? The Bartlett window
was an important ingredient to my argument.
> 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 ;-)
The trouble with functions that try to do everything is that they're
hell to write, hell to maintain and most importantly, hell to use, since
you invariably forget what goes where. One of the reasons why I'm not
overly fond of R is that, for precisely this reason, either you use R
all the time and you have exceptional memory or you end up spending 10%
of your time coding and the remaining 90% browsing the documentation or
googling for stuff. But maybe it's just me.
No, I agree. I don't find R intuitive, either, partly for the same
reason. That's also why I find it slightly worrying that more and more
instructors appear to be using R in introductory classes. (Because it's
free and widespread among a certain professional community.) I fear that
it will actually demotivate students and drive them away from econometrics.
cheers,
sven
8:03 p.m.
On Fri, 31 Jul 2009, Riccardo (Jack) Lucchetti wrote:
I'd like to voice my opinion on a few things:
Good ;-)
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'm inclined to agree. Shall we add the option to sort() and
mark dsort as deprecated, then before too long scrap dsort?
I'd like to make one exception, though: I like ok() and
missing() ...
Yup, me too.
2) pergm...
I don;t have strong feelings on this. What you say makes sense to
me -- and I guess it correspons to the status quo in CVS?
3) makemask is nice to have IMO. Sometimes you need to convert a
series to a matrix and then back to a series. If there are NAs
in the original series, the matrix will have less rows than
$nobs and "makemask" helps to map it back to a series.
Ah, OK.
4) string functions: I don't have strong opinions on strcmp vs "==".
strncmp is also fine by me. But what I'd really like to see is the
equivalent of C scanf().
We have the sscanf command; I've now added a functionized version,
and also generalized it slightly by allowing the format to be a
string variable (before it had to be a string literal). We could
add plain scanf if that would be useful.
Allin.
5648
days inactive
5663
days old
21 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber