Testing optimization solvers with equality constraints
I received an off-list email, questioning the relevance of my post. So, I thought I should clarify. If an optimization algorithm is dependent on the starting point (or other user-selected parameters), and then fails to find the "correct" solution because the starting point (or other user-selected parameters) are unsuitable, then that, in itself, does not indicate a problem with the algorithm. In other words, the R's packages listed in this thread appear to be working fine. (Or at least, there's no clear counter-evidence against). One solution is to project the surface (here, equality constraints) on to lower dimensions, as already suggested. Another much simpler solution, is to use two algorithms, where one selects one or more starting points. (These could be the solution to an initial optimization, or chosen at random, or a combination of both). Both of these approaches generalize to a broader set of problems. And I assume that there are other (possibly much better) approaches. However, that's an off-list discussion... All and all, I would say R has extremely good numerical capabilities. Which are even more useful still, with the use of well chosen mathematical and statistical graphics.
On Sun, May 23, 2021 at 5:25 PM Abby Spurdle <spurdle.a at gmail.com> wrote:
For a start, there's two local minima.
Add to that floating point errors.
And possible assumptions by the package authors.
----begin code----
f <- function (x, y, sign)
{ unsign.z <- sqrt (1 - x^2 - y^2)
2 * (x^2 - sign * y * unsign.z)
}
north.f <- function (x, y) f (x, y, +1)
south.f <- function (x, y) f (x, y, -1)
N <- 100
p0 <- par (mfrow = c (1, 2) )
plotf_cfield (north.f, c (-1.1, 1.1),
main="north",
ncontours=10, n=N, raster=TRUE, hcv=TRUE)
plotf_cfield (south.f, c (-1.1, 1.1),
main="south",
ncontours=10, n=N, raster=TRUE, hcv=TRUE)
par (p0)
----end code ----
Please ignore R warnings.
I'm planning to reinvent this package soon.
And also, it wasn't designed for circular heatmaps.
On Sat, May 22, 2021 at 8:02 PM Hans W <hwborchers at gmail.com> wrote:
Yes. "*on* the unit sphere" means on the surface, as you can guess from the equality constraint. And 'auglag()' does find the minimum, so no need for a special approach. I was/am interested in why all these other good solvers get stuck, i.e., do not move away from the starting point. And how to avoid this in general, not only for this specific example. On Sat, 22 May 2021 at 09:44, Abby Spurdle <spurdle.a at gmail.com> wrote:
Sorry, this might sound like a poor question: But by "on the unit sphere", do you mean on the ***surface*** of the sphere? In which case, can't the surface of a sphere be projected onto a pair of circles? Where the cost function is reformulated as a function of two (rather than three) variables.