Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upFix constrained optimizer documentation #201
Conversation
|
It looks like we need a corresponding mlpack pr to fix some dependent tests too? |
This shouldn't break anything or require any update. |
|
No, actually, it looks like mlpack's NCA implementation may depend on L-BFGS not terminating in the first iteration. (I am not clear on why the memory checks or static code analysis jobs are failing...) |
I guess for the static analysis job we have to update the job config same we did for the mlpack one, will look into it now. |
|
@mlpack-jenkins test this please |
|
The static code analysis check works now. |
|
Now that mlpack/mlpack#2479 is merged, this should build okay... let's find out... |
|
@mlpack-jenkins test this please |
|
@mlpack-jenkins test this please |
|
@zoq the memory checks build times out, even after 6 hours, I think because it's trying to run all of the tests---do you think we should adapt the script in |
|
Anyone willing to review this one? I believe everything is working here and we could merge it. |
I missed this one, I'll take a look at the memory script later, should be easy, but don't think we have to wait for the memory job to pass. |
|
Just resolved the merge conflict. |
|
Looks great to me. |
|
Second approval provided automatically after 24 hours. |
This solves #199.
Our documentation for constrained functions is actually incorrect. The documentation implies that both "hard" and "soft" constraints are supported but this is not true. In fact, the augmented Lagrangian optimizer (the only constrained optimizer we currently have) requires "soft" (differentiable) constraints. Although I think it would be useful to provide support for optimizers that can take in arbitrary constraints, at the moment we don't have any, so I thought it was best to just simplify the documentation.
Also I fixed an issue where the L-BFGS optimizer will return NaNs when the starting point gives a gradient that is 0. Essentially, for some reason, we previously did not allow termination on the first iteration due to the gradient norm being too small. That's likely just a code artifact; I can't find any good reason to avoid that.