Discrepancy between JMulti and Eviews ?!

Olivier_G
2005-09-16
2013-04-30
1 2 > >> (Page 1 of 2)
  • Olivier_G

    Olivier_G - 2005-09-16

    Ok I have a weird question here.

    I both use JMulti and Eviews. So far I had noticed small differences between the results. Actually I now think they have nothing in common besides the names !
    I mean for example I just ran a simple 4-dimension cointegration test. Eviews clearly yields ONE cointegrating relationship, while JMulti reports clearly two.
    Even in the VECM context, the same data directly imported from Eviews, with the same parameters do NOT yield the same results at all in JMulti and in Eviews.

    Obviously there may be computing errors as has been seen in the past. Yet there can't be such a persistant error and I must be wrong. Besides I'm kind of puzzled because when I look up in the help sections, I found out that JMulti does not presents the VECM model as the (conventionnal way to do it) in Eviews. But maybe it's just a rewriting issue I didn't get.
    Did anyone notice result differences between JMulti and other econometric software ?!

    PS: And why isn't there a constant in the error-correction part of the VECM ?

     
    • Nobody/Anonymous

      >Even in the VECM context, the same data directly imported from Eviews, with the same parameters do NOT yield the same results at all in JMulti and in Eviews.

      To maximize accuracy of this topic, do you confirm that the residuals are completely different too?

      (To completely exclude cosmetic or alternative expression issues of formulas.)

      G.

       
    • Nobody/Anonymous

      Hi there,
      this is something from my previouus posts:
      "I also tried to estimate same VECM using Eviews and the results were the same as with JMulTi. The initial number of included observation was lost after adjustments in Eviews and JMulti. But with PcGive there is no loss of initial included observations after adjustments. So, I think that the difference between VECM with PcGive and JMulTi is in adjustments. "

      Regarding cointegration test and the difference in results between JMulTi and Eviews I will check this again..I'am not sure now if the results were the same or not, but I get the same results as in JMulTi with PcGive!
      In help section of JMulTi is a comparision between cointegration test cases with JMulTi and Eviews .

      I think that this is due to similar but not exact Johansen testing procedure, maybe with some adjustments.

      ==>"Even in the VECM context, the same data directly imported from Eviews, with the same parameters do NOT yield the same results at all in JMulti and in Eviews."

      I estimated VECM in JMulTi and Eviews and the results were the same! Maybe you didn't included some constant and trend in JMulTi. I made for myself a comparision table for VECM and I can post it if you want.

      Manny

       
    • Nobody/Anonymous

      ==>"Regarding cointegration test and the difference in results between JMulTi and Eviews I will check this again..I'am not sure now if the results were the same or not"

      I checked and the results are not the same. As I said the difference between JMulTi and Eviews is in the sample which is adjusted in Eviews. You can check this when looking at the number of observation after adjustments ( then compare this number with the number "T" in JMulTi ). In Eviews you have excluded observations ( i.e. the sample is adjusted ) while  JMulTi  uses the full sample.

      Manny

       
    • Nobody/Anonymous

      the cointegrations tests give the same results, this has been checked a number of times already. But there seems to be occasional confusion on the specifications that match between Jmulti and Eviews. Please check the help system. It has been made rather clear there.

      In Eviews there is a spec with constant in EC term+outside.
      This spec does not exist in JMulTi because the constant is not identified in that case.

      m

       
    • Nobody/Anonymous

      I couldn't reproduce the same results using cointegration test. I tried many times without sucess. With PcGive yes, but with Eviews no. Trace statistic was different. The only difference in specifications was in adjusted sample or "T". So, I concluded that if "T" is different then trace statistic will differ too.
      Maybe I specified something wrong.

      Manny

      Ps. Markus if you have time try it once more. You said occasional but I get the difference all the time.

       
    • Olivier_G

      Olivier_G - 2005-09-19

      Ok as far as I can see there are three issues in here

      1- G. has suggested that the residuals are maybe the same ; actually no, I checked, the residuals are not the same

      2- MAnny suggeted the sample size is not the same. But no, again, this is not the reason why I see differences. For stability reasons I do not use the whole sample and discard the first 50 observations (I have a very large sample). So I use 203 observations in Eviews, and I use the very same 203 observations in JMulti (but you are right Manny, I got fooled by this more than once)

      3- M. (Markus is that you ?) suggested that "in Eviews there is a spec with constant in EC term+outside. 
      This spec does not exist in JMulTi because the constant is not identified in that case". That makes a lot of sense since this case in Eviews is Johansen's cointegration type 4 (trend and constant in EC, and constant in VAR). This is precisely the case I am talking about and I am using. And it also true that the constant in the EC part  is not identified, as the t-value is not reported.
      But :
      a- Cointegration is all about Johansen's 'classic' five cases, all nested into one another. I find it strange that JMutli does not EXACTLY support Johansen's cointegration type 4.
      b- Moreover, type 4 is 'the most general case' from which to start (case 5 yields improbable out-of-sample forecasts... and is not supported in JMulti anyways). Then the best modeling strategy is to test whether the trend(s) in the cointegrating relationships can be restricted to zero (i.e. non significant), and if so you end up estimating Johensen's case 3. BTW, is that case 3 called orthogonal trend in JMutli, or is there another difference between Johensen's typology and JMulti implementation ?
      c- What if I proceed that way in JMulti : estimate case 4 and try to restrict it to case 3 ? Is case 3 nested into case 4 in JMutli ? If not, this is pointless.

      Now, more seriously, I have redone the computations for my model which consists of three variables and a sample size of 203 observations.

      A- Cointegration tests : I couldn't find any big discrepancy between Eviews's and JMulti's results. They are based upon different critical values anyways.

      B- VEC Model : In general the are NO major differences between Eviews and JMulti when the model has a trend in the cointegrating relationship (case 4 in Eviews and in Johensen, trend in EC checked in JMulti). But there are MAJOR differences when a dummy is included.

      Examples below (exact same parameters, variables are renamed A, B and C) :

      NO DUMMY CASE ----------------------------------------
      In Eviews my two cointegrating relationships are
      A   ----   -0.821*C + 0.002*t + 10.271
      ----  B    -0.181*C  - 0.002*t  -  9.670
      While in JMulti with Johansen approach they are
      A   ----   -0.826*C + 0.002*t + 10.340
      ----  B    -0.176*C  - 0.002*t  -  9.686
      and in JMutli with S2S approach they are
      A   ----   -0.825*C + 0.002*t + 10.335
      ----  B    -0.168*C  - 0.002*t  -  9.738

      So there isn't any serious difference, if any at all.

      DUMMY CASE--------------------------------------
      (D stands for Dummy in the EC)
      In Eviews my two cointegrating relationships are
      A   ----   -0.820*C + 0.002*t + 10.252 + 0.044*D
      ----  B    -0.191*C  - 0.002*t  -  9.499   - 0.429*D
      While in JMulti with Johansen approach they are
      A   ----   -1.053*C  + 0.005*t + 12.025  - 0.714*D
      ----  B    +0.492*C  - 0.011*t  - 14.624 + 2.019*D
      and in JMutli with S2S approach they are
      A   ----   -0.826*C + 0.002*t + 10.348 - 0.034*D
      ----  B    -0.175*C  - 0.002*t  -  9.696 + 0.021*D

      --------------------------------------------------------------------

      So this is kinda weird : there are major differences between JMulti and Eviews when a Dummy is included. Results with Johansen's approach are especially crazy.
      - JMulti + Johensen approach have nothing in common with Eviews results.
      - JMulti + S2S approach yields different results than with JMulti + Johensen approach, but the former is much closer to Eviews.
      - Yet JMulti + Johensen approach do not give the same results as Eviews AT THE LEVEL OF THE DUMMY COEFFICIENTS. I haven't reported the t-ratios but again those differ.

      So what's wrong and where's the truth ?

      (I guess Eviews does not handle well in ECs... but still : why are the results different between JMulti + Johensen approach and JMulti + S2S approach ???)

      Markus, I need your profound enlightmentS here.

       
    • Olivier_G

      Olivier_G - 2005-09-19

      I should have added that the Dummy used here is a single Dummy variable picking up all recessions with value 1.

       
    • Nobody/Anonymous

      Regarding Johansen: I used the same data in JMulTi and Eviews in Johansen and I get EXACTLY ( not major differences ) the same results using the following comparision:

      E-Views vs. JMulTi

      No trend in data
      1) No intercept or trend in CE or VAR -->nothing checked
      2)Intercept ( no trend ) in CE  no intercept in VAR --> Intercept + CONST checked

      Linear trend in data

      3)Intercept ( no trend ) in CE and VAR --> only Intercept checked
      4)Intercept and trend in CE  no trend in VAR --> Intercept and Trend + TREND checked

      Quadratic trend in data

      5)Intercept and trend in CE  linear trend in VAR --> Intercept and Trend checked

      Note: CONST and TREND ( all capital letters )stands for EC term. And I didn't try with dummies.

      Regarding cointegration tests: I see differences in trace test and I think this is due to sample adjustment.

      Try this comparision and let me know your results.

      Manny

       
    • MannyCRO

      MannyCRO - 2005-09-20

      Ok, I see, logging is new.
      I again estimated VECM using Eviews and JMulTi. The results are the same, exactly the same ( I will post the results ). But standard errors and t-values are different!!!! I don't know why. Something is different in estimation.

      I have two questions Markus.
      1) Why cointegration trace test is different from Eviews?
      2) Why cointegration vector ( Johansen estimation ) is the same as in Eviews but standard errors and t-values are different?

      Manny

       
    • Olivier_G

      Olivier_G - 2005-09-20

      Manny,

      Markus said that JMulti did not EXACTLY support Johansen's case 4, whereas Eviews does. The difference is that Eviews has a trend and a constant in the EC equation, whereas JMulti only has a trend, on the basis that the constant 'is not identified' in that case n4.
      (and its true, Eviews does not report the t-value for it)

      Regarding the cointegration test (here case 4 in Eviews and 'constant and trend' in JMulti), I find small differences. I said earlier that the discrepancy should have come from the critical values which are different (Osterwald-Lenum in Eviews, Trenkler in JMulti), but it is not the case.
      Here is a comparison for the the very same sample (T=203, in a 4-dimension model) :

      Computed Trace Statistics in Eviews / JMulti :
      r0=0   56.59 / 53.51
      r0=1   26.36 / 28.14
      r0=2   13.79 / 14.37
      r0=3   5.85 / 5.64

      and the related p-values (Eviews / JMulti again)
      r0=0   0.17 / 0.27
      r0=1   0.71 / 0.61
      r0=2   0.67 / 0.63
      r0=3   0.47 / 0.51

      As I understand it, there are differences between the cointegration tests built in Eviews and JMulti. From the example above everyone can see that this is not due to computation errors.

       
    • MannyCRO

      MannyCRO - 2005-09-20

      Hmm...maybe Markus was thinking about cointegration test which can't be produced because there is no specification in JMulTi and not about VECM estimation.

      This option is not implemented and this is true: "intercept and trend in CE, linear trend in VAR - not implemented" ( JMulTi help ). But I think this is related only to Johansen cointegration test.

      Furthermore, I found differences between JMulTi and Eviews in cointegration tests in all possibile cases which can be tested in JMulTi

      In help system stays: "critical values and p-values The critical values as well as the p-values of all Johansen trace tests are obtained by computing the respective response surface according to Doornik (1998) if there are no breaks, or according to Johansen et al. (2000) if there are up to 2
      breaks."

      Perhaps, that's why I get the same results with JMulTi as with PcGive ( PcGive is developed by Doornik ) when testing for cointegration.

      Manny

       
    • Nobody/Anonymous

      No trend in data
      2)Intercept ( no trend ) in CE  no intercept in VAR č Intercept + CONST checked

      To simplify I used one lag and one cointegration vector ( without checking residual and stability diagnostics ). A, B and C are included variables.

      Results from EVIEWS:

      Estimated cointegration relation(s):

                      ec1(t-1) 
      -------------------------
      A(t-1)     |    1.000 
                     |   (0.000)
                     |   {0.000}
                     |   [0.000]
      B(t-1)     |    0.158 
                     |   (1.002)
                     |   {0.875}
                     |   [0.157]
      C(t-1)     |    0.215 
                     |   (1.757)
                     |   {0.903}
                     |   [0.122]
      CONST  |   -5.960 
                     |   (4.725)
                     |   {0.207}
                     |  [-1.261]
      -------------------------

      Results from JMULTI:

      Cointegrating Eq:     CointEq1
         
         
      A(-1)     1.000000
         
      B(-1)     0.157541
           (1.05315)
          [ 0.14959]
         
      C(-1)     0.214595
           (1.84762)
          [ 0.11615]
         
      CONST    -5.960495
           (4.96759)
          [-1.19988]

      If you increase precision in JMulTi you will get exactly the same results.

      T-values and standard errors are different!

      I don t know why is that, maybe Markus does.

      Manny

       
    • Olivier_G

      Olivier_G - 2005-09-21

      well as I can see your t-values are not very different... For variable B for instance, you get 0.157 in Eviews and 0.149 in JMulti... that's no big deal to me...
      but can you tell what estimation option you used in JMulti ? Is it Johanses's approach or is it S2S approach ? Also can you confirm you get exactly the same results with both approach in JMulti ?

      Olivier

       
    • Nobody/Anonymous

      I used Johansen in both!
      Ok, t-values are not very different but they still differs. This means that procedure for calculating t-values and std errors isn't the same.

      On your third question I will answer but not now because I'm not sure. I think I tried but will do it again and inform you.

      If you use exactly the same data you should get the same results as I. But you must be very carefull when checking constant and trends in JMulTi. I posted the comparision table in my previous posts.

      Also I can assure you that the difference in Johansen VECM estimation and Johansen cointegration tests between JMulTi and Eviews vs. PcGive and Gretl is in sample adjustment. I don't have another explanation.

      Manny

       
    • Nobody/Anonymous

      ==>Also can you confirm you get exactly the same results with both approach in JMulti ?

      The same results I get when estimateing VECM using Johansen(restrictions on beta are ignored) and with two stage procedure when in specify box estimate coint relations by Johansen is checked.
      Also I get the same results when using S2S procedure( restrictions on beta are used if available) and with two stage procedure when when in specify box estimate coint relations by S2S is checked.

      Manny

       
    • Olivier_G

      Olivier_G - 2005-09-22

      ok thanks MAnny... I'm gonna check my results

       
    • Nobody/Anonymous

      I tried another test. I tried to estimate cointegration vector using Gretl and PcGive. The coefficients of estimated cointegration vector were exactly the same but standard error were different!!! There must be some explanation for this.

      The same case is between JMulTi and Eviews! Why standard errors and t-values (if present) are  calculated on the different ways?

      Conclusion:
      1) JMulTi, PcGive and Gretl compute Johansen cointegration test on the same way with identical values.
      Eviews compute it on some other way.

      2) JMulti and Eviews compute VECM - Johansen on the same way with the same coefficients but with different standard errors and t-values.
      PcGive and Gretl compute VECM - Johansen on the same way with the same coefficients but with different standard errors and t-values. But their estimated coefficients differs from estimated coefficients with JMulti and Eviews.

      Markus please,maybe you know something?
      Everything is explained in this and in previous posts.

      Manny

       
    • Nobody/Anonymous

      I'm seeing experts of statistics being made here. The subject of Lesson I was: Never completely trust your statistical software. It is either bogus or if not, you don't completely understand what it does.

      The subject of the Lesson II will be about basically incomprehensible statistical assumptions combined with a suitable data set from hell: A fabulous curve fitting with real time data and bankrupting your employer when all the statistics indicated that the model was very valid. Thus you didn't check it with real predictions.

      After passing those lessons alive you'll be granted the honoured degree of time series wizards.

      G.

       
    • Nobody/Anonymous

      Ah ah G!

      You said wright - time series wizards!
      Sometimes is better to have trust in bean or in a sphere to see what will happen. Damn human wish to know it's future....;))

      Comparisions, tests and experiments ==> till waiting for the time machine!

      Manny

       
    • Nobody/Anonymous

      one remark,

      firstly: please check whether you use the same number of lags. JMulTi uses level specs for cointegration tests but differences for VECM estimation. This sometimes causes confusion but can be justified.

      second: JMulTi treats structural breaks in cointegration tests differently than Eviews, according to the Johansen Moscon Nielsen (2000) procedure. The p-values are computed from a response surface and therefore differ slightly from the asymptotic ones.

      The johansen procedure should give similar results in all cases with other packages. However, t-values for estimated betas depend on the chosen normalization. In JmulTi this is fixed to set the first rxr matrix in beta to the identity matrix. In PCGive there is more flexibility.

      did not find any bugs so far, if you have a concrete example I would check it though.

      m

       
      • Nobody/Anonymous

        About first remark: Johansen trace test in JMulTi is the same as in PcGive and Gretl. This is correct.

        About second remark: I haven't use structural breaks.

        The johansen procedure is simmilar to Eviews. In fact, the estimated coefficients are the same ( I posted it in previous possts ) but t-values and standard errors are different. Normalization was on the same i.e. first variable in the model.

        You said "The johansen procedure should give similar results.." Why simmilar, why not the same if the estimation is the same and this is improoved by same coefficients? Is this "simmilar" related to t-values and p-values, not to the coefficients?

        Manny

        Ps. If you have Eviews try it with using the same dataset.

         
    • Olivier_G

      Olivier_G - 2005-09-26

      TO G. : You are simply an econometrician of great wisdom. I'm hoping to get a magic wand soon, direct from my friend Harry at Hogwart :)

      To Markus :
      For my own part, I think the whole issue of this post is that the estimated coefficients and t-values are not exactly the same but they do not differ much at all. I would guess it is to be linked with computation precision or something, in which case I'd survive it. But Manny may say otherwise.
      Most importantly is that results from Eviews and JMulti are not exactly compatible. Models are different in the VEC case for instance (the undetermined constant). So I cannot take JMulti as a companion of Eviews 'with more features in it' (which I hoped to do). Maybe that's why people (including myself) see differences between the two all time.
      BUT I have a simple example of a difference between Eviews and JMulti. This is about checking the residuals' properties in a VAR. The same I(1) variables are entered the same way in both softwares with the same parameters and the same 'effective' sample (206 observations !).
      Here's what I get for NON-NORMAILTY with Doornik-Hansen factorization (common feature of JMulti and Eviews)
      Eviews ------------------------------------------------
      Component    Jarque-Bera    df    Prob.
                 
      1     3.809974    2     0.1488
      2     7.660540    2     0.0217
      3     2.601981    2     0.2723
                 
      Joint     14.07250    6     0.0288
                 
      JMulti ------------------------------------------------
      joint test statistic:     84.6542
      p-value:                 0.0000 
      degrees of freedom:       6.0000 
      along with
      variable        teststat   p-Value(Chi^2)  skewness   kurtosis 
      u1              9.6469     0.0080          0.3370     3.8183  
      u2              15.6457    0.0004         -0.0859     4.3391  
      u3              25.3194    0.0000         -0.0719     4.7115  

      The only thing in common here is the degrees of freedom. Those don't appear small differences, moreover. With Eviews you conclude that there is minor non-normality mostly due to residual#2, whereas with JMulti you conclude saying that the residualsa are very non-normal because of all three residuals. Of course the skewness and kurtosis measures differ.

      So why is it that way, and which one to trust ? Dataset is ready.

       
    • Olivier_G

      Olivier_G - 2005-10-02

      Ok here I run into the same problem again...
      This is about VECM estimation with dummies so we'll disregard Eviews in here since I don't know if it works with them. I have a four variable model with two cointegrating relationships.
      Question : Why are the results via Johansen estimation and S2S estimation different ?
      I saw in help section that Johansen's method results in a beta* (star) whereas S2S methods results in a beta~ (tilda).
      In practice that is a problem to me since with Johansen I get two NON SIGNIFICANT beta coefficients for the same variable, whereas with S2S appraoch I get the two same coefficients showing up very SINGIFICANT.

      What's the deal ?

       
    • Nobody/Anonymous

      Ok guys...I found something else.
      Very confusing to me.

      I estimated VECM - Johansen with PcGive with 4 lags and with JMulTi using 3 lags.
      The estimated cointegration vectors were the same!

      Look..

      PcGive estimation:

      Cointegrated VAR (4) in:
      [0] = A
      [1] = B
      [2] = C
      [3] = D
      Unrestricted variables:
      [0] = Constant
      Restricted variables:
      [0] = Trend
      Number of lags used in the analysis: 4

      beta
      A             1.0000
      B            -0.38191
      C            -0.10843
      D            -0.11581
      Trend       0.0032508

      alpha
      A             -0.067217
      B              2.0923
      C              0.42027
      D             -0.032237

      And JMulTi:

      Loading coefficients:
                d(A)  d(B)  d(C)  d(D) 

      ec1(t-1)|   -0.067     2.092     0.420    -0.032 
              |   (0.028)   (0.404)   (0.324)   (0.052)
              |   {0.015}   {0.000}   {0.194}   {0.534}
              |  [-2.430]   [5.175]   [1.298]  [-0.621]

      Estimated cointegration relation(s):

                      ec1(t-1) 
      A(t-1)|          1.000 
                     |   (0.000)
                     |   {0.000}
                     |   [0.000]
      B(t-1)       |   -0.382 
                     |   (0.073)
                     |   {0.000}
                     |  [-5.233]
      C (t-1)|        -0.108 
                     |   (0.052)
                     |   {0.036}
                     |  [-2.100]
      C(t-1)       |   -0.116 
                     |   (0.118)
                     |   {0.326}
                     |  [-0.983]
      TREND(t-1)     |    0.003 
                     |   (0.001)
                     |   {0.001}
                     |   [3.351]

      Ok, 4 lags in PcGive means 3 lags in JMulTi.

      Question: Is this ok?
      Or is this related to the fact that in JMulTi VECM endogenous lags are in differences while in PcGive not (they are in levels)?

      Furthermore, If  t-values and p-values with JMulTi are computed via different estimation related to Eviews then this is also clear.

      If this is so, this debate can be closed and everything is ok.

      Manny

       
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks