Tolerance on satisfying the constraint not passed to nloptr()

[fpetersma]

I started exploring this in relation to Issue #108. It did not explain why slsqp and solnp give different results, unfortunately, and it is not an very pressing issue, but worth logging here for someone to cover at some point (which could be me).

In the current implementation of mrds, there is an argument that allows the user to specify the tolerance for constraint optimisation. This value is stored in misc.options$mono.tol. It defaults to 1e06.

In the implementation of solnp(), this tolerance is passed on through the argument tol, which controls tolerance of convergence related to the objective function and the tolerance on constraint function (which checks if the function is between 0 and 1, and whether it is monotonic (enough)). More info in the manual.

nloptr(), on the other hand, requires specifitying the tolerance on convergence and on the constraint funciton separately. In the implementation of nloptr(), which is called when users specify the mono solver to be slsqp, misc.options$mono.tol is only passed on as the tolerance on the objective function (ftol_rel = misc.options$mono.tol) but not on the contraint. Because of this, nloptr defaults to a constraint tolerance of 1e-8, whereas the default value of misc.options$mono.tol is 1e-6. A list of the all the arguments that can be passed as a list to nloptr() through the main opts argument can be found by running nloptr::nloptr.print.options().

Potentially, this could be fixed relatively quickly by adding the following element to the named list that is supplied to the opts argument of nloptr():

tol_constraints_ineq = rep(misc.options$mono.tol, 2 * misc.options$mono.points)

The repeat function is used as it is required to supply a tolerance for every contraint (we effectively have a separate contraint for every constraint point), multiplied by 2 because it checks i) whether the point meets the monotonicity constraint and ii) where it is between 0 and 1 (the 'probability' constraint).

[erex]

thanks for digging into this @fpetersma. Useful to have the results of your archaeology stored in this new issue. Probably will need to wait until the holidays are fully passed before hearing from Tiago with his thoughts on this issue (raised because of his data set).

[lenthomas]

Yes, thanks for digging into this, @fpetersma.

Interesting that solnp has the same relative tolerance on both the objective function and the "feasibility" (which I assume means whether it meets the contstraint or not). These two things are, in general, not on the same scale (for example the former is in our case a log-likelihood while the latter is a difference in g(x) values) so I guess the key to why this is at all sensible is in the word "relative". I wonder how they calculate the "relative" values and whether this is the same way as nlopr uses for slsqp. I had a quick look at the help for nloptr but didn't see any info.

If the meaning of "relative" is the same, I'd be tempted to add an argument to add an argument to ddf so the user can separately specify mono.tol and (say) obj.tol, where the latter only works for the slsqp engine. On the other hand, that does make things more complex. Happy to chat more about this in the new year...