9:54 p.m.
Dear all,
The script below
illustrate the problem
Findings: extremely bad lnl
in comparison to --x-12-arima
zero values of the 2 last parameters
and gradients at all iterations
Strangely large scaling factor
Note that --x-12-arima gives
nice pol. roots and excellent Ljung-Box Q'
Also note that with the default $pd for
modtest --autocorr
obviously fails because zero df
open bad_data.gdt #attached
smpl 1 194
# note strange zeros for b[y_one] and b[y_two]
arima 3 0 0; 1 0 0; diff_series const y_one y_two
lnl1 = $lnl
modtest --autocorr 5
# compare
arima 3 0 0; 1 0 0; diff_series const y_one y_two --x-12-arima
lnl2 = $lnl
modtest --autocorr 5
eval lnl2 - lnl1
arima 3 0 0; 1 0 0; diff_series const y_one y_two --verbose
# Scaling y by 2.18989e+018 !!!
/*
Iteration 1: loglikelihood = -8292.74884180
Parameters: -2.8152e+016 0.65496 -0.090036 -0.16211 -0.44328 0.00000
0.00000
Gradients: 4.7608e-018 4.0881 1.2538 3.3817 -1.2644 0.00000
0.00000 (norm 7.59e-001)
Iteration 2: loglikelihood = -8292.71644305 (steplength = 0.0016)
Parameters: -2.8152e+016 0.66150 -0.088030 -0.15670 -0.44531 0.00000
0.00000
Gradients: 4.5624e-018 1.3507 -1.5003 1.0847 -1.4772 0.00000
0.00000 (norm 5.32e-001)
*/
#etc. etc
Oleh
12:33 p.m.
Scrub the redundant "const" and see what happens.
I
had scrubbed before the first message
I think this is because of 197 use only scaling
to mean(scaled_y) = 10 and does not use centering
That' why permanent problems when mean(y) ~o(10^-3 or 10^-4)
for models with consatnt
A more strange thing:
open bad_data.gdt
smpl 1 194
series sty=diff_series/sd(diff_series)
list zli = y_one y_two
y = sty+6.48001
arima 3 0 0; 1 0 0; y 0 zli
# ok
y = sty+6.47999
arima 3 0 0; 1 0 0; y 0 zli
# ok
y = sty+6.48
arima 3 0 0; 1 0 0; y 0 zli --verbose
/*
? arima 3 0 0; 1 0 0; y 0 zli --verbose
NLS: failed to converge after 1605 iterations
Error executing script: halting
arima 3 0 0; 1 0 0; y 0 zli --verbose
/*
This is very unexpected in several aspects
6.48 = (6.48001+6.47999)/2 so it is not special
--verbose is silent on iterations details
NLS: very unexpected substitute for 197
Oleh
26 жовтня 2018, 02:43:32, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Fri, 26 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear all,
The script below
illustrate the problem
Findings: extremely bad lnl
in comparison to --x-12-arima
Scrub the redundant "const" and see what happens.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:53 a.m.
New subject: a very strange case of arima (poor)convergence
On Fri, 26 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Scrub the redundant "const" and see what happens.
I had scrubbed before the first message
I think this is because of 197 use only scaling
to mean(scaled_y) = 10 and does not use centering
Weird as it may seem, the problem arises because of subsampling. if
TROUBLE == 1, the gradient is not computed correctly (as you can see from
the BFGS iterations).
<hansl>
open bad_data.gdt
TROUBLE = 0
if TROUBLE
smpl 1 194
endif
arima 3 0 0; 1 0 0; diff_series const y_one y_two --verbose
</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
-------------------------------------------------------
12:41 p.m.
New subject: a very strange case of arima (poor)convergence
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Fri, 26 Oct 2018, oleg_komashko(a)ukr.net wrote:
>> Scrub the redundant "const" and see what happens.
> I had scrubbed before the first message
>
> I think this is because of 197 use only scaling
> to mean(scaled_y) = 10 and does not use centering
Weird as it may seem, the problem arises because of subsampling. if TROUBLE
== 1, the gradient is not computed correctly (as you can see from the BFGS
iterations).
<hansl>
open bad_data.gdt
TROUBLE = 0
if TROUBLE
smpl 1 194
endif
arima 3 0 0; 1 0 0; diff_series const y_one y_two --verbose
</hansl>
Hmm, excluding the last 6 observations makes a huge difference to the
scaling factor applied to diff_series. I'll take a closer look when I
get time later today.
Allin
5:50 p.m.
New subject: a very strange case of arima (poor)convergence
Current scaling factor makes mean ~10
with 1 196 sample mean is ~10^-8
Hence, scaling factor ~10^18
provided sd was about 1
it will be huge and x1 and x2 becomes practically constants=> zero
caeffs
Use --x-12-arima
add 1, 10, 10^5 to dep var and compare results
--x-12-arima definitely use shifting
a good variant to use (y-mean(y))+1 and then restore const
in terms of original y
also desirable to standardize each x and then restore
everything in terms of original variables
Note that all z-statistics but for the one at const are invariant
Oleh
PS I do not know what do do with missing constant yet
28 жовтня 2018, 14:41:50, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Fri, 26 Oct 2018, oleg_komashko(a)ukr.net wrote:
>> Scrub the redundant "const" and see what happens.
> I had scrubbed before the first message
>
> I think this is because of 197 use only scaling
> to mean(scaled_y) = 10 and does not use centering
Weird as it may seem, the problem arises because of subsampling. if TROUBLE
== 1, the gradient is not computed correctly (as you can see from the BFGS
iterations).
<hansl>
open bad_data.gdt
TROUBLE = 0
if TROUBLE
smpl 1 194
endif
arima 3 0 0; 1 0 0; diff_series const y_one y_two --verbose
</hansl>
Hmm, excluding the last 6 observations makes a huge difference to the
scaling factor applied to diff_series. I'll take a closer look when I
get time later today.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
6:27 p.m.
New subject: a very strange case of arima (poor)convergence
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
Current scaling factor makes mean ~10
with 1 196 sample mean is ~10^-8
Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please
take a look.
-------------------------------------------------------
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
-------------------------------------------------------
6:52 p.m.
New subject: a very strange case of arima (poor)convergence
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Current scaling factor makes mean ~10
> with 1 196 sample mean is ~10^-8
> Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please take
a look.
As for the second problem, I guess the solution is quite easy but I'd wait
for Allin's opinion before committing any code to git.
In some cases, we initialise ARMA via NLS; however, we use NLS as if we
were estimating a "real" model, and therefore we employ our usual (rather
strict) convergence criterion. Of course, there's no need to be picky
about convergence, since nls is just meant to provide sensible starting
values. If you modify the nls_toler setting before running the arima
command, things go back to normal; example:
<hansl>
open bad_data.gdt
smpl 1 194
series sty=diff_series/sd(diff_series)
list zli = y_one y_two
set nls_toler 1.0e-5
y = sty+6.48
arima 3 0 0; 1 0 0; y 0 zli
</hansl>
Now the question is: should we raise NLS tolerance by default, when it's
used for ARMA initialisation, or do we have a better strategy?
-------------------------------------------------------
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
-------------------------------------------------------
10:07 p.m.
New subject: a very strange case of arima (poor)convergence
At last, I have known where
NLS diagnostics is from
Recall, this well specified model
with well behaved polynomial roots
and no autocorrelation
I hove, initial values are checked
and adjusted for roots to be outside
of the unit circle
Oleh
28 жовтня 2018, 20:52:10, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Current scaling factor makes mean ~10
> with 1 196 sample mean is ~10^-8
> Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please take
a look.
As for the second problem, I guess the solution is quite easy but I'd wait
for Allin's opinion before committing any code to git.
In some cases, we initialise ARMA via NLS; however, we use NLS as if we
were estimating a "real" model, and therefore we employ our usual (rather
strict) convergence criterion. Of course, there's no need to be picky
about convergence, since nls is just meant to provide sensible starting
values. If you modify the nls_toler setting before running the arima
command, things go back to normal; example:
<hansl>
open bad_data.gdt
smpl 1 194
series sty=diff_series/sd(diff_series)
list zli = y_one y_two
set nls_toler 1.0e-5
y = sty+6.48
arima 3 0 0; 1 0 0; y 0 zli
</hansl>
Now the question is: should we raise NLS tolerance by default, when it's
used for ARMA initialisation, or do we have a better strategy?
-------------------------------------------------------
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:58 p.m.
New subject: a very strange case of arima (poor)convergence
Hansl realization of exogenous variables transformations in arima
and some testing:
<hansl>
function void my_arima(string spec,
list y,
list xlist[null],
string opt[null])
list biglist = y xlist
#xxlist = xlist
smpl biglist --contiguous
bigtext = "arima "~spec~"; y"
bigtext2 = bigtext
nx = 0
matrix mxs = {}
matrix sdxs = {}
list zlist = null
if nelem(xlist)>0
iscst = inlist(xlist,const)
xlist = xlist - 0
nx = nelem(xlist)
matrix mxs = zeros(1,nx)
matrix sdxs = mxs
loop i = 1..nx -q
mi = mean(xlist[i])
sdi = sd(xlist[i])
vni = sprintf("oleh%d",i)
genseries(vni,(xlist[i] - mi)/sdi)
zlist+= @vni
mxs[i] = mi
sdxs[i] = sdi
endloop
if iscst
zlist = 0 zlist
xlist = 0 xlist
endif
bigtext = bigtext~" zlist"
bigtext2 = bigtext2~" xlist"
endif
if !isnull(opt)
opt = " "~strstrip(opt)
bigtext = bigtext~opt
bigtext2 = bigtext2~opt
endif
# original arima command
catch @bigtext2
err = $error
if err
em = errmsg(err)
printf "\n"
if strlen(em) == 0
print "traditional arima failed with empty errmsg(err)"
else
eval errmsg(err)
endif
printf "\n"
#print
else
matrix b0 = $coeff
lnl0 = $lnl
matrix se0 = $stderr
matrix z0 = b0./se0
endif
# arima command for transformed data
@bigtext
matrix b1 = $coeff
matrix z1 = b1./$stderr
# eval z1-z0
if nx>0
# restoring coeff and vcv for original data
nc = $ncoeff
difmat = I(nc)
b1[(nc-nx+1):] = b1[(nc-nx+1):]./sdxs'
loop i = 1..nx -q
difmat[(nc-nx+i),(nc-nx+i)] = 1/sdxs[i]
endloop
if iscst
matrix vec1 = b1[(nc-nx+1):]
b1[1]=b1[1]-mxs*vec1
difmat[1,(nc-nx+1):] = -mxs./sdxs
endif
#print difmat
#eval qform(difmat,$vcv)
matrix se1 = sqrt(diag(qform(difmat,$vcv)))
endif
# print sdxs
print "estimates, ses are under them:"
eval b1'
eval se1'
lnl1 = $lnl
printf "\n"
if !err
print "traditional estimates, ses are under them:"
eval b0'
eval se0'
printf "\n"
print "lnl1:"
eval lnl1
printf "\n"
print "difference in lnl (transformed - traditional):"
eval lnl1-lnl0
printf "\n"
print "difference in estimates:"
eval (b1-b0)'
printf "\n"
print "difference in ses:"
eval (se1-se0)'
else
printf "\nlnl = %g\n", lnl1
endif
end function
open bad_data.gdt
z10 = y_two+2
list zlic10 = 0 y_one z10
my_arima("3 0 0; 1 0 0",diff_series,zlic10,"-q")
arima 3 0 0; 1 0 0; diff_series zlic10 --x-12-arima -q
eval transp($coeff)
eval transp($stderr)
eval $lnl
z10 = y_two+4
list zlic10 = 0 y_one z10
my_arima("3 0 0; 1 0 0",diff_series,zlic10,"-q")
arima 3 0 0; 1 0 0; diff_series zlic10 --x-12-arima -q
eval transp($coeff)
eval transp($stderr)
eval $lnl
z10 = y_two+1000
list zlic10 = 0 y_one z10
my_arima("3 0 0; 1 0 0",diff_series,zlic10,"-q")
arima 3 0 0; 1 0 0; diff_series zlic10 --x-12-arima -q
eval transp($coeff)
eval transp($stderr)
eval $lnl
z10 = y_two+10000
list zlic10 = 0 y_one z10
my_arima("3 0 0; 1 0 0",diff_series,zlic10,"-q")
arima 3 0 0; 1 0 0; diff_series zlic10 --x-12-arima -q
eval transp($coeff)
eval transp($stderr)
eval $lnl
z10 = y_two+100000
list zlic10 = 0 y_one z10
my_arima("3 0 0; 1 0 0",diff_series,zlic10,"-q")
arima 3 0 0; 1 0 0; diff_series zlic10 --x-12-arima -q
eval transp($coeff)
eval transp($stderr)
eval $lnl
<hansl>
Oleh
28 жовтня 2018, 20:52:10, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Current scaling factor makes mean ~10
> with 1 196 sample mean is ~10^-8
> Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please take
a look.
As for the second problem, I guess the solution is quite easy but I'd wait
for Allin's opinion before committing any code to git.
In some cases, we initialise ARMA via NLS; however, we use NLS as if we
were estimating a "real" model, and therefore we employ our usual (rather
strict) convergence criterion. Of course, there's no need to be picky
about convergence, since nls is just meant to provide sensible starting
values. If you modify the nls_toler setting before running the arima
command, things go back to normal; example:
<hansl>
open bad_data.gdt
smpl 1 194
series sty=diff_series/sd(diff_series)
list zli = y_one y_two
set nls_toler 1.0e-5
y = sty+6.48
arima 3 0 0; 1 0 0; y 0 zli
</hansl>
Now the question is: should we raise NLS tolerance by default, when it's
used for ARMA initialisation, or do we have a better strategy?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti@univpm.ithttp://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
G
M
T
Detect
languageAfrikaansAlbanianAmharicArabicArmenianAzerbaijaniBasqueBelarusianBengaliBosnianBulgarianCatalanCebuanoChichewaChinese
(Simplified)Chinese
(Traditional)CorsicanCroatianCzechDanishDutchEnglishEsperantoEstonianFilipinoFinnishFrenchFrisianGalicianGeorgianGermanGreekGujaratiHaitian
CreoleHausaHawaiianHebrewHindiHmongHungarianIcelandicIgboIndonesianIrishItalianJapaneseJavaneseKannadaKazakhKhmerKoreanKurdishKyrgyzLaoLatinLatvianLithuanianLuxembourgishMacedonianMalagasyMalayMalayalamMalteseMaoriMarathiMongolianMyanmar
(Burmese)NepaliNorwegianPashtoPersianPolishPortuguesePunjabiRomanianRussianSamoanScots
GaelicSerbianSesothoShonaSindhiSinhalaSlovakSlovenianSomaliSpanishSundaneseSwahiliSwedishTajikTamilTeluguThaiTurkishUkrainianUrduUzbekVietnameseWelshXhosaYiddishYorubaZulu
AfrikaansAlbanianAmharicArabicArmenianAzerbaijaniBasqueBelarusianBengaliBosnianBulgarianCatalanCebuanoChichewaChinese
(Simplified)Chinese
(Traditional)CorsicanCroatianCzechDanishDutchEnglishEsperantoEstonianFilipinoFinnishFrenchFrisianGalicianGeorgianGermanGreekGujaratiHaitian
CreoleHausaHawaiianHebrewHindiHmongHungarianIcelandicIgboIndonesianIrishItalianJapaneseJavaneseKannadaKazakhKhmerKoreanKurdishKyrgyzLaoLatinLatvianLithuanianLuxembourgishMacedonianMalagasyMalayMalayalamMalteseMaoriMarathiMongolianMyanmar
(Burmese)NepaliNorwegianPashtoPersianPolishPortuguesePunjabiRomanianRussianSamoanScots
GaelicSerbianSesothoShonaSindhiSinhalaSlovakSlovenianSomaliSpanishSundaneseSwahiliSwedishTajikTamilTeluguThaiTurkishUkrainianUrduUzbekVietnameseWelshXhosaYiddishYorubaZulu
Text-to-speech function is limited to 200 characters
Options : History : Feedback : Donate Close
11:25 p.m.
New subject: a very strange case of arima (poor)convergence
I'm attaching a variant of the hansl code posted recently by Oleh,
which may be a little easier to understand than the original.
Summary: Oleh's hansl code standardizes a "difficult" exogenous
regressor in the arma context. His results are for the most part a
bit better than standard libgretl arma (though still not quite as
good as x13as).
The dataset used in Oleh's examples, bad_data.gdt, can be found
attached to his posting at
http://lists.wfu.edu/pipermail/gretl-devel/2018-October/009185.html
(see
http://lists.wfu.edu/pipermail/gretl-devel/attachments/20181026/da605227/...
)
For convenience, this dataset can now also be found at
http://ricardo.ecn.wfu.edu/pub/gretl/bad_data.gdt
Allin
4:55 p.m.
New subject: a very strange case of arima (poor)... new script
Dear Allin,
It seems that Riccardo implemented recently
not the same thing I proposed
So attached is arma_1() function which
realizes:
for y: (y-mean(y))/sd(y) + 1
for every x if any:
(x-mean(x))/sd(x)
In the sample the transformations applied twice:
for libgretl and for x-13
Hence 3 comparisons:
libretl based transformed and original libgretl
x-13 based transformed and original x-13
libretl based transformed and original x-13
Hopefully, this time your verdict would be
less humiliating
Oleh
31 жовтня 2018, 01:25:34, від "Allin Cottrell" <cottrell(a)wfu.edu>:
I'm attaching a variant of the hansl code posted recently by Oleh,
which may be a little easier to understand than the original.
Summary: Oleh's hansl code standardizes a "difficult" exogenous
regressor in the arma context. His results are for the most part a
bit better than standard libgretl arma (though still not quite as
good as x13as).
The dataset used in Oleh's examples, bad_data.gdt, can be found
attached to his posting at
http://lists.wfu.edu/pipermail/gretl-devel/2018-October/009185.html
(see
http://lists.wfu.edu/pipermail/gretl-devel/attachments/20181026/da605227/...
)
For convenience, this dataset can now also be found at
http://ricardo.ecn.wfu.edu/pub/gretl/bad_data.gdt
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:04 p.m.
New subject: a very strange case of arima (poor)... new script
On Wed, 31 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear Allin,
It seems that Riccardo implemented recently
not the same thing I proposed
So attached is arma_1() function which
realizes:
for y: (y-mean(y))/sd(y) + 1
for every x if any:
(x-mean(x))/sd(x)
In the sample the transformations applied twice:
for libgretl and for x-13
Hence 3 comparisons:
libretl based transformed and original libgretl
x-13 based transformed and original x-13
libretl based transformed and original x-13
Hopefully, this time your verdict would be
less humiliating
Thanks, Oleh. I didn't mean for my verdict to be humiliating, but
anyway... you have clearly shown that standardizing any exogenous
variables and "standardize plus 1" for the dependent can help
quite a bit in case of tricky data.
I'll follow up on this when I get some time.
Allin
6:29 a.m.
New subject: a very strange case of arima (poor)... new script
I didn't mean for my verdict to be humiliating
I it was
just poorly selected English word
I meant I was disappointed to see results
of the first script and didn't mean to
characterize intentions.
I was disappointed since I forgot to
insert smpl 1 194 into the first code (with my_arima)
With smpl 1 194 mean(diff_series) is O(10^-18)
and everything looks quite different
--x-12-arima comparison showed that
my transformations do actually nothing to
--x-12-arima estimation results
In my opinion this is an evidence that they
do something similar
Actually I have thought they did, analysing
the behavior of their estimates and based on
this conjecture I proposed the transformations
Oleh
1 листопада 2018, 00:04:18, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Wed, 31 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear Allin,
It seems that Riccardo implemented recently
not the same thing I proposed
So attached is arma_1() function which
realizes:
for y: (y-mean(y))/sd(y) + 1
for every x if any:
(x-mean(x))/sd(x)
In the sample the transformations applied twice:
for libgretl and for x-13
Hence 3 comparisons:
libretl based transformed and original libgretl
x-13 based transformed and original x-13
libretl based transformed and original x-13
Hopefully, this time your verdict would be
less humiliating
Thanks, Oleh. I didn't mean for my verdict to be humiliating, but
anyway... you have clearly shown that standardizing any exogenous
variables and "standardize plus 1" for the dependent can help
quite a bit in case of tricky data.
I'll follow up on this when I get some time.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2:45 p.m.
New subject: a very strange case of arima (poor)... new script
On Thu, 1 Nov 2018, oleg_komashko(a)ukr.net wrote:
> I didn't mean for my verdict to be humiliating
I it was just poorly selected English word
I meant I was disappointed to see results
of the first script and didn't mean to
characterize intentions.
I was disappointed since I forgot to
insert smpl 1 194 into the first code (with my_arima)
With smpl 1 194 mean(diff_series) is O(10^-18)
and everything looks quite different
OK!
--x-12-arima comparison showed that
my transformations do actually nothing to
--x-12-arima estimation results
In my opinion this is an evidence that they
do something similar [...]
That's possible, though maybe they don't need to standardize. We know
they use a switching algorithm -- ML for the ARMA terms plus GLS for
the regression terms -- and since GLS has an analytical solution it
shouldn't be so vulnerable to numerical problems in face of "wacky"
data for the exogenous variables.
Speaking of x12a, I've now (in git) enabled the $vcv accessor for this
case. The covariances between the ARMA and regression terms will be
identically zero since x12a doesn't calculate them. IIRC they argue
that they should be uncorrelated asymptotically.
Allin
7:17 p.m.
New subject: a very strange case of arima (poor)... new script
x12/x13 is open source too;
unfortunately I was taught paper
fortran ~35 years ago and have never used since that times
So it's unrealistic for me to understand in a realistic time
what they really do
But, look at lnl difference between libgretl/transformed
and x-13 original: but for random last digits in numbers
the difference was constant
It is hard to imagine a different reason but for
they actually use a similar transformation
Only imaginable differences could be:
I used 'one' for everything
they could use another numbers: 10, 5, log(10), etc
may be, they defined a range for non-traaforming
I am sure this is all difference
Oleh
1 листопада 2018, 16:47:07, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Thu, 1 Nov 2018, oleg_komashko(a)ukr.net wrote:
> I didn't mean for my verdict to be humiliating
I it was just poorly selected English word
I meant I was disappointed to see results
of the first script and didn't mean to
characterize intentions.
I was disappointed since I forgot to
insert smpl 1 194 into the first code (with my_arima)
With smpl 1 194 mean(diff_series) is O(10^-18)
and everything looks quite different
OK!
--x-12-arima comparison showed that
my transformations do actually nothing to
--x-12-arima estimation results
In my opinion this is an evidence that they
do something similar [...]
That's possible, though maybe they don't need to standardize. We know
they use a switching algorithm -- ML for the ARMA terms plus GLS for
the regression terms -- and since GLS has an analytical solution it
shouldn't be so vulnerable to numerical problems in face of "wacky"
data for the exogenous variables.
Speaking of x12a, I've now (in git) enabled the $vcv accessor for this
case. The covariances between the ARMA and regression terms will be
identically zero since x12a doesn't calculate them. IIRC they argue
that they should be uncorrelated asymptotically.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
7:36 p.m.
New subject: a very strange case of arima (poor)... new script
Dear Allin,
I think my propositions are neither smart, nor exotic
I am sure a kind of that variety is a must
Nobody estimates ols directly:
qr or svd are required
The more it is true for notoriously bad arima convergence
case
For, example, I used orthogonal polynomials for
variance model in my tobithetm, and it
routinely converges when R and stata
analogues faiil
Oleh
1 листопада 2018, 16:47:07, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Thu, 1 Nov 2018, oleg_komashko(a)ukr.net wrote:
> I didn't mean for my verdict to be humiliating
I it was just poorly selected English word
I meant I was disappointed to see results
of the first script and didn't mean to
characterize intentions.
I was disappointed since I forgot to
insert smpl 1 194 into the first code (with my_arima)
With smpl 1 194 mean(diff_series) is O(10^-18)
and everything looks quite different
OK!
--x-12-arima comparison showed that
my transformations do actually nothing to
--x-12-arima estimation results
In my opinion this is an evidence that they
do something similar [...]
That's possible, though maybe they don't need to standardize. We know
they use a switching algorithm -- ML for the ARMA terms plus GLS for
the regression terms -- and since GLS has an analytical solution it
shouldn't be so vulnerable to numerical problems in face of "wacky"
data for the exogenous variables.
Speaking of x12a, I've now (in git) enabled the $vcv accessor for this
case. The covariances between the ARMA and regression terms will be
identically zero since x12a doesn't calculate them. IIRC they argue
that they should be uncorrelated asymptotically.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
6:03 p.m.
New subject: a very strange case of arima (poor)convergence
open bad_data.gdt
z10 = y_two+2
list zlic10 = 0 y_one z10
arima 3 0 1; 1 0 0; diff_series zlic10
z10 = y_two+1000
list zlic10 = 0 y_one z10
arima 3 0 1; 1 0 0; diff_series zlic10
To compare:
no visible problem, BUT
1) absurd standard errors for const in the second model
2) false ma unit root in the second model
Run the script from the previous message
with "3 0 1; 1 0 0" to
see it can deal with ma terms
Oleh
28 жовтня 2018, 20:52:10, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 28 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Current scaling factor makes mean ~10
> with 1 196 sample mean is ~10^-8
> Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please take
a look.
As for the second problem, I guess the solution is quite easy but I'd wait
for Allin's opinion before committing any code to git.
In some cases, we initialise ARMA via NLS; however, we use NLS as if we
were estimating a "real" model, and therefore we employ our usual (rather
strict) convergence criterion. Of course, there's no need to be picky
about convergence, since nls is just meant to provide sensible starting
values. If you modify the nls_toler setting before running the arima
command, things go back to normal; example:
<hansl>
open bad_data.gdt
smpl 1 194
series sty=diff_series/sd(diff_series)
list zli = y_one y_two
set nls_toler 1.0e-5
y = sty+6.48
arima 3 0 0; 1 0 0; y 0 zli
</hansl>
Now the question is: should we raise NLS tolerance by default, when it's
used for ARMA initialisation, or do we have a better strategy?
-------------------------------------------------------
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
-------------------------------------------------------
6:53 p.m.
New subject: a very strange case of arima (poor)convergence
Obviously, the right setps
What is left is re-scale exogenous variables:
Compare:
open bad_data.gdt
smpl 1 194
z = y_two+10^5
arima 3 0 0; 1 0 0; diff_series const y_one y_two --x-12-arima
arima 3 0 0; 1 0 0; diff_series const y_one z --x-12-arima
arima 3 0 0; 1 0 0; diff_series const y_one z
Oleh
28 жовтня 2018, 20:27:54, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
Current scaling factor makes mean ~10
with 1 196 sample mean is ~10^-8
Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please
take a look.
-------------------------------------------------------
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
-------------------------------------------------------
7:17 p.m.
New subject: a very strange case of arima (poor)convergence
I a sorry, of course, I mean standarizing
Note: here we(you) have more work:
shifting constant becomes a function of
other parameters, so covariance matrix should
be also adjusted
It seems a range should be determined for
no shifting of the exogenous variables
Oleh
28 жовтня 2018, 20:53:43, від oleg_komashko(a)ukr.net:
Obviously, the right setps
What is left is re-scale exogenous variables:
Compare:
open bad_data.gdt
smpl 1 194
z = y_two+10^5
arima 3 0 0; 1 0 0; diff_series const y_one y_two --x-12-arima
arima 3 0 0; 1 0 0; diff_series const y_one z --x-12-arima
arima 3 0 0; 1 0 0; diff_series const y_one z
Oleh
28 жовтня 2018, 20:27:54, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 28 Oct 2018, oleg_komashko(a)ukr.net wrote:
Current scaling factor makes mean ~10
with 1 196 sample mean is ~10^-8
Hence, scaling factor ~10^18
I just pushed to git a one-liner that seems to solve the first issue you
raised. Now
<hansl>
open bad_data.gdt
smpl 1 194
arima 3 0 0; 1 0 0; diff_series const y_one y_two
</hansl>
produces sensible results. Allin: the fix is rather trivial, but please
take a look.
-------------------------------------------------------
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
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2251
days inactive
2258
days old
19 comments
3 participants
participants (3)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti