Talk:Durand–Kerner method

message: See Talk:Root-finding algorithm for some discussion relating to this method. -- Jitse Niesen (talk) 12:58, 10 January 2006 (UTC)
replies: text: Jitse, thanks! Moving the method here was the right thing to do! Oleg Alexandrov (talk) 16:30, 10 January 2006 (UTC)
replies: text:  PS The title is not perfectly correct. It should have been not Jacoby's method, rather Bo Jacoby's method. :) Oleg Alexandrov (talk) 16:30, 10 January 2006 (UTC)

text: That's great Fredrik! Go ahead and include the new reference and edit the title, preserving the links. Bo Jacoby 10:07, 26 January 2006 (UTC)
replies: text: I moved this to "Durand-Kerner method" because that name turns up the most Google hits by far. So does anyone know what each of Weierstrass, Durand and Kerner has to do with it? I've been unsuccessful in finding any historical information. Fredrik Johansson - talk - contribs 11:58, 26 January 2006 (UTC)
replies: text: There is something at http://netlib3.cs.utk.edu/cgi-bin/mfs/02/89/v89n10.html . I've been planning to go to the library to chase references but I haven't found the time yet. -- Jitse Niesen (talk) 14:00, 26 January 2006 (UTC)

text: The references to Durand and Kerner ought to be sufficient, but I'm curious about the Weierstrass link. My calculus professor said he recognized "Durand-Kerner" when I asked today, but that seemed to be about it. There are some experts in numerical analysis on campus who probably know more; I'll try to find out. Mailing the author of the page I linked to above might also be a good idea. Fredrik Johansson - talk - contribs 16:21, 26 January 2006 (UTC)
replies: text: In unrelated work, I came across this article in ACM ToMS, which seems to be freely available (at least, I could download it). It discusses the method and mentions the link to Weierstrass. -- Jitse Niesen (talk) 13:25, 31 January 2006 (UTC)

text: No way, delete it? What?? Once in ages I find very useful article written in human-readable language, with comprehensible example, and it turns out it barely escaped deletion in the past. Ha. Some wikipedians just can't recognize good stuff when they see it. Grrr. 178.95.241.37 (talk)  —Preceding undated comment added 18:16, 9 December 2010 (UTC)
thread_title:  Establishing the most common name 

