On Mon, 13 Nov 2017, Sven Schreiber wrote:
Am 11.11.2017 um 23:20 schrieb Sven Schreiber:
> Am 11.11.2017 um 20:21 schrieb Allin Cottrell:
>> On Fri, 10 Nov 2017, Sven Schreiber wrote:
>>> have 'modtest' but that it is currently somewhat arbitrary and
>>> path-dependent which specific tests it covers.
>> 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
> You mean because the first letter of an option is automatically its short
OK, I can see that already with 'qlrtest' there would be a clash with the
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!?
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.
Also, honestly I think it is unfortunate that because of this the
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."
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.