8:17 a.m.
hi,
I was mixing up the parentheses and tried to access a single value of a
series like this:
x(1995:1) -- instead of x[1995:1]
The problem is that gretl did not complain, but instead seems to have
treated this as a lag expression and I got some weird results. Now,
AFAICS the expression '1995:1' is not a valid numeral that can be used
as a lag order, so I think gretl should give an error instead, no?
thanks,
sven
12:56 p.m.
On Thu, 25 Apr 2013, Sven Schreiber wrote:
I was mixing up the parentheses and tried to access a single value of
a
series like this:
x(1995:1) -- instead of x[1995:1]
The problem is that gretl did not complain, but instead seems to have
treated this as a lag expression and I got some weird results. Now,
AFAICS the expression '1995:1' is not a valid numeral that can be used
as a lag order, so I think gretl should give an error instead, no?
Well, an expression such as '1995:1' is converted internally
into an integer observation number (assuming the dataset has a
suitable frequency), and in that guise it is accepted as a lag
(or actually a lead). You can also do, for example,
scalar t3 = (1995:1)*3
But note that if (in the context above) you specified the type
on the left-hand side
scalar foo = x(1995:1)
you would get an error OK.
We could, I suppose, make an internal distinction between
"general" scalars and scalars that have been converted from
observation identifiers, and limit the contexts in which we
accept the latter.
Allin
1:43 p.m.
On Thu, 25 Apr 2013, Allin Cottrell wrote:
On Thu, 25 Apr 2013, Sven Schreiber wrote:
> I was mixing up the parentheses and tried to access a single value of a
> series like this:
> x(1995:1) -- instead of x[1995:1]
>
> The problem is that gretl did not complain [...]
We could, I suppose, make an internal distinction between
"general" scalars and scalars that have been converted from
observation identifiers, and limit the contexts in which we
accept the latter.
I've done something like this in CVS, and done a certain
amount of checking for bad side-effects. OK so far, but more
testing would be good.
Allin
3:03 p.m.
Am 25.04.2013 15:43, schrieb Allin Cottrell:
On Thu, 25 Apr 2013, Allin Cottrell wrote:
> On Thu, 25 Apr 2013, Sven Schreiber wrote:
>
>> I was mixing up the parentheses and tried to access a single value of a
>> series like this:
>> x(1995:1) -- instead of x[1995:1]
>>
>> The problem is that gretl did not complain [...]
>
> We could, I suppose, make an internal distinction between
> "general" scalars and scalars that have been converted from
> observation identifiers, and limit the contexts in which we
> accept the latter.
I've done something like this in CVS, and done a certain
amount of checking for bad side-effects. OK so far, but more
testing would be good.
Thanks for the explanation of the cause (other email).
So the parsing ordering seems to be (1) internal conversions (here: to
obs index), (2) syntax-check (maybe implicit in the evaluation step). My
intuitive reaction would be that this ordering should be reversed; first
a syntax check (insofar as it's possible), and only afterwards do any
internal conversions, because the syntax is an "external thing" if you
know what I mean.
I don't know if that would be possible, and thank you of course for
addressing the issue. Just trying to get at the cleanest solution.
cheers,
sven
3:31 p.m.
On Thu, 25 Apr 2013, Sven Schreiber wrote:
Am 25.04.2013 15:43, schrieb Allin Cottrell:
> On Thu, 25 Apr 2013, Allin Cottrell wrote:
>
>> On Thu, 25 Apr 2013, Sven Schreiber wrote:
>>
>>> I was mixing up the parentheses and tried to access a single value of a
>>> series like this:
>>> x(1995:1) -- instead of x[1995:1]
>>>
>>> The problem is that gretl did not complain [...]
>>
>> We could, I suppose, make an internal distinction between
>> "general" scalars and scalars that have been converted from
>> observation identifiers, and limit the contexts in which we
>> accept the latter.
>
> I've done something like this in CVS, and done a certain
> amount of checking for bad side-effects. OK so far, but more
> testing would be good.
Thanks for the explanation of the cause (other email).
So the parsing ordering seems to be (1) internal conversions (here: to
obs index), (2) syntax-check (maybe implicit in the evaluation step). My
intuitive reaction would be that this ordering should be reversed; first
a syntax check (insofar as it's possible), and only afterwards do any
internal conversions, because the syntax is an "external thing" if you
know what I mean.
Actually the "something like this" that I implemented is a bit
different from what I first stated.
Before the change: when parsing numerical input (other than in
the context of matrix subscripting, where ':' has its own
special meaning) we don't immediately reject ':' but we record
the fact that we got a colon in the input stream. And once
we've finished assembling the "numerical" string, if we got a
colon we try interpreting that string as an observation
identifier. This will fail and generate an error if there's no
dataset in place, or if the frequency is wrong, or if the
index is out of bounds, but if it's OK as an obs identifier we
convert it to a straight numerical index and treat it as a
scalar thereafter.
After the change: as above, except that if we validate the obs
identifier we record it internally as a string, not a scalar.
Then when it comes to evaluating, e.g.,
scalar xt = x[1995:1]
we find the string "1995:1" which converts to an index in
situ. (This is OK since a string is in general acceptable as
an obs identifier.)
On the other hand, if we try to evaluate, e.g.,
foo = x(1995:1)
the form "x()", for x a series, leads us to expect a lag/lead
specification, which requires a scalar value. We find a string
where there ought to be a scalar, and we error out.
Allin
8:28 a.m.
Am 25.04.2013 17:31, schrieb Allin Cottrell:
After the change: as above, except that if we validate the obs
identifier we record it internally as a string, not a scalar.
Then when it comes to evaluating, e.g.,
scalar xt = x[1995:1]
we find the string "1995:1" which converts to an index in
situ. (This is OK since a string is in general acceptable as
an obs identifier.)
On the other hand, if we try to evaluate, e.g.,
foo = x(1995:1)
the form "x()", for x a series, leads us to expect a lag/lead
specification, which requires a scalar value. We find a string
where there ought to be a scalar, and we error out.
Sounds great, thanks.
-sven
4298
days inactive
4299
days old
5 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber