#### Associated Legendre functions (24.9.99)

##### TANGUY Christian

There seem to be something curious about the associated Legendre function of the ﬁrst kind, LegendreP(v,u,x) (I am using version 5.1 on a PC under NT 4.0):

> g1 := sum('binomial(2*n+1,2*k+1)*2^(3*k)','k'=0..n);

(3/4)     n
g1 := 1/8 (2 n + 1) sqrt(Pi) 8      (-7)  LegendreP(n, -1/2, -9/7)

let us see g1 for n=0 and 1

> for n from 0 to 1 do g1 od;

(3/4)
-2 (-1)

(3/4)
- 21/8 sqrt(Pi) 8      LegendreP(1, -1/2, -9/7)

ﬁrst surprise, we would have expected 1 and 11, respectively, and certainly not a complex number in the case n=0. I found no way to obtain the answers expressed as integers, so I decided to force the ﬂoating point evaluation of g1

> for n from 0 to 3 do evalf(g1) od;

1.414213562 - 1.414213562 I

22.00000000

298.0000001

4286.000004

Hmmm, truncation errors... AND, apart from the spurious complex value for n=0, what seems to be TWICE the correct result.

Let us try something else, using the inert operator Sum.

> g1b := Sum(binomial(2*n+1,2*k+1)*2^(3*k),k=0..n):
> for n from 0 to 3 do value(g1b) od;

1

11

149

2143

correct results at last!

In fact, the result is the sum of the nth powers of 9 +- 4sqrt(2) with appropriate coeﬃcients. It can also be calculated using

I have two questions:

- why are the LegendreP functions used in the simpliﬁcation of sums when even the Help about them acknowledges that their deﬁnition is a bit tricky, with _EnvLegendreCut being -1..1 or 1..infinity?

- is the numerical evaluation of these functions correctly implemented? LegendreP(0,-1/2,cos(phi)) diﬀers from 2*sqrt(tan(phi/2)/Pi), as given in the Gradshteyn-Ryzhik (eq. 8.753.1).

##### Helmut Kahovec (30.9.99)

Apparently there is a bug in Release 5 concerning Legendre functions. Release 4 uses hypergeometric functions for the sum:

This is the correct result.