Changes between Version 1 and Version 2 of Ticket #25034
 Timestamp:
 04/04/18 13:52:27 (3 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #25034
 Property Cc rws slelievre added

Ticket #25034 – Description
v1 v2 1 I am using the gen_legendre_P function (an instance of Func_assoc_legendre_P from sage/functions/orthogonal_polys.py) to evaluate associated Legendre functions / Ferrers functions in Sage Math 8.1. 1 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 functions / Ferrers functions in !SageMath 8.1. 2 4 3 There appears to be a discrepancy in the results I obtain, depending on whether I use gen_legendre_P.eval_poly() or directly call gen_legendre_P() in some cases. I think this is because the _eval_ method first tries to call the _eval_special_values_ method, before using eval_poly. 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. 4 9 5 10 With this input … … 37 42 }}} 38 43 39 This discrepancy also seems to be present in spherical_harmonic when n == m (an instance of SphericalHarmonic from sage/functions/special.py), which is built using gen_legendre_P. 44 This discrepancy also seems to be present in spherical_harmonic when 45 n == m (an instance of !SphericalHarmonic from sage/functions/special.py), 46 which is built using gen_legendre_P. 40 47 41 After discussion in the sagedevel mailing list (https://groups.google.com/d/msg/sagedevel/IDtiGF6HB28/ErLsqI1eBAAJ) it appears that this is because the n == m case in _eval_special_values_ is based on https://dlmf.nist.gov/14.7#E15, but this is not defined in (infinity,1]. 48 After [[https://groups.google.com/d/msg/sagedevel/IDtiGF6HB28/ErLsqI1eBAAJdiscussion]] 49 in the sagedevel mailing list it appears that this is because the n == m 50 case in _eval_special_values_ is based on https://dlmf.nist.gov/14.7#E15, 51 but this is not defined in (infinity,1]. 42 52 43 For the spherical harmonics, where the argument x = cos(theta), x will always be in the range [1, 1 ], where special case used in _eval_special_values_ is not defined. 53 For the spherical harmonics, where the argument x = cos(theta), 54 x will always be in the range [1, 1 ], where special case used 55 in _eval_special_values_ is not defined. 44 56 45 On the sagedevel mailing list, Howard Cohl suggested that the correct formula for x in [1, 1] is 57 On the sagedevel mailing list, Howard Cohl suggested that 58 the correct formula for x in [1, 1] is 46 59 47 60 {{{ … … 51 64 See: https://groups.google.com/d/msg/sagedevel/IDtiGF6HB28/QWwnAeLJBAAJ 52 65 53 According to Howard Cohl this is formally a Ferrers function (defined on (1,1) ), rather than an associated Legendre polynomial. However, the existing code for Func_assoc_legendre_P does not seem to make any distinction between Ferrers and associated Legendre functions. 66 According to Howard Cohl this is formally a Ferrers function 67 (defined on (1,1) ), rather than an associated Legendre polynomial. 68 However, the existing code for Func_assoc_legendre_P does not 69 seem to make any distinction between Ferrers and associated 70 Legendre functions. 54 71 55 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).