EViews.com

Hello, vector ssrt_debt = sum_ssr_ldebt + sum_ssr_hdebt That said, if your sum_ssr_{%c} vectors are only ever going to hold one element, use scalars instead of vectors. And there's no point to calculating sum_ssr_{%c} until after you've finished calculating ssr_{%c}, i.e., move that statement after ...

What I'm hinting at is that there are other available metrics for selecting the "best" VAR. If you look at the bottom of a VAR's estimation output you'll find a variety of summary statistics for the VAR as a whole.

Hello,

The real question is, what are you trying to quantify through a "total SSR of the VAR"?

Something like this...


The minimum SSRs are stored in vector min_ssr.

Those "restriction presets" are just simple, common sets of restrictions that can be customized further. You're not limited by those presets, e.g., the F matrix doesn't need to be triangular. The new error message you're receiving could be caused by many things, such as bad initial values ...

Sure, a few loops can easily go through any number of VARs you wish with any number of equations per VAR:

You need to specify which VAR equation's SSR you want, e.g., @ssr(1), @ssr(2), etc.

Hello,

Take a look at the VAR object documentation. I believe the @ssr data member is what you're looking for.

Lets start with the initial value issue, since that's easy to fix (if it's the cause of your difficulty). When estimating an SVAR, EViews uses an initial value of .1 for all estimates by default. If you open your VAR, go to Proc -> Estimate Structural Factorization, and switch to the Optimization Co...

Hello, There's no implicit restriction form on the long-run matrix, you can restrict any element(s) you wish as long as you completely identify the system. That error can occur when, for example, the choice of initial values for the estimation happens to produce a singular matrix or other numericall...

I believe what you're after is:

x.@last will return the date (as a string) of the last non-NA observation in series x.

Just use "@date" instead of "@date(res{%eq})". You generate dates based on the workfile sample and frequency, not on a specific series. The "(res{%eq})" term shifts the dates by the amount of the first residual, which you observed.

Here's a more general, EViews 9.5-friendly solution that (1) doesn't require all the NAs to be in the same column, and (2) preserves the order of the non-NA-containing rows. This solution constructs a new matrix as the result rather than modifying the original matrix. matrix(1,m.@cols) m2 for !i = 1...

That's almost certainly due to the lag dependence in the signal, i.e., for the first observation in your sample {%sig}(-1) is NA, which propagates to later observations until you get to a case number that doesn't depend on {%sig}(-1), such as case number 9 in the example you posted. In the statement...