Hi Tom,
I have a question that I hope you may be able to help me with about the above procedure. I am using it to conduct scenario analyses of a VAR I have already estimated. I have imposed two restrictions, whereby one of my variables (rgdp) is set to contract by 3.0 percent in 2009, and in 2010 I have imposed modest growth of .05 per cent. The variables are in logarithmic growth rates and I have imposed the two constraints directly on a supplemtary card, unike the example on pg 400 of the User Guide where the condition was set to 5.0 per cent year over year growth.
My question is that the simulated forecasts are quite sensitive: small changes in the constraints (if I say, increase the growth rate in 2010 to .10 while keeping 2009 contracting by 3.0 percent) results in large changes in simulated estimates, in both forecast years. Is this normal? If I re-estimate the underlying VAR, while keeping the constraints exactly the same, the estimates are also wildly different.
I am convinced that I am doing something wrong, but cannot quite get the estimates to behave reasonably. Looking forward to any advice you can provide.
Best wishes and many thanks,
Gary.
Condition.src Procedure
Re: Condition.src Procedure
You'll have to send us the program and data. That doesn't sound like the proper behavior.
Re: Condition.src Procedure
Hi Tom and the rest of the Estima team,
Many thanks for all your help with regards to below. It turned out that I was only looking at the results from the last trip through the loop, instead of summing and dividing by the number of draws to get the mean results. Thanks once again for pointing that out...just in case anyone else runs into something similar.
Best wishes,
Gary.
Many thanks for all your help with regards to below. It turned out that I was only looking at the results from the last trip through the loop, instead of summing and dividing by the number of draws to get the mean results. Thanks once again for pointing that out...just in case anyone else runs into something similar.
Best wishes,
Gary.