Re: [Gretl-devel] some function suggestions/questions

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.