Update. The problem goes away if the option *--progressive* is replaced with *--quiet*. However, it should not crash and crumble all the changes the user has made to the script anyway, should it? -- С уважением, —Андрей Викторович Костырка.— http://kostyrka.ru, http://kostyrka.ru/blog 2014-04-13 7:37 GMT+04:00 Andreï | Андрей Викторович < fifis.himik(a)gmail.com&gt;: Greetings, dear developers! > > Please consider the following humble code I am trying use to illustrate > the usefulness of a whole portfolio of models compared by AIC. What I am > expecting: (1) generate a true ARMA(2,2) model, (2) run a loop with i=1..5 > and j=1..5 for ARMA estimation and obtain the AIC’s for those, (3) the > result should look like those “long” models like ARMA(5,5) include more > redundant lags and they will be punished by Akaike and its DOF loss penalty. > However, on Linux Debian (testing, both x32 and x64) the 1.9.14 (build > 2014-03-19) version crashes and quits without any warning when the > following script is run: > ########## > nulldata 500 > setobs 1 1 --special-time-series > genr time > > set seed 20140413 > series wn = randgen(n,0,1) > > # ARMA(2,2) model, seems both stationary and invertible > series z = 4.5 > z = 1 + 0.25*z(-1) + 0.55*z(-2) + wn + 0.5*wn(-1) + 0.5*wn(-2) > > # The beast > loop i=1..5 --progressive > loop j=1..5 --progressive > arima $i 0 $j ; z > printf "Akaike criterion: %f\n", $aic > endloop > endloop > ########## > > Same problem if *arma* command is used. > I tried to run it on the current snapshot (1.9.15cvs b.2014-04-04) for > Windows x32, but to no avail: the message given before the crash is “MS > Visual C++ Runtime Library: This application has requested the Runtime to > terminate it in an unusual way”. > > What can I do in order to avoid this mishap and sort of estimate > ARMA(i,j) for various $i and $j in a loop? > > Best wishes, > Andreï V. Kostyrka > > -- > С уважением, > —Андрей Викторович Костырка.— > http://kostyrka.ru, http://kostyrka.ru/blog >

On Sun, 13 Apr 2014, Andreï | Андрей Викторович wrote: > I should be grateful if you fixed the crash, though. The problem you discovered needs to be fixed, and we thank you for spotting it. I'm not quite sure what the fix should be, though: the crash occurs because you're nesting two loops, both of which have the --progressive option. This leads to memory corruption and has presumably been there forever; I can only say that nesting two progressive loops is something that nobody, to my knowledge, ever attempted before, basically before (from a semantic point of view) ot makes little sense to do so: the --progressive option acts like a binary switch (on/off); you normally don't want to turn the light on if it's on already, do you? ;) I can see 3 alternatives here: 1) Take actions to fix the memory corruption 2) forbid the nesting of progressive loops (which makes no sense anyway) 3) Ignore the innermost --progressive flag if present. I'd go for 3). Allin?