HP Forums

hi everybody,
I put in the Prime Software Library a first attempt to make a program to handle Elliptical integrals (1st, 2nd and 3rd kind).
It calculate:
ell1F(x, k) -> F, Elliptic integral of first kind
ell2E(x, k) -> E, Elliptic integral of second kind
ell3∏(x, k, n) -> ∏, Elliptic integral of third kind
But it needs to have some controls to avoid singular values and other issues.
More, it could be expanded to calc also sn(), cn(), dn() [sometimes called amplitude sine, amplitude cosine, delta amplitude] and other parameters...
In that program k is the "eccentricity", n (only for 3rd type) is a number called "characteristic" of the various curves.
The program handle the "incomplete" integrals. For now, to attempt the complete ones, put x=1.

I invite to collaborate and make a stronger and more stable and useful program, if you want.
Thank you! you're welcome.

Salvo M.

These integrals are related to the Jacobi Elliptic Function (see in Wikipedia).

See here in the Library my version for the Prime.

About the two version of 1st kind integral I used in the two programs, they are related, being the same integral: x = sin(φ), then φ=ASIN(x), m=k^2...
The relation involve also sn(), cn(), dn() [sometimes called amplitude sine, amplitude cosine, delta amplitude

However I get values a bit different (see attachment): what kind of rounding is responsible of the difference, in this case?

A part of the examples in the attached image, another example: in the first case for the function ell1F() I test x=1 k=0.4 then ell1F(1,0.4) that returns 1.63999977306; in the second case (Jacobi) for the function Jacobi_fn() I test φ=ASIN(x), m=0.4^2 that returns 1.63999986587...

First case: the integral is int(1/(SQRT((1-t^2)*(1-(k^2)*t^2))),t,0,x);
Second case: the integral is int(1/(SQRT(1-m*SIN(θ)*SIN(θ))),θ,0,φ).
The *should* be the same value.
laTeX form (Wikipedia):
1st form
2nd form

What about it?

Salvo

In the first pair of calculations you are integrating over a singularity at the end of the integration internval when you use the non-trig defiinition (i.e. at x=t=1). The trig version does not have that singularity. So I suspect that the integration algorithm gives you a less accurate result because of that singularity, i.e. it is not so good at guessing the limit of the improper Riemann integral.

This seems to be comfirmed by the second pair of calculations where you are staying away from the singularity and the results are essentially the same.

(11-03-2017 01:54 PM)AlexFekken Wrote: [ -> ]In the first pair of calculations you are integrating over a singularity at the end of the integration internval when you use the non-trig defiinition (i.e. at x=t=1). The trig version does not have that singularity. So I suspect that the integration algorithm gives you a less accurate result because of that singularity, i.e. it is not so good at guessing the limit of the improper Riemann integral.

This seems to be comfirmed by the second pair of calculations where you are staying away from the singularity and the results are essentially the same.

thank you for the explaining, Alex.
Yes, I left the first pair in non trig definition for studying purpose, as they are well know in this form, however you are right: so there is a singularity to avoid (and in effect the Prime gives also a message first to calculate). Surely the code could be stronger, but I'd not want to pass at trig-form for the 1st pair, for now...


Salvo

Thank you salvomic!

(11-07-2017 12:51 PM)Eddie W. Shore Wrote: [ -> ]Thank you salvomic!

you're welcome!, thank you