Solution out of bounds about optimization-engine

[alphaville]

Are you imposing these constraints using the penalty method? If so, the constraint violation can be controlled via the constraint tolerance. If you're using regular constraints, there shouldn't be any constraint violation. I'll have a look.

[alphaville]

@sinashm How small is the constraint violation? Can you also share the exit status of the algorithm (whether it has converged, norm of FPR, number of iterations, etc)?

[sinashm]

I am using:
bounds= og.constraints.Rectangle(umin,umax)
The constraint violation is quit small -5e-11
however the sign is messing with further parts

[alphaville]

It is safe to take a projection on the solution you're getting. The guarantees that you have is that the solution you will get has an FPR of adequately small norm. This does not mean that the solution will be feasibly, but the infeasibility is controlled by the tolerance.

In the algorithm there are two iterates: u and u_bar (see below). Both converge to the solution, but u_bar is always feasible. Our implementation returns u (which might be slightly infeasible), instead of u_bar.

Perhaps it makes better sense to return u_bar instead of u. I wouldn't like to return both - this would confuse the users.

I added the following line in method solve in panoc_optimizer.rs and all unit tests pass:

// copy u_half_step into u
u.copy_from_slice(&self.panoc_engine.cache.u_half_step);

I need to create a test to make sure everything works. Thanks a lot for reporting this.