Regarding R, and "dare i ask: is stata better than eviews?"

[Kavorka]

dare i ask: is stata better than eviews?

It is hard to deny that the competition is very tough and I am getting mocked by my colleagues for using EViews (I work at a department of Economics and Statistics). Some softwares have almost died by the competition such as Gauss and other programs.

The R-project is a free software that in the end will win over all its competitors unless EViews is able to fully integrate the routines from R into EViews. Then I mean that the programmers at EViews must make it easy for EViews' users to borrow every routine from R so that it can be inserted into the EViews code (e.g. in simulations). My prediction is that EViews and Stata will slowly die in the end if this integration between the programs is not accomplished. I know that version 7 is taking that a first step in that direction, but I would like to see a user-friendly tutorial for how to implement every routine from R into EViews (not only the 1 or 2 that can be downloaded from EViews' web page). Right now it seems a little bit complicated if this even can be done.

If you compare EViews and Stata, my subjective view is that EViews is much more user-friendly, and this is why I use it for my courses that I teach (Econometrics 1 and 2 and Time-series analysis).

Moreover, this EViews forum with extremely competent support staff is also an advantage of EViews.

Basically all my senior colleagues have swapped to R since there are no limitations. Since it is free it will continue to grow. However, if the routines could be integrated (by simultaneously running R) together with EViews then EViews is a software that can actually benefit from the progress of R. If this is not done (that is integrating R), free softwares such as R (not very user-friendly but infinitely flexible and lots of canned routines), Gretl (user-friendly but not flexible... can be used for teaching) and maybe even J-Multi will take a piece of the pie from EViews. Even if R is not as user-friendly as EViews, the students can use R at home and can also use R for free at any working place after graduation. Therefore it should be important for EViews to get into as many schools as possible since then the students will continue to use EViews even after graduation.

I had planned to drop EViews and start investing time in R, but when I bought version 7 I could see a first (but not a sufficient) step of integrating the routines of R into EViews, so I will give EViews some more time and see what happens.

(If my subjective discussion about competitors is inappropriate in this forum, I do not mind if the moderators remove my message before people read it)

To the moderators: please state what the future plans are for EViews 7 and 8 regarding integrating R routines into EViews. When I say integrated routines I will just like to call an R-routine, not open a menu. It would be important to know since then it will also be easier to convince the rest of the school that we should use EViews in the future too. Some teachers thinks that we should use a free software instead. I am very happy with EViews, but I need some more arguments for convincing the rest of the department that we should stick with EViews for the future.

Best wishes,
P

[EViews Glenn]

Kavorka,

I'm not going to comment generally since your posting is a broad discussion of a number of issues, but I do want to point out specifically that you currently can call R (and Matlab) routines from within EViews without "going through the menus". You may or may not be aware of the fact that the EViews family of x functions, xopen, xrun, and xget should allow you to, as you say, "borrow every routine from R so that it can be inserted into the EViews code".

The add-ins (with menus) that we provide are wrappers that provide an interface for people who can't or don't want to use R commands directly. As such they are somewhat involved since we have to wrap all of the options. But you shouldn't feel that you need only use the supplied interfaces when working with R in EViews. We encourage R and Matlab users to work directly with the x-functions if that approach suits them better.

You are correct that we should provide more examples on how to do this and we hope to do so as time goes by. Since the basic idea is so simple, we are still trying to determine what our users will find to be the most useful tools and idioms for working with EViews/R so that we can craft useful examples (again, any suggestions are welcome), but our manual does provide an example that shows the basics...

For example, from the manual:

'The following commands show you how to move data from EViews into R, how to use EViews to run an R command, and how to retrieve results from R into EViews.

Code: Select all

'create a workfile wfcreate u 100 'create some data series y=rnd series x1=rnd series x2=rnd 'open a connection to R with upper-case default output names xopen(type=r, case=upper) 'put regressors and dependent variable into R xput(rtype=data.frame, name=vars) y x1 x2 'run a command to perform GLM xrun "z<-glm(Y~X1+X2, family=Gamma(link=log), data=vars)" xrun "summary(z)" 'retrieve coefs xget(name=beta, type=vector) z$coef 'create EViews equation equation e1.glm(family=gamma,link=log) y c x1 x2 show e1 show beta 'close R connection xclose

The program first creates a workfile, then creates some series objects. The series Y is the dependent variable, and the series X1 and X2 and a constant are regressors. xopen is used to open a connection to R, and then xput is used to pass the series into an R data.frame container, which we name "VARS". Note that the names of the data.frame, and its contents are all uppercased in R since the connection was opened with the "case=upper" option.

xrun is used to estimate a GLM equation in R, with the results being stored in a GLM output object, "z". xget is used to retrieve the coefficient member of z back into EViews, where it is stored as a vector called BETA.

Finally, the same GLM specification is estimated inside EViews, and the coefficient estimates are shown on the screen for comparison.

The bottom line is that if you have your EViews data in a workfile, all you have to do is to open an R connection using xopen, put the data using xput, run the R command using xrun, and get results using xget. We viewed these functions as a good first step toward integration that covered a wide range of applications. To be honest, we haven't had much feedback on R integration; if there are additional integration tools that you think would be useful, we would be happy to hear suggestions.

Lastly, this discussion is useful for all to see but probably won't be found in its current location. I'm recommending that the moderators move it to somewhere more appropriate. Alternately, if you'd like to create a new topic about R integration in, say the programming forum, we can comment on it there.

Thanks for the suggestion. Hope my comments have been useful.

[Kavorka]

Thanks for good feedback!

For me, one of the main advantages of EViews is that it can be used on different levels of academia, so that one does not need to swap software too often (due to the integration of R). I appreciate EViews' user-friendlyness so that it can be used for teaching undergraduates (so that the students can focus on understanding applied statistics/econometrics instead of only focusing on problem solving and syntax exercises... which in the end will lead to mechanical problem solving instead of real understanding of statistics). Therefore, EViews is optimal for teaching purposes. Since EViews (apparently) can be used for integrating R (and also Matlab), the same students do not need change software for their post graduate studies (and not even for their post doc years). Since routines can be borrowed from R there will be no limitations for EViews users any longer. As from now, EViews can be used on all levels in academia. In my school some teachers use R for teaching undergraduates, but I use EViews since it is more user-friendly. For new undergraduates, I think that it is better to focus on statistical theory (for beginners) instead of focusing on coding.

