11:34 a.m.
Hello,
I have several measures of volatility v1, v2, v3 and their 5-day and 22-day averages
(v1_5, v1_22, etc.) loaded into the session. What I would like is to write a loop over the
explained and explanatory variables so that I have one code for OLS estimation into which
I just feed different data. The pseudocode should look something like this
strings explainedVars = array(3)
explainedVars[1] = "v1"
explainedVars[2] = "v2"
explainedVars[3] = "v3"
strings explanatoryVars = array(9)
explanatoryVars[1] = "v1(-1)"
explanatoryVars[2] = "v1_5(-1)"
explanatoryVars[3] = "v1_22(-1)"
...
explanatoryVars[9] = "v3_22(-1)"
loop i = 1 to 3
loop j = 1 to 9
ols explainedVars[i] explanatoryVars[j]
endloop
endloop
The OLS line is the one that is not working for me, I do not know how to tell the
estimation command that the string explainedVars[i] should be taken as a series name. The
problem is naturally a simplified version of the real problem.
Any help is much appreciated,
Daniel
12:28 p.m.
On Fri, 26 Dec 2014, Daniel Bencik wrote:
I have several measures of volatility v1, v2, v3 and their 5-day and
22-day
averages (v1_5, v1_22, etc.) loaded into the session. What I would like is to
write a loop over the explained and explanatory variables so that I have one
code for OLS estimation into which I just feed different data. The pseudocode
should look something like this
strings explainedVars = array(3)
explainedVars[1] = "v1"
explainedVars[2] = "v2"
explainedVars[3] = "v3"
strings explanatoryVars = array(9)
explanatoryVars[1] = "v1(-1)"
explanatoryVars[2] = "v1_5(-1)"
explanatoryVars[3] = "v1_22(-1)"
...
explanatoryVars[9] = "v3_22(-1)"
loop i = 1 to 3
loop j = 1 to 9
ols explainedVars[i] explanatoryVars[j]
endloop
endloop
The OLS line is the one that is not working for me, I do not know how to tell
the estimation command that the string explainedVars[i] should be taken as a
series name. The problem is naturally a simplified version of the real
problem.
Arrays of strings are not the right tool for the job here; you should
use lists. Suppose your "explainedVars" are all put in a list named Y
and your "explanatoryVars" in a list named X. Then this would do the
analysis:
<hansl>
loop foreach i Y -q
loop foreach j X -q
list reglist = Y[i] 0 X[j]
ols reglist
endloop
endloop
</hansl>
Allin Cottrell
2:37 p.m.
On Sun, 28 Dec 2014, Allin Cottrell wrote:
On Fri, 26 Dec 2014, Daniel Bencik wrote:
> I have several measures of volatility v1, v2, v3 and their 5-day and
> 22-day averages (v1_5, v1_22, etc.) loaded into the session. What I would
> like is to write a loop over the explained and explanatory variables so
> that I have one code for OLS estimation into which I just feed different
> data. [...]
Arrays of strings are not the right tool for the job here; you should use
lists. Suppose your "explainedVars" are all put in a list named Y and your
"explanatoryVars" in a list named X. Then this would do the analysis:
<hansl>
loop foreach i Y -q
loop foreach j X -q
list reglist = Y[i] 0 X[j]
ols reglist
endloop
endloop
</hansl>
The use of the variable "reglist" in the inner loop above ought to
be unnecessary, but up till now it has been required due to a little
bug in the interpreter. That's now fixed in CVS and snapshots, so
one can simply do
ols Y[i] 0 X[j]
in a construction such as the one shown above.
Allin Cottrell
3:14 p.m.
Am 28.12.2014 um 20:37 schrieb Allin Cottrell:
> Arrays of strings are not the right tool for the job here; you
should use
> lists. Suppose your "explainedVars" are all put in a list named Y and your
> "explanatoryVars" in a list named X. Then this would do the analysis:
>
> <hansl>
> loop foreach i Y -q
> loop foreach j X -q
> list reglist = Y[i] 0 X[j]
> ols reglist
> endloop
> endloop
> </hansl>
(Minor point: I have to say, putting both the LHS _and_ the RHS into one
single list for the ols command feels a little like an abuse of the
syntax and I'm surprised gretl's not complaining about wrong number of
arguments or something similar.)
The use of the variable "reglist" in the inner loop above ought to
be unnecessary, but up till now it has been required due to a little
bug in the interpreter. That's now fixed in CVS and snapshots, so
one can simply do
ols Y[i] 0 X[j]
This is interesting, I didn't know that indexing into a list like this
is possible. It doesn't seem to be documented, or is it?
According to what I've learned about the 'loop foreach' construction, I
would have done the following instead, which feels more natural to me:
ols $i 0 $j
cheers,
sven
3:34 p.m.
On Sun, 28 Dec 2014, Sven Schreiber wrote:
Am 28.12.2014 um 20:37 schrieb Allin Cottrell:
>> Arrays of strings are not the right tool for the job here; you should use
>> lists. Suppose your "explainedVars" are all put in a list named Y and
your
>> "explanatoryVars" in a list named X. Then this would do the analysis:
>>
>> <hansl>
>> loop foreach i Y -q
>> loop foreach j X -q
>> list reglist = Y[i] 0 X[j]
>> ols reglist
>> endloop
>> endloop
>> </hansl>
(Minor point: I have to say, putting both the LHS _and_ the RHS into one
single list for the ols command feels a little like an abuse of the
syntax and I'm surprised gretl's not complaining about wrong number of
arguments or something similar.)
Internally, all of gretl's basic estimation commands accept a single
list argument for the regression specification. For the user doc we
split this into "dependent variable" plus "independent variables"
but supplying a single named list is OK.
> The use of the variable "reglist" in the inner loop
above ought to
> be unnecessary, but up till now it has been required due to a little
> bug in the interpreter. That's now fixed in CVS and snapshots, so
> one can simply do
>
> ols Y[i] 0 X[j]
This is interesting, I didn't know that indexing into a list like this
is possible. It doesn't seem to be documented, or is it?
It hasn't been available for very long. I'll have to check whether
it's actually documented.
According to what I've learned about the 'loop foreach'
construction, I
would have done the following instead, which feels more natural to me:
ols $i 0 $j
That will work, though it uses string substitution, which is
basically evil. (Note to self: I need to write an explanation of why
I really don't like string substitution and would like to get rid of
it if at all possible).
Allin
3:44 p.m.
Am 28.12.2014 um 21:34 schrieb Allin Cottrell:
On Sun, 28 Dec 2014, Sven Schreiber wrote:
Internally, all of gretl's basic estimation commands accept a single
list argument for the regression specification. For the user doc we
split this into "dependent variable" plus "independent variables"
but supplying a single named list is OK.
Ok let's see if I can remember this until I need it...
> According to what I've learned about the 'loop foreach' construction, I
> would have done the following instead, which feels more natural to me:
>
> ols $i 0 $j
That will work, though it uses string substitution, which is
basically evil. (Note to self: I need to write an explanation of why
I really don't like string substitution and would like to get rid of
it if at all possible).
This is a surprising statement -- in principle I absolutely agree and I
think I have expressed my mixed feelings about gretl's string handling
on various occasions over the years. I have stopped complaining in order
not to appear too annoying, and also have slowly grown used to it.
However, maybe you and Jack should have a private discussion about this,
because the user manual is full of such examples involving string
substitution, and then there's the quote "It’s amazing what string
substitution can do for you, isn’t it?" (from section 16.3 in the manual).
-sven
4:22 p.m.
On Sun, 28 Dec 2014, Sven Schreiber wrote:
However, maybe you and Jack should have a private discussion about
this,
because the user manual is full of such examples involving string
substitution, and then there's the quote "It’s amazing what string
substitution can do for you, isn’t it?" (from section 16.3 in the manual).
I remember writing that sentence. String substitution is a great thing in
scripting languages. As a heavy bash user, I absolutely love it. The
problem is, it makes it very difficult to optimise a language for speed
and efficiency.
-------------------------------------------------------
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
-------------------------------------------------------
4:45 p.m.
On Sun, 28 Dec 2014, Riccardo (Jack) Lucchetti wrote:
On Sun, 28 Dec 2014, Sven Schreiber wrote:
> However, maybe you and Jack should have a private discussion about this,
> because the user manual is full of such examples involving string
> substitution, and then there's the quote "It’s amazing what string
> substitution can do for you, isn’t it?" (from section 16.3 in the manual).
I remember writing that sentence. String substitution is a great thing in
scripting languages. As a heavy bash user, I absolutely love it. The problem
is, it makes it very difficult to optimise a language for speed and
efficiency.
Jack and I have discussed this at length and we're basically on the
same page. We're not going to snatch away something that many people
find very convenient, but I'm interested in exploring alternatives
to string substitution: this is the intent behind some recent
additions such as the genseries() function and the "setopt" command.
Allin
3571
days inactive
3573
days old
7 comments
4 participants
participants (4)
-
Allin Cottrell -
Daniel Bencik -
Riccardo (Jack) Lucchetti -
Sven Schreiber