message: Thank you Jitse. The new reference talks about how well the method finds multiple roots. Well, I don't think that multiple roots should be found numerically (and approximately), because they can be isolated from the polynomial algebraically (and exactly). The point is this. If f has a multiple root, p, then p is also root in the derivative f' , which can be computed algebraically from f. Use the Euclid algoritm to compute f2 := the greatest common divisor of f and f' . The roots of f2 are exactly the multiple roots of f. Now any triple root of f will be double root of f2, so f3 is calculated as the greatest common divisor between f2 and f2' , and so on until the degree is 1. Let fn have only simple roots. Substitute fm-k:=fm-k / fmk, for k=1..m-1, for m=n..2. All these polynomial divisions give zero remainder. Now all the fi have only simple roots, and f=f1×f22×...×fnn. The polunomials fi are now subject to numerical root-finding. Bo Jacoby 15:15, 31 January 2006 (UTC)
replies: text: This may be okay if you know in advance that the polynomial has multiple roots. If you do not, then you can theoretically use Euclid's algorithm to find the gcd, but I'm not sure this works in the presence of round-off errors (for essentially the same reason as you can't compare to zero in numerical algorithm). Furthermore, understanding how the algorithm performs with multiple roots helps you understand how it performs when roots are clustered. -- Jitse Niesen (talk) 18:52, 1 February 2006 (UTC)
replies: text: The polynomial gcd is done in integer arithmetic without round-off errors. If the polynomial has no double roots, then f2 has degree zero. A cluster of roots slow down convergence until it is infiltrated by p,q,r,s. The real problem is the precise evaluation of the polynomial inside a cluster. Polynomials with reasonably small integer coefficients do not have clusters of roots, as small fractions have big denominators. Bo Jacoby 08:56, 2 February 2006 (UTC)
replies: text: True if your polynomial has small integer coefficients; these are the easiest to handle. -- Jitse Niesen (talk) 13:52, 2 February 2006 (UTC)
thread_title:  Numerical behavior at multiple roots 

message: The recent references have expensive initializations. 
#Random numbers should be used with care, noting that one cannot reproduce a calculation that depend on random numbers. 
#Computing points evenly distributed on the unit circle is as costly as computing the roots. 
So stick to the simple suggestion of the article.
But the references support the method.
Bo Jacoby 13:17, 30 January 2006 (UTC)
replies: text: The simple way seems practical enough, but the advantages and disadvantages of more complex initialization schemes should probably be discussed in the article. Fredrik Johansson - talk - contribs 13:31, 30 January 2006 (UTC)
thread_title:  Initialization 

message: The article is not clear whether the new roots should be updated sequentially or in parallel.  I've tried both and haven't found any significant advantage either way, but I'm wondering whether someone can give reasonable justification for either. --njh 00:12, 14 June 2006 (UTC)
replies: text: My observations confirm yours: no significant advantage either way. In the article I inserted semicolons after the substitutions, just to fix that the algorithm stated was ment to be sequential, but it doesn't matter. If you use the APL programming language or the J programming language or another array programming language you would prefer to do it in parallel. If you use C programming language or fortran or pascal programming language or another scalar programming language you would prefer to do it sequentially. The article root-finding algorithm says that global convergence properties are still under investigation, so please share your experience with the curious world. Bo Jacoby 19:14, 14 June 2006 (UTC)
thread_title:  substitutions parallel or sequential 

message: A small point. As a casual consumer of math wiki pages, I think it would be nice if you could mention that the algorithm as given doesn't work if the polynomial has duplicate roots. It doesn't seem to be mentioned anywhere on the page. Thanks for the exceptional quality of these and similar pages. Robin Davies --74.104.47.37 04:19, 2 December 2006 (UTC)
replies: text: The algorithm even works in the presence of multiple roots or clusters of close-by roots, provided the approximations at the beginning are all different. It's only that the convergence to the multiple roots is linear instead of quadratic, and the last steps become even more numerically instable, because one has to divide a small quantity by a small quantity with a result that is a small quantity.--LutzL 10:15, 4 December 2006 (UTC)
thread_title:  Roots with multiplicity 

message: After helpful discussions with Bo Jacoby, I have implemented this algorithm as a generic library package in Ada. My results are here. I'd be grateful for any comments. Thanks! John Matthews JMatthews 18:54, 7 November 2007 (UTC)
replies: text: Hi, on my machine (Pentium(R) 4 CPU 3.00GHz, gnat-4.2) it only starts breaking at degree 49.--LutzL 15:57, 9 November 2007 (UTC)
thread_title:  Implementation Notes 

message: Hi LutzL. Your addition reads: "One could also choose the initial values for p,q,r,s randomly in a way that they are inside some circle containing also the roots of f(X), e.g. the circle around the origin with radius  1  + \max |a|, |b|, |c|, |d|) , (where 1,a,b,c,d are the coefficients of f(X)) but are not too close to each other, which becomes increasingly a concern as the degree of the polynomial increases". What is the point? Computing random numbers take more time and space than computing the powers of (0.4+0.9*i). Do random numbers have any advantage in general? Random numbers outside the circle can also be used. The high powers of (0.4+0.9*i) are close to 0, because |0.4+0.9*i|<1, but not equal to 0, nor equal to one another, so they are perfectly suitable as initial guesses. Choosing powers of some complex constant, k, where |k|>1, gives the risk of floating point overflow. If you know anything about the roots a priori you can probably make better initial guesses, but the reason why you are using a root-finding algorithm is of course that you do not know the roots. So let's not confuse the readers.    Bo Jacoby 00:35, 11 November 2007 (UTC)
replies: text: It was meant to indicate that the special choice of the starting points as powers of this a=0.9+0.4i is just that, a special choice that is alien to the method itself. One could use other patterns, a quadratic or hexagonal grid or, as in the Bini article on the Aberth-Ehrlich method, equally spaced points on concentric circles. So that is random as in RAM, random-access-memory.--LutzL (talk) 10:21, 6 November 2008 (UTC)

text: I think we don't differ that much in opinion. Only that I'm not always as lucky with words to precisely express my intend.--LutzL (talk) 11:59, 9 November 2008 (UTC)
thread_title:  LutzL's edit 

message: It is interesting for me to read all this discussion because I have used the Weierstrass algorithm since the late 1960's and only recently learned via Wikipedia about it being called Durand-Kerner.  I and some coworkers at Stanford Research Institute (later named SRI International) published our investigations regarding apparent global convergence in the Problems and Solutions section of SIAM Review Vol.18, No.3, July 1976, for all but a set of starting vectors of measure zero, and with no other restrictions such as no multiple roots or only real coefficients, etc, as we found in late 1960's articles in the Journal of the CACM where we first found the algorithm.  One of our coworkers pointed out to us the algorithm appearing as part two of a constructive proof of the Fundamental Theorem of Algebra published in the collected works of Weierstrass in 1903.  Over the years since the late 1960's none of us ever found an example of the algorithm failing to converge.  Each of us contributing to the SIAM Review "problem" came up with a different proof at the time that the algorithm with parallel iterations converges in the quadratic case except when the trial roots lie equally spaced away from the right bisector of the line segment joining the true roots in the complex plane.  None of us ever managed to prove or disprove global convergence for degree greater than two since that time, except that one of us, Mike Green, told me a few years ago he thought he had later proved convergence for degree 3 but now can't find his paperwork on that.  I personally have run vast trials on my PC over the past ten years, using a program I wrote in Win32Forth with randomly changing starting vectors and polynomial coefficients, and I have never come across a case where the algorithm does not eventually converge.  It even works for the notorious example p(z) = z^4 - z^2 - 11/36 when starting trial roots are near the so-called superattracting 2-cycle +-1/sqrt(6) for Np(z) = z - p(z)/p'(z), as described in Exercise 9, Sec.1, Ch.2, Using Algebraic Geometry by David Cox, John Little and Donal O'Shea, Springer Graduate Texts in Mathematics 185, 1998.  With my Forth program I plot the trial solutions, and it's fun to watch them flail around all over the complex plane sometimes, wildly jumping far out and then always getting their act together somehow as they eventually come flying in from far away towards the true roots.  
Andrew Korsak, Ph.D. (U.C. Berkeley '66), now retired since Jan'02.  Kr6dd (talk) 06:21, 5 June 2009 (UTC)
replies: text: Thank you very much for this comment. Would you like to include your results in the article? I took the liberty to give your comment a section header. Bo Jacoby (talk) 23:11, 13 October 2010 (UTC)

text: I just made [flash applet] to find coefs that cause roots collide at certain iteration. It seems that, given unlimited precision, you could always find some coefs that collide roots; but this applet, limited by stanard floating point precision, seems to hit the wall (couldn't get roots closer than 4.4e-15). Even if you can collide roots exactly for some other set of coefs, re-seeding the algorithm with different initial values will solve it! It's amazing algorithm, thank you whoever started this article (otherwise I would never know about it). 95.135.85.139 (talk) 15:52, 28 December 2010 (UTC)
replies: text: Actually nvm, it was my mistake - narrowed range too fast. See [here] for bad coefs set. 95.135.85.139 (talk) 16:44, 28 December 2010 (UTC)

text: Also, you don't actually need to re-seed algorithm and re-do the iterations, simply shifting one of collided roots a bit would set it back on track. Which is what I am going to do in my implementation :) 95.135.85.139 (talk) 16:54, 28 December 2010 (UTC)
replies: text: Ok, so if I spamming wikipedia tonight, let me go all the way down :) I actually tried this hack, and not only it works, but decreases iteration number from 50s to 15s, so I suggest anyone looking to implement it - always push your roots apart whenever they are closer than certain threshold! The way algorithm constructed, it does so on its own, but it would not hurt to help it. 95.135.85.139 (talk) 17:11, 28 December 2010 (UTC)
thread_title:  Andrew Korsak 

message: The article states that initial values must be " neither a real number nor a root of unity" but (0.4 + 0.9i)^0 is exactly 1 + 0i, isn't it? Should powers of 0.4 + 0.9i start from 1 rather than 0? 178.95.241.37 (talk) 23:21, 9 December 2010 (UTC)
replies: text: The initial approximations are chosen as 1,a,a^2,a^3,\dots, using as many powers as necessary. Were the generator a real, all intermediate results of the algorithm would be real, no complex root could be reached. Were a a root of unity, powers would be repeating and thus powers of a could not constitute an universal set of initial points. So the condition is on the generator a, not on the starting values themselves.--LutzL (talk) 08:07, 10 December 2010 (UTC)
thread_title:  Again on starting values? 

message: Hopefully,this is the right place for this question. I have doubts about the example. I programed it in C++ and FORTRAN an get the same roots but in a different order. In the German discussion page,
LutzL told me, not to find any error in my code and that I should ask Bo Jacoby. Below my table and the links to my code.
Greetings
--129.69.55.84 (talk) 07:16, 11 June 2012 (UTC)
replies: text: Bo, if you could find the code you used, could post it here for comparison? -- LutzL (talk) 09:00, 11 June 2012 (UTC)

text: Hi, so if I read this right, this is a sequential variant of the algorithm, using the new approximations as soon as they become available, resp. computing the approximations in place. Which is probably optimal for small-degree polynomials. For large degrees one might want to use the O(n*log(n)) variants of multi-point evaluation and computation of the derivative in the denominator, which is only possible with the parallel or simultaneous computation of all new approximations.--LutzL (talk) 17:35, 11 June 2012 (UTC)
thread_title:  Values in the example table