Frequently Asked Questions
This page lists some common questions and problems and what you can do if you encounter them.
Operating System Compatibility
What operating systems are LIMDEP and NLOGIT compatible with?
LIMDEP and NLOGIT are compatible with Windows 10, Windows 8, Windows 7, Windows Vista, and Windows XP.
Are LIMDEP and NLOGIT compatible with 64 bit computers?
LIMDEP and NLOGIT are compatible with 64 bit systems, but are not 64 bit applications.
Problems that Appear to be System or Program Related
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. LIMDEP and NLOGIT cannot read .xlsx files directly. The simple option is to save files in the .csv format, then read these into LIMDEP with an IMPORT command (or use Project:Import in the desktop menu). There is a ‘compatibility mode’ offered by Excel that should retain the old style file format. However, reviews indicate that this does not always work with Excel 2007. (It appears to work with Excel 2010.) A useful solution for importing .xlsx files as well as other types of files is StatTransfer, an inexpensive third party software program that can quickly and conveniently transfer data from Excel 2007 into LIMDEP and NLOGIT project files.
I read a data set into LIMDEP (or NLOGIT) with nnnn (more than 5,000) observations. I did not get any error messages, but the program only read 5,000 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 5,000. 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 firstname.lastname@example.org or email@example.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 by email to firstname.lastname@example.org or email@example.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
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 255 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.
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 R16 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.
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.
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.