Opened 5 years ago

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

Reported by: Owned by: mafra minor sage-7.4 calculus gegenbauer, ultraspherical, derivative rws Carlos R. Mafra N/A #21645

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) = 2*a*C(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

```

Changed 5 years ago by mafra

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

comment:1 Changed 5 years ago by mafra

• Description modified (diff)

comment:3 Changed 5 years ago by mafra

• Authors set to Carlos R. Mafra

comment:4 Changed 5 years ago by rws

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 ⎠                    ⎠

```

comment:5 Changed 5 years ago by rws

The second case would depend on #21645.

comment:6 Changed 5 years ago by rws

Version 0, edited 5 years ago by rws (next)

comment:7 follow-up: ↓ 8 Changed 5 years ago by mafra

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?

Last edited 5 years ago by mafra (previous) (diff)

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 5 years ago by rws

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.

comment:9 in reply to: ↑ 8 Changed 5 years ago by 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.

comment:10 follow-up: ↓ 11 Changed 5 years ago by rws

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.

Last edited 5 years ago by rws (previous) (diff)