6:54 a.m.
Hi all,
I am bit puzzled about the following behaviour. Even though, the sample
is restricted to "t>3" obs. only, the strvals() function returns the
distinct string-values of series x of the full data set. Is this
intended, or a bug? I use latest git version on Ubuntu 19.04.
<hansl>
clear
set verbose off
nulldata 6 -p
genr time
series x = 1
smpl time > 3 --restrict
x = 2
smpl full
strings names = defarray("A", "B")
stringify(x, names)
eval strvals(x) # shows ["A", "B"]
smpl time > 3 --restrict
eval strvals(x) # still shows ["A", "B"]
</hansl>
Best,
Artur
8:19 a.m.
On Sat, 29 Feb 2020, Artur Tarassow wrote:
Hi all,
I am bit puzzled about the following behaviour. Even though, the sample is
restricted to "t>3" obs. only, the strvals() function returns the distinct
string-values of series x of the full data set. Is this intended, or a bug? I
use latest git version on Ubuntu 19.04.
<hansl>
clear
set verbose off
nulldata 6 -p
genr time
series x = 1
smpl time > 3 --restrict
x = 2
smpl full
strings names = defarray("A", "B")
stringify(x, names)
eval strvals(x) # shows ["A", "B"]
smpl time > 3 --restrict
eval strvals(x) # still shows ["A", "B"]
</hansl>
I would say that's intended, since the "strvals" are a property of the
data series, irrespective of the current sample selection. In your
particular case, the workaround "strvals(x)[values(x)]" after subsampling
works because values(x) turns out to be a scalar, but that would need to
be generalised, as the following example shows:
<hansl>
set seed 666
nulldata 20
x = randgen(i, 1, 6)
s = defarray("a", "b", "c", "d", "e",
"f")
stringify(x, s)
print x
eval strvals(x)
smpl 6 10
eval strvals(x)[values(x)]
</hansl>
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
8:42 a.m.
Am 29.02.2020 um 14:19 schrieb Riccardo (Jack) Lucchetti:
On Sat, 29 Feb 2020, Artur Tarassow wrote:
> I am bit puzzled about the following behaviour. Even though, the
> sample is restricted to "t>3" obs. only, the strvals() function
> returns the distinct string-values of series x of the full data set.
> Is this intended, or a bug?
I would say that's intended, since the "strvals" are a property of the
data series, irrespective of the current sample selection.
Actually I agree with Artur here: In gretl AFAIK any function that
operates on a series is about the currently active part in-sample.
Otherwise your argument could also be made for 'values', but that has
the behavior that Artur expected:
<hansl>
open denmark
eval nelem(values(LRM)) # 55
smpl +10 +0
eval nelem(values(LRM)) # 45
</hansl>
cheers
sven
1:32 p.m.
Am 29.02.20 um 14:42 schrieb Sven Schreiber:
Am 29.02.2020 um 14:19 schrieb Riccardo (Jack) Lucchetti:
> On Sat, 29 Feb 2020, Artur Tarassow wrote:
>
>> I am bit puzzled about the following behaviour. Even though, the
>> sample is restricted to "t>3" obs. only, the strvals() function
>> returns the distinct string-values of series x of the full data set.
>> Is this intended, or a bug?
> I would say that's intended, since the "strvals" are a property of the
> data series, irrespective of the current sample selection.
Actually I agree with Artur here: In gretl AFAIK any function that
operates on a series is about the currently active part in-sample.
Otherwise your argument could also be made for 'values', but that has
the behavior that Artur expected:
<hansl>
open denmark
eval nelem(values(LRM)) # 55
smpl +10 +0
eval nelem(values(LRM)) # 45
</hansl>
Thanks for your responses. We definitely need some decision on this.
Sven's 'values'-example also let me think that strvals() should
consider the current active sample. Let's hear what Allin has to add on
this ;-)
Artur
8:10 p.m.
On Sat, 29 Feb 2020, Riccardo (Jack) Lucchetti wrote:
On Sat, 29 Feb 2020, Artur Tarassow wrote:
> Hi all,
>
> I am bit puzzled about the following behaviour. Even though, the sample is
> restricted to "t>3" obs. only, the strvals() function returns the
distinct
> string-values of series x of the full data set. Is this intended, or a bug?
> I use latest git version on Ubuntu 19.04.
>
> <hansl>
> clear
> set verbose off
> nulldata 6 -p
> genr time
> series x = 1
> smpl time > 3 --restrict
> x = 2
> smpl full
>
> strings names = defarray("A", "B")
> stringify(x, names)
>
> eval strvals(x) # shows ["A", "B"]
> smpl time > 3 --restrict
> eval strvals(x) # still shows ["A", "B"]
> </hansl>
I would say that's intended, since the "strvals" are a property of
the data series, irrespective of the current sample selection.
I agree with Jack. It's inherent that strvals() gives access to a
property of an entire data series. If you have a use case for
obtaining the set of strings associated with the values of a string
variable over a particular sub-sample that can be done (left as an
exercise, but not a terribly difficult one), but it's not the job of
strvals().
Allin
1:43 a.m.
Am 01.03.2020 um 02:10 schrieb Allin Cottrell:
On Sat, 29 Feb 2020, Riccardo (Jack) Lucchetti wrote:
> On Sat, 29 Feb 2020, Artur Tarassow wrote:
>
> I would say that's intended, since the "strvals"
are a property of the
> data series, irrespective of the current sample selection.
I agree with Jack. It's inherent that strvals() gives access to a
property of an entire data series. If you have a use case for obtaining
the set of strings associated with the values of a string variable over
a particular sub-sample that can be done (left as an exercise, but not a
terribly difficult one), but it's not the job of strvals().
OK, I'm noting that 'stringify' indeed also always seems to work on the
entire series. Besides, 'firstobs' and 'lastobs' have an explicit switch
for that.
But I still think it's surprising, given the behavior of the majority of
gretl functions, so it should be documented, for example like in the
'obs' doc: "Note that the result is invariant to subsampling."
(Yes I could do that if there are no objections.)
thanks
sven
9:54 a.m.
Am 01.03.20 um 07:43 schrieb Sven Schreiber:
Am 01.03.2020 um 02:10 schrieb Allin Cottrell:
> On Sat, 29 Feb 2020, Riccardo (Jack) Lucchetti wrote:
>
>> On Sat, 29 Feb 2020, Artur Tarassow wrote:
>>
>> I would say that's intended, since the "strvals" are a property of
the
>> data series, irrespective of the current sample selection.
>
> I agree with Jack. It's inherent that strvals() gives access to a
> property of an entire data series. If you have a use case for obtaining
> the set of strings associated with the values of a string variable over
> a particular sub-sample that can be done (left as an exercise, but not a
> terribly difficult one), but it's not the job of strvals().
Thanks for clarification of this.
OK, I'm noting that 'stringify' indeed also always seems
to work on the
entire series. Besides, 'firstobs' and 'lastobs' have an explicit switch
for that.
But I still think it's surprising, given the behavior of the majority of
gretl functions, so it should be documented, for example like in the
'obs' doc: "Note that the result is invariant to subsampling."
Good idea!
Best,
Artur
7:55 a.m.
Am 01.03.2020 um 15:54 schrieb Artur Tarassow:
Am 01.03.20 um 07:43 schrieb Sven Schreiber:
>
> OK, I'm noting that 'stringify' indeed also always seems to work on the
> entire series. Besides, 'firstobs' and 'lastobs' have an explicit
switch
> for that.
>
> But I still think it's surprising, given the behavior of the majority of
> gretl functions, so it should be documented, for example like in the
> 'obs' doc: "Note that the result is invariant to subsampling."
Good idea!
I see that Allin (?) beat me to it such that it's in 2020a already!
cheers
sven
1713
days inactive
1723
days old
7 comments
4 participants
participants (4)
-
Allin Cottrell -
Artur Tarassow -
Riccardo (Jack) Lucchetti -
Sven Schreiber