M@ximize 1.1, or how to bridge the gap between cml, maxlik, optmum and Ox.

Preamble

Important new technical advances have been made in theoretical econometrics over the past few years. Due to the ever increasing use of computer intensive modelling techniques and estimation methods, applied econometricians are more and more facing the dire need to write programs with the aim of implementing these recently developed techniques. While some pre-packaged routines are often made available in standard econometric software like RATS or TSP, most of the latest technical advances are not so rapidly introduced in these softwares. For example, the estimation of various non-linear time series models requires high computing skills from the researcher. Real world applications of computer intensive techniques like bootstrap inferences, indirect inferences, non-parametric and semi-parametric analyzes also require efficient programming. In all theses cases, researchers will have to put their shoulders to the wheel. As pointed out by Cribari-Neto and Zarkos (2003) in their review of Ox, programming forces a researcher to think more deeply into the issue that is being investigated. It may however sometimes be rather inefficient to programme complex procedures, estimation techniques that have already been used and programmed by other researchers for the sole purpose of application or replication of results.

The replicability of simulation and empirical results in econometrics is recognized as being a fairly important aspect of research as exemplified by the practice of the Journal of Applied Econometrics that asks authors to make their data and possibly specialized codes available to the potentially interested reader. The availability of these enables the reader to replicate the results obtained in a particular study. Not surprisingly, an increasing number of researchers in econometrics are making their codes and routines freely available to the econometrics community. This has led to an increase in the exchange of routines that were initially prepared by researchers for their own work, often with the aim of illustrating theoretical advances using some Monte Carlo simulations or real data sets.

Sharing codes has hence become a fairly standard practice in econometrics. Of the various programming environments used in econometrics, Gauss is probably one of the most, if not the most, popular programming environments for the last two decades along with S-Plus, Matlab and now Ox. The many codes available through several Gauss archives provide for the applied researcher a unique and important opportunity to implement procedures that are otherwise often demanding to programme.

The many codes available through several Gauss archives give the applied researcher a unique and important opportunity to implement procedures that are otherwise often demanding to programme. However, the researcher who is willing to replicate or to apply these freely available techniques should already be a Gauss user or should at least have a direct access to a legally registered version of Gauss. Moreover, the price of many software packages (including Gauss) has increased substantially over the last few years, making the acquisition of these packages very costly to small research groups or, more importantly, to researchers located in third world countries where financial resources are rather scare.

Besides the whole GNU project, several statisticians and econometricians have made a number of softwares freely available, at least to academics and students. These include Easyreg, ECTS, Vista (Visual Statistics System), GRETEL (Gnu Regression, Econometrics and Time-series Library), or some low-cost alternatives or clowns of Matlab (O-Matrix, Octave) and (R). Although these softwares are very useful for empirical research given the wide range of tools offered, they still do not give the opportunity to benefit from the impressive Gauss code archive.

For all these reasons, OxGauss fulfils a genuine need in that it provides the researcher with a free and rather simple solution to run Gauss codes. The advantage of OxGauss is that, even with the console version (free for academics), Gauss codes can be called from Ox programs, or can be run and executed on their own. OxGauss has in this sense similar possibilities than O-matrix that can run most Matlab codes; but the crucial difference is that OxGauss comes freely with the console version of Ox.

While OxGauss is in many situations very powerful, it becomes of little use at least in two situations. First, it is important at this stage to emphasize that, in terms of compatibility, OxGauss is currently not designed to run (or call) Gauss procedures making use of new features specific to Gauss 4.0 and 5.0. Indeed, OxGauss only supports Gauss versions 3.2 and 3.5. Second, OxGauss is useless once the purpose is to execute a program that attempts to solve an optimization problem using one of the three well know Gauss application modules Cml, Maxlik or Optmum. This was already noted by Philip Viton " ... not every piece of Gauss code will be convertable to OxGauss. As we've seen, one important case is when it uses Gauss's Maxlik procedure; or more generally, other extra-cost Gauss add-ons. Even in the Maxlik case it may be possible to substitute Ox's own optimization routine; if anyone knows how to do this, I'd like to know. In the mixed-logit case we were fortunate in being provided with an alternative optimization routine domax written in Gauss as a substitute to Maxlik; and this could be converted. So another possibility is to map Maxlik and its output generally to domax. Again, if anyone does this and would like to explain it, I'd be glad to include the information here."

We propose to fix this second limitation of OxGauss. In particular, we propose a set of additional procedures (gathered in the M@ximize package) that contribute to bridge the gap between Ox and the above mentioned optimizers.

Program Version

The current version of the package is v.1.1.

What's new in version 1.1?

Thanks to Charles Bos: Better compatibility with GnuDraw and linux.

Disclaimer

This package is functional but no warranty is given whatsoever. The most appropriate way to discuss about problems and issues of the M@ximize package is the Ox-users forum. Suggestions, mistakes, typos and possible improvements can be reported to the authors via e-mail: s.laurent@maastrichtuniversity.nl for Sébastien and j.urbain@maastrichtuniversity.nl for Jean-Pierre.

Availability and Citation

The M@ximize package is available for downloading at the following address:

Download

M@ximize 1.1 package.
Bridging the Gap Between Ox and Gauss using OxGauss, by S. Laurent and J.P. Urbain. Version: 10/07/2003

What is OxGauss ?

OxGauss is an integral part of Ox. It is important for non-Ox users or newcomers to point out once again that, in contrast to the old g2ox.exe program provided with Ox, OxGauss is not a translator from Gauss to Ox.

OxGauss enables a user (even of the console version) of Ox to:

1. call an existing Gauss code (procedure) under Ox in a similar way than one can call C (dll) or fortran codes from Gauss and Ox;
2. run a pure Gauss code.

Depending on the goal of the analysis and on the experience of the user, both use can prove to be particularly useful. From an Ox user point of view, the main objective of OxGauss is probably to allow the many existing Gauss codes to be called from Ox with only a minimum of changes to these codes. This is beneficial to both the Ox user and the writer of the Gauss codes as it increases the visibility and hence the potential use of the underlying statistical technique. This may also help in the transition from Gauss to Ox if this is the purpose of the exercise. On the other hand, running a pure Gauss code with OxGauss is attractive for the non-Gauss and potentially even non-Ox users in that it makes the replication of published work (theoretical MC simulations, empirical examples) possible using the free version of Ox. The following two subsections briefly summarize what we believe are the two main advantages of using OxGauss currently.

Calling OxGauss from Ox

The main objective of OxGauss is probably to allow Gauss code to be called from Ox. This helps in the transition to Ox, and increases the amount of code that is available to users of Ox.

As an example we consider a small project (download here the zip file) that mixes both Gauss and Ox codes. The first file, Gaussprocs.src, consists of a code file containing the procedure gengarch(omega,alpha,beta,nu,T_0,T,n) that simulates a GARCH model. As most of the Gauss codes available on the internet, it is provided with a very detailed preamble that explains the meaning of its inputs and gives information concerning its output. This procedure has been written by Dick van Dijk and is downloadable from his web site.

To call this procedure from an Ox code, one first has to create an header file. The second file, Gaussprocs.h is actually this header file and consists of the following instructions:

                                                                                           Gaussprocs.h

namespace gauss
{
	gengarch(const omega,const alpha,const beta,const nu,const T_0,const T, const n);
	// Add new procedures
}
 

The header file communicates the declaration of functions, constants and external variables. Additional procedures can be added in Gaussprocs.src but the header file has to be modified accordingly. We shall always use the .src extension for the Gauss programs and .h for the header files.

In the example GarchEstim.ox, we use the Gauss procedure to generate 20.000 observations following a GARCH(1,1) process with Student-t errors and then, rely on Ox package G@RCH 3.0 to estimate a GARCH(1,1) model by Quasi-Maximum likelihood. Do to that, the OxGauss code must be imported into the Ox program, together with the G@RCH package. The #import command has been extended to recognize OxGauss imports by prefixing the file name with gauss::.

                                                                                          GarchEstim.ox

