3 a.m.
Hi,
this is nothing new, but I stumbled over it again and now I can use it
as an excuse why I never manage to remember the correct syntax:
When we access the coeff vector after estimation, we have '$coeff'; when
we give the variable index we use square brackets ($coeff[2]), but when
we give the name then it's round brackets ($coeff(myvar)).
So far so good. But when we formulate restrictions, it's now 'b' for the
coeff vector, and we _always_ have to use square brackets apparently
(b[2] as well as b[myvar]). So there are two pretty obvious questions
from the point of view of the user I think:
1) Why have a separate symbol for the coeff vector in restrict blocks at
all? (Backward compatibility issues aside for now.)
2) The bracket situation seems arbitrary and confuses me every time. Can
it be changed? (in the medium term I mean, no need to rush.)
Thanks,
sven
5:50 p.m.
On Mon, 1 Dec 2014, Sven Schreiber wrote:
this is nothing new, but I stumbled over it again and now I can use
it
as an excuse why I never manage to remember the correct syntax:
When we access the coeff vector after estimation, we have '$coeff'; when
we give the variable index we use square brackets ($coeff[2]), but when
we give the name then it's round brackets ($coeff(myvar)).
So far so good. But when we formulate restrictions, it's now 'b'
for the coeff vector, and we _always_ have to use square brackets
apparently (b[2] as well as b[myvar]). So there are two pretty
obvious questions from the point of view of the user I think:
1) Why have a separate symbol for the coeff vector in restrict blocks at
all? (Backward compatibility issues aside for now.)
The original intent, as I recall, was just to cut down on verbosity:
easier to use "b[]" than "$coeff[]" (but we wouldn't really want
to
make "b" a reserved word in place of $coeff in the world outside of
"restrict"). Also $coeff is a read-only accessor, the result of
estimation. It would seem a bit funny to allow stipulating a value
for a $coeff element in the context of restrict -- to me, anyway.
2) The bracket situation seems arbitrary and confuses me every
time. Can it be changed? (in the medium term I mean, no need to
rush.)
In the $coeff context, IMO the [] versus () business is justified.
When using [] you're saying, "Hey, I'm supplying an index into a
matrix". Scalars are OK here; vectors and some specials are also
accepted. But one sort of object that's _not_ acceptable for this
purpose is a series. On the other hand, when you use () with $coeff
you're saying, "I know I'm giving the name of a series but don't try
to interpret it as an index as such, I want you to translate it into
an index for me" -- that is you're in effect using a special
convenience function.
If we were redesigning this from scratch, the latter usage might
perhaps be better written as, e.g.,
$coeff[idxof(seriesname)]
As for b[] in "restrict", well yes we might have said by analogy
that you need to use b() rather than b[] when giving a regressor
name rather than an index. Only it's not required for disambiguation
in that context because "restrict" is a self-contained little
environment where the full power of "genr" is not available.
Allin
7:27 a.m.
Am 01.12.2014 um 23:50 schrieb Allin Cottrell:
On Mon, 1 Dec 2014, Sven Schreiber wrote:
If we were redesigning this from scratch, the latter usage might
perhaps be better written as, e.g.,
$coeff[idxof(seriesname)]
Please no, that's certainly not what I wanted to imply...
As for b[] in "restrict", well yes we might have said by
analogy
that you need to use b() rather than b[] when giving a regressor
name rather than an index. Only it's not required for disambiguation
in that context because "restrict" is a self-contained little
environment where the full power of "genr" is not available.
Basically I'm asking for syntactic sugar from a user's point of view so
that the behavior of $coeff() can be matched by b(). This seems to me
like the most natural/intuitive way. "Can do" is perfectly fine with me,
I don't need more "must do", so if b[myvar] stays then it's fine with
me.
Another way of stating this could be: Exactly because 'restrict' has its
own environment, why can't gretl allow the user more flexibility in
there, where side effects shouldn't be an issue (I hope)?
thanks,
sven
12:39 p.m.
On Tue, 2 Dec 2014, Sven Schreiber wrote:
Basically I'm asking for syntactic sugar from a user's point
of view so
that the behavior of $coeff() can be matched by b(). This seems to me
like the most natural/intuitive way. "Can do" is perfectly fine with me,
I don't need more "must do", so if b[myvar] stays then it's fine with
me.
OK, we now accept b(varname) in place of b[varname] in the context of
a "restrict" block -- by analogy with the situation for the $coeff
accessor.
Allin
3:03 p.m.
Am 04.12.2014 um 18:39 schrieb Allin Cottrell:
On Tue, 2 Dec 2014, Sven Schreiber wrote:
> Basically I'm asking for syntactic sugar from a user's point of view so
> that the behavior of $coeff() can be matched by b(). This seems to me
> like the most natural/intuitive way. "Can do" is perfectly fine with me,
> I don't need more "must do", so if b[myvar] stays then it's fine
with me.
OK, we now accept b(varname) in place of b[varname] in the context of
a "restrict" block -- by analogy with the situation for the $coeff
accessor.
Thank you!
-sven
3591
days inactive
3594
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber