Compare EViews | Gekko Timeseries and Modeling Software

Compare: AREMOS

Compare with EViews

This section compares EViews (version 8) modules and functionality with Gekko 2.0 (as of December 2015). Please note that since then, Gekko 3.0 has been released, containing many new features compared to 2.0.

The comparison is limited to data management purposes, where the following questions can be raised. (This section is taken originally from the user manual)

EViews for data management purposes

EViews is indeed a polished and professional software product. It is not the intention here to judge the EViews capabilities regarding model solving or econometrics, but instead we will take a look at EViews for data management purposes (on timeseries data).

The following points may be biased, or even wrong (comments are appreciated), but they reflect an honest attempt to perform some timeseries related tasks in EViews, as compared to running them in Gekko.

When you open up EViews with a new ‘workfile’, it seems a bit cumbersome that the user always as the first thing has to pick out a sample (period) for the work file. Workfiles can have ‘pages’ (a bit like tabs in Excel), and for each page there seems to be a global sample period (defined once and for all) and fixed frequency. So if there are several frequencies, these seem to have to live on separate pages in the workfile. The databank/workfile format seems proprietary and undocumented, in contrast to the open-format Gekko databanks (protobuffers). [Edit January 2023: EViews now has an open .wf2 format, based on .json. This will probably not be very fast for large datasets, but at least it is open).
It does not seem possible to refer directly to objects on other pages or workfiles. These have to be copied/cloned first, before use. For instance “copy wf1::page1\ser1”, but it does not seem possible to use “wf1::page1\ser1” in expressions (in contrast to Gekko’s use of colon). This will result in quite a lot of copying, and then the user must remember to delete these objects afterwards.
It does not seem possible to obtain a line-by-line execution of commands (like in Gekko or AREMOS or other packages). The EViews user can run a whole file ‘batch’, or a block of commands can be marked and executed by right-clicking and choosing in the menu. The only way to run a single command line seems to be to mark it, right-click it, and choose ‘Run selected’ (for which there is no short-cut). But even if the user does this, there is for instance a problem with executing the lines “%s = “hello”” and “show %s” one by one. After the first line is executed, %s no longer exists in memory when it is to be shown in the second line (this variable only seems to live while the first line is executing). So these two lines must be executed as one block, and cannot be tried out separately.
Apparently, EViews does not provide the line number, when errors occur, neither for marked blocks of commands (run from the command window), or from batch/command files run with EXEC. This is not very user-friendly when running larger files/systems. The user can see the file involved, and how the offending line looks. But EViews inserts concrete values from control variables, so the user may receive an error like “!m is not defined or is an illegal command in ‘!m = 0 + 0′”, in stead of a raw depiction of the line (“!m = !m + !k”). Sometimes it can be convenient to see the concrete value of control variables in a line, but this does not make it easier to locate the line in a command file…
In the main window, there does not seem to be a dedicated output window (like the upper part of the main window in Gekko, or the main window in AREMOS). Instead, there are floating sub-windows. If, as an example, the user wants to print out a scalar or timeseries, it only seems possible by means of opening up a sub-window with that content (in a kind of mini-spreadsheet). Maybe there are other ways to do it, but if not, quite a lot of sub-windows may clutter the working area (and these, by the way, do not seem to be closeable with the Escape key). As an consequence, back-browsing/looking in the output window like in Gekko or AREMOS does not seem possible. Related to this, it seems a bit odd that printing out a text string via “show %s” opens up a whole new sub-window and shows the result in a mini-spreadsheet with the value of the string shown for each observation in the sample. Isn’t it possible to use a TELL command like in Gekko or AREMOS? Using “print %s” seems to send the results to the printer…
User-defined functions do not seem possible in EViews. It is possible to design user-defined procedures, and these can return stuff via their ingoing arguments. But it is not possible to have a function that returns something that can be used directly as an argument in other places/functions. So it does not seem possible to design a user-defined function product(x, y), where product(2, 3) = 6, and product(product(2,3), 4) = 24. This seems like a serious limitation, and such functions do not seem to be underway according the the EViews user forums.
Dates seem to be internally represented as strings in EViews. In order to ‘calculate’ on such dates, it seems necessary to use the functions @dtoo() og @otod(), that is, date-to-observationindex and observationindex-to-date, respectively. These functions obtain the number of observations from the start period of the workfile itself, relative to some date written as a text string. But if you need an ‘offset’ of dates (for instance, adding five periods to some date %t), it seems necessary to use something like this: %tt = @otod(@dtoo(%t)+5); !x = @elem(y1, %tt). Of if you need to find the timeseries observations that in Gekko would be VAL x = y1[%t+5], in EViews it seems necessary to write something like this: !x = @elem(y1, @otod(@dtoo(@str(!t))+5)). Since EViews does not have user-defined functions, this is proabably not something that could be hidden/wrappted inside a function. Correspondingly, refererence like for instance y1[2010] seem a bit cumbersome to write in EViews, since it seems to involve writing @elem(fy, “2010:1”). Normal lags in timeseries, however, are non-problematic and are written like y1(-1) etc.
In a similar vein, it seems involved to set some observation of a timeseries to some particular value. In order to do what in Gekko would be “SERIES <2010m1 2010m1> fy = fx[2000m1];” seems to involve the following in EViews: “smpl 2010m1 2010m1; fy = @elem(fx, “2000m1″); smpl @all;”. It seems necessary to alter the globals sample period to do this in EViews.
The EViews syntax originally origins from TSP, since EViews origins from MicroTSP, which again stems from TSP. It is probably a matter of taste, but somehow the syntax of EViews seems a little bit old-fashioned, for instance with its use of blanks instead of commads to separate items.
It seems a bit strange that the EViews user can operate with both string-replacement variables (%s) on the one hand, and simultaneously on the other hand operate with string-objects (that can live in a workfile). These have almost the same functionality, so why two types? The same goes for scalars, where you can either use the control variable !x, or a corresponding scalar object. The reasons are probably historical, but it is a bit confusing.
EViews does not seem to compile command files into executable code, but seems to use a so-called interpreter instead. This hampers the execution speed of EViews command files, even though EViews itself is written in (speedy) C++. The speed of model simulations has not been tested, since this is not the focus of the present section.