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