Incorrect x0 in LN_PRAXIS

[dweindl]

What happened?

Since 6a9fbb0, LN_PRAXIS uses some x0 different from the one passed to optimize.

How to reproduce the issue?

Reproducible with the following example (adapted from test/t_python.py):

import nlopt
from numpy.testing import assert_allclose
import math as m
import sys

def myfunc(x, grad):
    print(f"x: {x}")
    assert_allclose(x, [0.1, 0.1], rtol=1e-2, atol=1e-16)
    if grad.size > 0:
        grad[0] = 0.0
        grad[1] = 0.5 / m.sqrt(x[1])
    return m.sqrt(x[1])

algo = nlopt.LN_PRAXIS
opt = nlopt.opt(algo, 2)
print(f"algo: {opt.get_algorithm_name()}")
opt.set_lower_bounds([0, 0])
opt.set_upper_bounds([0.5, 0.5])
opt.set_min_objective(myfunc)
opt.set_maxeval(1)
x0 = [0.1, 0.1]
x = opt.optimize(x0)

6a9fbb0:
passes the unexpected x=array([0.31706 , 0.317049]) in the first call to myfunc

4d57a8a:
passes the expected x=array([0.0 , 0.0]) in the first call to myfunc

Version

v2.9.0-2-g6a9fbb0

bad: 6a9fbb0
good: 4d57a8a

Note that this also affects nlopt==2.9.0 on PyPI (https://github.com/DanielBok/nlopt-python), which seems to be based on some more recent nlopt than v2.9.0 / c500b50.

Operating System

Linux

Installation media

from source

Additional Context

No response

[jschueller]

indeed the inverse transformation is wrong, also the wheel on pypi uses the wrong commit: DanielBok/nlopt-python#43
I'm pushing a new 2.9.1 version with the fix so hopefully other users do not pick up the 2.9.0 from pypi that contains a non-stable commit

[dweindl]

Great, thanks for the quick response.