# QPSOLVE iterations halted due to lack of precision

Hi,

I've been using co to solve optimization problem with linear constraint. I got this warning message saying "QPSOLVE iterations halted due to lack of precision". What does this mean exactly.

I would appreciate a guidance about handling this.Thanks.

Huihui

## 3 Answers

0

This is probably due to an ill-conditioned Hessian.  The log to the base 10 of the condition number of the Hessian is a good measure of condition.  A condition number of 16 means a nearly total loss of information.  This could be due to something structural like a linear dependency such as collinearity, or it could be due to catastrophic loss of precision in the calculations.

This could have been a temporary situation and CO might be able to recover and continue on with the iterations.  This case you can ignore.  However, if this error occurs and CO fails to recover, you will need to look at the calculations in your procedure computing the objective function, or you may need to make sure your model and data are well conditioned, in particular that the data are properly scaled.

Calculations in your procedure to look for are anywhere very large and very small numbers occur together in the computation.  Subtraction is the most difficult operation.  If you are subtracting a very small number from a very large number, precision is lost.  Problems can also occur with the calculations involved exp() which can generate a very large number from a relatively small argument.

90% of the problems occur from poor scaling of the data.  You want all your numbers to be roughly about the same magnitude.  If not you start getting those very large numbers and very small numbers getting involved together in the calculations destroying your conditioning.

0

Thanks, Ron. One follow-up questions. By "CO might be able to recover and continue on with the iterations", do you mean Gauss does not stop or crash and continue the calculation?

Huihui

0

I depends on when the problem occurs.  Sometimes CO can recover, i.e., not crash, and continue iterations.

Also, it can be useful to write your procedure computing the objective function to return an error code if something goes wrong in your procedure.  For example suppose a statement generates a complex result because of an attempt to take the log of a negative number.  Test for the argument to the log function before it is attempted for a zero or negative argument, or test the result after the statement is exercised for a complex result, and then return an error code if it happens.

if b[1] <= 0;
retp(error(0));
endif;
.
.
.

CO will recognize the error return and in some circumstances can recover and continue the iterations.

## 3 Answers

0

This is probably due to an ill-conditioned Hessian.  The log to the base 10 of the condition number of the Hessian is a good measure of condition.  A condition number of 16 means a nearly total loss of information.  This could be due to something structural like a linear dependency such as collinearity, or it could be due to catastrophic loss of precision in the calculations.

This could have been a temporary situation and CO might be able to recover and continue on with the iterations.  This case you can ignore.  However, if this error occurs and CO fails to recover, you will need to look at the calculations in your procedure computing the objective function, or you may need to make sure your model and data are well conditioned, in particular that the data are properly scaled.

Calculations in your procedure to look for are anywhere very large and very small numbers occur together in the computation.  Subtraction is the most difficult operation.  If you are subtracting a very small number from a very large number, precision is lost.  Problems can also occur with the calculations involved exp() which can generate a very large number from a relatively small argument.

90% of the problems occur from poor scaling of the data.  You want all your numbers to be roughly about the same magnitude.  If not you start getting those very large numbers and very small numbers getting involved together in the calculations destroying your conditioning.

0

Thanks, Ron. One follow-up questions. By "CO might be able to recover and continue on with the iterations", do you mean Gauss does not stop or crash and continue the calculation?

Huihui

0

I depends on when the problem occurs.  Sometimes CO can recover, i.e., not crash, and continue iterations.

Also, it can be useful to write your procedure computing the objective function to return an error code if something goes wrong in your procedure.  For example suppose a statement generates a complex result because of an attempt to take the log of a negative number.  Test for the argument to the log function before it is attempted for a zero or negative argument, or test the result after the statement is exercised for a complex result, and then return an error code if it happens.

if b[1] <= 0;
retp(error(0));
endif;
.
.
.

CO will recognize the error return and in some circumstances can recover and continue the iterations.

### Have a Specific Question?

Get a real answer from a real person

### Need Support?

Get help from our friendly experts.