Skip to content

included update_warm_start functionality#37

Open
raoul-herzog wants to merge 1 commit into
osqp:masterfrom
raoul-herzog:master
Open

included update_warm_start functionality#37
raoul-herzog wants to merge 1 commit into
osqp:masterfrom
raoul-herzog:master

Conversation

@raoul-herzog
Copy link
Copy Markdown

No description provided.

@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Apr 22, 2021

CLA assistant check
All committers have signed the CLA.

Copy link
Copy Markdown
Member

@imciner2 imciner2 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the delay in reviewing this. I just had two comments on the contents of this.

}

// update warm_start
if (!strcmp("update_warm_start", cmd)) {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (!strcmp("update_warm_start", cmd)) {
if (!strcmp("warm_start", cmd)) {

The class wrapper doesn't call update_warm_start actually, it will call warm_start when it wants to update both vectors.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I may have gotten confused here because I didn't see this was the emosqp file, so this change probably isn't actually needed (although we need to document this now in https://github.com/oxfordcontrol/osqp/blob/master/docs/codegen/matlab.rst as well).

y_vec = copyToCfloatVector(mxGetPr(y), (&workspace)->data->m);
}

if(!mxIsEmpty(y)){
Copy link
Copy Markdown
Member

@imciner2 imciner2 May 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason the call to warm starting is guarded against y being non-empty? As another note, with the update above to make this function callable from the wrapper, it should be guaranteed to get both an x and y to warm start.

@raoul-herzog
Copy link
Copy Markdown
Author

raoul-herzog commented May 29, 2021 via email

@imciner2
Copy link
Copy Markdown
Member

imciner2 commented May 30, 2021

Sorry about that confusion. My second comment on the if statement guarding the call to the actual OSQP update function still needs to be addressed though, since only checking for y non-empty seems to be incorrect. That function requires both x and y, so we should be making sure they both are non-empty for the call and throwing an error if either are empty I believe.

@raoul-herzog
Copy link
Copy Markdown
Author

raoul-herzog commented May 31, 2021 via email

@imciner2
Copy link
Copy Markdown
Member

in principle a warm start with only x and without y is possible, but indeed the question is whether it makes sense ...

The function to call if you only want to warm start one of them is osqp_warm_start_x or osqp_warm_start_y - the function osqp_warm_start requires that both x and y be provided, so we should be checking that both x and y are non-empty vectors if we use that function.

@gbanjac
Copy link
Copy Markdown
Collaborator

gbanjac commented May 31, 2021

We plan to remove osqp_warm_start_x, osqp_warm_start_y, as well as the function for updating lower and upper bounds separately. We have already done that in develop-1.0 branch of the main OSQP repository. See the commits below:
osqp/osqp@fab90f8
osqp/osqp@e49cf60

@imciner2
Copy link
Copy Markdown
Member

imciner2 commented May 31, 2021

Basically what I am saying we should do is have code before the call to osqp_warm_start like:

if ( mxIsEmpty(x) || mxIsEmpty(y) ) {
    mexErrMsgTxt("Both x and y must be given");
}

because otherwise we can get a segfault/random data if one isn't specified.

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.

4 participants