Add long double precision support - #73
Conversation
|
Has this been tested on real problems? Does it improve performance? |
|
It's basically a bypass for long double usage, strictly for precision, to handle extreme epsilons in case you're working with high dimensions. I haven't tested it on my problems yet, but I can add a synthetic test suite where it might matter. It will be a slow test, though. |
|
Sounds good. I am just curious why you added this and if you found it necessary on your problems. |
|
I'm working with high-dimensional discrete optimization problems, which I'm solving as cone programs via QOCO and then apply the custom rounding procedure at the end. Because we convert from continuous to discrete values after solving (and due to high dimensionality too), even if the projection's effect on the continuous loss is small, its final impact after rounding can actually be massive, so I need all the precision that's available. |
|
I'll also add another PR that would add an optional custom primal starting point (x0) for initialization some time later, if it's possible. |
Sure sounds good, but your initialization procedure should also choose y0,s0, and z0. The initializations s0 and z0 must be in the interior of the cone. |
|
Added in #74: init isn't fully bypassed there: I'm just changing |
Optional
long doubleprec support:QOCOFloatand bundled QDLDL type so the built-in CPU solver uses matching precision end-to-end (CUDA is unsupported).precision_teststo verify that extended precision is preserved, types match betweenQOCOFloatandQDLDL_float, and user input is not mutated bysetup()orsolve().