On Thu, 6 Jan 2022, Sven Schreiber wrote: > Hi, > > it looks as if the panel-time information in the current dataset is lost > when: > > 1) a user-written hansl function is executed which internally plays > around with and repeatedly resets the sample > > 2) before calling that function, the current panel dataset is restricted > (in the time dimension) > > Symptom: trying to use $obsdata works before calling the function, but > yields an error "won't work with the current periodicity". But $pd and > $datatype still work correctly. > > Workaround: re-issue the setobs command after execution of the hansl > function, in my case: "setobs 4 1991:1 --panel-time" > > Or to formulate my hypothesis differently: it seems that on exit from > the function, gretl somehow forgets to reinstate the previous panel time > properties when it reconstructs the state of the dataset that prevailed > at the time of calling the function. I believe that the problem didn't > show up for me when I was previously working with a dataset which was > *not* restricted at the outer level. So the sample restriction appears > to play a role. If you could devise a minimal case in point that would be helpful.

On Fri, 7 Jan 2022, Sven Schreiber wrote: > Am 07.01.2022 um 03:41 schrieb Allin Cottrell: >> On Thu, 6 Jan 2022, Sven Schreiber wrote: >> >>> it looks as if the panel-time information in the current dataset is lost >>> when: >>> >>> 1) a user-written hansl function is executed which internally plays >>> around with and repeatedly resets the sample >>> >>> 2) before calling that function, the current panel dataset is restricted >>> (in the time dimension)

Thanks. I see what you mean. We simply don't have apparatus in place at present to handle modification and restoration of "panel time" information across calls to functions. I don't have time to work on this right now, but it seems like something that ought to be fixed when somebody has the time to do so.