Sergio Ghinami <ghnsrg_recap@hotmail.com> wrote: > I hope that some expert of Elliptic Integrals will > explain why the complete E.I. specific for the Ellipse > seems to give so rough numeric output, at least against > the test proposed by Paul Bourke (and David Cantrell) on: > http://astronomy.swin.edu.au/~pbourke/geometry/ellipsecirc > > I tried such test, which gives the quarter length of an > Ellipse, on the case: a = 1.0, b = 0.5 > The original test, seized to output 12 decimal digits, > gave: > > "Exact" (Dedicated Series): 1.211056027573 > "Numerical" ("broken line"): 1.211056027569 > "Integral" (compl. Ellip. Integral): 1.211056145378 I have no idea where you're getting that inaccurate value above. Paul certainly doesn't give it in his article. To evaluate the length you were considering, by using the complete elliptic integral of the second kind, you might wish to use a computer algebra system in which that function is already implemented. For example, in Mathematica, that length can be expressed precisely, in terms of the complete elliptic integral of the second kind, as EllipticE[3/4] Asking for a numerical approximation, accurate to, say, 40 decimal places, one gets In[1]:= N[EllipticE[3/4], 40] Out[1]= 1.211056027568459524803562899548978676494 But even if you don't have direct access to Mathematica, you can still get that result easily using <http://functions.wolfram.com/webMathematica/FunctionEvaluation.jsp?name=EllipticE> by just setting z = 3/4 and Digits of Precision = 40. > So, "Exact" and "Numerical" seem to agreed on 10-11 > digits, while "Integral" only on 6. > "Numerical" and "Integral" used the same decomposition > into 10 million chunks, while "Exact" used a Series > of 62 terms. > I tried to extend the test till 15 digits, putting > decomposition into 100 million chunks, and the Series > for "Exact" to 86 terms. The test gave: > > "Exact" (Dedicated Series): 1.211056027568461 > "Numerical" ("broken line"): 1.211056027568551 > "Integral" (compl. Ellip. Integral): 1.211055918024458 > > So, "Exact" and "Numerical" seem to agreed on 12 > digits, while "Integral" seems to behave a little worse > than above. > By the way, the last outcome of "Exact" is confirmed by > other similar algorithms; so, on the first outcome, > "Numerical" seems to show the best result. > > But the question is: why "Integral" seems to give so > rough results, in comparison against the old, elementary > trick of the "broken line"? why no more than 6 digits? The representaion of the length as a complete elliptic integral is precise. As to why you are having trouble approximating that integral accurately, I have no idea. Obviously, you need to re-examine whatever it is that you've been doing! David W. Cantrell > I am aware how Elliptic Integrals can get very great > numerical accuracy on other curves, such as "Lemniscata" > or "Elastic Curve": is that of Ellipse a difficult case? > Or such Integration must be translated into more efficient > algorithms? > Thank you.

Sergio Ghinami <ghnsrg_recap@hotmail.com> wrote: > Thanks to David W. Cantrell for his replay and for the references given. > Likely I didn't understood well how to use the program given in the Site > of Paul Bourke: > http://astronomy.swin.edu.au/~pbourke/geometry/ellipsecirc Ah, I had not realized, when replying previously, that you were using C code given by Paul. > Paul, and David too, will excuse me for that mistake. > > It seems from your replay that type "double" of C language is not > sufficient in order to make appropriate comparison. I don't know whether that's true or not. I don't know C, and so have never looked at Paul's C code. > Let me notice, > however, that the "Exact" method of the above program, roughly forced by > me to 86 iterations, gave 14 exact digits: > 1.211056027568461 > as comes out comparing against the 40 digit value that you wrote in your > replay: > > In[1]:= N[EllipticE[3/4], 40] > > Out[1]= 1.211056027568459524803562899548978676494 > > Using only C language type "double", near identical results came from the > algorithms given by Gerard Michon in: > http://home.att.net/~numericana/answer/ellipse.htm Gauss-Kummer Series > gave: > 1.211056027568460 > Cayley Series gave: > 1.211056027568459 > that's why I wrote that the value was "confirmed by similar algorithms". > > Indeed, I had in mind a computation between the limits of type "double" > of C. That has nothing to do with geometry, and hence this newgroup is not good for your purpose. If you still have questions of that type, I would recommend sci.math.num-analysis instead. > It would be very interesting to know how an accuracy of 40 decimal > digits can be reached, and by which hardware and software resources. As noted in my previous reply, I used the computer algebra system called Mathematica, which can give any accuracy desired. I had also given a link to a web page which allows you to do the same evaluation for free. Best regards, David