cureos / jcobyla Goto Github PK

Hello,
I'm using jcobyla for a minimization problem, but when testing some things some results are showing unexpected jumps.

Iterating over my goals, I see that the solutions of jcobyla generally presents curves that should be smooth, but there are some big unexpected jumps at some places. The iteration finished normally, so it is not that there were not enough iterations. I've tried increasing the rho-end, as well as my epsilon test (conditions is for equality to zero) but it does not solve the issue. Surprisingly, there seem to be less such jumps with a lower rho-end.

Could I be running in to issues due to double representation? Or is there something in the iterative algorithm that may explain it?

Thanks

sorry if it's silly, but the output "F" is the optimal value of the objective function?

Hello,
Is there a preferred way of citing this jcobyla implementation in publications, or is the github data sufficient?
I'm using it as part of a solution and will cite it in the references; some algorithms/implementations provide some citation data so I prefer to ask.
Thanks,
Jörg

On line 1078 of Cobyla.java, there is a deviation from the behavior of the original Fortran code:

                    if (mcon == m)
                    {
                        double acca = step + 0.1 * resmax;
                        double accb = step + 0.2 * resmax;
                        if (step >= acca || acca >= accb) break L_70;
                        step = Math.min(step, resmax);
                    }

This corresponds to the following Fortran code:

        if (mcon == m) then
            acca = step + 0.1_wp * resmax
            accb = step + 0.2_wp * resmax
            if (step >= acca .or. acca >= accb) go to 480
            step = min (step, resmax)
        end if

The break L_70 statement takes the Java code to line 1184:

                if (step == stpful) return true;

This is equivalent to a go to statement to the line just above the label 480 in the original Fortran. In this case, the condition step == stpful is always true, resulting in a premature exit from trstlp, causing it to return a step of size zero, while claiming to have taken a full step and thus multiple evaluations of sample points.

In order to match the effects of the go to 480 statement in the Fortran code, the break L_70 statement should instead be continue L_60.

I have a similar issue as described in scipy/scipy#2891 for the python port of cobyla2: the minimization can terminate without actually satisfying the constraints.

I've uploaded an example to pastebin: http://pastebin.com/B7Z0Y95h

In my case, reducing rhobeg (solution in scipy/scipy#2891 ) won't help. With rhobeg=1 the constraints are violated by 0.091. With rhobeg=0.001 the constraints are violated by 0.254. With rhobeg=0.00001 the constraints are violated by 0.267 ... (with simultaneous increase from 710 to 27153 iterations).

In my opinion this is a bug.

Thanks
Stefan