Frequently Asked Questions

This page lists some common questions and problems and what you can do if you encounter them.

Problems that Appear to be System or Program Related

Are LIMDEP and NLOGIT compatible with Windows, including Vista?

Yes, LIMDEP and NLOGIT are generally compatible with Vista and other versions of Windows operating systems since Windows 95. Note that the Help systems used by LIMDEP and NLOGIT are no longer installed as standard in Windows Vista, and Microsoft has released an update (details below). For other Windows operating systems since Windows 95, there are a small handful of cases with computer specific DLL file incompatibilities that may be resolved with the downloads listed in the relevant questions below.

The LIMDEP (NLOGIT) Help program does not work with my new computer. I am running Windows Vista.

The LIMDEP (NLOGIT) Help program is an .HLP file, which is a special file type for Windows. In order to run a Help program of this sort, LIMDEP needs to use a part of Windows, WinHlp32.exe, that Microsoft had included with all operating systems since Windows 3.1. With the release of Vista, Microsoft decided to terminate support for this file type. The Help files of all software programs that use this feature of Windows (and that will be many, not just ours), will now be disabled. There was no public announcement of this decision; developers simply found out about it after the release of Vista. The official policy is now posted on Microsoft’s website:

http://support.microsoft.com/kb/917607

Microsoft has decided to provide a download that will work with Vista, but, they promise, will not be available for their ‘next’ operating system. The download is available at:

http://go.microsoft.com/fwlink/?LinkID=82148

Per Microsoft, this download program cannot be offered directly by software developers. It is an update to the Windows Vista operating system, and Microsoft will verify that you have a legitimate copy of Vista before downloading and installing the program.

We will be redeveloping the Help systems in LIMDEP and NLOGIT.

I cannot import spreadsheet files from Excel 2007 into LIMDEP or NLOGIT. I had no problem doing so with my earlier version of Excel.

With the release of Excel 2007, Microsoft changed the internal file format of spreadsheet files. In the past, such changes have been minor modifications of the basic binary formatted file that were easy to adjust to. With Excel 2007, they have decided to discard the old binary format completely, and switch to a file format based on XML. LIMDEP and NLOGIT (and, in all likelihood, all other programs that you are used to) cannot read these files. Excel 2007 will provide some options for creating files that are portable to programs that are used to the older format. You can save files in the .CSV format, then read these into LIMDEP with a READ command. There is a ‘compatibility mode’ offered by Excel that seems to promise that it will maintain the old style file format. Reviews are still coming on this, but early returns suggest it does not work very well. If you are able to use Save As... in Excel to save the file in an older format, that may be a solution as well.

When I try to use the LIMDEP or NLOGIT Help:Topics feature, I receive an error message, ‘Cannot find or load the file RoboEx32.dll. This file should be copied to C:\WINNT\System32 or a directory in your PATH.’ (The place to where it should be copied may be different on your computer.)

When I try to use Help (in spite of the message above), I receive another error message, ‘An error exists in this Help file. Contact your application vendor for an updated Help file. (1024)’

Some older implementations of Windows were shipped without this DLL file. Both diagnostics occur because this DLL is not in the indicated place in your computer. We have provided a copy of the DLL for you to install on your computer.

  1. Use your web browser to download the file RoboEx32.dll. Download this file to any folder on your computer.
  2. Using Explorer, move this file from where you downloaded it to the specific location indicated in the diagnostic. You do not have to ‘install’ the file; you only have to place a copy of it in the system folder.

(Note, Windows ME and XP may give you a warning when you point your Explorer into the system folder that sounds like it is telling you not to enter that area and not to make any changes. Placing this DLL file in your system folder does not change the way any other software operates. But, do not make any other changes in this folder.)

When I try to run LIMDEP or NLOGIT, I get a message about a DLL file (RICHED, RICHED20 or RICHED32) and the program shuts down.

Some windows systems, primarily Windows ME, contain a DLL file that is incompatible with LIMDEP. We have a replacement for this file that you can install that will fix this problem. (We have learned that at least one other commercial econometrics package has this same problem, and our fix repaired their program as well.) To implement this fix, do the following:

  1. Use your web browser to download the file dllfiles.exe. Download this file to any folder on your computer. Although this is an .exe file, it is not an application. It is a self-extracting archive file. It contains three DLL files, riched.dll, riched20.dll and riched32.dll, in .zip format. When you double click this executable file in Windows Explorer, it will unzip the file and place the three DLL files in the same folder as the .exe file.
  2. Now, using Start:Find or Start:Search, locate on your system the file(s) riched.dll, riched20.dll and riched32.dll. You will probably find only one of these, possibly two, and rarely all three. You are going to replace these files with the ones you obtained at step 1. These files will probably appear in your Windows System folder or WINNT folder, or some other part of the Windows system on your computer. The precise location differs with various Windows installations and systems.
  3. Using Explorer, rename the DLL files that are currently on your system to create a backup of these files. (We have never heard of a problem arising from this fix, but it is always a good idea to back up a file before you make any changes in it.)
  4. Using copy/paste, replace only the files you renamed in step 3 with the ones you downloaded in step 1.

