[Scipy-tickets] [SciPy] #392: optimize.leastsq segfaults
SciPy
scipy-tickets@scipy....
Sat Mar 24 11:29:39 CDT 2007
#392: optimize.leastsq segfaults
----------------------------+-----------------------------------------------
Reporter: pwuertz | Owner: somebody
Type: defect | Status: new
Priority: normal | Milestone:
Component: scipy.optimize | Version: 0.5.2
Severity: critical | Keywords: minpack optimize leastsq segfault
----------------------------+-----------------------------------------------
Hi, I experienced some strange segfaults when using python/scipy in my
application. I think I tracked it down to optimize.leastsq. This function
is highly unstable when using jacobians and no full output.
For some numbers of equations it will segfault. But its definately going
to segfault if you are using equation vectors greater than 2^16^.
This is a minimal example:
{{{
from numpy import ones, array
from scipy import optimize
N = 2**16 + 1
par_init = ones(2)
func = lambda p: ones( N )
jacobian = lambda p: ones((N, 2))
print "these functions are working"
result = optimize.leastsq(func, par_init, Dfun = jacobian, full_output=1)
result = optimize.leastsq(func, par_init, full_output=1)
result = optimize.leastsq(func, par_init)
print "this one is crashing"
result = optimize.leastsq(func, par_init, Dfun = jacobian)
}}}
My guess is the bug is in LMDER, where LMDIF is clean, because the
functions without jacobians are working.
I dont know how full_output is affecting the minpack binding... maybe a
different function will be called, no idea. Also the 2^16^ condition is
strange... looks like a 16 bit int has been used for looping through the
array or something like that.
As workaround for this problem one could always use the full_output=1
option... but I dont assume this is the intended behavior *g*.
--
Ticket URL: <http://projects.scipy.org/scipy/scipy/ticket/392>
SciPy <http://www.scipy.org/>
SciPy is open-source software for mathematics, science, and engineering.
More information about the Scipy-tickets
mailing list