4:48 p.m.
Hi,
more or less minimal example:
<hansl>
function list heylist (const series x)
print "aha"
list out = x # L
return out
end function
open denmark
heylist(diff(LRM)) # works!
list oi = heylist(diff(LRM)) # fails
</hansl>
thanks
sven
7:40 p.m.
On Sun, 24 Oct 2021, Sven Schreiber wrote:
<hansl>
function list heylist (const series x)
print "aha"
list out = x
return out
end function
open denmark
heylist(diff(LRM)) # works!
list oi = heylist(diff(LRM)) # fails
</hansl>
Specifically, the second case fails with the error message:
"heylist: argument 1 is of the wrong type (is list, should be series)"
In the second case gretl notices that the statement as a whole
involves assignment to a list object. Trying to be helpful, it
therefore "casts" the argument to diff(), namely LRM, to a
single-member list. This _would_ in fact be helpful if the statement
were of the simpler form
list oi = diff(LRM) # call it case B
Why? Because diff(LRM), without a cast to list for the argument,
produces an anonymous series, and only named series (members of the
dataset) can be put into lists.
Clearly, gretl is not clever enough here: in the heylist() context
"diff(LRM)" _should_ produce an anonymous series result; this
expression is supposed to create an argument to a function that
wants a series. Gretl doesn't understand that, unlike case B,
"diff(LRM)" occurs in an "opaque" context as an argument to
heylist().
So what's the fix? Either (a) gretl has to figure out how to detect
opacity of context, or (b) we drop the series-to-list cast business
altogether, in which case statements of the "case B" type would
fail.
Arguably, case B statements ought to fail. But we probably need to
check if that would break any existing function packages. And if we
decide to scrap the cast we should probably amend the doc for
functions such as diff() to point out that you can't assign to a
list if the RHS is just a series. (To be clear, it's not a problem
if the RHS is a single-member list, only if it's a series as such.)
Allin
8:33 p.m.
Am 24.10.2021 um 21:40 schrieb Allin Cottrell:
On Sun, 24 Oct 2021, Sven Schreiber wrote:
> heylist(diff(LRM)) # works!
> list oi = heylist(diff(LRM)) # fails
> </hansl>
Specifically, the second case fails with the error message:
"heylist: argument 1 is of the wrong type (is list, should be series)"
In the second case gretl notices that the statement as a whole involves
assignment to a list object. Trying to be helpful, it therefore "casts"
the argument to diff(), namely LRM, to a single-member list. This
_would_ in fact be helpful if the statement were of the simpler form
list oi = diff(LRM) # call it case B
Why? Because diff(LRM), without a cast to list for the argument,
produces an anonymous series, and only named series (members of the
dataset) can be put into lists.
Hm, thanks for the explanation...
Clearly, gretl is not clever enough here: in the heylist() context
"diff(LRM)" _should_ produce an anonymous series result; this expression
is supposed to create an argument to a function that wants a series.
Gretl doesn't understand that, unlike case B, "diff(LRM)" occurs in an
"opaque" context as an argument to heylist().
Let me just note that it wouldn't be such a big problem if in this case
diff(LRM) did produce a hardwired-prefix-named internal new series
d_LRM, I think, in analogy to what diff() does to list members. I'm just
saying it doesn't have to be anonymous, FWIW.
So what's the fix? Either (a) gretl has to figure out how to
detect
opacity of context, or (b) we drop the series-to-list cast business
altogether, in which case statements of the "case B" type would fail.
Isn't there also the option (c): cast only the _result_ of diff(LRM) to
a one-element list (with the hardwired prefix naming) in case B, instead
of casting already the argument? This would seem like the logical order
of evaluation of the statement/assignment.
Arguably, case B statements ought to fail.
Hm, if I understand correctly, the reasoning is the missing name for the
produced series result. Is that really compelling? I mean if LRM is part
of a list then there isn't a problem to apply the convention d_LRM. Why
then is it a problem to use d_LRM also if the result is a series? (Of
course, in standard assignments an explicit new name for the produced
series will be specified and so would [have to] overwrite the predefined
convention.)
if that would break any existing function packages. And if we decide
to
scrap the cast we should probably amend the doc for functions such as
diff() to point out that you can't assign to a list if the RHS is just a
series. (To be clear, it's not a problem if the RHS is a single-member
list, only if it's a series as such.)
Is that really the needed rule: "can't assign to a list if the RHS is
just a series" ? Aren't we talking about anonymous series only?
Argh, lists are nice for the simple command-like use cases, but then the
business gets messy quite quickly...
cheers
sven
9:30 p.m.
On Sun, 24 Oct 2021, Sven Schreiber wrote:
Am 24.10.2021 um 21:40 schrieb Allin Cottrell:
> On Sun, 24 Oct 2021, Sven Schreiber wrote:
>> heylist(diff(LRM)) # works!
>> list oi = heylist(diff(LRM)) # fails
>> </hansl>
>
> Specifically, the second case fails with the error message:
>
> "heylist: argument 1 is of the wrong type (is list, should be series)"
>
> In the second case gretl notices that the statement as a whole involves
> assignment to a list object. Trying to be helpful, it therefore "casts"
> the argument to diff(), namely LRM, to a single-member list. This
> _would_ in fact be helpful if the statement were of the simpler form
>
> list oi = diff(LRM) # call it case B
>
> Why? Because diff(LRM), without a cast to list for the argument,
> produces an anonymous series, and only named series (members of the
> dataset) can be put into lists.
Hm, thanks for the explanation...
> Clearly, gretl is not clever enough here: in the heylist() context
> "diff(LRM)" _should_ produce an anonymous series result; this expression
> is supposed to create an argument to a function that wants a series.
> Gretl doesn't understand that, unlike case B, "diff(LRM)" occurs in an
> "opaque" context as an argument to heylist().
Let me just note that it wouldn't be such a big problem if in this case
diff(LRM) did produce a hardwired-prefix-named internal new series
d_LRM, I think, in analogy to what diff() does to list members. I'm just
saying it doesn't have to be anonymous, FWIW.
I think it does have to be anonymous. Given a series x, a statement
such as
series foo = 100*diff(x)/x(-1)
must not add a series d_x to the dataset; the result of diff(x) is
strictly a throw-away anonymous series. And a statement such as
series mydiff = diff(x)
must not add a shadow series under the name d_x; in this case the
user has taken charge of naming the new series.
But we need to think about this some more. Just eliminating the
series-to-list cast breaks the packages FEP, CommonTrendsTest, ridge
and robust_RESET.
Allin
10:36 a.m.
Am 24.10.2021 um 23:30 schrieb Allin Cottrell:
But we need to think about this some more. Just eliminating the
series-to-list cast breaks the packages FEP, CommonTrendsTest, ridge
and robust_RESET.
Agreed that more thought is needed. But changing those packages would be
feasible in principle - I'm involved in the first three anyway, and the
latter was by Oleh, such that minor edits could also be applied by
myself, as we have done in the past with other packages by him.
One other totally wild (?) thought, given that the problem of
assignments such as...
list oi = diff(LRM) # call it case B
...is the missing naming of the anonymous series: Why not add to the
"list" command (implying the underlying "genr" command) some kind of
mechanism where the author can provide names for the created series? Be
it a double-dash option or some kind of additional arg.
cheers
sven
2:02 p.m.
Am 25.10.2021 um 12:36 schrieb Sven Schreiber:
Am 24.10.2021 um 23:30 schrieb Allin Cottrell:
>
> But we need to think about this some more. Just eliminating the
> series-to-list cast breaks the packages FEP, CommonTrendsTest, ridge
> and robust_RESET.
Agreed that more thought is needed.
I can confirm that the problem (with the script previously posted) does
not appear anymore on the latest snapshot.
thanks Allin!
-s
9:40 p.m.
On Sun, 24 Oct 2021, Allin Cottrell wrote:
To be clear, it's not a problem if the [right-hand side of a
statement including assignment to a list on the left] is a
single-member list, only if it's a series as such.
Sorry, not clear enough: I meant that it's a problem only if the
series on the right is anonymous, generated on the fly, not a member
of the datatset.
Nothing wrong with creating a list consisting of a single named
series.
Allin
1175
days inactive
1184
days old
6 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber