2:02 p.m.
This is a follow-up to Sven's posting at
http://lists.wfu.edu/pipermail/gretl-devel/2012-January/003663.html
I've added a chapter on "Multivariate models" to the User's
Guide. I haven't got very far with it yet, but I've included
the material Sven posted. However, before we lock this in I
think maybe we can improve things a little.
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?
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?
So, I'm proposing that one should be able to do the following
sort of thing, either inside or outside of functions (with or
without the "restrict" bit):
<hansl>
system
equation y1 0 x1
equation y2 0 x2
end system
restrict
b[1,2] - b[2,2] = 0
end restrict
estimate method=sur
</hansl>
Does anyone see a downside to this?
Allin
2:24 p.m.
Allin,
I think your proposed changes make a lot of sense. Your example seems much cleaner than
the current setup.
PS
-----Original Message-----
From: gretl-devel-bounces(a)lists.wfu.edu [mailto:gretl-devel-bounces@lists.wfu.edu] On
Behalf Of Allin Cottrell
Sent: Tuesday, January 24, 2012 9:03 AM
To: Gretl development
Subject: [Gretl-devel] new "system" syntax
This is a follow-up to Sven's posting at
http://lists.wfu.edu/pipermail/gretl-devel/2012-January/003663.html
I've added a chapter on "Multivariate models" to the User's Guide. I
haven't got very far with it yet, but I've included the material Sven posted.
However, before we lock this in I think maybe we can improve things a little.
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?
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?
So, I'm proposing that one should be able to do the following sort of thing, either
inside or outside of functions (with or without the "restrict" bit):
<hansl>
system
equation y1 0 x1
equation y2 0 x2
end system
restrict
b[1,2] - b[2,2] = 0
end restrict
estimate method=sur
</hansl>
Does anyone see a downside to this?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2:35 p.m.
I also think your new approach is an improvement. While you are on
this topic, would it be possible that copying a script and directly
pasting it into the GUI system specification window work, please.
Currently one has to type one by one restrictions, equations etc.
Cheers
Talha
On Tue, Jan 24, 2012 at 4:02 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
This is a follow-up to Sven's posting at
http://lists.wfu.edu/pipermail/gretl-devel/2012-January/003663.html
I've added a chapter on "Multivariate models" to the User's
Guide. I haven't got very far with it yet, but I've included
the material Sven posted. However, before we lock this in I
think maybe we can improve things a little.
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?
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?
So, I'm proposing that one should be able to do the following
sort of thing, either inside or outside of functions (with or
without the "restrict" bit):
<hansl>
system
equation y1 0 x1
equation y2 0 x2
end system
restrict
b[1,2] - b[2,2] = 0
end restrict
estimate method=sur
</hansl>
Does anyone see a downside to this?
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
3:05 p.m.
On Tue, 24 Jan 2012, Talha Yalta wrote:
I also think your new approach is an improvement. While you are on
this topic, would it be possible that copying a script and directly
pasting it into the GUI system specification window work, please.
On which platform does this not work? On linux I can do this
either via the X-selection or the Ctrl-C, Ctrl-V mechanism.
Allin
3:25 p.m.
> I also think your new approach is an improvement. While you are
on
> this topic, would it be possible that copying a script and directly
> pasting it into the GUI system specification window work, please.
On which platform does this not work? On linux I can do this
either via the X-selection or the Ctrl-C, Ctrl-V mechanism.
Ah, I see that ctrl+v
does work. But, adding a "paste from clipboard"
item to the right click menu sure can be as useful as the other 4
items.
Cheers
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
11:20 p.m.
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.
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.
But although explicit is better than implicit (from the Zen of Python
again), I admit that for simple rough-and-ready scripts the parsimony of
your suggestion could be nice.
cheers,
sven
1:46 a.m.
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
9:10 a.m.
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
2:30 p.m.
On Wed, 25 Jan 2012, Sven Schreiber wrote:
> 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?
That's because "restrict" works differently for "system"
compared with other model commands: in relation to a system,
the restrict block simply sets up a restriction -- it's not
actually tested until you follow up with "estimate", and
that's when the method comes in.
How desirable this is may be debatable, but it's the
long-standing behavior with "system".
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.
I was really just thinking out loud, looking for comments. The
"$system" dummy-name seems to be redundant in relation to the
"estimate" command, but we're agreeing that it's not (always)
redundant in relation to "restrict". So perhaps we should
continue to require it in both contexts, as confirmation that
the command pertains to the last-defined anonymous system: I
don't have a problem with that.
Allin
4474
days inactive
4475
days old
8 comments
4 participants
participants (4)
-
Allin Cottrell -
Summers, Peter -
Sven Schreiber -
Talha Yalta