Note that when the OxGauss functions or variables are accessed, they must also be prefixed with the identifier gauss::. To run this program on the command line, enter oxl GarchEstim.ox. Alternatively, it can be launched from OxEdit. Indeed, OxEdit is a free but powerful text editor provided with both versions of Ox. Like Oxmetrics Desktop, OxEdit supports syntax colouring of Ox programs, and context-sensitive help. The first time you use OxEdit, execute the Preferences/Add Predefined Modules menu and select Ox. From then on you can run your Ox and Gauss programs from the Modules menu, without leaving OxEdit. See also the OxEdit web page for more details. Finally, users of the Ox Professional can run Ox codes within Oxmetrics Desktop by using the menu Modules/Start OxRun.

Running Gauss codes

The second potentially attractive feature of Oxgauss is to enable the user to directly run a wide range of Gauss programs under Ox.

As an example, we consider the Gauss package Mixed Logit Estimation Routine for Panel Data of Kenneth Train, David Revelt and Paul Ruud. The archive file train0299.zip contains seven files including the code file mxlp.g and the data. This program has been written by Kenneth Train and used by this author in a collection of papers (see the web site above for more details) dealing with mixed logit models. Note that Mixed logit (also called random-parameters logit) generalizes standard logit by allowing the parameter associated with each observed variable (e.g., its coefficient) to vary randomly across units (e.g. individuals or customers).

This program (mxlp.g) can be run on the command line by entering oxl -g mxlp.g.

Alternatively, it can be launched from OxEdit (Modules/OxGauss menu)

or within Oxmetrics Desktop by using the menu Modules/Start OxGauss.

Note that while the previous versions of OxGauss required a few modifications on the codes, the program is now almost fully compatible with the new version. The only problem is that the program estimates the model by maximum likelihood, giving the opportunity to the user to chose the maximization routine domax of Paul Ruud or the commercial package maxlik. Launching the program could lead to the following error message:

C:\...path...\mxlp.g (1372): ’maxlik’ file not found
C:\...path...\mxlp.g (1373): ’maxlik.ext’ include file not found

To solve this problem one can either comment out lines 421 to 451 concerning the add-on maxlik (and use the domax procedure, i.e. the default option OPTIM=1 in the program) or install the M@ximize package. Table 1 below reports the estimated parameters obtained using Gauss 3.2 and OxGauss. As expected, they are very similar, if not identical (the only difference is detected after the sixth decimal of the standard errors).

Table:1 Estimated parameters produced by mxlp.q using OxGauss and Gauss 3.2 and the maximization routine domax of Paul Ruud

2.3 Understanding OxGauss

When an OxGauss program is run, it automatically includes the \include\oxgauss.ox file. This itself imports the required files:

These import statements ensure that g2ox.h and oxgauss.h are being included. The majority of the OxGauss run-time system is in \include\g2ox.ox while the keywords are largely in oxgauss.src.

A nice feature of OxGauss is its transparency since most of the codes that link Gauss functions to Ox are gathered in the file \include\g2ox.ox. Suppose one wishes to use the Gauss function seqa(const start, const inc, const m) that creates an additive sequence. Recall that start is a scalar specifying the first element of the sequence, inc is a scalar specifying the increment and n is a scalar specifying the number of elements in the sequence. The output is a column vector containing the specified sequence. A similar function is available in Ox: range(const min, const max, const step), where min and max are integers or doubles specifying respectively the first and last values of the sequence, and step is an integer or double specifying the increment. The output is a row vector containing the specified sequence.

The Ox code here below (copy from the file g2ox.ox) shows how OxGauss makes the link between these two functions.

From this example, it is clear from that OxGauss does not translates the Gauss code in to Ox but makes the link between the Gauss function (here seqa) and its Ox counterpart (here range)

Recall that, in terms of compatibility, OxGauss is currently not designed to run (or call) Gauss procedures making use of new features specific to Gauss 4.0 and 5.0. While this can be seen as a drawback from the current version of Oxgauss, one should emphasize again the open source character of Oxgauss that implies that the users are free to provide and add further procedures that exploit specific Gauss 4.0 or Gauss 5.0 features. For this reason, when comparing OxGauss and Gauss, we will only consider Gauss 3.2 and 3.5 to ensure maximum compatibility even if we know that this will bias the conclusions that can be drawn from our comparisons. Oxgauss being by definition a "work in constant progress", compatibility with specific Gauss 4 and 5 features is desirable.

