8:58 p.m.
On Mon, 6 Oct 2014, henrique.andrade(a)bb.com.br wrote:
Dear Gretl Developers,
I think there's something wrong with the "catch" function. The problem
occurs inside a function and inside a loop. Please take a look at the
attached script and functions (AutoARIMA and Backtest).
When I use a "catch" in the line 96 of the "Catch & Function
potential
problem.inp", Gretl stops responding and crashes. Also, when I don't use it
in the command the second loop inside "Catch & Function potential
problem.inp" (the loop starts in line 83) generates an error.
Furthermore, the "flush" command is not working in this context.
I really don't know if it is a problem of Gretl or a problem of mine :-(
There may or may not be problems in your scripts, but if gretl
crashes that is undeniably a problem of gretl. I'm looking into it.
Allin
9:34 p.m.
On Mon, 6 Oct 2014, Allin Cottrell wrote:
On Mon, 6 Oct 2014, henrique.andrade(a)bb.com.br wrote:
> I think there's something wrong with the "catch" function. The
> problem occurs inside a function and inside a loop. Please take a
> look at the attached script and functions (AutoARIMA and
> Backtest).
>
> When I use a "catch" in the line 96 of the "Catch & Function
> potential problem.inp", Gretl stops responding and crashes. Also,
> when I don't use it in the command the second loop inside "Catch
> & Function potential problem.inp" (the loop starts in line 83)
> generates an error.
>
> Furthermore, the "flush" command is not working in this context.
>
> I really don't know if it is a problem of Gretl or a problem of
> mine :-(
There may or may not be problems in your scripts, but if gretl
crashes that is undeniably a problem of gretl. I'm looking into
it.
OK, for the moment I'll concentrate on the "catch" issue. I'll stand
by my statement that gretl should not crash, regardless. All the
same, your script is definitely in error. As we state in the "catch"
help text,
<quote>
If an error does occur, this is registered in an internal error code
which can be accessed as $error (a zero value indicates success).
The value of $error should always be checked immediately after using
catch, and appropriate action taken if the command failed.
</quote>
You are ignoring that, proceeding without checking the variable
$error after using "catch": you go on to use variables such as
$xlist which are not valid after a failed estimation command, and
that's what's causing the crash. I think the best response of gretl
under these conditions, if we can arrange it, would be to abort
execution of the script (stopping but not crashing) with a message
stating that the user broke his/her contract with gretl!
Allin
3:31 p.m.
On Mon, 6 Oct 2014, henrique.andrade(a)bb.com.br wrote:
I think there's something wrong with the "catch"
function. The problem
occurs inside a function and inside a loop. Please take a look at the
attached script and functions (AutoARIMA and Backtest).
When I use a "catch" in the line 96 of the "Catch & Function
potential
problem.inp", Gretl stops responding and crashes. Also, when I don't use it
in the command the second loop inside "Catch & Function potential
problem.inp" (the loop starts in line 83) generates an error.
There is an error in estimating one of the arima models: "Failed to
compute numerical Hessian." If you use "catch" on this but do not check
the $error value, then the subsequent fcast command will reference a
broken model. This will no longer (in CVS and snapshots) cause a crash,
but it will cause an uncaught error that will stop the script. The idea
with "catch" is like this:
<hansl>
catch arima ...
if $error
# skip to the next iteration or something, but
# don't try to do anything with the "last model"
else
fcast ...
endif
Furthermore, the "flush" command is not working in this
context.
Ah, the help text for "flush" was not explicit enough. I've now added an
example. This command won't do anything if placed at the top of a script,
when there's no output to flush. The idea is something like this:
<hansl>
loop i=1..n
# do some time-consuming operation
# print some results
if i < n
flush
endif
endloop
</hansl>
Allin
3694
days inactive
3695
days old
3 comments
2 participants
participants (2)
-
Allin Cottrell -
henrique.andrade＠bb.com.br