On 01/25/2012 02:46 AM, Allin Cottrell wrote:
On Wed, 25 Jan 2012, Sven Schreiber wrote:
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.
I see, and I tend to agree that it's probably not worth the effort.
...
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.
Why does this work if no estimation method for the system has been
specified? In a sense it's a good example for the problems here :-) --
First the argument was that '$system' is redundant and now it's not.
If there's a
compelling case for allowing such interleaving in functions, we can
reconsider.
To be honest, I'd have to make one up: maybe one wants to check a
simultaneous-equation bias, doing single-equ OLS first and then
embedding that equation in a system. Imagine you want to do a
Hausman-type test by hand, comparing the OLS and system estimates. And
then depending on the test outcome you want to continue with only one of
the estimates and place restrictions there.
I'm not saying this is urgently necessary, but it is conceivable I guess.
cheers,
sven