# [Scipy-tickets] [SciPy] #1892: scipy.optimize.brute -- minimum value is mapped to integer without obvious reason

SciPy Trac scipy-tickets@scipy....
Tue Apr 16 03:45:46 CDT 2013

#1892: scipy.optimize.brute -- minimum value is mapped to integer without obvious
reason
----------------------------+-----------------------------------------------
Reporter:  jgehrcke        |       Owner:  somebody
Type:  enhancement     |      Status:  needs_info
Priority:  normal          |   Milestone:  Unscheduled
Component:  scipy.optimize  |     Version:  0.12.0
Keywords:                  |
----------------------------+-----------------------------------------------

Comment(by jgehrcke):

I think I understand now. Consider this code:

{{{
from scipy.optimize import brute

def f(x):
if x < 1:
return 10
return x**2 - 0.1

x0, fval, grid, Jout = brute(f, ranges=((-3,3),), full_output=True,
finish=None)

print fval
print type(fval)

x0, fval, grid, Jout = brute(f, ranges=((-3,3),), full_output=True)

print fval
print type(fval)
}}}

It prints

{{{
1
<type 'numpy.int64'>
0.900051398687
<type 'numpy.float64'>
}}}

My 'buggy' code fulfilled these conditions:

* For part of the parameter space the target function returns integer
values.
* This part is tested first by `brute`.
* The `finish` argument to the `brute` function is `None`.

`brute` obviously determines the type of its `Jout` array and `fval` value
from the first evaluation of `f()`. When not setting `finish` to `None`, a
floaty type might still be returned by `brute`, because it is followed by
an `fmin` run.

Hence, this might be a documentation issue: the

{{{
Returns: fval : int
}}}

is misleading. If it is true that the first target function evaluation
determines the type, should it be explained in the docs?

--
Ticket URL: <http://projects.scipy.org/scipy/ticket/1892#comment:3>
SciPy <http://www.scipy.org>
SciPy is open-source software for mathematics, science, and engineering.