Changes between Version 2 and Version 7 of Ticket #25034
 Timestamp:
 06/15/20 23:11:41 (12 months ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #25034
 Property Cc fredrik.johansson added

Property
Milestone
changed from
sage8.2
tosage9.2

Ticket #25034 – Description
v2 v7 1 I am using the gen_legendre_P function (an instance of Func_assoc_legendre_P2 from sage/functions/orthogonal_polys.py) to evaluate associated Legendre1 I am using the `gen_legendre_P` function (an instance of `Func_assoc_legendre_P` 2 from `sage/functions/orthogonal_polys.py`) to evaluate associated Legendre 3 3 functions / Ferrers functions in !SageMath 8.1. 4 4 5 5 There appears to be a discrepancy in the results I obtain, depending on whether 6 I use gen_legendre_P.eval_poly() or directly call gen_legendre_P()in some cases.7 I think this is because the _eval_ method first tries to call the _eval_special_values_8 method, before using eval_poly.6 I use `gen_legendre_P.eval_poly()` or directly call `gen_legendre_P()` in some cases. 7 I think this is because the `_eval_` method first tries to call the `_eval_special_values_` 8 method, before using `eval_poly`. 9 9 10 10 With this input 11 12 11 {{{ 13 12 x = SR.var('x') 14 print gen_legendre_P.eval_poly(1,1,x)15 print gen_legendre_P(1,1,x)16 print gen_legendre_P.eval_poly(1,1,0.5)17 print gen_legendre_P(1,1,0.5)13 print(gen_legendre_P.eval_poly(1, 1, x)) 14 print(gen_legendre_P(1, 1, x)) 15 print(gen_legendre_P.eval_poly(1, 1, 0.5)) 16 print(gen_legendre_P(1, 1, 0.5)) 18 17 }}} 19 18 20 19 I obtain 21 22 20 {{{ 23 21 sqrt(x^2 + 1) … … 28 26 29 27 The result from eval_poly agrees with Mathematica, i.e. 30 31 28 {{{ 32 29 LegendreP[1, 1, 0.5] … … 34 31 }}} 35 32 36 Based on the above output, it seems to me that gen_legendre_P.eval_poly(1,1,cos(theta)) will always be real while gen_legendre_P(1,1,cos(theta))will be complex (unless cos(theta) = 1), since cos(theta) is in the interval [1,1].33 Based on the above output, it seems to me that `gen_legendre_P.eval_poly(1, 1, cos(theta))` will always be real while `gen_legendre_P(1, 1, cos(theta))` will be complex (unless cos(theta) = 1), since cos(theta) is in the interval [1,1]. 37 34 38 Looking at the code for Func_assoc_legendre_P._eval_special_values_, I suspect the culprit is the n == m case, which returns 39 35 Looking at the code for `Func_assoc_legendre_P._eval_special_values_`, I suspect the culprit is the `n == m` case, which returns 40 36 {{{ 41 37 factorial(2*m)/2**m/factorial(m) * (x**21)**(m/2) 42 38 }}} 43 39 44 This discrepancy also seems to be present in spherical_harmonicwhen45 n == m (an instance of !SphericalHarmonic from sage/functions/special.py),46 which is built using gen_legendre_P.40 This discrepancy also seems to be present in `spherical_harmonic` when 41 `n == m` (an instance of `SphericalHarmonic` from `sage/functions/special.py`), 42 which is built using `gen_legendre_P`. 47 43 48 44 After [[https://groups.google.com/d/msg/sagedevel/IDtiGF6HB28/ErLsqI1eBAAJdiscussion]] 49 in the sagedevel mailing list it appears that this is because the n == m50 case in _eval_special_values_is based on https://dlmf.nist.gov/14.7#E15,45 in the sagedevel mailing list it appears that this is because the `n == m` 46 case in `_eval_special_values_` is based on https://dlmf.nist.gov/14.7#E15, 51 47 but this is not defined in (infinity,1]. 52 48 53 49 For the spherical harmonics, where the argument x = cos(theta), 54 50 x will always be in the range [1, 1 ], where special case used 55 in _eval_special_values_is not defined.51 in `_eval_special_values_` is not defined. 56 52 57 53 On the sagedevel mailing list, Howard Cohl suggested that 58 54 the correct formula for x in [1, 1] is 59 60 55 {{{ 61 56 P_m^m(x)=(1)^m (2m)!/(2^m m!) (1x^2)^(m/2) … … 70 65 Legendre functions. 71 66 72 My proposed fix would be to have Func_assoc_legendre_P._eval_special_values_ choose between two n == m special cases, based on whether 1 <= x <= 1 (above expression) or > 1(current expression).67 My proposed fix would be to have `Func_assoc_legendre_P._eval_special_values_` choose between two `n == m` special cases, based on whether `1 <= x <= 1` (above expression) or `> 1` (current expression). 73 68 74 This raises the question of whether Func_assoc_legendre_Pis correctly defined, as at present it would seem to cover both Ferrers functions and associated Legendre functions.69 This raises the question of whether `Func_assoc_legendre_P` is correctly defined, as at present it would seem to cover both Ferrers functions and associated Legendre functions. 75 70 76 In my experience with the physics/chemistry literature, the spherical harmonics are universally defined in terms of "associated Legendre functions", even though the argument is x = cos(theta). DLMF suggests these are defined in terms of Ferrers functions of the first kind (https://dlmf.nist.gov/14.30.E1). Wolfram Mathematica does not seem to distinguish. Possibly it is worth flagging in the docstring for Func_assoc_legendre_Pthat the class seems to cover both functions.71 In my experience with the physics/chemistry literature, the spherical harmonics are universally defined in terms of "associated Legendre functions", even though the argument is x = cos(theta). DLMF suggests these are defined in terms of Ferrers functions of the first kind (https://dlmf.nist.gov/14.30.E1). Wolfram Mathematica does not seem to distinguish. Possibly it is worth flagging in the docstring for `Func_assoc_legendre_P` that the class seems to cover both functions.