-
Notifications
You must be signed in to change notification settings - Fork 209
Add support for sparsity exploitation for SOCs of large dimensionality #1468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
01f3469
9c8965e
4ed64ef
9622be8
e5b81d7
dc2e7f0
1ffb4a7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -283,6 +283,8 @@ class pdlp_solver_settings_t { | |
| bool eliminate_dense_columns{true}; | ||
| pdlp_precision_t pdlp_precision{pdlp_precision_t::DefaultPrecision}; | ||
| bool barrier_iterative_refinement{true}; | ||
| bool barrier_csr_ir_matvec{false}; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Lets remove this if its faster always faster to avoid the operator based version.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So far, I haven't see significant speedup for others but fail optimality for several examples in cblib. It's better to keep it as an option but not default until I can improve the numerical stability of it.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. which problem are you seeing the issue with?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We want to avoid code divergence as much as possible. This definitely should not be a user facing option.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree not to expose it when the PR is merged.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
| i_t barrier_soc_threshold{5}; | ||
| f_t barrier_step_scale{0.9}; | ||
| bool save_best_primal_so_far{false}; | ||
| /** | ||
|
|
||
Large diffs are not rendered by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this parameter needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are parameters I want to tune, so I want to expose them during the developing phase. They would be removed when I'm going to merge PR.