Error "system is computationally singular" when running a glm

I'm using the robustbase package to run a glm estimation. However when I do it, I get the following error:

Error in solve.default(crossprod(X, DiagB * X)/nobs, EEq) :
system is computationally singular: reciprocal condition number = 1.66807e-16


What does this mean/indicate? And how can I debug it?

PS. If you need anything (the formula/specification or data) to answer, I'll gladly provide it.

It means your design matrix is not invertible and therefore can't be used to develop a regression model. This results from linearly dependent columns, i.e. strongly correlated variables. Examine the pairwise covariance (or correlation) of your variables to investigate if there are any variables that can potentially be removed. You're looking for covariances (or correlations) >> 0. Alternatively, you can probably automate this variable selection by using a forward stepwise regression.

This can also result from having more variables than observations, in which case your design matrix is probably not full rank. This is a bit trickier to fix, but there are ways. I believe lasso regression is supposed to work well when the data is "wider" than it is "long."

Keep in mind: if you decide to try lasso or stepwise selection, your doing much more (in terms of variable selection) than just handling multicolinearity.

• Thanks, two questions: 1. Do you know of any procedure in r, that might work well for me in debugging this? 2. I can see, that when I run the exact same model on the exact same data with glm() instead of glmrob() I don't get any errors - does that make sense, or does it imply an error in the glmrob() function?
– NK1
Nov 14 '13 at 9:11
• I disagree with the suggestion to use stepwise selection. That is almost always a poor approach. -1 Jun 2 at 13:43

I've dealt with the exact same problem. My teacher told me that this is because one of my variables is much bigger than the others. (In my case, the trading volume was much bigger than the returns in two different moments.) The problem is because of limitations in floating-point computations and precision, not anything inherently mathematical or statistical.

Therefore I've divided the biggest variable by 1000000.

data$$Volume <- data$$Volume / 1000000