[SciPy-Dev] More robust scalar root finding

[Eric Moore]

I suspect that people end up not using brentq since it requires a bracket
and not a single point.  I think adding some kind of heuristic to
root_scalar to find a bracket from an initial guess and then using brentq
or toms748 to find the root would be a good addition, if a good bit of
work.  This really is the missing piece between say Matlab's fzero and
root_scalar and is why I think people are using newton instead.   I think
boost has something for this, but I haven't used it to know if it is any
good.

Eric

On Thu, Aug 27, 2020 at 6:29 AM Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> FWIW I'd always recommend brentq for scalar root-finding.
>
> Trying to make newton-based methods more robust seems to be more or less
> reinventing that wheel, which has already been implemented (don't know who
> implemented it; hope you read this thread so that you see my thank you!)
> and is as robust  as it gets.
>
> чт, 27 авг. 2020 г., 12:57 Juan Luis Cano <juanlu001 at gmail.com>:
>
>> Hi all,
>>
>> A month ago I was trying to migrate some MATLAB code to Python and found
>> a couple of annoyances in the scalar root finding functions of SciPy. I
>> opened these issues:
>>
>> "Make root_scalar work when only x0 is given, similar to newton"
>> https://github.com/scipy/scipy/issues/12620
>> "newton chokes when iteration steps outside function domain"
>> https://github.com/scipy/scipy/issues/12625
>>
>> and a pull request to address #12625:
>>
>> "Make scalar, iterative root finding methods robust against steps outside
>> domain" https://github.com/scipy/scipy/pull/12626
>>
>> It seems that the conversation has stalled, so I wanted to bring them to
>> the mailing list.
>>
>> As I said in #12625, common wisdom dictates that if one chooses a
>> starting guess closer to the real solution, convergence is achieved.
>> However, leaving this well known numerical fact aside for a moment, I
>> wonder if some work could be done on the *usability* side of things to
>>
>> (a) make root_scalar a drop-in replacement to newton (#12620)
>> (b) have some opt-out way to increase the robustness of the solution in a
>> way that "just works", which is that MATLAB and Octave achieve (#12625)
>>
>> A personal side note: The original authors of the code I'm migrating
>> tried Python half a decade ago but noticed that "SciPy was not converging,
>> while MATLAB had no problems", so they ended up using the latter. While we
>> all scoffed when the infamous "top reasons to choose MATLAB" comparison was
>> published [1][2][3][4], I do think there's still a lot to understand from a
>> UX point of view of why people choose one or another. After 7 years of
>> teaching Python to engineers, they either become data scientists or they go
>> back to MATLAB, and as a result I have decided to get my hands dirty and
>> find out the reasons, to the best of my possibilities.
>>
>> Best,
>>
>> Juan Luis
>>
>> [1]
>> https://web.archive.org/web/20190806100605/https://www.mathworks.com/products/matlab/matlab-vs-python.html
>> [2] https://twitter.com/moorepants/status/1158248132355874817
>> [3] https://twitter.com/randal_olson/status/1158402855818018816
>> [4] https://twitter.com/neuromusic/status/1158556716096618497
>> [5] https://twitter.com/vboykis/status/1158559458173313024
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200828/f41afcb0/attachment.html>