10:36 p.m.
Hi,
for the first thing, here's a minimal example:
<hansl>
function void checko(list L)
list L print # d_LRY d_LRM (expected result)
varlist # weird: 0) const 5) [masked] 6) [masked]
end function
open denmark
list L = LRY LRM
checko(diff(L))
</hansl>
OK, then in my use case I'm also using 'append' (inside the function) to
load data from a csv file. The first part of that csv file contains the
same data as in the list L, with the same series names. However,
afterwards it seems that for example d_LRY appears twice in the dataset
- at least it's the result of an empty "print". ("varlist"
doesn't show
duplicates, but again has these [masked] entries as before with large
series ID# gaps.)
How to avoid the duplication and get a "sane" dataset view inside the
function?
thanks
sven
10:45 a.m.
Am 20.06.21 um 00:36 schrieb Sven Schreiber:
Hi,
for the first thing, here's a minimal example:
<hansl>
function void checko(list L)
list L print # d_LRY d_LRM (expected result)
varlist # weird: 0) const 5) [masked] 6) [masked]
end function
open denmark
list L = LRY LRM
checko(diff(L))
</hansl>
OK, then in my use case I'm also using 'append' (inside the function) to
load data from a csv file. The first part of that csv file contains the
same data as in the list L, with the same series names. However,
afterwards it seems that for example d_LRY appears twice in the dataset
- at least it's the result of an empty "print". ("varlist"
doesn't show
duplicates, but again has these [masked] entries as before with large
series ID# gaps.)
I also recently saw those "[masked]" series names when appending new
columns which were not present in already active dataset.
However, this toy using cross-sectional data works as intended, I guess
<hansl>
set verbose off
nulldata 3
series foo1 = normal()
series foo2 = normal()
print dataset -o
# Generate new dataset
matrix data_tobe_appended = mnormal(3,3)
cnameset(data_tobe_appended, "foo1, app1, app2")
# Store matrix as dataset
string fname = "to_be_appendex.csv"
store @fname --matrix=data_tobe_appended
eval readfile(fname)
append @fname
print dataset -o
</hansl>
Artur
2:13 p.m.
On Sun, 20 Jun 2021, Sven Schreiber wrote:
Hi,
for the first thing, here's a minimal example:
<hansl>
function void checko(list L)
list L print # d_LRY d_LRM (expected result)
varlist # weird: 0) const 5) [masked] 6) [masked]
end function
open denmark
list L = LRY LRM
checko(diff(L))
</hansl>
"varlist" is not showing series 1 to 4 because they're not supposed
to be visible inside the function; they were not passed in. It's
showing "[masked]" for series 5 and 6 because they were passed as
list members, and inside the function you're supposed to access them
via the list, or individually as <listname>.$i.
OK, then in my use case I'm also using 'append' (inside
the function) to
load data from a csv file. The first part of that csv file contains the
same data as in the list L, with the same series names. However,
afterwards it seems that for example d_LRY appears twice in the dataset
- at least it's the result of an empty "print".
You've added a new series, "d_LRY", local to the function. This
leaves undisturbed the series passed in via list, which could be
accessed inside the function as L.d_LRY. The new "d_LRY" will not
propagate to the caller unless you return it.
If there's a bug here, it's that the "print" (all series) command
shows the name "d_LRY" twice: on the first occurrence it should
probably be shown as "[masked]" or as "L.d_LRY". In fact, if it can
be arranged without too much difficulty, we might replace all
occurrences of "[masked]" with the form "listname.seriesname".
[Guide, section 14.4, subsection "List arguments"]
Allin
2:37 p.m.
Am 20.06.2021 um 16:13 schrieb Allin Cottrell:
On Sun, 20 Jun 2021, Sven Schreiber wrote:
"varlist" is not showing series 1 to 4 because they're not supposed to
be visible inside the function; they were not passed in. It's showing
"[masked]" for series 5 and 6 because they were passed as list
members, and inside the function you're supposed to access them via
the list, or individually as <listname>.$i.
Thanks for the explanation, Allin!
As you write below, perhaps then the printout for "list L print" should
also output something like L.d_LRY instead.
> OK, then in my use case I'm also using 'append' (inside the function) to
> load data from a csv file. The first part of that csv file contains the
> same data as in the list L, with the same series names. However,
> afterwards it seems that for example d_LRY appears twice in the dataset
> - at least it's the result of an empty "print".
You've added a new series, "d_LRY", local to the function. This leaves
undisturbed the series passed in via list, which could be accessed
inside the function as L.d_LRY. The new "d_LRY" will not propagate to
the caller unless you return it.
Again, thanks. Indeed, it was may intention to return the newly appended
series in a list, and I wasn't sure what the effect of this seeming
"duplication" would be.
If there's a bug here, it's that the "print" (all series) command
shows the name "d_LRY" twice:
Yes, that was the source of my worries.
on the first occurrence it should probably be shown as
"[masked]" or
as "L.d_LRY". In fact, if it can be arranged without too much
difficulty, we might replace all occurrences of "[masked]" with the
form "listname.seriesname".
Sounds quite reasonable.
thanks
sven
3:26 p.m.
Am 20.06.2021 um 16:37 schrieb Sven Schreiber:
Again, thanks. Indeed, it was may intention to return the newly appended
series in a list, and I wasn't sure what the effect of this seeming
"duplication" would be.
minor follow-up issue: Doing "return dataset" in the function fails, but
the more verbose two-liner works:
list out = dataset
return out
So it kind of looks to me as if doing "return dataset" directly could
also be allowed syntax.
thanks
sven
6:12 p.m.
On Sun, 20 Jun 2021, Sven Schreiber wrote:
Am 20.06.2021 um 16:37 schrieb Sven Schreiber:
>
> Again, thanks. Indeed, it was may intention to return the newly appended
> series in a list, and I wasn't sure what the effect of this seeming
> "duplication" would be.
minor follow-up issue: Doing "return dataset" in the function fails, but
the more verbose two-liner works:
list out = dataset
return out
So it kind of looks to me as if doing "return dataset" directly could
also be allowed syntax.
My first thought is that "dataset" should not be allowed as a
list-name inside a function.
Allin
6:34 p.m.
Am 20.06.2021 um 20:12 schrieb Allin Cottrell:
On Sun, 20 Jun 2021, Sven Schreiber wrote:
> minor follow-up issue: Doing "return dataset" in the function fails, but
> the more verbose two-liner works:
>
> list out = dataset
>
> return out
>
> So it kind of looks to me as if doing "return dataset" directly could
> also be allowed syntax.
My first thought is that "dataset" should not be allowed as a
list-name inside a function.
Well, it does work already! I can understand why the special form should
not be over-stretched as in "return dataset", but then there might be
"return deflist(dataset)" (untested).
But seriously, there appear to be clear rules as to which series are
locally available inside a function. Why should 'dataset' be banned then
in that context?
cheers
sven
6:54 p.m.
On Sun, 20 Jun 2021, Sven Schreiber wrote:
Am 20.06.2021 um 20:12 schrieb Allin Cottrell:
> On Sun, 20 Jun 2021, Sven Schreiber wrote:
>> minor follow-up issue: Doing "return dataset" in the function fails,
but
>> the more verbose two-liner works:
>>
>> list out = dataset
>>
>> return out
>>
>> So it kind of looks to me as if doing "return dataset" directly could
>> also be allowed syntax.
>
> My first thought is that "dataset" should not be allowed as a
> list-name inside a function.
Well, it does work already! I can understand why the special form should
not be over-stretched as in "return dataset", but then there might be
"return deflist(dataset)" (untested).
But seriously, there appear to be clear rules as to which series are
locally available inside a function. Why should 'dataset' be banned then
in that context?
According to the Guide, the "dataset" macro refers to "all the
series in the current dataset (except the pre-defined const)". In
general, within a function you do not have access to the entire
current dataset, and moreover some of the access you have may be
just "borrowed", so this is not applicable. It's like you're saying,
"Hey gretl, you figure out what should go into this list I want to
return!".
The hansl idioms for creating a list as return value from a function
are (a) create a named list via a single function call, or if that's
not feasible (b) start by defining a null list then sequentially
append the series in question.
Allin
8:01 p.m.
lAm 20.06.2021 um 20:54 schrieb Allin Cottrell:
On Sun, 20 Jun 2021, Sven Schreiber wrote:
> But seriously, there appear to be clear rules as to which series are
> locally available inside a function. Why should 'dataset' be banned then
> in that context?
According to the Guide, the "dataset" macro refers to "all the series
in the current dataset (except the pre-defined const)". In general,
within a function you do not have access to the entire current dataset,
Well I
guess it depends on the intended meaning of "current". I took it
to mean the local scope of the function.
The hansl idioms for creating a list as return value from a function
are (a) create a named list via a single function call, or if that's
not feasible (b) start by defining a null list then sequentially
append the series in question.
OK, what about this, should it be banned, too?:
<hansl>
function list cL (list L)
diff L
list out = *
return out
end function
open denmark
list inL = LRM LRY
list check = cL(inL)
list check print # LRM LRY d_LRM d_LRY
</hansl>
cheers
sven
4:31 p.m.
On Sun, 20 Jun 2021, Sven Schreiber wrote:
Am 20.06.2021 um 16:13 schrieb Allin Cottrell:
> In fact, if it can be arranged without too much difficulty, we
> might replace all occurrences of "[masked]" with the form
> "listname.seriesname".
Sounds quite reasonable.
Here's the current status in git:
<terminal>
myrtle:~/src/build/cli$ cat denmark_plus.csv
obs,d_LRY
1974q2,1
1974q3,2
1974q4,3
myrtle:~/src/build/cli$ cat checko.inp
set verbose off
function void checko(list L)
append denmark_plus.csv --quiet
varlist
print --byobs --range=[1:6]
end function
open denmark --quiet
list L = LRY LRM
checko(diff(L))
myrtle:~/src/build/cli$ ./gretlcli -q -b checko.inp
gretl version 2021c-git
? run checko.inp
/home/allin/src/build/cli/checko.inp
Read datafile /opt/esl/share/gretl/data/misc/denmark.gdt
Read datafile /home/allin/src/build/cli/denmark_plus.csv
Listing 4 variables:
0) const 5) L.d_LRY 6) L.d_LRM 7) d_LRY
L.d_LRY L.d_LRM d_LRY
1974:1
1974:2 -0.02984 -0.02840 1
1974:3 -0.03600 -0.02263 2
1974:4 -0.02556 0.02033 3
1975:1 -0.008309 -0.01554
1975:2 -0.01718 0.01819
</terminal>
Allin
5:54 p.m.
Am 20.06.2021 um 18:31 schrieb Allin Cottrell:
On Sun, 20 Jun 2021, Sven Schreiber wrote:
> Am 20.06.2021 um 16:13 schrieb Allin Cottrell:
>
>> In fact, if it can be arranged without too much difficulty, we might
>> replace all occurrences of "[masked]" with the form
>> "listname.seriesname".
>
> Sounds quite reasonable.
Here's the current status in git:
Thanks, Allin.
..
Listing 4 variables:
0) const 5) L.d_LRY 6) L.d_LRM 7) d_LRY
The ID integers are not usable inside the function in their standard
way, right? I mean, you cannot do in the function:
list Linside = 5 6
because those series are only accessible as list members. (I'm just
thinking out loud.) But I guess inside a function this isn't a problem,
since no interactive use is possible.
thanks
sven
1280
days inactive
1281
days old
10 comments
3 participants
participants (3)
-
Allin Cottrell -
Artur T. -
Sven Schreiber