optimize.differential_evolution: possibility to pass parameters to the polish function

Other global minimization functions already support this option like shgo with minimizer_kwargs or dual_annealing with local_search_options for instance. However, differential_evolution only support toggling on and off this minimization with the polish parameter. It would be great to have the possibility to choose the method as well as any other parameter that the method supports.

Moreover, I propose that the same name for this parameter is used for all other algorithms of this type being the name minimizer_kwargs the most clarifying in my opinion.

[tupui]

After reading both sides, I have three remarks:

1. There is indeed a discrepancy between the way we can customize the polishing/minimizer and this should be fixed. IMO, it is up to the user to say if an unbounded optimizer would fit better in their case. We can still provide with a default we think is working ok.
2. If polishing with L-BFGS-B add a small value, is a bit arbitrary as a choice, and we don’t want to add options, then why not completely remove it? This would be clearer and we could highlight in the doc that you can go with another optimization loop if wanted. Because in the end, we don’t really take advantage to be in the function and have the function evaluations around to help the last minimization (no precomputed gradient, etc.).
3. Adding an intermediate local minimization is another story and IMO should be considered as a separate thing.

So I would either go for completely removing the polishing, or having a coherent interface with the other functions as suggested by @labay11.

[mdhaber]

There are a lot of good points here, but since this has been inactive, I thought I’d suggest something that may be a reasonable compromise and doesn’t require much decision-making: instead of deprecating polish or adding a new parameter minimize_kwargs parameter, why don’t we allow the user to pass an optimizer callable (that satisfies the minimize interface) into the existing polish keyword?

Of course, this is so much more convenient to the user than for the user to just pass the output of differential_evolution into the local optimizer themselves. But then again, neither is the minimizer_kwargs of the existing PR, and hopefully, this suggestion is less contentious since we can reuse the existing polish keyword, it’s 100% customizable, and it’s backward compatible, so we don’t have to do the work of a deprecation.