[SciPy-User] curve_fit with float32 values

[Sebastian Berg]

On Fri, 2013-01-18 at 10:53 +0100, Sebastian Berg wrote:
> On Fri, 2013-01-18 at 09:18 +0100, Georg Brandl wrote:
> > Am 12.01.2013 15:58, schrieb Pauli Virtanen:
> > > 12.01.2013 14:54, Georg Brandl kirjoitti:
> > > [clip]
> > >> In the end (which took quite a while!) we found that the problem
> > >> was that the X data (which was directly loaded from a HDF file)
> > >> had a float32 dtype.  This seems to confuse curve_fit.  Same goes
> > >> for float16.  float128 at least raises an exception.  Integer types
> > >> seem fine given rounding, see the code/output below.
> > > 
> > > AFAIK, a likely bug here is probably the choice of epsilon for numerical
> > > differentiation in leastsq --- the chosen epsilon is probably smaller
> > > than the machine epsilon for float32, hence problems appear.
> > 
> > I had a look at the code now; minpack_lmdif calls
> > 
> > ap_x = (PyArrayObject *)PyArray_ContiguousFromObject(x0, NPY_DOUBLE, 1, 1);
> > 
> > IIUC this should already result in a float64 array, at least on machines
> > where double is 64-bits?
> > 
> 
> It may have been fixed, but I think the problem may be only about the
> temporaries within the function evaluation. You do not and maybe even
> cannot know if `args` contains a float32 array (you could check that the
> function return value is double, but even that may not tell the whole
> story).
> 

To be exact, the thing is x0 gets typically unpacked in the evaluation
function. Which means that x0 is a set of scalars that have no effect on
the casting. You *could* hack around that... but...


> Sebastian
> 
> > Georg
> > 
> > _______________________________________________
> > SciPy-User mailing list
> > SciPy-User at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-user
> > 
> 
> 
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>