Tables A1 and A2 give a list of all the Gauss functions supported by OxGauss. To simplify the reading of the list, we report pre-compiled functions (or directly mapped functions) like sin in Table A1 and open source functions (like seqa, see above) in Table A2. Adding adding all the functions leads to a total of 420 functions recognized by OxGauss. Table A3 in the appendix gives a list of 64 Gauss functions not supported by the current version of Ox (or about 15%).

It is important to note that "Function name"() unsupported will be printed whenever the user calls or uses a Gauss function that is currently not supported by OxGauss. For instance, there is no equivalent of the Gauss function intgrat2 (for the computation of double integrals) in Ox 3.3. For this reason, the corresponding procedure in OxGauss.ox just reports the error message intgrat2() unsupported (see below).

If such a function becomes available in a next version of Ox, mapping ingrat2 to the corresponding function in Ox will be a child's play!

Graphs using GnuDraw

While most graphical features of Gauss are recognized by OxGauss via Ox Professional, Oxconsole has no graphs support. Nevertheless, the user of the console version can rely on the Ox package GnuDraw developed by Charles Bos that allows the creation of GnuPlot graphics from Ox. The package is free of charge and is downloadable from his homepage, together with the GnuPlot software. When using Ox, GnuPlot can be called automatically from within Ox. Usage of GnuDraw is intended to be simple - see Cribari-Neto and Zarkos (2003) for a comprehensive overview of the GnuDraw package.

Interestingly, as OxGauss implements just a layer over Ox, it is possible to instruct the underlying Gauss to call GnuDraw routines instead of the OxDraw routines. The program gnuGauss.prg implements this (download here the zip file).  

To use GnuDraw from OxGauss, no change to the Gauss programma is needed at all. The Ox executable will default to using GnuDraw when the program is started using
oxl -DGNUDRAW -g GnuGauss.prg. The option -DGNUDRAW defines the token GNUDRAW, triggering the use of GnuDraw instead of OxDraw.

Alternatively, if you use OxEdit (1.62 or later) you can launch using the menu Modules/OxGauss(OxEdit/GnuDraw).

Here is the graph obtained with GnuDraw.

See the file packages/gnudraw/doc/gnudraw.html for gnudraw-specific explanations.

Some larger projects using M@ximize

The main drawback of OxGauss is that it is not suited to run Gauss codes that make use of commercial packages. For instance OxGauss reports an error message if the Gauss code requires one of the well known optimizators Cml, Maxlik, or Optmum. This makes OxGauss useless in many situations. To overcome this problem, we propose a set of three procedures that make the link between the optimizators of Ox 3.3 and the main options of the optimizators of Gauss. Note that we do not translate the Gauss optimizators into Ox but we just link the options. To install the package M@ximize, unzip the main file into the Ox directory. The objective of this section is to give several concrete examples, and address some of the issues that can be encountered. As explained above, the main reason for using OxGauss is probably to replicate the results obtained in a research paper. To test OxGauss and M@ximize 1.0 in a real-life situation, we have downloaded from the internet a huge number of Gauss codes. Here is a list of five web sites that we have visited together with a zip file containing the data and the programs:

• James Hamilton: Download here
• Bruce Hansen: Download here
• Chang-Jin Kim: Download here
• Luc Bauwens: Download here
• Rolf Tschering: Download here

From these web sites we have found both the data and the Gauss codes used in a collection of articles. In addition, we have used the codes provided by Kim and Nelson (1999) in their book on markov-switching models (chapters 3 to 11). A list of papers we have replicated is available here below. Almost all these codes rely on non-linear optimization technique and thus require one the three above mentioned optimizators of Gauss.

 

