[SciPy-dev] Duplicate functionality.

Charles R Harris charlesr.harris@gmail....
Sun Dec 20 20:48:10 CST 2009

On Sun, Dec 20, 2009 at 6:46 PM, David Goldsmith <d.l.goldsmith@gmail.com>wrote:

> On Sun, Dec 20, 2009 at 4:03 PM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> > Hi All,
> >
> > There are two versions of bisection for finding roots, bisect in zeros.py
> > and bisection in minpack.py. I think it might be appropriate to deprecate
> > bisection with a suggestion to use bisect instead. Along the same lines,
> I
> > think newton should be moved into the zeros module. Thoughts?
> >
> > Chuck
> First off, are the implementations equivalent, e.g., do they both
> return the same results for test cases, and with essentially the same
> speed?  Are they both implemented at the C level?  Both at the Python?
>  One one way, the other the other?  You see where I'm going with this:
> make sure you keep the "right" one. :-)
Bisection is in python, bisect is in C and a bit faster. I haven't checked
the comparative accuracy, bisect is the only one currently tested. Newton
isn't tested either.

> Second, it's been a while, but my recollection is that some
> minimization methods (e.g., conjugate gradient) rely fundamentally on
> the bisection method, correct?  Is bisection called within minpack.py?

Doesn't look like it. Newton doesn't seem to be called anywhere either.

 More than once?  Do you really want to add an import zeros into
> minpack.py and replace bisection everywhere with zeros.bisect?

No, but I don't think any of the routines are needed there. The c versions
of the zero finders were written back around 2003 (by me) and came later
than the versions in minpack. I think the current placement is a bit of an
historical accident.

> (It's
> a semi-rhetorical question: I know it's not that big a deal to do so,
> "but if it ain't broke, don't fix it"; of course, code divergence is a
> source of future breakage...)
Maintenance can get to be a hassle, but that really isn't a problem yet.

Those would be my only concerns about that; as far as moving newton
> into zeros, I assume we'd keep a copy where it is through two release
> cycles and add a "this has been moved" warning, correct?
Actually, I'd like to move zeros too, but that is probably a change too much

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091220/b5fd725f/attachment.html 

More information about the SciPy-Dev mailing list