two small issues
by Sven Schreiber
Hi,
the first:
<hansl>
open data9-3.gdt
matrix check = {1;2}
series x = (price > 3) ? check[1] : check[2] # fails
</hansl>
A 1x1 matrix apparently is not allowed here. (If I do 'scalar s =
check[1]' first, then it runs.)
The second "issue":
eval pi # works
Not sure if 'pi' is supposed to be an alias for '$pi'. For me 'pi' was a
typo and the fact that it didn't fail caused another bug that was a bit
difficult to track down.
thanks,
sven
9 years
refinement to export to R
by Riccardo (Jack) Lucchetti
I was thinking that we might want to map what we call "discrete" series
into what R calls "factors". The idea is quite simple, and exemplified in
the script below. My question to the list is: is this a good idea? Is it
worth the coding effort (very small IMO)?
Comments welcome.
<hansl>
nulldata 50
cont1 = normal()
cont2 = normal()
disc1 = floor(uniform(1,5))
disc2 = floor(uniform(4,18))
discrete disc1 disc2
list D = dataset
loop foreach i D
if !isdiscrete($i)
D -= $i
endif
endloop
matrix mD = D
mwrite(mD, "discrete.mat", 1)
foreign language=R --send-data
D <- gretl.loadmat("discrete.mat");
for (i in D) {gretldata[,i] <- as.factor(gretldata[,i])};
summary(gretldata);
end foreign
</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
-------------------------------------------------------
9 years
Bug (?) in hi-freq lag counting of midas
by Sven Schreiber
Hi,
I think a midasreg with a 'mdsl' term may get the included lags wrong in
the information that is printed in the output.
For example, as a benchmark I have the following (shortened) line:
midasreg dep ... ; ... mds(dO, 2,3 , 2, theta)
So my high-frequency lags of dO go from 2 to 3, and indeed gretl tells
me just that in the output:
MIDAS list dO, high-frequency lags 2 to 3
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
Fine -- I know there are numerical problems here but that's not the
issue right now. I can get the same result by defining a lag list dOL
with hi-freq lags 2 to 3, and then using mdsl:
midasreg dep...; ... mdsl(dOL, 2, theta)
This produces the same result numerically which makes me confident that
I defined the dOL list correctly; however, gretl no tells me the lags
would be from 1 to 2 instead:
MIDAS list dOL, high-frequency lags 1 to 2
HF_slope2 −1.78684e-05 1.97184e+010 0.0000 1.0000
Beta1 1.00000 1.22905e+030 0.0000 1.0000
Beta2 2.00000 1.22905e+030 0.0000 1.0000
So this looks like a off-by-one bug to me. (Latest snapshot BTW.)
Thanks,
sven
9 years
duplicate variables / error message
by Sven Schreiber
Hi,
I'm getting a "matrix not positive definite" error for the following
(wrong) command:
open denmark
var 3 LRM LRM LRY
The message is of course correct, but I'm wondering whether duplication
of terms should be caught by gretl -- note that gretl does that already
for the 'ols' command (e.g. try "ols LRM const LRY LRY").
Any other estimation commands that could be affected?
thanks,
sven
9 years
printf or errmsg bug
by Sven Schreiber
hi,
example:
<hansl>
catch ols # incomplete command
err = $error
if err
printf "%s", errmsg(err)
endif
</hansl>
As output I get "Befehl hat zu wenige Argumente? endif", so a spurious
'endif' printout at the end.
This is with a July snapshot, haven't checked more recent snapshots yet.
thanks,
sven
9 years
vif
by Sven Schreiber
Hi,
I just answered a gretl-related question about the variance inflation
factors on Stackexchange
(https://stats.stackexchange.com/questions/298612/why-is-variance-inflatio...).
When looking at the 'vif' command basically for the first time ever, my
first reaction was "why is this a command"? It would seem more natural
to call it with "modtest --vif" or something like that. (Although I
admit it wouldn't provide any p-values.)
Related, shouldn't there be a scripting way to access the output of vif
without doing the calculations manually?
cheers,
sven
9 years
Collection of gretl speed examples
by Sven Schreiber
Hi,
it has often been said that many people do not take gretl seriously as a
high-performance research tool.
Today Jack posted a file on the sourceforge tracker which runs some
comparison benchmarks. I am copying and attaching that file here. (For a
successful run you'll need to have R and Octave and Julia installed I
believe.)
Anyway, I thought that maybe we could jointly put together a gretl
working paper that would simply be a collection of speed comparisons
(code + result tables). The working title would be "Benchmarking the
speed of gretl".
I would be willing to coordinate the effort in the sense of testing the
codes, as well as putting together and editing (not writing!) the
corresponding text snippets. The idea is that everybody who contributes
at least one speed comparison between at least two programs (gretl and
another) will be a co-author. (But just the code is not enough, the
setup and results would have to be explained in a couple of paragraphs,
presumably with a result table.)
You could start sending the code + explanations immediately. Please
mention in the corresponding text snippets which versions of the
respective programs you have used and on which machine the benchmark was
run; possibly also what method you used to measure the computing time.
You can send to the list or to me directly off-list.
I cannot promise when that working paper will be ready, as it depends on
everybody. I'd say a minimal length would be roughly 10 typeset pages
before it would be released.
Hope you like the idea and have a good weekend,
Sven
9 years, 1 month
arma estimation performance on Atom with 64-bit OpenBLAS
by Allin Cottrell
I'm abstracting here from information provided by Oleh. He's
estimating an ARMAX model (ARMA with an exogenous regressor) using
current gretl snapshots for Windows, both 64-bit and 32-bit.
The relevant gretl commands are:
open phillips_aus.gdt # from the POE4 data collection
arma 1 1 ; inf 0 diff(u)
Trimming down Oleh's information gives these three cases:
1. host: DESKTOP-DE5ESQO, gretl in 64-bit mode, running Windows 10,
using OpenBLAS (64-bit) with Atom blascore
Function evaluations: 132
Evaluations of gradient: 22
Log-likelihood -62.75480
2. host: DESKTOP-DE5ESQO, gretl in 32-bit mode, running Windows 10,
using OpenBLAS (32-bit) with Atom blascore
Function evaluations: 52
Evaluations of gradient: 17
Log-likelihood -62.56261
3. host: HER-PC, gretl in 64-bit mode, running Windows 8
using OpenBLAS (64-bit) with Nehalem blascore
Function evaluations: 52
Evaluations of gradient: 17
Log-likelihood -62.56261
The important contrast is 32-bit gretl vs 64-bit gretl on Oleh's
DESKTOP-DE5ESQO, with an Intel "Atom"- or "Bay Trail"-type processor
(specifically Pentium N3540). As you can see, the 64-bit version is
performing badly: it takes a lot more iterations to achieve a worse
log-likelihood on the ARMAX problem.
Oleh's case 3 (Nehalem processor, 64-bit) is basically the same as
all cases I've seen on machines I'm running: it seems "right". And
case 2 is practically indistinguishable from case 3.
So what's wrong with 64-bit gretl on Atom, running Windows? I'm
assuming (perhaps wrongly) that this is an OpenBLAS issue, so I'll
try pursuing that further. But if anyone else is able to test on
Atom in 64-bit mode, or to contribute relevant knowledge, please do!
Allin
9 years, 1 month
strange behavior of arima on Windows 10
by oleg_komashko＠ukr.net
Dear all,
arima command gives somewhat inconsistent results:
1) estimates are different from ones on Ubuntu and Windows 8
2) estimates are different when there are more than one
call of the same model inside an user-specified function
To be more precise:
linux_2_arma.inp is the script to illustrate the problem
linux_2_arma_output was obtained on April's git on Ubuntu 16.10, 64
The results are the same as ones from 09.05 snapshot on Windows 8, 64
(linux_2_arma_output)
Output from 09.05 snapshot on Windows 10, 64 is in win10_try_res.txt
Also with --x12-arima option output on W-10 is ok
Oleh
9 years, 1 month
small issue with calling libsvm
by Artur T.
Dear all,
I am just experimenting with libsvm. Overall it works fine. However, see
below an example where calling the svm() function fails. I try to
provide an alternative epsilon value for an e-SV regression from the
matrix epsval but obtain the error:
<output>
Data types not conformable for operation
Error executing script: halting
> series yhat2 = svm(L, parms)
</output>
<hansl>
set verbose off
open sw_ch14.gdt
series infl = 400 * log(PUNEW/PUNEW(-1))
ntrain = 130
test1 = ntrain + 1
list L = infl LHUR(-1 to -3) infl(-1 to -3)
smpl L --no-missing
# works
bundle parms = defbundle("n_train", ntrain, "quiet", 1)
parms.kernel_type=2
parms.svm_type=3
parms.search=1
series yhat1 = svm(L, parms)
# doesn't work
matrix epsval = {0.5,1} # matrix of possible eps. values
bundle parms = defbundle("n_train", ntrain, "quiet", 1)
parms.kernel_type=2
parms.svm_type=3
parms.search=1
parms.epsilon=epsval[1] # error: doesnt recognize epsval[] as scalar
series yhat2 = svm(L, parms)
</hansl>
Best,
Artur
9 years, 1 month