1.	Hamilton, J. (1994): State-Space Models, in Handbook of Econometrics, Volume 4, 3039--3080, edited by R.F. Engle and D., McFadden, Amsterdam: North Holland.
2.	Hamilton, J. (1996): "The Daily Market for Federal Funds", Journal of Political Economy, pp. 26--56.
3.	Hamilton, J. (1996): "Specification Testing in Markov-Switching Time-Series Models", Journal of Econometrics, 70, 127--157.
4.	Hamilton, J., and C. Engle (1990): "Long Swings in the Exchange Rate: Are They in the Data and Do Markets Know It?", American Economic Review, pp. 689--713.
5.	Hamilton, J., and O. Jorda (2002): "A Model for the Federal Funds Rate Target", Journal of Political Economy, 110, 1135--1167.
6.	Hamilton, J., and G. Lin (1996): "Stock Market Volatility and the Business Cycle", Journal of Applied Econometrics, 11, 573--593.
7.	Hamilton, J., and G. Perez-Quiros (1996): "What Do the Leading Indicators Lead?", Journal of Business, 69, 27--49.
8.	Hamilton, J., and R. Susmel (1994): "Autoregressive Conditional Heteroskedasticity and Changes in Regime", Journal of Econometrics, 64, 307--333.
9.	Bauwens, L. M. Lubrano (1998): Bayesian Inference on GARCH models using the Gibbs Sampler, The Econometrics Journal, 1, C23-C46.
10.	Hansen, B. (1992): "Tests for Parameter Instability in Regressions with I(1) Processes", Journal of Business and Economic Statistics, 10, 321-335.
11.	Hansen, B. (1992): "Testing for Parameter Instability in Linear Models", Journal of Policy Modeling, 14, 517-533.
12.	Hansen, B. (1992): "The likelihood Ratio Test under Non-standard Conditions: Testing the Markov Switching Model of GNP", Journal of Applied Econometrics, 7, S61-S82.
13.	Hansen, B. (1994): "Autoregressive Conditional Density Estimation", International Economic Review, 35, 705-730.
14.	Hansen, B. (1996): "Inference when a Nuisance Parameter is not Identified under the Null Hypothesis", Econometrica, 64, 413-430.
15.	Hansen, B. and A. Gregory (1996): "Residual-based Tests for Cointegration in Models with Regime Shifts", Journal of Econometrics, 70, 99-126.
16.	Hansen, B. (1997): "Approximate Asymptotic p-values for Structural Change Tests", Journal of Business and Economic Statistics, 15, 60-67.
17.	Hansen, B. (1997): "Inference in TAR Models", Studies in Nonlinear Dynamics and Econometrics, 2, 1-14.
18.	Hansen, B. (1999): "Testing for Linearity", Journal of Economic Surveys, 13, 551-576.
19.	Hansen, B. (2000): "Sample Splitting and Threshold Estimation", Econometrica, 68, 575-603.
20.	Hansen, B. (2000): "Testing for Structural Change in Conditional Models", Journal of Econometrics, 97, 93-115.
21.	Hansen, B. and M. Caner (2000): "Threshold Autoregression with a Unit Root", Econometrica, 69, 1555-1596.
22.	Hansen, B., D. Cox and E. Jimenez: "How Responsive are Private Transfers to Income? Evidence from a Laissez-faire Economy", forthcoming in Journal of the Public Economics.
23.	Hansen, B. and B. Seo (2002): "Testing for Threshold Cointegration", Journal of Econometrics, 110, 293-318.
24.	Hansen, B. (2001): "The New Econometrics of Structural Change: Dating Changes in U.S. Labor Productivity", Journal of Economic Perspectives, 15, 117-128.
25.	Hansen, B.: "Recounts from Undervotes: Evidence from the 2000 Presidential Election", forthcoming in Journal of the American Statistical Association.
26.	Kim, C.-J. and C. Nelson (1999): State-Space Models with Regime Switching: Classical and Gibbs-Sampling Approaches with Applications, The MIT Press.
27.	Yang, L. and R. Tschernig (1999): "Multivariate Bandwidth Selection for Local Linear Regression", Journal of the Royal Statistical Society, Series B, 61, 793-815.

While most of the codes can be run in their present form some changes are sometimes needed. Here is a list of the most frequently encountered problems:

• Converting data files. For instance, when running example 22 in Table 2 gives the ‘Invalid .FMT or .DAT file’ error message. The reason is that old style Gauss data sets (v89 .dht/.dat) must be converted to the new Gauss format (v96 .dat). The program to do this conversion is ox/lib/dht2dat. The conversion can be run from the command line as:

  oxl lib/dht2dat old_datafile.dht new_datafile.dat
  

  Alternatively, the data files can be converted to the new format through Oxmetrics Desktop by loading first the .dht file and second saving the file into the new format.

