Implement derivative of gegenbauer(n,a,x) wrt to a

[sagetrac-mafra]

Implement

In [3]: gegenbauer(n,m,x)
Out[3]: gegenbauer(n, m, x)

In [4]: _.diff(m)
Out[4]: 
n - 1                                                                          
 ____                                                                          
 ╲                                                                             
  ╲   ⎛⎛      -k + n    ⎞                                                      
   ╲  ⎜⎝2⋅(-1)       + 2⎠⋅(k + m)⋅gegenbauer(k, m, x)     ⎛         2⋅k + 2      
   ╱  ⎜────────────────────────────────────────────── + ⎜──────────────────────
  ╱   ⎝            (-k + n)⋅(k + 2⋅m + n)                ⎝(k + 2⋅m)⋅(2⋅k + 2⋅m +
 ╱                                                                             
 ‾‾‾‾                                                                          
k = 0                                                                          

                                       
                                       
                                       
                                      ⎞
           2     ⎞                    ⎟
─── + ───────────⎟⋅gegenbauer(n, m, x) ⎟
 1)   k + 2⋅m + n ⎠                    ⎠
                                       

Previous description was (now implemented):

I noticed that the derivative of the gegenbauer polynomial wrt x was not implemented, so I wrote a patch for it.

I used the formula C'(n,a,x) = 2aC(n-1,a+1,x)

With the patch applied I get, for example:

sage: var('a');
sage: derivative(gegenbauer(2,a,x),x)
4*(a + 1)*a*x

Depends on #21645

CC: @rwst

Component: calculus

Keywords: gegenbauer, ultraspherical, derivative

Author: Carlos R. Mafra

Issue created by migration from https://trac.sagemath.org/ticket/21639

[sagetrac-mafra]

Patch implementing the derivative of gegenbauer(n,a,x) wrt x

[sagetrac-mafra]

Description changed:

--- 
+++ 
@@ -4,7 +4,11 @@
 
 With the patch applied I get, for example:
 
+
+```
 sage: var('a');
 sage: derivative(gegenbauer(2,a,x),x)
 4*(a + 1)*a*x
 
+```
+

[sagetrac-mafra]

comment:1

Attachment: 0001-Implement-derivative-of-gegenbauer-n-a-x-w.r.t-x.patch.gz

[sagetrac-mafra]

Author: Carlos R. Mafra

[rwst]

comment:4

Thanks. I would like to extend this ticket with derivatives on the second index:

In [3]: gegenbauer(n,m,x)
Out[3]: gegenbauer(n, m, x)

In [4]: _.diff(m)
Out[4]: 
n - 1                                                                          
 ____                                                                          
 ╲                                                                             
  ╲   ⎛⎛      -k + n    ⎞                                                      
   ╲  ⎜⎝2⋅(-1)       + 2⎠⋅(k + m)⋅gegenbauer(k, m, x)     ⎛         2⋅k + 2      
   ╱  ⎜────────────────────────────────────────────── + ⎜──────────────────────
  ╱   ⎝            (-k + n)⋅(k + 2⋅m + n)                ⎝(k + 2⋅m)⋅(2⋅k + 2⋅m +
 ╱                                                                             
 ‾‾‾‾                                                                          
k = 0                                                                          

                                       
                                       
                                       
                                      ⎞
           2     ⎞                    ⎟
─── + ───────────⎟⋅gegenbauer(n, m, x) ⎟
 1)   k + 2⋅m + n ⎠                    ⎠
                                       

I'll both implement in Pynac directly. See also #21644.

[rwst]

comment:5

The second case would depend on #21645.

[rwst]

comment:6

The first case is pynac/pynac@6587fdc

Doctests will be in the Pynac upgrade ticket, can be already seen at pynac/sage@85726b1

[sagetrac-mafra]

comment:7

Thanks for adding the derivative wrt m, I wasn't aware of this identity (where did you get it?).

Btw, what is the guiding principle to decide if things should go into pynac or pure sage?

I was under the impression that 'performance' was the primary factor to move things to pynac. Is this the case here?

[rwst]

comment:8

Replying to @sagetrac-mafra:

Thanks for adding the derivative wrt m, I wasn't aware of this identity (where did you get it?).

This is from SymPy.

Btw, what is the guiding principle to decide if things should go into pynac or pure sage?

I was under the impression that 'performance' was the primary factor to move things to pynac. Is this the case here?

You are right, in many cases this is the reason. One other reason can be that when all the function code is already in Pynac then for clarity add the new functionality there.

[sagetrac-mafra]

comment:9

Replying to @rwst:

Replying to @sagetrac-mafra:

Btw, what is the guiding principle to decide if things should go into pynac or pure sage?

I was under the impression that 'performance' was the primary factor to move things to pynac. Is this the case here?

You are right, in many cases this is the reason. One other reason can be that when all the function code is already in Pynac then for clarity add the new functionality there.

IMHO, Pynac should be reserved for performance reasons only.

Adding the derivative functions to Pynac only complicates the situation here as we lose a unified handling of the derivatives within the Python file, like in this case with 'hermite' needing a fix in Pynac and gen_laguerre in Sage. I don't think this adds to 'clarity'.

So I disagree with moving the derivative of gegenbauer to Pynac, as it is not performance motivated and could be easily done in Sage.

[rwst]

comment:10

You would not believe how much slower any Python (and Cython) code is versus C/C++. That's for example why SymPy has extraordinary performance problems for even simple computations, and why they urgently push the SymEngine project. I therefore feel justified to replace *any !Python/Cython code with C++, and contrarily to SymPy we are in the fortunate position that Pynac is already integrated in Sage. While the time when to do this transcription may certainly be a matter of debate, the necessity itself is not.