### Aptech Systems, Inc. Worldwide Headquarters

Address:

Aptech Systems, Inc.

2350 East Germann Road, Suite #21

Chandler, AZ 85286Phone: 360.886.7100

FAX: 360.886.8922**Ready to Get Started?**### Request Quote & Product Information

### Industry Solutions

### Products

### Resources

### Support

### Training & Events

Want more guidance while learning about the full functionality of GAUSS and its capabilities? Get in touch for in-person training or browse additional references below.

### Tutorials

Step-by-step, informative lessons for those who want to dive into GAUSS and achieve their goals, fast.

### Have a Specific Question?

### Q&A: Register and Login

### Support Plans

Premier Support and Platinum Premier Support are annually renewable membership programs that provide you with important benefits including technical support, product maintenance, and substantial cost-saving features for your GAUSS System or the GAUSS Engine.

### User Forums

Join our community to see why our users are considered some of the most active and helpful in the industry!

### Where to Buy

Available across the globe, you can have access to GAUSS no matter where you are.

### Recent Tags

applications character vectors CML CMLMT Constrained Optimization datasets dates dlibrary dllcall econometrics Editor error error codes error handling errors Excel file i/o floating network GAUSS Engine GAUSS Light graphics GUI hotkeys installation license licensing linux loading data loop loops matrix manipulation Maximum Likelihood Maxlik MaxLikMT Memory multidimensional array optimization Optmum output PQG graphics procs random numbers strings structures threading### Recent Questions

- G16 crashes
- How to allow error recovery
- CCAPM (Consumption Based Capital Asset Pricing Model)
- How to identify the break date for Hatemi-J cointegration test
- error G0152 : Variable not initialized stack trace:
- 'selif' does not work for strings
- Some parts of the screen show very small fonts
- Integration over an interval
- CKLS 1992 Gauss Code with Structural Breaks?
- plotSetXRange is not working

### Features

### Time Series 2.0 MT

### Industry Solutions

### Find out more now

### Time Series MT 2.1

### Find out more now

### Find out more now

# Resources

# 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

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.

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

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.

## Your Answer

## 3 Answers

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.

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

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.