[SciPy-dev] Duplicate functionality.

[David Goldsmith]

On Sun, Dec 20, 2009 at 6:48 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> 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
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>

Sounds good then: I've deposited my $0.02, and it sounds like they're
earning interest. :-)

DG