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
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
-------------------------------------------------------
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                8 years, 1 month
                        
                        
                 
         
 
        
            
        
        
        
                
                        
                                
                                 
                                        
                                
                         
                        
                                
                                
                                        
                                                
                                        
                                        
                                        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
                                
                         
                        
                                
                                8 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
                                
                         
                        
                                
                                8 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
                                
                         
                        
                                
                                8 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
                                
                         
                        
                                
                                8 years, 1 month