[SciPy-Dev] More robust scalar root finding

[Evgeni Burovski]

Shrug. IMO bracketing is a feature. Unless the interval is really
inbounded, i.e. the roots may go to some sort of asymptotics. In which case
I suspect a heuristics need to take into account specific details of the
problem, and a general case heuristics breaks down.
(A prototypical case in mind here is something like `x = a ctg(x) + c`,
where depending on a and c, a root may be close to a multiple of \pi/2.)

I once tried using boost root-finding and after some effort moved over to
brentq + fsolve, which worked much better. It was a while ago, maybe things
have improved over there.

This all is not to say that a there is no room for some bracketing
heuristics. What I'm saying is that this should probably be a separate
step, as in

>>> x1, x2 = try_bracketing(f, x0)
>>> root = brentq(f, x1, x2)

Cheers,

Evgeni

пт, 28 авг. 2020 г., 16:54 Eric Moore <ewm at redtetrahedron.org>:

> 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
>>
> _______________________________________________
> 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/0cae4a24/attachment-0001.html>