• Absence of extension. To launch a Gauss code using OxEdit, the file needs an extension. It is common to use the extension .src.
• Interactive mode. Examples 1, 6, 9 and 13 use the Gauss function cons that requests an input from the keyboard (console) and puts it into a string. The typical use of this function is to generate a message like "Do you wish to continue (y or n)?". Depending of the result the program takes one direction or the another. In other words, the program enters in an interactive mode. In such a case the program has to be launched using "Ox interactive", i.e. Oxli.exe under Windows instead of Oxl.exe.
  When using OxEdit to run the Gauss code, an additional shortcut has to be created. The simple solution is to click on the menu View/Preferences/Add/Remove Modules. Then clone the OxGauss shortcut and in the Command line change Oxl.exe by Oxli.exe.

As illustration, we consider the Gauss package written by Rolf Tschernig for his Journal of the Royal Statistical Society, Series B paper (number 27 in the table). We focus on the example file provided be the author, i.e. multband.tes. This file is made up of about 190 lines of Gauss code and includes three libraries, i.e. Optmum, pgraph and multband (a library provided by the author) as well as a set of three dll files. To use the package under Gauss, one has first to install the library multband by first copying the file multband.lcg into the subdirectory ./lib of Gauss and second the files multband.src (about 2900 lines of code) and multband.dec (declarations of global variables) into the subdirectory ./src. Finally, to complete the installation, one has to copy the three dll files locling.dll, density.dll and loccubg.dll into the subdirectory ./dlib. Importantly, to use the package under OxGauss, one has to follow the same instructions and copy the files into the existing subdirectories ./OxGauss/lib, ./OxGauss/src and ./OxGauss/dlib.

Now the example file multband.tes can be executed. Note that this example file simulates a sequence of 250 observations. To make the comparison between Gauss and OxGauss possible we have changed the original code that now always uses (load) the same random numbers.

The outputs obtained with OxGauss (left) and Gauss 3.2 (right) are reported below. Once again, we see that even with this very complex program (that uses dll files and an external library) the program does not report a compilation error and gives very similar results.

Ox version 3.30 (Windows) (C) J.A. Doornik, 1994-2003
hdrot_ll: chosen block: 2.0000000 1.0000000	hdrot_ll: chosen block: 2.0000000 1.0000000
Results from bandrot.g	Results from bandrot.g
h_ROT	h_ROT
0.051626512	0.051626512
0.051626512	0.051626512
hd_ROT	hd_ROT
0.044616931	0.044616919
0.064029894	0.064029901
B_hat 0.23183482	B_hat 0.23183482
Cm_hat	Cm_hat
5535.4077 477.33950	5535.4077 477.33950
477.33950 1305.0202	477.33950 1305.0202
C_hat 7795.1069	C_hat 7795.1069
hdrot_ll: chosen block: 2.0000000 1.0000000	hdrot_ll: chosen block: 2.0000000 1.0000000
hcdrotlp: chosen block: 2.0000000 1.0000000	hcdrotlp: chosen block: 2.0000000 1.0000000
hcdrotlp: Blamu	hcdrotlp: Blamu
78617.709 -3421.7567	78617.709 -3421.7567
-4919.6541 80.592526	-4919.6541 80.592526
Results from bandpi.g	Results from bandpi.g
h_PI	h_PI
0.076176271	0.076176271
0.076176271	0.076176271
hd_PI	hd_PI
0.082851089	0.082851007
0.064612911	0.064612978
Bd_hat 0.37280023	Bd_hat 0.37280024
hd_ROT	hd_ROT
0.044616931	0.044616919
0.064029894	0.064029901
C_hat 1227.6312	C_hat 1227.6312
hC_ROT 0.18391889	hC_ROT 0.18391889
Cm_hat	Cm_hat
458.95790 18.900462	458.95789 18.900464
18.900462 1240.7565	18.900464 1240.7565
hCd_ROT	hCd_ROT
0.16024143 0.17575527	0.16024143 0.17575527
0.17575527 0.37881573	0.17575527 0.37881573