# Why such high precision

Hello! I have been having this problem that the solution obtained by cvx is so small, sometimes even to 10^(-20) or 10^(-30), it is approximately 0. Why doesn’t cvx just give me a 0 and I do not need this high precision. This high precision has made the problem NAN.

And, why do I get NAN as the optimization result while all the variables are solved. And when I type the objective function into the command, I can get an exact result. I am so confused QAQ

If you show us your complete reproducible problem, with all input data, and show us all CVX and solver output, perhaps more specific guidance cam be provided.

NEVER use `cvx_precision high` in CVX. Don’t use the `cvx_precision` statement at all The CVX developer included it with the best of intentions, but the collective expertise and experience on this forum is that it is sometimes a bad thing to do, and almost never a good thing to do.

It might also be the case the your problem is badly scaled numerically. Change units of variables so that all non-zero input numbers are within a small number of orders of magnitude of 1.

These are just guesses, because you haven’t provided adequate information.

if CVX reports Failed, all CVX variable values are meaningless, and if not already NaN, should be considered to be.

My optimization problem is just one linear programming problem, with A1-A9 being matrix, w and f being variables. I have presented in the picture the solution of f in one time, you can see that it is in the order of 10^(-12), and I only need it to be 0 if it is so small. In fact, the value of it being so small instead of 0 makes some of the constraints invalid, for example, for the constraint A8*f==0, since some of the variables are 10^(-12), so A8*f is in the order of 10^(-12) instead of 0, so the problem is NAN. I this this is the reason that makes the problem unsolvable.

Is there any way to round the variables to 0 directly?

You have to do the rounding yourself after you get the results. This is floating point-arithmetic, you only ever get the results up to certain precision. Except for some trivial problems the solution never satisfies all constraints exactly. See for example https://docs.mosek.com/modeling-cookbook/practical.html#the-quality-of-a-solution

To say anything about why CVX reported Failed please post the full log output or reproducible code. The last bit of the log from your first post contains some humongous statistics in the `norm` section, so probably your problem is badly scaled and therefore does not solve.

Here is the full log output, it is indeed very long, does it mean that it is badly scaled?

## Calling SDPT3 4.0: 2304 variables, 451 equality constraints

num. of constraints = 451
dim. of linear var = 2304
number of nearly dependent constraints = 441
To remove these constraints, re-run sqlp.m with OPTIONS.rmdepconstr = 1.

SDPT3: Infeasible path-following algorithms

## number of iterations = 100 primal objective value = -7.80707903e-01 dual objective value = -7.22720073e+08 gap := trace(XZ) = 9.31e+08 relative gap = 1.29e+00 actual relative gap = 1.00e+00 rel. primal infeas (scaled problem) = 1.59e+00 rel. dual " " " = 2.57e+00 rel. primal infeas (unscaled problem) = 0.00e+00 rel. dual " " " = 0.00e+00 norm(X), norm(y), norm(Z) = 9.1e+08, 5.7e+16, 5.7e+16 norm(A), norm(b), norm© = 1.3e+13, 3.3e+01, 5.5e+00 Total CPU time (secs) = 0.91 CPU time per iteration = 0.01 termination code = -6 DIMACS: 4.7e+00 0.0e+00 7.0e+00 0.0e+00 1.0e+00 1.3e+00

Status: Failed
Optimal value (cvx_optval): NaN

It reaches maximal number of iterations and at that point the solution has huge norms and gap, so yes, your problem is extremely bad numerically and/or ill-posed in some way. Maybe a reading of https://docs.mosek.com/modeling-cookbook/practical.html#practical-optimization can give you some hints about how to rescale/improve it. I would start by checking that the magnitude of the data you feed, and the magnitude of the expected solution in is in reasonable range and then maybe also if the problem is not borderline infeasible. Good luck.