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