[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.
More information about the Scipy-tickets
mailing list