EViews.com

Hi everyone,

Me and my small team are having a problem with the calculation time of our model (ranging calculation times that might take 1.5 hours or 40 hours). I have found that roots of the problem are the following 2 equations that are embedded in the larger code (x being just the name of the series):

equation eq_LSTrend.ls(cov=hac) log(x) = c(1)*@trend+c(10)
equation eq_LSTrend_BM.ls(cov=hac) log(xBM) =c(2)*@trend+c(20)

where the parameters c(1), c(2), c(10), c(20) are calculated for multiple times for one series with a rolling time window (the series has approx. 9000 entries (that is slowly growing as we update the data every 1-to-2 weeks) with a time window of approx. 300 entries - resulting in multiple calculations). For the majority of the series (we have multiple ones) a calculation for a single time window in the series takes only a fraction of a second (approx. 0.005 seconds), while for some other series it sometimes takes over 2 seconds! You can imagine what a toll it takes on the total calculation time since it does not take a lot of such "lagging" series to make the calculation significantly longer (with 9000 total entries and a window of 300, that is approx. 8700*2 seconds! for a single series). To add to the confusion, the "lagging" series are not always the same ones (we run the model every 1-to-2 weeks and after updating the data some series become the "lagging" series, while others show fast calculation times again and sometimes even all of the series run fast and the model calculates very quickly).

I have tried lowering the "Max Iterations" and "Convergence" parameters in the "general options", but it did not help. I have also checked the data in the Eviews series itself as well as the source that we import the data from and yet I did not see anything fishy. Also, this problems depends neither from the specific desktop used (since my colleagues also have the same issue) nor from the Eviews version used (I have Eviews12 while my colleague is having the same issue with Eviews10).

I am fairly new to Eviews (joined the team only a couple of months ago) so I still really lack the intuition towards a possible solution. So any thoughts, suggestions or help would be much appreciated!

Thanks

Do you absolutely need the cov=hac option?

I believe so, since this cov=hac has always been used since the creation of the model.
Also, changing the cov option would (I assume) change the c(1) and other parameters and this would not be satisfactory since we are producing some content that is based on the values that have been computed previously by this method. So an abrupt change in computed values would not be consistent with the content that we produced in the past.

The cov option makes no difference to the estimated parameters. If all you are retrieving from the equations is the estimated parameters, you don't need the cov option.

I have removed the cov option (left the brackets empty) and, unfortunately, the problem still persists.

Then it is probably the way you have written the loop(s).

I think I solved the problem. What I did is right before using the

equation eq_LSTrend.ls(cov=hac) log(x) = c(1)*@trend+c(10)

I created a separate series that multiplied the log difference by 1 (for example: series TestSeries = log(x) * 1) and plugged this series in the equation as follows:

equation eq_LSTrend.ls(cov=hac) TestSeries = c(1)*@trend+c(10)

This must have forced an "update" or "refresh" the series and fed it correctly that caused Eviews to get "unbugged". Of course, the sample for the TestSeries was also adjusted as needed before feeding it to the equation (but this was also the case with the normal log(x) input).

Just to add a few comments:
It appears that Eviews is begging to get buggy while pushing its limits and I believe that was the reason for the problem. I later noticed that even when closing and opening the same workfile without saving, or opening a second exact copy of the workfile, the new "lagging" series in both instances were different and completely random. To add to that the results of the calculations were exactly the same, the only difference being the considerable time difference for the calculations. The forced "refresh" of the series is what worked at the end.