[SciPy-dev] Duplicate functionality.

[Charles R Harris]

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

> On Sun, Dec 20, 2009 at 4:03 PM, Charles R Harris
> <charlesr.harris at 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
;)

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