2

TL;DR: How to minimize a fairly smooth function that returns an integer value (not a float)?

>>> import scipy.optimize as opt
>>> opt.fmin(lambda (x,y): (0.1*x**2+0.1*(y**2)), (-10, 9))
Optimization terminated successfully.
         Current function value: 0.000000
         Iterations: 49
         Function evaluations: 92
array([ -3.23188819e-05,  -1.45087583e-06])
>>> opt.fmin(lambda (x,y): int(0.1*x**2+0.1*(y**2)), (-10, 9))
Optimization terminated successfully.
         Current function value: 17.000000
         Iterations: 17
         Function evaluations: 60
array([-9.5 ,  9.45])

Trying to minimize a function that accepts floating point parameters but returns an integer, I'm running into a problem that the solver terminates immediately. This effect is demonstrated in the examples above - notice that the when the value returned is rounded as an int, the evaluation terminates prematurely.

I assume that this is happening because it detects no change in the derivative, i.e. the first time it changes a parameter, the change it makes is too small and the difference between first result and second is 0.00000000000, incorrectly indicating a minimum has been found.

I've had better luck with optimize.anneal, but despite its integer valued return I've plotted some regions of the function in three dimensions and it's actually pretty smooth. Therefore, I was hoping that when a derivative-aware minimizer would work better.

I've reverted to manually graphing to explore the space, but I'd like to introduce a couple more parameters so it'd be great if I could get this working.

The function I'm trying to minimize can't be made to return a float. It's counting the number of successful hits from a cross-validation, and I'm having the optimizer alter parameters on the model.

Any ideas?

UPDATE

Found a similar question: How to force larger steps on scipy.optimize functions?

Community
  • 1
  • 1
Alex
  • 18,332
  • 10
  • 49
  • 53
  • random grid search or [brute force](http://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.brute.html) – behzad.nouri Dec 16 '13 at 02:01
  • yes, that's basically what i'm doing at the moment... i was hoping for something better! The function IS reasonably smooth, just integer-valued – Alex Dec 16 '13 at 02:03
  • 2
    Just read the link you posted @behzad.nouri - perhaps I could create a recursive grid search for this... – Alex Dec 16 '13 at 02:07
  • It sounds like your function has clamped values for different regions. Maybe you can index the regions, given it is well-recognizable, and do integer-programming over the index? – Patrick the Cat Dec 16 '13 at 02:30
  • @Mai not precisely sure what you mean. The function has an integer return value, but the parameters can take any floating point value, so it's not an integer problem. – Alex Dec 16 '13 at 05:32
  • For example, if for x in (0, 1] f(x) = 1 and for x in (1, 2] f(x) = 2, then (0, 1] can be indexed y = 0 and (1, 2] be indexed y = 1, we transform f(x)->g(y) s.t. g(0) = 1 and g(1) = 2. g is a mapping from integer to integer, though may not be one-to-one. – Patrick the Cat Dec 16 '13 at 05:37
  • Alex, what is the reason that no derivative change does not get you the minimum? Does your cost function have multiple local minimum? Is it necessary to add some constraints to your cost function? – lennon310 Dec 16 '13 at 14:46
  • No, the problem is that a small change in the parameters does not yield any change in the outcome. I've updated with an example. – Alex Dec 18 '13 at 11:30

1 Answers1

0

In general, minimization on the integer space is an entirely different field called integer programming (or discrete optimization). The addition of integer constraints actually creates quite a few algorithmic difficulties that render continuous methods unfit. Look into scipy.optimize.anneal

Axel Magnuson
  • 1,192
  • 1
  • 10
  • 26
  • 1
    No, this is not an integer problem. It's a function that returns an int, but the parameters are floating point. – Alex Dec 18 '13 at 22:55
  • OK, fair enough. I misread the question. Still, most conventional optimization techniques don't work on stepwise functions. – Axel Magnuson Dec 19 '13 at 00:36
  • A random thought: heuristically, you could apply some smoothing technique sufficiently broad enough to do away with non-minimal flat areas. – Axel Magnuson Dec 19 '13 at 00:44
  • Yeah, I reckon so. I guess I could simulate that effect by somehow forcing it to use really big steps when estimating the derivative. I wonder if that's possible... – Alex Dec 20 '13 at 08:01
  • I can't seem to find any parameter for that in the scipy docs, do you know if one exists? – Alex Dec 20 '13 at 08:03
  • Sorry, I don't know enough about that particular function. – Axel Magnuson Dec 20 '13 at 20:13