EViews.com

Dear All,

Possibly not a bug (please feel free to move the thread to the appropriate sub-forum), but I am confused as to what is happening. I've written a routine which has computed a very large number of forecasts, but one error occurs with one of the combinations of the variables: 'attempt to raise a negative number to a non-integer power'. Please see the attached workfile. What (non-linear) calculations could EViews be doing from a .forecast on a single OLS equation which would involve raising a negative number to a non-integer power? What combination of events means that this error is occurring for this combination of variables, but not any of the other billions which I've estimated? I am slightly perplexed, and any help would be gratefully received!

Very best wishes, as always!

Charlie


Edit: Some further thought on the matter has lead me to think that it could be something to do with the way that EViews is recovering the forecasts to levels from the @pca transformation, but I'm still unsure as to what's going on.

Not really a bug, but a quirk of the way that EViews does forecasts...

For various complicated reasons, even though you are forecasting @pca(X), EViews first forecasts X and then calculates @pca(X). It forecasts X by calculating what @pca(X) is and then finding the inverse of the @pca function.

So, in your case, for 2007Q3, if you calculate: You receive an answer of -101.8556.

EViews takes that number as @pca(X) and then tries to calculate X.
From that you can see that if @pca(X) is less than -100, you will receive an error since @pca(X)+100 will be negative, and then you're raising it to a fractional power (1/4).


This is a case where, if you really want to forecast @pca(x), you're better off creating a variable equal to @pca(x) and using that as the dependent variable, rather than the expression. EViews will be able to forecast that no problem.

Thank you so much Gareth - as always, a perfectly clear explanation of what was going on. I shall remedy the situation as you suggest (and indeed - I think you once told me that for a large number of calculations, program efficiency will be increased by transforming prior to estimating, rather than using @functions in procedures: I should have listened better!)

Thanks again,

Charlie