[Gretl-devel] some function suggestions/questions

[Sven Schreiber]

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