This completes the fix. You do not have to reboot your computer.

I read a data set into LIMDEP (or NLOGIT) with nnnn (more than 1,900) observations. I did not get any error messages, but the program only read 1,900 observations. What happened to the rest of the data?

You discovered this by going to the data editor and scrolling down as far as you could. You reached what appeared to be the end at row 1,900. In fact, that is all the data that the data editor can display regardless of the number of observations actually read. If you did not get a diagnostic, your data were read correctly. You can see the right number of observations that were actually read at the top of the project window. Also, to verify the data, you can use the command DSTAT ; Rhs = * $ to get the descriptive statistics for the sample.

While estimating a model, LIMDEP or NLOGIT committed a division by zero or some other numerical error, and the program shut down.

Nearly all of the models that you fit with LIMDEP are complicated and nonlinear. We have protected the program from numerical failures of this type as well as possible. Still, they do come up, particularly when you are using an unusual data set. (An example that comes to mind: fitting a Poisson regression to a data set in which the dependent variable takes very large values – in the thousands or larger – rather stretches the model definition and the program.) If you do ‘crash’ LIMDEP or NLOGIT, we do want to know about it. The best way to get quick resolution of the problem is to send to support@limdep.com or support@nlogit.com commands, output, and data documentation sufficient for us to see the problem ‘on paper’ and then to replicate it on our own systems. Please include your serial number with your technical support inquiry.

If you believe you have found a bug in LIMDEP, please do the following:

If it is something obvious, please send us the necessary details. (Email is best, to support@limdep.com or support@nlogit.com) We’ll resolve the problem with alacrity. But, it is much more likely that it will be something subtle. For example, suppose LIMDEP crashed in the middle of an iteration because it tried to divide by zero. This sort of thing usually requires us to execute the program with your data and your commands. Try to produce the error with as small a data set and command set as possible. Send us enough material, including your trace file and the data, so that we can reproduce and resolve the problem. Please try to avoid sending huge data sets. Also, in almost all cases, it is extremely helpful if you can send us the TRACE.LIM file that is associated with your problem run. Please include your serial number with your inquiry.
In this connection, please note a common diagnostic that is, unfortunately, not informative: In Windows based systems, the error ‘Page fault at …’ is a catch all for a mathematical condition from which the program could not recover. It gives no indication of what happened. In such a case, we will require the documentation described above. Unfortunately, page faults also occur for a variety of other reasons. Again, the diagnostic itself almost never helps you figure out what has actually gone wrong.

Problems with Models or Running the Program

In reading a data file, LIMDEP claims to have reached the end of the file after reading exactly (or roughly) one half of the observations. Why?

There are a few possible explanations. If you are using a format statement, it may be inadequate. For example:

READ ; File = ... ; Nvar = 3 ; Format = (2F5.3) ...

This command reads three variables but gives only two format codes. This requires two lines of data per observation. The second line is used to give the third variable, and one number is lost. If you do not have a format statement, your data file may be too wide. The data file that you are using may have lines that are over 1024 characters wide. LIMDEP reads 1024 characters. If it does not find all the values it expects, it goes to the next line. This causes each observation to use twice as many lines as you intended.

I was able to fit a model with ... variables with no problems. But, when I added ... variables and submitted the command nothing happened.

This will happen when you are using the text editor if you make your command lines too long. The command lines in the text editor have a limit of about 140 characters. If you just extend the line too long, then the command reader will not find the end of the command. The crucial point is that it will not find the ending dollar sign ($). If your command does not end with a $, then ‘nothing happens.’ The solution is to press the Enter key in the middle of very long command lines so that they become two or more shorter command lines.

The iterations failed to converge. A diagnostic stated that a minimum of the function could not be found.

This is common in models with correlation coefficients, such as the selection models and the bivariate probit models. It should not happen with univariate probit or any kind of logit models. It should be quite rare with LDVs such as the tobit model. Check for the following possible conditions:

Scaling the data. Are the variables of very different magnitudes? Avoid this. This is especially problematic in routines that involve quadrature (random effects probit/ordered probit) and in routines that fit correlation coefficients (bivariate probit).

Multicollinearity is also a problem in nonlinear models.

A strategy: When you are having trouble estimating a model, try estimating it with a very small subset of the variables. Choose one or two independent variables (for each equation if necessary) and estimate with just them (even if you do not believe the specification). Build up the model from a small base. When problems emerge, you will know where to look in the data.

Questions about R-squareds

R-squared is a valid measure of fit only for linear regression models that contain a constant term and are fit by ordinary least squares. In this case, and only in this case, the statistic will be between zero and one and will tell you the amount of variation in the dependent variable that is explained by variation in the independent variable(s). In no other case will these results hold. LIMDEP and many other programs report statistics that are named with some variation on ‘R-squared.’ But, these are not fit measures and they do not give any measure of variation explained. They are often not even bounded by zero and one. For example, when a linear model is fit by instrumental variables, the ‘R-squared’ can be negative. This is a consequence of how it is computed, not a flaw in the computation or the program. For nonlinear models such as probit or logit, some R-squared measures are based on the likelihood functions or on counts of correct predictions. Once again, these are not fit measures, they are descriptive measures that are sometimes meaningful and (unfortunately) sometimes not. 

Conversely, most nonlinear models do not produce a readily interpreted ‘fit measure.’ For example, the tobit model is one that we are often asked about. There is simply no general measure of fit for this model. In order to make an assessment of model adequacy, you will have to construct some diagnostic(s) from the likelihood function or other test statistics against restricted models.

The log-likelihood function for my model is positive. Isn’t this impossible?

Log-likelihood functions are only required to be negative for models with discrete dependent variables. Tobit models, regression models, duration models, etc. are based on continuous distributions. Thus, the log-likelihoods for these models can be positive.  For example, in random sampling (xi, i =1,..n) from the normal distribution with mean 0 and variance a2, at the MLE of s2 = x′x/n, the log likelihood function is -(n/2)[1 + log2p + logs2], which is positive if s2 is less than 0.05855, regardless of n.

During the iterations, I get a diagnostic that a variance (or standard deviation) is not positive or that a correlation coefficient is outside the admissible range (-1,+1). Does this mean that my final estimates are not useable?

No. LIMDEP searches for the maximizer of a log-likelihood by taking a step from a valid parameter estimate toward a new estimate. If the new estimate is invalid, as in the query, LIMDEP issues a warning, then tries a shorter step. If the iterations ultimately did converge, then the warnings can be ignored. If convergence is not achieved, the warnings might be helpful in finding out why.

The Cox proportional hazards model seems to take a very long time to iterate.

You are using an old version of LIMDEP. The algorithm for this estimator has been changed in the current version, and the new one brings radical increases in speed. A problem with 75,000 observations, which heretofore might have required several hours of computation will now take less than 5 minutes.

Can I expand the data array?

Of course. You need only adjust the workspace to whatever amount of space you need. The program handles everything else. Use Tools:Options/Projects to set the data area to whatever number of cells you need. Then, stop and restart LIMDEP (NLOGIT)

My computations require a matrix larger than 50,000 cells. Can I get around this limit?

This limit is hard coded into LIMDEP, so no. On the other hand, you should never have to create a matrix whose length is the number of observations in the sample – that is how a matrix would grow this large. Chapter R12 of the LIMDEP reference manual contains extensive details on how to handle data matrices. Chances area there is a way to do your computations without having to create a matrix this large.

Why did LIMDEP give me a different answer for my model than … (e.g., Stata or SAS, which is the most common objects of this query)?

Our standard answer to this query will be that we are unsure. We do know how LIMDEP does its computations. Generally, we are unsure of how your alternative does its counterparts. In this manual, you will find a finely detailed ‘How it’s done’ section for every computation that LIMDEP does. When a question such as this arises, you should use the information in this section when you pose the question to the technical support people for the other software. (Unfortunately, many of them are less diligent about documenting the mathematical background of their estimators.) One thing you should definitely check first: You must always ask specifically for a constant term in a model in LIMDEP. If SAS or Stata automatically installs a constant in a model, you will get a different answer if you do not ask for the constant in the model you fit with LIMDEP. (One of the loudest exchanges in recent memory in our list server discussion group concerned exactly this point, in comparing a probit model fit with both LIMDEP and Stata.)

I was unable to estimate my model with LIMDEP. Why not?

We’ve received this query and others equally unspecific a surprising number of times. As a general proposition, when it appears that something has gone wrong as you use LIMDEP, please provide us with enough information to analyze your problem. This generally means sending details on the commands you were using, some general description of your data, and, of course, specific details on what the problem seems to be.

I have the following data set … and I’d like to model the following phenomenon … Can you show me how to do this with LIMDEP or NLOGIT?

Unfortunately, this question goes beyond technical support. We have thousands of users and, as much as we would like to, we cannot address general questions on econometric modeling or the translation of theoretical specifications to LIMDEP or NLOGIT commands. You might find the LIMDEP list server helpful.