11:43 a.m.
Hello
I appreciate very much that db.nomics and gretl was able to handle the
new access to the data published by OECD.
When using the menu in gretl (file>databases>dbnomics) I get all series
I want.
But when using the command in a gretl script e.g. "data
OECD/DSD_PRICES(a)DF_PRICES_ALL/AUT.M.N.CPI.PD._T.N.GOY" gretl does not
like the @.
The other way around It works fine with
provider = "OECD"
database = "DSD_PRICES@DF_PRICES_ALL"
bundle spec = defbundle("mask","AUT.M.N.CPI.PD._T.N.GOY")
bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
dbnomics_bundles_print(bs)
list X = dbnomics_bundles_to_list( bs, "series_code" )
printf "\nHere are the series in list X:\n"
list X print
but surprisingly the bundl request does not work with all data, for
instance not for
provider = "OECD"
database = "DSD_IMTS@DF_IMTS"
bundle spec = defbundle("mask","DNK.W.X.C.M.XDC.Y.N")
bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
dbnomics_bundles_print(bs)
list X = dbnomics_bundles_to_list( bs, "series_code" )
printf "\nHere are the series in list X:\n"
list X print
Are there ways to solve it?
Thank you very much
Klaus
4:18 p.m.
Am 04.11.2024 um 12:43 schrieb klaus.hasenbach(a)web.de:
Hello
I appreciate very much that db.nomics and gretl was able to handle the
new access to the data published by OECD.
When using the menu in gretl (file>databases>dbnomics) I get all series
I want.
But when using the command in a gretl script e.g. "data
OECD/DSD_PRICES(a)DF_PRICES_ALL/AUT.M.N.CPI.PD._T.N.GOY" gretl does not
like the @.
The other way around It works fine with
Sorry for a stupid question, but since you
have a failing and a working
example, how do you know that it's the @ character that is causing the
problem? Is this a known problem from the past?
but surprisingly the bundl request does not work with all data, for
instance not for
provider = "OECD"
database = "DSD_IMTS@DF_IMTS"
bundle spec = defbundle("mask","DNK.W.X.C.M.XDC.Y.N")
bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
I can confirm the problem, but right now that's all, sorry.
cheers
sven
10:26 p.m.
Thanks for the report, Klaus. My reactions:
* '@' is treated specially on the gretl command-line: it calls for
string substitution. So I'm not surprised that OECD's revising their
identifiers to include '@' in some cases (which seems to me a bit
goofy) has caused trouble. But in gretl git there's now a workaround
for that: we recognize '@' as simply a literal character in the
context of the "data" command when the command "open dbnomics" has
been issued. This change will be in gretl snapshots tomorrow.
* On the two examples you give of scripted calls to
dbnomics_get_multiple() below: I get correct results in the first case
(as you do) but I can't replicate a problem in the second case where
you say "the request does not work". Here's my full script:
<hansl>
clear
set verbose off
include dbnomics.gfn
nulldata 836
setobs 12 1955:01
provider = "OECD"
database = "DSD_IMTS@DF_IMTS"
bundle spec = defbundle("mask", "DNK.W.X.C.M.XDC.Y.N")
bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
dbnomics_bundles_print(bs)
list X = dbnomics_bundles_to_list( bs, "series_code" )
printf "\nHere are the series in list X:\n"
list X print
</hansl>
Running this I get:
<output>
Contents of bs:
Provider Code Description
1: OECD/DSD_IMTS@DF_IMTS DNK_W_X_C_M_XDC_Y_N Denmark – World –
Exports – Commoditi... 836 observations (pd = 12) [1955-01:2024-08]
Here are the series in list X:
DNKWXCMXDCYN
</output>
Allin Cottrell
On Mon, Nov 4, 2024 at 6:43 AM klaus.hasenbach(a)web.de
<klaus.hasenbach(a)web.de> wrote:
>
> Hello
>
> I appreciate very much that db.nomics and gretl was able to handle the
> new access to the data published by OECD.
> When using the menu in gretl (file>databases>dbnomics) I get all series
> I want.
>
> But when using the command in a gretl script e.g. "data
> OECD/DSD_PRICES(a)DF_PRICES_ALL/AUT.M.N.CPI.PD._T.N.GOY" gretl does not
> like the @.
>
> The other way around It works fine with
>
> provider = "OECD"
> database = "DSD_PRICES@DF_PRICES_ALL"
> bundle spec = defbundle("mask","AUT.M.N.CPI.PD._T.N.GOY")
> bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
> dbnomics_bundles_print(bs)
> list X = dbnomics_bundles_to_list( bs, "series_code" )
> printf "\nHere are the series in list X:\n"
> list X print
>
> but surprisingly the bundl request does not work with all data, for
> instance not for
>
> provider = "OECD"
> database = "DSD_IMTS@DF_IMTS"
> bundle spec = defbundle("mask","DNK.W.X.C.M.XDC.Y.N")
> bs = dbnomics_get_multiple(provider, database, 1000, 0, spec)
> dbnomics_bundles_print(bs)
> list X = dbnomics_bundles_to_list( bs, "series_code" )
> printf "\nHere are the series in list X:\n"
> list X print
>
> Are there ways to solve it?
>
> Thank you very much
> Klaus
6:31 a.m.
On 04/11/2024 23:26, Cottrell, Allin wrote:
Thanks for the report, Klaus. My reactions:
* '@' is treated specially on the gretl command-line: it calls for
string substitution. So I'm not surprised that OECD's revising their
identifiers to include '@' in some cases (which seems to me a bit
goofy) has caused trouble. But in gretl git there's now a workaround
for that: we recognize '@' as simply a literal character in the
context of the "data" command when the command "open dbnomics" has
been issued. This change will be in gretl snapshots tomorrow.
Uhm, are we sure we want this?
I mean, in theory one could use string substitution in a gretl script to
obtain the desired results.
Maybe we could introduce some sort of "escaping" rule, or a "set"
variable with the same effect of \makeatletter and \makeatother in LaTeX.
-------------------------------------------------------
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:41 a.m.
Am 05.11.2024 um 07:31 schrieb Riccardo (Jack) Lucchetti:
On 04/11/2024 23:26, Cottrell, Allin wrote:
> Thanks for the report, Klaus. My reactions:
>
> * '@' is treated specially on the gretl command-line: it calls for
> string substitution. So I'm not surprised that OECD's revising their
> identifiers to include '@' in some cases (which seems to me a bit
> goofy) has caused trouble. But in gretl git there's now a workaround
> for that: we recognize '@' as simply a literal character in the
> context of the "data" command when the command "open dbnomics"
has
> been issued. This change will be in gretl snapshots tomorrow.
Uhm, are we sure we want this?
I mean, in theory one could use string substitution in a gretl script
to obtain the desired results.
Good point.
Also loosely related, during my little testing it seemed that you cannot
use a quoted string (and probably not a string variable?) with the
'data' command. Maybe that would be good to have?
thanks
sven
3:41 p.m.
On Tue, 5 Nov 2024, Riccardo (Jack) Lucchetti wrote:
On 04/11/2024 23:26, Cottrell, Allin wrote:
> Thanks for the report, Klaus. My reactions:
>
> * '@' is treated specially on the gretl command-line: it calls
> for string substitution. So I'm not surprised that OECD's
> revising their identifiers to include '@' in some cases (which
> seems to me a bit goofy) has caused trouble. But in gretl git
> there's now a workaround for that: we recognize '@' as simply a
> literal character in the context of the "data" command when the
> command "open dbnomics" has been issued. This change will be in
> gretl snapshots tomorrow.
Uhm, are we sure we want this?
Actually, yes. What I did was right but I messed up on the
explanation. Let me try again.
First, when we encounter '@' in pre-processing a gretl command we
check if there's a portion of the input string immediately to the
right that names a string variable, and if so we substitute the
value of that variable, otherwise we leave the '@' alone. That is
unchanged.
Second, when it comes to executing the command we check for
instances of "undigested" '@'. In general these will be erroneous,
since '@' doesn't occur in gretl command words, function names,
variable names or punctuation. However, '@' could obviously occur
legitimately in a string literal. Up till now our policy has been to
reject undigested '@' in all contexts other than string literals.
What's new in git is that we also make an exception for the argument
to the "data" command when it follows "open dbnomics".
The net result is that all these variants now work:
<hansl>
open dbnomics
# standard version
data OECD/DSD_PRICES(a)DF_PRICES_ALL/AUT.M.N.CPI.PD._T.N.GOY
# using a string variable for the whole request
string dbreq = "OECD/DSD_PRICES(a)DF_PRICES_ALL/AUT.M.N.CPI.PD._T.N.GOY"
data @dbreq
# using a string variable for part of the request
string endbit = "T.N.GOY"
data OECD/DSD_PRICES@DF_PRICES_ALL/AUT.M.N.CPI.PD._@endbit
</hansl>
BTW, as Sven suggested, it might be good to accept a quoted argument
for "data" (since we now treat it as if it were quoted in the
dbnomics case). But I don't think that would give any additional
functionality.
Allin
48
days inactive
49
days old
5 comments
5 participants
participants (5)
-
Allin Cottrell -
Cottrell, Allin
-
klaus.hasenbach＠web.de -
Riccardo (Jack) Lucchetti -
Sven Schreiber