Re: [Gretl-devel] new "system" syntax
On Wed, 25 Jan 2012, Sven Schreiber wrote:
Am 24.01.2012 15:02, schrieb Allin Cottrell:
>
> 1) In gretl 1.9.7 the option of creating an "anonymous system"
> (i.e. using the "system" command with neither assignment to a
> name or a "method=whatever" tag) is confined to functions. But
> it strikes me: why shouldn't this be available for scripting
> in general? If you're not interested in creating a GUI session
> icon, why should you have to name a system?
That's right, it's a bit artificial to limit that to functions.
But a more general thought on this: I assume that the reason for the
nice concept to first specify a system and then separately estimate it
with one or more estimators is that it would be annoying to repeat a
long-ish specification just for re-estimation.
(In contrast, re-estimating single equs doesn't seem to be possible via
their assigned names, presumably because their spec can be easily
repeated and thus there is no pressing need. Although it would sometimes
make for cleaner script code I guess.)
But this reason would apply also to systems in functions, and this would
mean that the real solution is to allow "private" names (local function
scope) for system specifications such that we can have the convenient
re-estimating feature (not only for the last model, as the anonymous
solution would imply).
In terms of syntax one could think of 'system --name=hello' or somesuch.
Well, yes, the syntax wouldn't be a problem in itself. The problem
would lie in the implementation of a multi-level stack of named
model objects. I'm not saying it's infeasible, but it wouldn't be
trivial and I'm not sure the advantages are compelling.
> 2) Also in 1.9.7, having defined an anonymous system you are
> required to use the dummy name "$system" if you want to access
> the system for the "restrict" or "estimate" commands, as in
>
> estimate $system method=sur
>
> This seems a bit clunky. Shouldn't such commands just work on
> the last-defined system by default?
IMHO it doesn't look clunky at all, it can almost be read aloud.
(Imagine for a moment introducing 'with-method' as an alias for 'method'
and reading "estimate $system with-method=sur".) For example, why it may
be clear to the gretl pro that the last system is referenced, if you
also have a single-equ model in your script it is not immediately
obvious what is re-estimated.
That's true. And for that reason I'm not proposing to abolish the
"$system" dummy-name in relation to the "restrict" command. Consider
this example:
<hansl>
ols y1 0 x1
system
y1 0 x1
y2 0 x2
end system
restrict
b[1,2] - b[2,2] = 0
end restrict
</hansl>
With current CVS this will produce an error, because "restrict" by
preference looks to the last-estimated model, which in this case is
single-equation OLS, to which the specified restriction is not
applicable. (A system has been defined but has not yet been
estimated, and so does not occupy the place of "last model".) But if
you substitute
restrict $system
for plain "restrict", the script-fragment above works OK, with the
restrict command referring to the last-defined system rather than
the last-estimated model.
To address your point more generally, my thinking was that writers
of functions are likely to be able to arrange matters sequentially,
so that operations such as "restrict" and "estimate" always refer to
the last model/system, rather than interleaving restriction and/or
estimation of various previously defined models -- possibly with the
help of the "$system" dummy-name, as above.
In a plain script "full interleaving" is possible, via the
name <- system
mechanism; in a function it is not, at present. If there's a
compelling case for allowing such interleaving in functions, we can
reconsider.
Allin