Skip to content

Add long double precision support - #73

Merged
govindchari merged 4 commits into
qoco-org:mainfrom
yk4r2:long-double-support
May 5, 2026
Merged

govindchari merged 4 commits into
qoco-org:mainfrom
yk4r2:long-double-support

Conversation

@yk4r2

@yk4r2 yk4r2 commented May 5, 2026

Copy link
Copy Markdown
Contributor

Optional long double prec support:

  -DQOCO_LONG_DOUBLE_PRECISION=ON
  • Routes increased precision through both QOCOFloat and bundled QDLDL type so the built-in CPU solver uses matching precision end-to-end (CUDA is unsupported).
  • Adds validation checks to catch QOCOFloat / QDLDL_float precision mismatches.
  • Adds precision_tests to verify that extended precision is preserved, types match between QOCOFloat and QDLDL_float, and user input is not mutated by setup() or solve().

@govindchari

Copy link
Copy Markdown
Member

Has this been tested on real problems? Does it improve performance?

@yk4r2

yk4r2 commented May 5, 2026

Copy link
Copy Markdown
Contributor Author

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.

@govindchari

Copy link
Copy Markdown
Member

Sounds good. I am just curious why you added this and if you found it necessary on your problems.

@yk4r2

yk4r2 commented May 5, 2026 •

Copy link
Copy Markdown
Contributor Author

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.

@yk4r2

yk4r2 commented May 5, 2026

Copy link
Copy Markdown
Contributor Author

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.

@govindchari

Copy link
Copy Markdown
Member

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.

@yk4r2

yk4r2 commented May 5, 2026 •

Copy link
Copy Markdown
Contributor Author

Added in #74: init isn't fully bypassed there: I'm just changing x0 after init and do the s = h - Gx0 -> bring2cone(s) + keep the default y and z.

@govindchari
govindchari merged commit 38a5046 into qoco-org:main May 5, 2026
15 checks passed
@yk4r2
yk4r2 deleted the long-double-support branch May 8, 2026 17:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants