Possibility of passing iteration number to objective function

[julian-goettingen]

I am parallelizing an optimization where the objective function in its current form keps track of the iteration number in order to use it in filenames and excel-rows because the whole process of optimization should be understandable to the engineers that work with the data.

The cleanest way to preserve this structure would be if the objective function could receive its iteration number, since the algorithm seems to already keep track of this information, while my own code would have to implement this logic using multiprocessing-shared-resources. I would be willing to create a patch for this if we can find a solution that fits the design principles of this library.

My idea for doing this that I believe preserves backwards-compatibility:
-add a default-false parameter to rbfOptions 'pass_iter_count' to let client-code indicate its objective function can handle the information
-have the algorithm always pass its iteration count to objfun
-have the RBFBlackBox-evaluate-method take an optional keyword-arg 'itercount'
-have objfun evaluate the blackbox either as blackbox.evaluate(point) or blackbox.evaluate(point, itercount=itercount) depending on the settings of the blackbox

[julian-goettingen]

Perhaps a more general solution would be helpful to more people while being equal effort to implement:
Passing a dict with various details about the current point evaluation (is it part of a global search? Is it a refinement of another point?)

[gnannicini]

This should be doable but I am wondering if it isn't easier to implement by having the evaluate() method as part of a class, so that one can keep track of the number of calls using an instance attribute. There is no restriction that the evaluate() is outside of a class scope, so one can definitely play with that.

I'm not opposed to the suggestion, but I would like to:

1. Understand the need: in what situations would one need to know whether the requested point is a global/local search etc.? (Keep in mind that the definition of global/local search is a bit fuzzy as there are several parameters that intervene, and it's more of a spectrum than a binary local/global property)
2. Think about repercussions: can this be made fully backward compatible, so that existing code would run out-of-the-box if we make the suggested change?

[julian-goettingen]

The global/local thing is not important to me, I just thought maybe a more general solution would be good if its doable. We can just leave that out.

The problem I see with keeping track of the evaluation number locally is that I am not sure if it can be done correctly in my code. The rbf-opt-library has a serial loop (even in the parallel version) where itercount has a clear meaning. But when it evaluates a point, here is my understanding of what happens (correct me if I'm wrong): the point gets submitted to a multiprocessing-pool which will evaluate it in some other process which has its own local copy of the RBFOptBlackBox with its evaluate-function. To keep track of the evaluation number, this blackbox would need to do some IPC with the rest of the pool to increment a global counter.

However, since process scheduling is not controllable I cannot guarantee that when the algorithm starts some point evaluations A,B,C that my own counting will get the same order, maybe it would be like this:

point | rbf_opt-itercount | my own itercount
A | 1 | 2
B | 2 | 3
C | 3 | 1

this would make for some confusing logs, especially since it would probably happen sometimes but not always.

As for being fully backwards-compatible, I believe it would be, because of this:
If the pass_iter_count-flag in the options is false, the evaluate-function of the blackbox would be called in the completely normal way
Since false will be the default, existing code will get passed the normal arguments.
Only new code which opts-in to use the feature by explicitly setting pass_iter_count to true will receive the new keyword-argument.

edit: formatting