Re: FindRoots?
- To: mathgroup at smc.vnet.net
- Subject: [mg112232] Re: FindRoots?
- From: Andrzej Kozlowski <akozlowski at gmail.com>
- Date: Mon, 6 Sep 2010 04:13:43 -0400 (EDT)
It has been a long time since I looked at the source code of the RootSearchpackage (Ted sent it to me several years ago). I forgot the details of it and when writing this simply assumed it used FindRoot or an essentially equivalent method. In fact it implements Brent's method, which is of course one of the values of the Method option in FindRoot. I don't know exactly why Ted did wanted to implement this independently, but in any case it is not relevant to my comments. Everything "mathematical" that I wrote applies just as much to RootSearch as to FindRoot. The point of my original post was not that Mathematica should not have a functionality to produce complete solutions of numerical equations but that leasing packages from users is not the right approach for Wolfram. The arguments for this view are unrelated to mathematics and I do not want to enter into them here (I know of only one exception that WRI has made to this rule: the Combinatorica package, co-authored by Steven Skiena and although there were very good reasons for doing so once I doubt that this is something WRI would wish to repeat). From the "mathematical" viewpoint the problem with the RootSearch package is that it is unable to prove that all roots have been found. To know that the user has to rely on other ad hoc methods, like looking at the graph. These will of course fail whenever one is dealing with clusters of roots so close together than they cannot be distinguished by the eye. The answers given by Reduce, on the other hand, are mathematically guaranteed to be correct (barring bugs, of course). It's pointless to compare an example where Reduce is trying to obtain a mathematical proof (which may take a very long time in some cases) with a method which will return "roots" which may not be roots at all. Of course Reduce, as currently written, is limited only to complex analytic functions. But there exist methods which are much more general, and will work in all the cases where SearchRoot works, but, unlike SearchRoot, will return mathematically provable answers. One such method is due to Semenev and is the subject of two of my demonstrations on the Demosntrations site. It deals not just with a singe equation but with a system of n real equations in n variables. The functions are only required to be of class C2 - that is have continuous second derivatives. My implementation uses Interval and FindRoot, and the results are "guaranteed" (without the need for any options) in all cases where these two functions work. I don't think this includes the case of Interpolating functions because I don't think Interval arithmetic works in this case. But I don't believe that RootSearch is at all reliable in such cases - in fact I can provide real life important examples where it fails no ma t! ter what options are used. Andrzej On 5 Sep 2010, at 13:41, David Park wrote: > I do not find any reference to or instance of FindRoot in the RootSearch > code. > > > David Park > djmpark at comcast.net > http://home.comcast.net/~djmpark/ > > > From: Andrzej Kozlowski [mailto:akozlowski at gmail.com] > > This is, of course, not an argument against having in Mathematica the sort > of capabilities that Gianluca wrote about. Rather, I don't think the > existing RootSearch actually offers them, since I think it relies on the > built in FindRoot function. Although FindRoot is indeed intended for solving > numerical equations I do not think it can be reliably used with > InterpolatingFunction objects that arise as solutions of differential > equations. I say this on the basis of my own experience. There is often a > way to avoid this by using the "EventLocator" value of the option Method in > NDSolve. > > > Andrzej Kozlowski > >