[SciPy-dev] Duplicate functionality.
Mon Dec 21 12:33:56 CST 2009
On Sun, Dec 20, 2009 at 6:48 PM, Charles R Harris
> On Sun, Dec 20, 2009 at 6:46 PM, David Goldsmith <firstname.lastname@example.org>
>> On Sun, Dec 20, 2009 at 4:03 PM, Charles R Harris
>> <email@example.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.
>> 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
> SciPy-Dev mailing list
Sounds good then: I've deposited my $0.02, and it sounds like they're
earning interest. :-)
More information about the SciPy-Dev