Changes between Version 1 and Version 2 of Ticket #25034


Ignore:
Timestamp:
04/04/18 13:52:27 (3 years ago)
Author:
slelievre
Comment:

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.
     1I am using the gen_legendre_P function (an instance of Func_assoc_legendre_P
     2from sage/functions/orthogonal_polys.py) to evaluate associated Legendre
     3functions / Ferrers functions in !SageMath 8.1.
    24
    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.
     5There appears to be a discrepancy in the results I obtain, depending on whether
     6I use gen_legendre_P.eval_poly() or directly call gen_legendre_P() in some cases.
     7I think this is because the _eval_ method first tries to call the _eval_special_values_
     8method, before using eval_poly.
    49
    510With this input
     
    3742}}}
    3843
    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.
     44This discrepancy also seems to be present in spherical_harmonic when
     45n == m (an instance of !SphericalHarmonic from sage/functions/special.py),
     46which is built using gen_legendre_P.
    4047
    41 After discussion in the sage-devel mailing list (https://groups.google.com/d/msg/sage-devel/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].
     48After [[https://groups.google.com/d/msg/sage-devel/IDtiGF6HB28/ErLsqI1eBAAJ|discussion]]
     49in the sage-devel mailing list it appears that this is because the n == m
     50case in _eval_special_values_ is based on  https://dlmf.nist.gov/14.7#E15,
     51but this is not defined in (-infinity,1].
    4252
    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.
     53For the spherical harmonics, where the argument x = cos(theta),
     54x will always be in the range [-1, 1 ], where special case used
     55in _eval_special_values_ is not defined.
    4456
    45 On the sage-devel mailing list, Howard Cohl suggested that the correct formula for x in [-1, 1] is
     57On the sage-devel mailing list, Howard Cohl suggested that
     58the correct formula for x in [-1, 1] is
    4659
    4760{{{
     
    5164See: https://groups.google.com/d/msg/sage-devel/IDtiGF6HB28/QWwnAeLJBAAJ
    5265
    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.
     66According to Howard Cohl this is formally a Ferrers function
     67(defined on (-1,1) ), rather than an associated Legendre polynomial.
     68However, the existing code for Func_assoc_legendre_P does not
     69seem to make any distinction between Ferrers and associated
     70Legendre functions.
    5471
    5572My 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).