Re: [Gretl-devel] syntax inconsistency for coeff vector
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