On Fri, 10 Nov 2017, Sven Schreiber wrote: I think of the "hausman" command as an exploratory thing. If you want to estimate a panel-data model but have no a priori idea of which estimator is likely to be suitable you _might_ find it helpful to try pooled OLS plus "hausman". (Or perhaps more likely, do the GUI equivalent, via /Tests/Panel diagnostics after OLS). But if you want the relevant accessors you'd estimate fixed or random effects. I take your last point here, but there's a practical limitation. We only have so many option flags available (at present, as many as there are letters in the Roman alphabet) and I think we might be struggling to avoid collisions if we merge in several additional tests that each has an array of options of its own. I'd need to check, but I suspect we'd have to switch to syntax along the lines of modtest --test=autocorr <specific options> modtest --test=heterosked <specific options> and so on, where the choice of diagnostic becomes an option parameter rather than an option as such. And then backward compatibility would be difficult to arrange. [Of course, in principle we could have a practically unlimited number of distinct option flags, but it would mean a fairly substantial internal redesign to allow more than 26, and a bigger redesign to allow more than the number of bitflags that fit into a 32-bit integer.] Allin

Am 11.11.2017 um 23:20 schrieb Sven Schreiber: OK, I can see that already with 'qlrtest' there would be a clash with the 'q' from 'quiet'. OTOH, looking at the modtest options there are some with the same starting letter: autocorr/arch, squares/silent, etc. So I guess I don't really understand the technical problem!? Also, honestly I think it is unfortunate that because of this the diagnostic tests are split into two groups in a quite ad-hoc way that is difficult to communicate. (At least I didn't understand it before!) As an interim remedy we might add to the built-in doc for 'modtest' a sentence like this: "For other diagnostic tests after estimation (which require more option flags) see cusum, qlrtest, reset, hausman, chow." cheers, sven

On Mon, 13 Nov 2017, Sven Schreiber wrote: Sorry for the delay in responding, but here we go... No, the first letter of an option is not necessarily its short form. In case of conflict in that regard we cast around for another letter that does not conflict in context. For example, the autocorr option to modtest bags 'a' and the arch option gets 'h'. If a given command takes a large number of options it can become kinda difficult to find an unused letter, but that in itself is not a show-stopper. There follows an explanation of the main constraint. 1) We represent option flags internally using a C enumeration or "enum", which provides an easy and efficient way to associate a set of symbolic constants with integer values. The C enum type is guaranteed to be "big enough" to hold a (4-byte, 32-bit) "int". 2) A 32-bit integer can represent up to 2^32 distinct values, but... while some gretl options are mutually exclusive in certain contexts others are complementary, so we have to allow for distinct option flags coexisting in our 32-bit integer. That means we have at most 32 independent options in our enum (each commanding 1 bit). We want to reserve one of these to represent "this option is not yet set", so that leaves 31. Right now we represent 26 of these by the symbolic constants OPT_A,OPT_B,..., OPT_Z. This is important for the (at least semi-)comprehensibility and maintainability of the code: we want, for example, to be able to refer to the "robust" option flag as OPT_R, rather than as some unmemorable large integer. 3) We could add a few more symbolic constants (say, OPT_A1,OPT_B1,...) but we'd soon run out of those (and the flags in question wouldn't have a single-letter abbreviation, but maybe that's no big loss). The 32-bit limitation still binds, unless we go over to a bigger and more complex representation of option flags. 4) We've actually already hit the practical limit on option flags in at least one case, the "gnuplot" command. That's because in addition to user-visible options (of which there are many) we use the option argument to gnuplot() to pass some internal state information. That was the rationale for getting rid of the old distinct option flags for different "fit" options in favor of a single option flag, --fit=whatever, which takes a number of parameters. I agree. We can look into the practicality of folding more tests into the "modtest" command. And if we can't fit them all in, we should surely do the appropriate cross-referencing in the help doc. Allin