9:53 a.m.
Happy new year!
Is there a recommended way to automatically (i.e., in a script) save the automatically
generated string-table to a) an icon in the session b) a file in the (script's)
working directory? Perhaps via an optional command to 'open' ?
In my case I read a Stata data file and Gretl automatically converts string variables to
numericals, saving the table to the temporary Gretl directory and opening it. I can
manually do the saving, but I'd like to automate it so that if someone else runs the
script, the strings-table is generated right away and stored accordingly.
Best
Frederik
2:04 a.m.
Good question. We'll look into it (possibly with a slight delay owing
to holidays!)
Allin
On Wed, Jan 2, 2019 at 1:50 PM Frederik.Schaff(a)ruhr-uni-bochum.de
<Frederik.Schaff(a)ruhr-uni-bochum.de> wrote:
Happy new year!
Is there a recommended way to automatically (i.e., in a script) save the automatically
generated string-table to a) an icon in the session b) a file in the (script’s) working
directory? Perhaps via an optional command to ‘open’ ?
In my case I read a Stata data file and Gretl automatically converts string variables to
numericals, saving the table to the temporary Gretl directory and opening it. I can
manually do the saving, but I’d like to automate it so that if someone else runs the
script, the strings-table is generated right away and stored accordingly.
Best
Frederik
8:43 a.m.
Am 03.01.2019 um 03:04 schrieb Cottrell, Allin:
On Wed, Jan 2, 2019 at 1:50 PM Frederik.Schaff(a)ruhr-uni-bochum.de
<Frederik.Schaff(a)ruhr-uni-bochum.de> wrote:
>
> Happy new year!
>
> Is there a recommended way to automatically (i.e., in a script) save the
automatically generated string-table to a) an icon in the session b) a file in the
(script’s) working directory? Perhaps via an optional command to ‘open’ ?
Hi, but what do you need the string table for? I find that chapter 15 of
the guide explains how to see the numeric codes for the strings (print
city --byobs --numeric) and that you can access them apparently as a
vector with curly braces ({city}).
From that you can re-build your string table if needed. Also I see in
that chapter that if you copy the string series you get the numeric
codes (only) in the new series (series citycodes = city).
And finally there's the strvals() function which retrieves all the
string values in a series and puts them in a strings array.
Note that ten minutes ago I didn't know any of these things. I just
searched for "string table" in the user guide. I'm glad you asked the
question so I could learn a new aspect of gretl, so I'm not saying you
shouldn't have asked. I think such questions are perfectly OK. I just
want to point out (or repeat) that the documentation we have is really
in good shape.
cheers,
sven
10:33 a.m.
Thanks Sven. I took a look at it, but it doesn't help.
My case:
I followed an R-Script, where (because it is R) you can directly work with strings as
factors. Now, I want to load the data in Gretl and perform some similar analysis there.
Gretl converts the strings to numerics. In some cases, it keeps them (individual codes)
but not if they are factors. For example, country names are changed to numerical factors.
I cannot find this information in the new Gretl data-set. From the log, this corresponds
to:
A minimum working example:
You may try with the following Data Set from Gesis:
(ZA3778: EVS - European Values Study 1999 - Germany)
https://dbk.gesis.org/dbksearch/download.asp?db=E&id=50392
In this case, after opening it with Gretl, the version number is transformed and the
string is stored (double klick the variable to see it). But for all the (factorial) items
from the questionary, only the new code is saved, the mapping is only visible in the
string_table.
Best
Frederik
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu <gretl-users-bounces(a)lists.wfu.edu> On
Behalf Of Sven Schreiber
Sent: Donnerstag, 3. Januar 2019 09:44
To: gretl-users(a)lists.wfu.edu
Subject: Re: [Gretl-users] script: open Stata data file - save string-table
Am 03.01.2019 um 03:04 schrieb Cottrell, Allin:
On Wed, Jan 2, 2019 at 1:50 PM Frederik.Schaff(a)ruhr-uni-bochum.de
<Frederik.Schaff(a)ruhr-uni-bochum.de> wrote:
>
> Happy new year!
>
> Is there a recommended way to automatically (i.e., in a script) save the
automatically generated string-table to a) an icon in the session b) a file in the
(script’s) working directory? Perhaps via an optional command to ‘open’ ?
Hi, but what do you need the string table for? I find that chapter 15 of the guide
explains how to see the numeric codes for the strings (print city --byobs --numeric) and
that you can access them apparently as a vector with curly braces ({city}).
From that you can re-build your string table if needed. Also I see in that chapter that
if you copy the string series you get the numeric codes (only) in the new series (series
citycodes = city).
And finally there's the strvals() function which retrieves all the string values in a
series and puts them in a strings array.
Note that ten minutes ago I didn't know any of these things. I just searched for
"string table" in the user guide. I'm glad you asked the question so I could
learn a new aspect of gretl, so I'm not saying you shouldn't have asked. I think
such questions are perfectly OK. I just want to point out (or repeat) that the
documentation we have is really in good shape.
cheers,
sven
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
10:47 a.m.
Am 03.01.2019 um 11:33 schrieb Schaff, Frederik:
Thanks Sven. I took a look at it, but it doesn't help.
My case:
I followed an R-Script, where (because it is R) you can directly work with strings as
factors. Now, I want to load the data in Gretl and perform some similar analysis there.
Gretl converts the strings to numerics. In some cases, it keeps them (individual codes)
but not if they are factors.
I'm not sure I understand what you mean by "factor" in this context.
For example, country names are changed to numerical factors. I cannot
find this information in the new Gretl data-set. From the log, this corresponds to:
A minimum working example:
You may try with the following Data Set from Gesis:
(ZA3778: EVS - European Values Study 1999 - Germany)
https://dbk.gesis.org/dbksearch/download.asp?db=E&id=50392
Sounds like an interesting example, but the link isn't open. Could you
post some excerpt perhaps?
thanks,
sven
12:27 p.m.
Am 03.01.2019 um 11:47 schrieb Sven Schreiber:
Am 03.01.2019 um 11:33 schrieb Schaff, Frederik:
For example, country names are changed to numerical factors. I cannot
find this information in the new Gretl data-set. From the log, this
corresponds to:
> A minimum working example:
> You may try with the following Data Set from Gesis:
> (ZA3778: EVS - European Values Study 1999 -
Germany)https://dbk.gesis.org/dbksearch/download.asp?db=E&id=50392
Sounds like an interesting example, but the link isn't open. Could you
post some excerpt perhaps?
thanks,
(Frederik sent me the file off-list in the meantime.)
OK, I see what you mean. However, it seems to me that the variables that
you are referring to aren't really string series in the Stata source
file. Notice the double explanation in gretl's string table at the top
-- first it says "at least one non-numeric variable", then it says
"furthermore some mappings from numerical values to labels were found
which are printed below" [re-translated from German here].
Now, if you look at the variable called "version", gretl reports a
"String/Code" table and that works alright, as you've said already. (In
German: "Zeichenketten / Code -Tabelle")
BUT: For variable "caseno" gretl reports something else in English
(perhaps this string isn't marked for translation yet in the sources):
"Value -> label mappings". For example -5 is mapped to 'other
missing'.
Actually, it happens that these codes never really appear as values in
this series, but this is just a special case I think.
So I believe the original series is numeric in Stata's file, and that's
why it is imported as numeric. Stata itself would use the value/label
mappings to display the values' string codes I guess.
If I'm correct, in the end your question then seems to be a (valid)
feature request: On importing Stata files with value/label mappings, can
this meta information be retrieved somehow in a structured way. But it
doesn't have to do with string-valued series I think.
Let's see what Allin has to say about that, but in general I suggest to
file a ticket on the feature request tracker. Right now I don't have a
solution with gretl. Perhaps there exist some other tools to query the
meta information of a Stata data file.
cheers,
sven
12:35 p.m.
Am 03.01.2019 um 11:47 schrieb Sven Schreiber:
Am 03.01.2019 um 11:33 schrieb Schaff, Frederik:
For example, country names are changed to numerical factors. I cannot find this
information in the new Gretl data-set. From the log, this corresponds to:
A minimum working example:
You may try with the following Data Set from Gesis:
(ZA3778: EVS - European Values Study 1999 - Germany)
https://dbk.gesis.org/dbksearch/download.asp?db=E&id=50392
Sounds like an interesting example, but the link isn't open. Could you post some
excerpt perhaps?
thanks,
(Frederik sent me the file off-list in the meantime.)
OK, I see what you mean. However, it seems to me that the variables that you are referring
to aren't really string series in the Stata source file. Notice the double explanation
in gretl's string table at the top -- first it says "at least one non-numeric
variable", then it says "furthermore some mappings from numerical values to
labels were found which are printed below" [re-translated from German here].
Now, if you look at the variable called "version", gretl reports a
"String/Code" table and that works alright, as you've said already. (In
German: "Zeichenketten / Code -Tabelle")
BUT: For variable "caseno" gretl reports something else in English (perhaps this
string isn't marked for translation yet in the sources): "Value -> label
mappings". For example -5 is mapped to 'other missing'.
Actually, it happens that these codes never really appear as values in this series, but
this is just a special case I think.
So I believe the original series is numeric in Stata's file, and that's why it is
imported as numeric. Stata itself would use the value/label mappings to display the
values' string codes I guess.
If I'm correct, in the end your question then seems to be a (valid) feature request:
On importing Stata files with value/label mappings, can this meta information be retrieved
somehow in a structured way. But it doesn't have to do with string-valued series I
think.
Let's see what Allin has to say about that, but in general I suggest to file a ticket
on the feature request tracker. Right now I don't have a solution with gretl. Perhaps
there exist some other tools to query the meta information of a Stata data file.
cheers,
sven
For example, with R you get the information right away. R imports the data in its own data
field type. I agree, it seems to be a feature request then. As it seems to be a special
request, I would not open a ticket for it, if no one else sees a need for this feature.
Best
Frederik
1:09 p.m.
Am 03.01.2019 um 13:35 schrieb Schaff, Frederik:
For example, with R you get the information right away. R imports the
data in its own data field type. I agree, it seems to be a feature
request then. As it seems to be a special request, I would not open a
ticket for it, if no one else sees a need for this feature.
There's no harm in opening a ticket, as this is not a guarantee it will
be implemented. It just serves to be reminded of it.
The thing is, gretl already reads this information alright, so it
wouldn't be a whole new thing. However, the question is how to store
that information, because essentially it amounts to having different
categories of missings, which gretl doesn't have. String-valued series
are not the answer, because the majority of values in those imported
series are numeric and must be interpreted as such.
In principle one needs some nested bundles I guess (not an array of
bundles though).
Also you have to watch out that the codes like -5, -1 etc. in your
series are not to be treated as regular numbers in the econometrics.
Some conceptual thinking needed I guess.
cheers,
sven
6:29 p.m.
Am 03.01.2019 um 14:09 schrieb Sven Schreiber:
Am 03.01.2019 um 13:35 schrieb Schaff, Frederik:
>
> For example, with R you get the information right away. R imports the
> data in its own data field type. I agree, it seems to be a feature
> request then. As it seems to be a special request, I would not open a
> ticket for it, if no one else sees a need for this feature.
>
There's no harm in opening a ticket, as this is not a guarantee it will
be implemented. It just serves to be reminded of it.
Actually I just realized that in section 15.5 of the guide there is
already something very similar in terms of description of this missing
feature (referring to Stata files and the value labels):
"We could check such variables [meaning the labels AFAICS] and import
them as string-valued series if they satisfy the criteria stated in
section 15.2 but we don’t at present."
The thing is, gretl already reads this information alright, so it
wouldn't be a whole new thing. However, the question is how to store
that information, because essentially it amounts to having different
categories of missings, which gretl doesn't have. String-valued series
are not the answer, because the majority of values in those imported
series are numeric and must be interpreted as such.
In principle one needs some nested bundles I guess
The above comment in the guide inspires a different approach to store
those labels, namely as a companion string-valued series, possibly like
in this example (monospaced font best here):
Stata's value-label mapping (readable from the original file):
-1 -> no answer
-3 -> not applicable
Implied series pair:
original_var gretl_label_series
1998 NA
-1 "no answer"
2001 NA
1996 NA
-3 "not applicable"
Then you could for example restrict the sample with the help of
ok(gretl_label_series), or you could set to missing (NA) all the values
in original_var which have a label in the companion gretl_label_series.
In principle it would already be doable I guess by capturing the output
from 'open' in a buffer string (with outfile ... --buffer), and working
on that. But it would be complicated and error-prone.
cheers,
sven
1939
days inactive
1940
days old
8 comments
4 participants
participants (4)
-
Cottrell, Allin -
Frederik.Schaff＠ruhr-uni-bochum.de -
Schaff, Frederik -
Sven Schreiber