#13720: Scale legendre_P to [a,b]
------------------------------------+---------------------------------------
Reporter: mjo | Owner: burcin
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-5.6
Component: symbolics | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Michael Orlitzky | Merged in:
Dependencies: | Stopgaps:
------------------------------------+---------------------------------------
Comment (by mjo):
Replying to [comment:2 fwclarke]:
> * The code seems over-complicated to me. Replacing the last few lines
with
> {{{
> R = PolynomialRing(ZZ, 't')
> f = R([(-1)^(n - k)*binomial(n, k)*binomial(n + k, k) for k in
range(n + 1)])
> return f((x - a)/(b - a))
> }}}
> is much simpler and is significantly faster. Moreover, this makes
expressions such as
> {{{
> legendre_P(4, Zmod(5), 3, 6)
> }}}
> evaluate correctly; at it stands the patch yields an
> {{{
> ArithmeticError: 0^0 is undefined.
> }}}
>
[[BR]]
I tried this, but it's producing the wrong results. For example,
{{{
sage: legendre_P(1, x)
-1/2*x - 5/2
}}}
That said, there are two reasons it might seem over-complicated.
The first is that I was very careful not to break any existing doctests,
even though they're doing some crazy things. I tried to comment each of
these hurdles.
The second is that I wanted to be clear about what was happening. The
`c(m)` and `g(m)` functions are as defined in A&S. So the final `return`
statement is exactly the form given in the reference. The use of the
affine transform `phi()` allows me to retain that form, and also provides
some rationale for the result. I think this makes it (more) clear that
we're composing the standard `P()` over [-1,1] with an affine transform,
which will intuitively preserve orthogonality.
[[BR]]
> * I don't see why `a` and `b` need to be real numbers. Actually they
could be polynomial variables, giving:
> {{{
> sage: R.<r,s,t> = QQ[]
> sage: legendre_P(2, t, r, s)
> 6*((r - t)/(r - s) - 1)*(r - t)/(r - s) + 1
> }}}
>
[[BR]]
I'm happy to change this if it can be done without breaking the existing
doctests. I'll wait to see what you say about the first thing.
[[BR]]
> * I don't see the need to use `bool` in doctests such as
> {{{
> bool(legendre_P(0, x, 0, 1) == p0)
> }}}
[[BR]]
Often, the `==` operator will return a symbolic equality rather than
True/False. This is true even in this simple case:
{{{
sage: p0 = 1
sage: legendre_P(0, x, 0, 1) == p0
1 == 1
}}}
If you cast the symbolic equality to `bool`, you get,
* True, if Sage can convince itself that equality holds.
* False, if Sage can "prove" inequality.
* False, if it's not sure.
So it should be safe to test for `True`.
[[BR]]
> * It's not clear to me why back-quotes are used in some of the error
strings:
> {{{
> raise TypeError('`n` must be a natural number')
> }}}
> but
> {{{
> raise ValueError('n must be nonnegative')
> }}}
[[BR]]
I was just careless with that one, I'll fix it. I think backticks or
single quotes are needed around 'a' and 'b', otherwise it reads weird. But
'n' at the beginning is fine without it.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13720#comment:3>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
