Confirmed on my Linux Mint 18.3 system after updating to 2017a. Very good work, Jack!

On Sun, 26 Mar 2017, Riccardo (Jack) Lucchetti wrote: On Sun, 26 Mar 2017, Clive Nicholas wrote: > > Confirmed on my Linux Mint 18.3 system after updating to 2017a. >> >> Very good work, Jack! >> > > Thanks, on behalf of Allin too, who actually wrote most of the code. > This may be more than people want know, but I'm tempted to expand a little on the (IMO) excellent division of labour that stands behind gretl development, and of which this is a not untypical example. 1) Jack proposes a very good idea, initially in the form of a hansl-scripted "prototype". 2) I can see it's a good idea, but I have trouble following Jack's hansl script -- not because it's obfuscated (= deliberately obscure) but just because Jack can see 3 or 4 moves ahead on the chess-board where most of us (well, I speak for myself) can only see 1 or 2 moves at a time. 3) Jack produces C-code to expand on the hansl prototype. Since coding in C forces you to go relatively step-by-step I now "get it" more definitely. 4) There then arise practical questions of how exactly the required information can be got into the right place at the right time, in the context of gretl's C code. Since I know that code like the back of my hand, I can contribute something useful at this point. 5) We then go back and forth a few times, trying to iron out any problems that may arise (e.g. special cases not handled). 6) If all goes well we end up with something that implements Jack's original idea and is reasonably robust across a wide range of possible cases. Allin _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

Confirmed on my Linux Mint 18.3 system after updating to 2017a. Very good work, Jack! C On 26 March 2017 at 11:00, Riccardo (Jack) Lucchetti < r.lucchetti(a)univpm.it&gt; wrote: > In the current git version and snapshots, we have a new diagnostic plot, > which IMHO is rather nice: after estimating an arima model, you get a > comparison of the sample periodogram vs the spectrum implied by the model > estimates. For example, try this: > > <script> > clear > open fedstl.bin > data houstnsa > series y = 100*sdiff(ln(houstnsa)) > arma 2 2 ; y --window > </hansl> > > In the "Graphs" menu of the model window you should now have a new item, > called "Spectrum vs sample periodogram", that should (hopefully) produce a > nice plot comparing the two. > > Please test. Comments, as usual, welcome. > > ------------------------------------------------------- > 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-users mailing list > Gretl-users(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-users > -- Clive Nicholas "My colleagues in the social sciences talk a great deal about methodology. I prefer to call it style." -- Freeman J. Dyson _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

On Mon, 27 Mar 2017, Artur Bala wrote: Great!!!!! It works fine on Windows too. > However, when switched from english to french language, an error occurs > and > the graph is not plotted. > Ah, maybe you're using a snapshot version that is not 100% synced with git (Allin fixed that not so long ago). I think it's a decimal separator problem. If you disable localised decimal separators (Preferences menu), the problem should disappear. The problem is transitory anyway, it should disappear in the next snapshot. ------------------------------------------------------- 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 -------------------------------------------------------

On Mon, 27 Mar 2017, Artur Bala wrote: Absolutely right!!!!! > I tried to disable the locale decimal point and things work great! > Ah, we had our decimal-comma guard in the wrong place in the arma spectrum plot code. That's now fixed in git. Allin Cottrell _______________________________________________ Gretl-users mailing list Gretl-users(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-users

Am 26.03.2017 um 12:00 schrieb Riccardo (Jack) Lucchetti: > In the current git version and snapshots, we have a new diagnostic plot, > which IMHO is rather nice: after estimating an arima model, you get a > comparison of the sample periodogram vs the spectrum implied by the > model estimates. When you say "sample periodogram", I guess you're using the smoothed periodogram? (As the raw periodogram isn't a consistent estimator.)

Am 27.03.2017 um 08:47 schrieb Riccardo (Jack) Lucchetti: > On Mon, 27 Mar 2017, Sven Schreiber wrote: >> When you say "sample periodogram", I guess you're using the smoothed >> periodogram? (As the raw periodogram isn't a consistent estimator.) > > I thought that the sample periodogram is better for the purpose I had in > mind, which is to provide a basic visual "mis-specification test". Maybe > I'm wrong, but the whole idea was to provide a sort-of > "actual-vs-fitted" plot. If the model is correctly specified, you should > see the spectrum nicely going through the periodogram points. I think it depends on how you define "through". Intuitively I'd say that if you are using the correct model (an estimated version of the DGP), then asymptotically the parametrically estimated spectrum and the non-parametrically estimated one (for example, using the smoothed periodogram) will converge on each other.

I don't think that the same result would hold for the raw sample periodogram, because it is not a consistent estimator of the spectrum. In that sense the periodogram ordinates are not "actuals" like datapoints are, I think.

Graphically I would expect the sample periodogram to "wiggle" around, and the parametric spectrum estimate will be comparably smooth and go "through" the periodogram in a common-sense way. I think that would basically mean that the user is doing the smoothing of the periodogram herself mentally, in her imagination.

(Smoothing is of course not the only way to obtain a consistent estimator.)