proposePoints should also return the crit value about mlrmbo HOT 14 CLOSED

The function should not only return the design point, but also - now in a list - the infill crit value found by optimization, with a correct name.

It would be cool if this was stored in the opt.path. Or does this introduce problems?
(it should not).

from mlrmbo.

Just to make sure that I understood. Assume infill.x stores the generated points. The function should now return a list of the following type: list(infill.x = infill.x, infill.y = infill.crit.fun(infill.x, ...)).
Afterwards the generated points shall be stored in the opt.path.

from mlrmbo.

Looks ok.
Stay with the names in propPoints return.

You could ask the optimizers for the y value, but maybe it is much easier to program, to do one extra infill eval.

The points are of course already in the optpath. They get added when they are really evaled.

You need to add an extra column in the optpath. Please call this not infill.y, but use the name of the crit from the control.

from mlrmbo.

Yes, I thought about adapting each optimizer to return the y value, but I think one extra evaluation is not that bad.

from mlrmbo.

Do the simple, extra eval!

from mlrmbo.

At the moment the only way to add a column is to handle the crit.value as a performance measure. Maybe we should think about extending the opt path functions to allow logging of other interesting values (beside dob and eol)?

from mlrmbo.

Is it possible to allow the object function to return not only the "y"'s but also other measures? Should I open a new issue regarding this problem? I tackle this problem at the moment with saving my measures in an extern file...

from mlrmbo.

Hmm. This is definitely another issue.

Open another issue and explain what you want and why.

from mlrmbo.

proposePoints now returns the crit value as well. As a next step it will be stored in the optimization path.

from mlrmbo.

Adding the infill crit value to the opt path is no problem, but I got errors during the learning and predictions phases of the learners. Do they somehow use the opt.path y-values?
I circumvent the problem by maintaining another variable opt.path2 which is used just for storing the values and is not passed to any other function. This is far from elegant, I know, but I think it is much easier than adapting all the other parts.

from mlrmbo.

Fixed errors for single point proposal by removing the infill crit value from the opt path in makeMBOTask, but with multipoint proposal I get the following error. You cannot reproduce that, because I did not commit something that fails.

Warnung in train(learner, rt) :
Could not train learner regr.km: Error in chol.default(R) :
der führende Minor der Ordnung 9 ist nicht positiv definit

from mlrmbo.

1. Removing the crit val in makeMBOTask is correct!
   This functions takes the stored / logged data and transform it into a regr. problem.
   The function needs of course to drop all technical stuff we also store in the optpath.

2. The error you get simply means that the kriging model "numerically breaks".
   If this ONLY happens after your changes, there might be something wrong there.

If everything else seems ok, push, and I will look at it.

from mlrmbo.

Some tests fail and I simply cannot figure out the reason. It ONLY occurs if I use only one opt.path. I set up a new branch for this. Please take a look at this. Otherwise I will get a heart-attack soon 😞

from mlrmbo.

crit values are returned and also nicely stored in opt.path

from mlrmbo.