However, what is really needed, is to market that it is possible to integrate R with EViews. No one at my department of economics and statistics knew this. It is more convenient to use the same software both for teaching and research. But, first some better instructions must be available (since the EViews' niche in the market is that it is a flexible BUT USER-FRIENDLY software... otherwise people would use R since it is free). Therefore there must be user-friendly instructions for how to integrate R into EViews.

Consequently, when you have time I would suggest that you would give a real cookbook step-by-step example on R integration. I have to admit that I should am not 100% sure that there are no such examples, so please correct me if there is already such an example somewhere. Such hands-on example(s) would include:

1. Data (if the data is generated, put in a random seed so that the result can be replicated)
2. A link to where routines can be found for R (a link to where to download R etc.)
3. The entire code should be included so that a beginner could get an output (it can be frustrating if there is only one comma that is missing in my amateur code, so if one can start with something that works... this would help and save time and frustration)

You could have one example with really clean and simple code, and another more advanced example so that we can see what COULD be done (if one has the knowledge). Most important is that the the example is not explained only in theory, it should be a complete example of all the steps (save it in the end as a *.prg-file).

If there would be one or two such examples, we who are not experts could just copy and paste some code and continue to use EViews but with the access of all routines from R.

With this integration EViews would be able to compete with the free user-friendly beginner softwares such as Gretl, and also be able to (in a user-friendly way) access all the routines from R. Using only 1 software is worth a lot to me and most likely to others. The barriers of swapping to a new software are high, so it is important to have a software that works on all levels (otherwise people would not choose EViews, if the from the beginning know that they need to change to R or Matlab when they become post graduates or post docs). If more researcher would use EViews for their research, then they will more often use it when teaching undergraduates. These undergraduates will later on see no point in changing software when when they become post graduates (if EViews will access R routines in a user-friendly way). Therefore, in my opinion having one software that works on all levels is important... thus, R integration is very important.

This letter became longer than planned (sorry for this) and I should definitely not tell you how to run things - but anyway, this is my opinion!

/P

[EViews Gareth]

It is true that, perhaps, we could do a better job of letting our users know what is new in each edition, although we do email and send pamphlets out to existing users explaining what is new when we release a new version.

With regards to your suggestions for a concrete example - isn't that exactly what the code that Glenn posted above is? It is a section of code that can be copied and pasted into a .prg file and run alone. It generates its own data, and then shows you how to send that data over to R, perform a built in R routine, and then bring the results back to EViews. It is printed in the manual, as well as being posted above.

[EViews Glenn]

The example above doesn't do the first step, configure the application and download the R-module part, though that too is in the manual a little before the snippet that I provided above.

That said, I agree with the general comments of the op, and welcome the suggestion to produce more examples/documentation. Is there a concrete example that you would like to see us work up? If we do this right, we can crowd-source the step-by-step document that you'd like to see. :D

[terrya]

The example above doesn't do the first step, configure the application and download the R-module part, though that too is in the manual a little before the snippet that I provided above.

That said, I agree with the general comments of the op, and welcome the suggestion to produce more examples/documentation. Is there a concrete example that you would like to see us work up? If we do this right, we can crowd-source the step-by-step document that you'd like to see. :D

If I might ask as part of this discussion, is it possible to use, for example, R's spectral analysis routines via EViews? I haven't tried anything yet, other than running the example programme, as I'm just beginning to come to grips with R.

I would also like to add that your information in the Guide about how to install R is great. I followed it and had no trouble installing it.

[EViews Gareth]

I see no reason why spectral analysis routines wouldn't work. I haven't tried it myself, but having tried calling a number of different R routines, I haven't had too many problems.

The only issue is that some R routines expect the data to be in a specific format. Some require it as a data.frame, others require a vector etc... In such cases you might have to use the rtype= option in xput to ensure that the data is being send across in the correct format.

[terrya]

I see no reason why spectral analysis routines wouldn't work. I haven't tried it myself, but having tried calling a number of different R routines, I haven't had too many problems.

The only issue is that some R routines expect the data to be in a specific format. Some require it as a data.frame, others require a vector etc... In such cases you might have to use the rtype= option in xput to ensure that the data is being send across in the correct format.

Thanks

[Kavorka]

Gareth is most likely correct, and I am not offended by his rather clear comment (I probably deserved it, but I was only trying explain how many amateur users may be thinking). Most of us are lazy and we want to save time and we want as easy solutions as possible. The easier the better... and the more documentation the better...

In all honesty, I have yet not tried to integrate R yet (since I did not know that it was possible until a couple of months ago and since then I have taught 3 courses simultaneously so I have not had the time),... and moreover because it sounded more complicated that what it probably is. However, still a couple of more examples for dummies would probably not hurt.

Many of us have less time than what we would like to have, therefore user-friendlyness is extremely important, otherwise everyone would work with free softwares which also could do the job.

In summary, Gareth, you definitely have a point that everyone could probably figure everything out (but most people are lazy to a higher of lower extent), so some some more examples would not hurt... and more people would probably be interested in EViews.

Please, continue with your good support work of EViews, I do indeed like it, and if you do not think that I have a point, I will not be offended if you throw this letter in the dustbin. I can take that!

Best wishes,
/P