On Tue, 1 Mar 2022, Sven Schreiber wrote:
unfortunately the panel subsampling business doesn't seem to be
fully
resolved. I'm struggling to understand where exactly the apparent bug is
located or if there are perhaps more than one, so let's go step by step.
1) First, consider the attached panel-structured dataset
"checkdata.gdt", and then the following small script:
<hansl>
function void samplecheck(series x)
smpl # simply prints the currently active sample
end function
# assuming checkdata.gdt is loaded...
setobs 4 1991:1 --panel-time
smpl 1991:1 2017:4 --time # restricts from 1708 to 1512 obs
samplecheck(UKIB)
</hansl>
The point here is that the samplecheck function should only get the
restricted active sample from the outer scope (right?)
No, the function only gets regular _access_ to the restricted range,
but it still "knows" the full data range.
inside the function it still reports 1708 as being the relevant
"full" sample range. Is that expected?
Yes, I would say. Note how the following behaves:
<hansl>
function void tsmpl (void)
smpl
end function
open data9-7
smpl ; -10
tsmpl()
</hansl>
2) OK, next it gets more "interesting" in terms of the
printed sample
information. Again with the attached dataset, consider the following
script, where in the end things are totally messed up:
<hansl>
# assuming checkdata.gdt is loaded...
smpl full
setobs 4 1991:1 --panel-time
smpl 1991:1 2017:4 --time # n = 1512
function void check2 (series x)
series dates = $obsdate
smpl 5 5 --unit
smpl dates < 20010101 --restrict
smpl
end function
[...]
</hansl>
The problem exposed by check2() lies in libgretl's automatic
compounding of a "--unit" style restriction with a regular
--restrict. It works fine if you compound them manually in a single
command:
? smpl $unit == 5 and dates < 20010101 --restrict
Full data set: 1708 observations
Current sample: 40 observations
But anyway, you're right, more work is needed in this area.
Allin