Allow more general evaluation of FDerivativeOperator

[nbruin]

Currently:

sage: f=function("f");
sage: fx=f(x).diff(x).operator();
sage: fx
D[0](f)
sage: fx(x^2)
NotImplementedError: currently all arguments must be distinct variables

This can change.

Apply attachment: 12796.patch, attachment: sage-trac_12796-review.patch.

CC: @kcrisman @orlitzky

Component: symbolics

Author: Nils Bruin

Reviewer: Michael Orlitzky

Merged: sage-5.0.beta14

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

[nbruin]

comment:1

With the attached patch we have:

sage: f=function('f')
sage: g=function('g')
sage: fx=diff(f(x),x).operator()
sage: fx(g(x))
D[0](f)(g(x))
sage: I=fx(g(x)).integrate(x)
sage: I
integrate(D[0](f)(g(x)), x)

but unfortunately:

sage: I.simplify()
TypeError: unable to make sense of Maxima expression 'integrate(at(diff(f(t0),t0,1),[t0=g(x)]),x)' in Sage

The problem here is in symbolic_expression_from_maxima_string. Maxima's syntax allows a sequence as an argument for multiple substitutions, but the string-based parser is unable to handle that.
max_to_sr and sr_to_max do the trick already, which is why "I" can be defined in the first place. simplify still uses the strings-based conversion, hence the problem. Any experts on the parser of maxima strings want to weigh in? In short, the maxima expression

at( f(x,y,z), [x=u,y=v,z=w])

is valid, but is currently not accepted by the string-based parser.

[nbruin]

Author: Nils Bruin

[nbruin]

comment:2

The problem of lists as arguments can be solved by changing the grammar that sage.misc.parser.Parser accepts: An argument now can also contain a list. This is necessary because the parser is meant to accept essentially maxima language grammar and the construction at(f(x,y),[x=1,y=2]) is grammatical in maxima.
This means that some errors may change from being syntax errors to being semantic errors for certain uses of Parser, but none occur in the doc tests.

Another possibly controversial point is the name of the temporary variables used: now it's t0,t1,.... It's good to pick names that print reasonably, because they can end up on the screen (e.g., if you use
latex(maxima(f(x^2).diff(x)))
or
show(maxima(f(x^2).diff(x))).
and t seemed sufficiently neutral for that.

[nbruin]

Description changed:

--- 
+++ 
@@ -9,3 +9,5 @@
 NotImplementedError: currently all arguments must be distinct variables
 ```
 This can change.
+
+Apply [attachment: 12796.patch](https://github.com/sagemath/sage-prod/files/10655276/12796.patch.gz).

[kcrisman]

comment:5

Just for reference - related, though only very distantly, are #6756 and #6480.

[nbruin]

comment:6

Quite closely related: #7401, which takes a similar approach but only implements the univariate case.

[kcrisman]

comment:7

Hmm, does that mean that the doctest in #7401 that caused it to never be merged will now not fail? That would be nice; it was really a shame that was never brought in.

[orlitzky]

comment:8

It'll take me a while to understand the patch, but combined with #12801 and the use of function('f')(x) this looks like it will save me a lot of trouble:

sage: f = function('f')                            
sage: f(x).diff(x)(x=1).substitute_function(f, sin)
cos(1)

I have a lot of code I can test it against.

[orlitzky]

comment:9

The approach looks correct to me, I've just added a bunch of doctests and fixed some small issues:

• A failing doctest due to an extra space.
• The p_arg parser couldn't handle val = [x]
• Logic duplicated in max_at_to_sage() and calculus.at()

I get two deprecation warnings from my spline code, but one of them occurs on the lines that #12801 modifies, so we can fix them there.

If the review patch is OK, the original is for me.