Is new symbolic derivative really worth the efforts?

[Golam Mortuza Hossain]

Hi,

I have spent considerable amount of time in last one month
working with new symbolics. Overall, I am impressed with
it.

However, my experience with new derivative makes me
wonder whether the pynac "fderivative" construct is really
worth the efforts!

While implementing functional derivative and integration
algorithm for generalized function using new symbolics, I
have been brought to near a dead end because of new
derivative.

It....

(1) Breaks substitution:

Arguments of derivative can't be substituted

http://trac.sagemath.org/sage_trac/ticket/6480

(2) Nightmare for writing integration algorithm:

If h = f(g(x)).diff(x) then integrate(h, x) is trivial. However, in
new symbolics to do so, one needs compute

integrate( D[0](f)(g(x, y))*D[0](g)(x, y), x)

Let me claim: Integrating an expression involving new symbolic derivative
is at best EQUAL and often MORE computationally EXPENSIVE than its "diff"
counterpart.

(4) Causes Maxima interface to break:

http://trac.sagemath.org/sage_trac/ticket/6376

(4) Gives mathematically non-sensical results:

http://trac.sagemath.org/sage_trac/ticket/6465

(5) Looses information irrecoverably:

From "D[0](f)(x-a)" its not possible to decide whether original
variable of differentiation was "x" as in f(x-a).diff(x) or "a"
as in -f(x-a).diff(a). This again affects integration algorithm.

(6) Compact?

It is true that this format is sometime compact but consider
the counter example:
------
sage: f( g(x) + h(x) ).diff(x)
(D[0](g)(x) + D[0](h)(x))*D[0](f)(g(x) + h(x))
------

In old symbolics it takes less space to print
-----
sage: f( g(x) + h(x) ).diff(x)
diff(f(h(x) + g(x)), x, 1)
-----

(7) Printing issues:

We are still debating on this in separate thread.

My question now is it really worth solving all of the
above issue to keep working with fderivative of pynac?

Or should we just restore old "diff" by simply sub-classing it
from SFunction like what is being done for "integration"
and others?

Cheers,
Golam

[Tim Lahey]

On Jul 19, 2009, at 12:08 PM, Golam Mortuza Hossain wrote:

>
> Hi,
>
> I have spent considerable amount of time in last one month
> working with new symbolics. Overall, I am impressed with
> it.
>
> However, my experience with new derivative makes me
> wonder whether the pynac "fderivative" construct is really
> worth the efforts!
>
> While implementing functional derivative and integration
> algorithm for generalized function using new symbolics, I
> have been brought to near a dead end because of new
> derivative.
>
> It....
>
> (1) Breaks substitution:
>
> Arguments of derivative can't be substituted
>
> http://trac.sagemath.org/sage_trac/ticket/6480
>

This is a really big problem. I know I need to be able to
do this all the time.

>
>
> (2) Nightmare for writing integration algorithm:
>
> If h = f(g(x)).diff(x) then integrate(h, x) is trivial. However, in
> new symbolics to do so, one needs compute
>
> integrate( D[0](f)(g(x, y))*D[0](g)(x, y), x)
>
> Let me claim: Integrating an expression involving new symbolic
> derivative
> is at best EQUAL and often MORE computationally EXPENSIVE than its
> "diff"
> counterpart.
>
>

It's also a mess.

>
> (4) Causes Maxima interface to break:
>
> http://trac.sagemath.org/sage_trac/ticket/6376
>

Since there are many useful calculus-related routines, that's a problem.

>
>
> (4) Gives mathematically non-sensical results:
>
> http://trac.sagemath.org/sage_trac/ticket/6465
>

That's more of a problem that it doesn't know about integration, which
is
quite annoying.

>
>
> (5) Looses information irrecoverably:
>
> From "D[0](f)(x-a)" its not possible to decide whether original
> variable of differentiation was "x" as in f(x-a).diff(x) or "a"
> as in -f(x-a).diff(a). This again affects integration algorithm.
>

This is one of the reasons I hate this notation. It may be compact,
but it hides information that may be useful and makes it difficult to
unravel.

>
> (6) Compact?
>
> It is true that this format is sometime compact but consider
> the counter example:
> ------
> sage: f( g(x) + h(x) ).diff(x)
> (D[0](g)(x) + D[0](h)(x))*D[0](f)(g(x) + h(x))
> ------
>
> In old symbolics it takes less space to print
> -----
> sage: f( g(x) + h(x) ).diff(x)
> diff(f(h(x) + g(x)), x, 1)
> -----
>

The first appears to be an expansion. I'd much rather see the second.

>
> (7) Printing issues:
>
> We are still debating on this in separate thread.

I need to have standard partial derivative notation as an option at
least
in LaTeX form. There is no way I'm going to re-write the from this
notation
to standard notation hundreds of equations.

I've basically stopped working with Sage because of this notation. I
can see
what's going on much simpler with something like

\left.\frac{\partial f}{\partial x}(x,y)\right_{x=x-a}

than the equivalent in the D notation. Sure, it isn't as compact, but
from long
experience, I know exactly what it means. More importantly, my
supervisor and my
committee members know what it means. I thought there was going to be an
option of not using the D notation?

Note that I've been discussing specifically the LaTeX output. That's
what's most
important for me, but I'd prefer using notation that's consistent.
This D notation
may be internally consistent, but it doesn't work with the rest of Sage.

>
>
> My question now is it really worth solving all of the
> above issue to keep working with fderivative of pynac?
>
> Or should we just restore old "diff" by simply sub-classing it
> from SFunction like what is being done for "integration"
> and others?
>
> Cheers,
> Golam
>

Also, Maple has a useful feature of letting you present partial
derivatives in
the form f,x,x,x for a triple partial derivative with respect to x.
Note the variables
of f aren't show. They're implicit. However, this is just a nice
display feature, but they
do have a similar input feature. See PDETools and DETools.

Like I said above, this D notation has basically guaranteed I won't
use Sage
for my work.

Cheers,

Tim.

---
Tim Lahey
PhD Candidate, Systems Design Engineering
University of Waterloo
http://www.linkedin.com/in/timlahey

[William Stein]

At first glance doing this sounds like a really good idea. How hard
would it be for you to make a mock-up prototype of this to more
clearly demonstrate it? I'm definitely not opposed.

William

>>
>> Cheers,
>> Golam
>>
>
>
> Also, Maple has a useful feature of letting you present partial
> derivatives in
> the form f,x,x,x for a triple partial derivative with respect to x.
> Note the variables
> of f aren't show. They're implicit. However, this is just a nice
> display feature, but they
> do have a similar input feature. See PDETools and DETools.
>
> Like I said above, this D notation has basically guaranteed I won't
> use Sage
> for my work.
>
> Cheers,
>
> Tim.
>
> ---
> Tim Lahey
> PhD Candidate, Systems Design Engineering
> University of Waterloo
> http://www.linkedin.com/in/timlahey
>
>
> >
>

--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org

[Golam Mortuza Hossain]

Hi,

On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com> wrote:
>> On Jul 19, 2009, at 12:08 PM, Golam Mortuza Hossain wrote:
>>>
>>> My question now is it really worth solving all of the
>>> above issue to keep working with fderivative of pynac?
>>>
>>> Or should we just restore old "diff" by simply sub-classing it
>>> from SFunction like what is being done  for "integration"
>>> and others?
>
> At first glance doing this sounds like a really good idea.  How hard
> would it be for you to make a mock-up prototype of this to more
> clearly demonstrate it?   I'm definitely not opposed.

Thanks. OK, I will come up with a prototype "diff" hopefully soon.

I might need to ask some sage-pynac interface related questions
as my current understanding of this interface is limited.

Cheers,
Golam

[Golam Mortuza Hossain]

Hi,

On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com> wrote:
>

> At first glance doing this sounds like a really good idea.  How hard
> would it be for you to make a mock-up prototype of this to more
> clearly demonstrate it?   I'm definitely not opposed.

I need bit of help. How does one convert Ginac symbol to
python object?

For example: I could find examples of converting Ginac seq to
python arguments as: PyObject* args = exvector_to_PyTuple(seq);

However, I couldn't find an example for doing the same with
Ginac symbol. Basically, I need to pass the variable of differentiation
to python/cython function as

PyObject* pyresult = py_derivative(serial, var, args);

Thanks
Golam

[Golam Mortuza Hossain]

Hi,

On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com> wrote:

>>> Or should we just restore old "diff" by simply sub-classing it
>>> from SFunction like what is being done  for "integration"
>>> and others?
>
> At first glance doing this sounds like a really good idea.  How hard
> would it be for you to make a mock-up prototype of this to more
> clearly demonstrate it?   I'm definitely not opposed.

OK, here is a prototype implementation.

This is based on the principle that we stop applying chain rule
when we hit a symbolic function and whose derivative isn't defined
in sage/pynac.

These are the output from my sage console
---------
sage: f(x) = function('f',x)

sage: f(x).diff(x)
diff(f(x), x, 1)

sage: f(x).diff(x,2)
diff(f(x), x, 2)

sage: sin(cos(f(x))).diff(x)
-sin(f(x))*cos(cos(f(x)))*diff(f(x), x, 1)

sage: f(sin(x)).diff(x)
diff(f(sin(x)), x, 1)
---------

I have done three things:

(1) Defined a symbolic derivative wrapper SFunction (attached).
Frankly, this is not much different than: diff = function('diff')

(2) Added a small wrapper cython function in symbolic/pynac.pyx as

cdef public object py_derivative(unsigned id, object var, object args) except +:
"""
"""
cdef SFunction func = get_sfunction_from_serial(id)
assert(func is not None)
from sage.symbolic.derivative import newdiff
return newdiff(func(*args), var)

(3) Added a condition in "function.cpp" in pynac such that it calls
"py_derivative" instead of applying chain rule when it hits
a symbolic function and whose derivative function is not defined.

// No derivative defined? Then dont apply chain rule
if (opt.derivative_f == NULL) {
// convert seq to a PyTuple of Expressions
PyObject* args = exvector_to_PyTuple(seq);
PyObject* dvar = ex_to_pyExpression(s);
PyObject* pyresult = py_derivative(serial, dvar, args);
Py_DECREF(args);
Py_DECREF(dvar);
if (!pyresult) {
throw(std::runtime_error("function::derivative():
python function raised exception"));
}
// convert output Expression to an ex
ex result = pyExpression_to_ex(pyresult);
Py_DECREF(pyresult);
if (PyErr_Occurred()) {
throw(std::runtime_error("function::derivative():
python function (pyExpression_to_ex) raised exception"));
}
return result;

Notes: This is not the fastest implementation but my current priority
is to get my work done even if it takes bit longer rather than not
able to do at all.

Cheers,
Golam

[Robert Bradshaw]

Excellent idea!

- Robert

[Golam Mortuza Hossain]

Hi,

On Mon, Jul 20, 2009 at 8:31 PM, Robert
Bradshaw<robe...@math.washington.edu> wrote:
>> On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com>
>> wrote:
>>>>> Or should we just restore old "diff" by simply sub-classing it
>>>>> from SFunction like what is being done  for "integration"
>>>>> and others?
>>>
>>> At first glance doing this sounds like a really good idea.  How hard
>>> would it be for you to make a mock-up prototype of this to more
>>> clearly demonstrate it?   I'm definitely not opposed.
>>
>> OK, here is a prototype implementation.
>>
>> This is based on the principle that we stop applying chain rule
>> when we hit a symbolic function and whose derivative isn't defined
>> in sage/pynac.
>

> Excellent idea!

Thanks Robert.

Its now up to Sage policy maker to decide whether to continue
with pynac fderivative.

Inability to substitute the argument of D[] has ensured that
I am forced out from using new sage symbolics for my own work.

Cheers,
Golam,

[William Stein]

On Tue, Jul 21, 2009 at 3:03 PM, Golam Mortuza
Hossain<gmho...@gmail.com> wrote:
>
> Hi,
>
> On Mon, Jul 20, 2009 at 8:31 PM, Robert
> Bradshaw<robe...@math.washington.edu> wrote:
>>> On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com>
>>> wrote:
>>>>>> Or should we just restore old "diff" by simply sub-classing it
>>>>>> from SFunction like what is being done  for "integration"
>>>>>> and others?
>>>>
>>>> At first glance doing this sounds like a really good idea.  How hard
>>>> would it be for you to make a mock-up prototype of this to more
>>>> clearly demonstrate it?   I'm definitely not opposed.
>>>
>>> OK, here is a prototype implementation.
>>>
>>> This is based on the principle that we stop applying chain rule
>>> when we hit a symbolic function and whose derivative isn't defined
>>> in sage/pynac.
>>
>> Excellent idea!
>
> Thanks Robert.
>
> Its now up to Sage policy maker to decide whether to continue
> with pynac fderivative.

Well I'm a policy maker and I vote +1 to you continuing with this
line. As far as I can tell all the people involved with writing pyanc
(me, Mike Hansen, and Burcin), don't use formal derivatives at all for
any of our research/work. We just implemented something because other
people need it and to finish the switch over. Several people on
this list, including Golam, *do* need and use formal derivatives for
their research. So go for it!

William

>
> Inability to substitute the argument of D[]  has ensured that
> I am forced out from using new sage symbolics for my own work.
>
>
> Cheers,
> Golam,
>
> >
>

[Burcin Erocal]

I still don't see the motivation for switching back to Maxima behavior.
Somehow Maple and MMA both work the same way as GiNaC/pynac, and their
users don't have difficulty using them.

I'm sure if some users complained about how partial derivatives behaved
in these commercial systems, the companies would be motivated to
provide an alternative, but they don't.

> > Inability to substitute the argument of D[]  has ensured that
> > I am forced out from using new sage symbolics for my own work.

As I said above, you could have added a short term workaround for this,
once you start using cython to call pynac internals.

I believe the effort could be better spent fixing the bugs you listed
above. Once you start playing with the internals of pynac, the problems
you reported are not hard to fix.

Of course, I cannot tell you how to spend your time, but I really don't
see enough justification to change the default behavior of pynac/Sage
to something other than the current one, which closely models how Maple
and MMA does things.

So, my vote is -1.

Thanks.

Burcin

[Golam Mortuza Hossain]

Hi,

On Wed, Jul 22, 2009 at 7:47 AM, Burcin Erocal<bur...@erocal.org> wrote:

>> > Inability to substitute the argument of D[]  has ensured that
>> > I am forced out from using new sage symbolics for my own work.
>
> As I said above, you could have added a short term workaround for this,
> once you start using cython to call pynac internals.

As someone said, talk is cheap. FYI, I spent two full days trying to
find a work-around that really works. May be I did stupid way but I would
like to invite you to substitute f(x^2)=1 in the following simple expression
by using any sage algorithm

---------
h = f(x^2).diff(x)*(x+1/x)

sage: h.subs(f(x^2)==1)
2*(x + 1/x)*x*D[0](f)(x^2)

sage: h.subs(f(x^2).diff(x)==0)
2*(x + 1/x)*x*D[0](f)(x^2)
---------

> I believe the effort could be better spent fixing the bugs you listed
> above.

Thanks for letting know your "belief". If Sage development is dictated
by someone's belief rather than user's need, then I really shouldn't
argue anymore.

Cheers,
Golam

[Tim Lahey]

On Jul 22, 2009, at 6:47 AM, Burcin Erocal wrote:

>
> I still don't see the motivation for switching back to Maxima
> behavior.
> Somehow Maple and MMA both work the same way as GiNaC/pynac, and their
> users don't have difficulty using them.
>
> I'm sure if some users complained about how partial derivatives
> behaved
> in these commercial systems, the companies would be motivated to
> provide an alternative, but they don't.

Maple provides the D notation as an option (I don't know about
Mathematica).
Plus, they provide a way to convert to standard notation. Sage
doesn't. In
addition, this notation doesn't work properly with the rest of Sage
(which
includes Maxima).

+1 for changing things.

Sage is currently unusable for me with this notation.

[William Stein]

No worries. This will get sorted out. Burcin is sharing his opinion,
but it isn't the law or anything, and Sage development is not done by
"dictators".

I would like to hear more from other users if anybody else has an opinion.

-- William

[Tim Lahey]

On Jul 22, 2009, at 2:21 PM, William Stein wrote:

>
> No worries. This will get sorted out. Burcin is sharing his opinion,
> but it isn't the law or anything, and Sage development is not done by
> "dictators".
>
> I would like to hear more from other users if anybody else has an
> opinion.
>
> -- William

I'm in complete support of Golam on this. He and I have similar needs
on this
issue. Plus, as I've stated before, outputting the D notation to LaTeX
isn't
particularly useful since it isn't well recognized so any paper or
thesis using
it would first have to explain it. Given paper size constraints, this
isn't
practical.

Burcin states that Maple uses this notation for partial derivatives
and while it
can, it doesn't always and there is a command to convert to the
standard notation.
What I've found is that most average users use standard notation while
the people
work develop Maple packages prefer the D notation.

A big problem is that people aren't used to reading the D notation. I
can read
complex examples in the standard partial derivative notation quickly,
while I will
spend a minute or two on each line that uses D notation.

The other problem with the D notation is that it doesn't match
textbooks for teaching
purposes.

[Jaap Spies]

I think the D notation will not be very helpful in education. My
students (in the past) experienced severe problems using this in Maple.

Jaap


> -- William
>
> >
>

[Maurizio]

Hi all,
let me give some comments.

On Jul 19, 6:08 pm, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:
> Hi,
>
> I have spent considerable amount of time in last one month
> working with new symbolics. Overall, I am impressed with
> it.

One of the best selling point of Pynac has always been its speed, so
we should anyway keep in mind this.

>
> However, my experience with new derivative makes me
> wonder whether the pynac "fderivative" construct is really
> worth the efforts!
>
> While implementing functional derivative and integration
> algorithm for generalized function using new symbolics, I
> have been brought to near a dead end because of new
> derivative.
>

I think this is absolutely a STRATEGIC TOPIC. Having functional
derivatives and (most of all) integration in Sage should be top
priority, but this of course depends on my needs :P

> It....
>
> (1) Breaks substitution:
>
> Arguments of derivative can't be substituted
>
> http://trac.sagemath.org/sage_trac/ticket/6480
>
> (2) Nightmare for writing integration algorithm:
>
> If  h = f(g(x)).diff(x) then integrate(h, x) is trivial.  However, in
> new symbolics to do so, one needs compute
>
> integrate( D[0](f)(g(x, y))*D[0](g)(x, y), x)
>
> Let me claim:  Integrating an expression involving new symbolic derivative
> is at best EQUAL and often MORE computationally EXPENSIVE than its "diff"
> counterpart.
>

Well, at the very end I wouldn't comply about this if the integration
engine were fully working. What I can't understand is why can't we at
least obtain integration of a function defined by a derivative. Is
this functionality not present in Ginac? My (limited) understanding is
that integration is not provided by Ginac, so we should be really
careful in acquiring its derivative: I think that derivatives and
integrals should at least work out together pretty well by definition,
otherwise there's no chance to have a working integration engine.
What I am trying to say is that I am not cutting out Pynac's
fderivative since there's not a "fintegral" counterpart, but I want to
say that I clearly understand why your efforts have not been
successful: probably little can be accomplished without working on
pynac code itself. Moreover, it is not said that fderivative has a
good design.

> (4) Causes Maxima interface to break:
>
> http://trac.sagemath.org/sage_trac/ticket/6376
>

Although I think this is VERY important NOW, this shouldn't be an
issue, since Pynac wants to replace Maxima. I think that forgetting
retrocompatibility can sometimes be useful to have deep improvements.

> (4) Gives mathematically non-sensical results:
>
> http://trac.sagemath.org/sage_trac/ticket/6465
>

This is certainly more serious, but I think that in this case the
problem is that integration comes from maxima, while maybe derivatives
from Pynac, and they simply don't work well together, yet.

> (5) Looses information irrecoverably:
>
> From "D[0](f)(x-a)" its not possible to decide whether original
> variable of differentiation was "x" as in f(x-a).diff(x)  or "a"
> as in -f(x-a).diff(a). This again affects integration algorithm.
>

Is this caused by the representation or by how the information is
stored?
In case its just representation, it should be trivial to fix.
In case the information is not stored... Well, I don't think this is
possible, it does not make sense that the definition of a derivative
doesn't include the variable of derivation.

> (6) Compact?
>
> It is true that this format is sometime compact but consider
> the counter example:
> ------
> sage: f( g(x) + h(x) ).diff(x)
> (D[0](g)(x) + D[0](h)(x))*D[0](f)(g(x) + h(x))
> ------
>
> In old symbolics it takes less space to print
> -----
> sage: f( g(x) + h(x) ).diff(x)
> diff(f(h(x) + g(x)), x, 1)
> -----
>

Compactness is not necessarily the first issue to address, I think
(but this is questionable) that the output should be first of all very
readable. More than that, I think that staying with something
recognized as a standard in the scientific community (rather than in
the information technology world) has been one of the design choices
of SAGE I mostly agree with. So in this case I would consider
comparing with the output of Maple or MMA, but I would also stick with
the canonical mathematical representation (like partial derivatives or
whatever else) at least for the Latex output.

> (7) Printing issues:
>
>  We are still debating on this in separate thread.
>
> My question now is it really worth solving all of the
> above issue to keep working with fderivative of pynac?
>
> Or should we just restore old "diff" by simply sub-classing it
> from SFunction like what is being done  for "integration"
> and others?
>
> Cheers,
> Golam

At the very end, my personal opinion is that the community should plan
the work on derivatives AND integrals at the same time, otherwise it
does not make sense to stick with some derivatives we are not going to
support in the long term (integrals are going to take a lot of time
probably).

My 2 cents

best regards

Maurizio

[Ondrej Certik]

The second thing works in sympy:

In [7]: h.subs(f(x**2).diff(x), 1)
Out[7]:
1
x + ─
x

the first doesn't:

http://code.google.com/p/sympy/issues/detail?id=1549

and we'll fix it. This should definitely work.

Ondrej

[Golam Mortuza Hossain]

Hi,

On Wed, Jul 22, 2009 at 9:25 PM, Maurizio<maurizio...@gmail.com> wrote:
>> (5) Looses information irrecoverably:
>>
>> From "D[0](f)(x-a)" its not possible to decide whether original
>> variable of differentiation was "x" as in f(x-a).diff(x)  or "a"
>> as in -f(x-a).diff(a). This again affects integration algorithm.
>>
>
> Is this caused by the representation or by how the information is
> stored?
> In case its just representation, it should be trivial to fix.
> In case the information is not stored... Well, I don't think this is
> possible, it does not make sense that the definition of a derivative
> doesn't include the variable of derivation.

Unfortunately, it is the later. Pynac fderivative doesn't store
variable of differentiation by design.

This is the reason why it must continue applying chain rule
until the end.

> At the very end, my personal opinion is that the community should plan
> the work on derivatives AND integrals at the same time, otherwise it
> does not make sense to stick with some derivatives we are not going to
> support in the long term (integrals are going to take a lot of time
> probably).

I agree. Both Sage derivative and anti-derivative should be made compatible
to each other by design from the very beginning. Having them in two
separate sub-system can make thing only worse.

Regarding Maxima, I strongly believe that Sage needs Maxima for
symbolic integration for quite some time.

Cheers,
Golam

[Tim Lahey]

On Jul 22, 2009, at 7:33 PM, Golam Mortuza Hossain wrote:

>
> I agree. Both Sage derivative and anti-derivative should be made
> compatible
> to each other by design from the very beginning. Having them in two
> separate sub-system can make thing only worse.
>
> Regarding Maxima, I strongly believe that Sage needs Maxima for
> symbolic integration for quite some time.

I suspect that SymPy could be used for symbolic integration with some
work. How
much better (if it would be at all) is a different matter. I'll try to
put some
more work back into my integration test suite soon.

[Bill Page]

> On Jul 19, 6:08 pm, Golam Mortuza Hossain wrote:
>
>> (5) Looses information irrecoverably:
>>
>> From "D[0](f)(x-a)" its not possible to decide whether original
>> variable of differentiation was "x" as in f(x-a).diff(x) or "a"
>> as in -f(x-a).diff(a). This again affects integration algorithm.
>>

On Wed, Jul 22, 2009 at 5:25 PM, Maurizio wrote:
>
> Is this caused by the representation or by how the information
> is stored? In case its just representation, it should be trivial to
> fix. In case the information is not stored... Well, I don't think
> this is possible, it does not make sense that the definition of
> a derivative doesn't include the variable of derivation.
>

On Wed, Jul 22, 2009 at 2:33 PM, Tim Lahey wrote:
> ...

> Burcin states that Maple uses this notation for partial derivatives
> and while it can, it doesn't always and there is a command to
> convert to the standard notation. What I've found is that most
> average users use standard notation while the people work
> develop Maple packages prefer the D notation.
>

While I am not (yet) a fan of the "new symbolics" in Sage (it still
seems like a step backward), I am a little disappointed about this
discussion of 'D' versus 'diff'. It seems to miss almost entirely the
distinction between a function and an expression. I think it is quite
inaccurate to refer to this as simply a matter of notation, but as Tim
Lahey admits both constructions are well supported in Maple (and
probably in Mathematica as well, see previous threads on this
subject).

It is important to understand that 'D[...](...)' in Maple is a
function-valued operator, it takes a function (and one or more
parameters) as argument and returns a function. E.g.

> f:=(x,y)->x*y;
f := (x, y) -> x*y
> g:=D[1](f);
g := (x, y) -> y

The result of applying a function to some arguments is an expression.

> f(x0,y0);
x0*y0
> g(x0,y0);
y0

In the case that D operations on some unknown function

> D[1](p);
D[1](p)

The result is an unevaluated function-valued expression. The kind of
thing that one might substitute into this expression is simply a
function and the result is a function:

> eval(D[1](p), p=((x,y)->x*y));
(x, y) -> y

Sage already has a reasonable notation for functions not so different
than Maple's:

sage: q(x)=x^2; q
x |--> x^2

and this is the kind of object on which D should operate.

On Wed, Jul 22, 2009 at 12:31 PM, Golam Mortuza Hossain wrote:
> ...

> As someone said, talk is cheap. FYI, I spent two full days trying to
> find a work-around that really works. May be I did stupid way but I
> would like to invite you to substitute f(x^2)=1 in the following simple
> expression by using any sage algorithm
>
> ---------
> h = f(x^2).diff(x)*(x+1/x)
>
> sage: h.subs(f(x^2)==1)
> 2*(x + 1/x)*x*D[0](f)(x^2)
>
> sage: h.subs(f(x^2).diff(x)==0)
> 2*(x + 1/x)*x*D[0](f)(x^2)
> ---------

It does not make sense to ask to "substitute" 'f(x^2)=1' into 'h'
because 'f(x^2)' is an expression - not a function. What one should
expect perhaps is to write:

sage: q(x)=1
sage: h.subs({f:q})

since sage does not automatically treat constants as functions.

'diff(...)' on the other hand is an expression-valued operator. It
takes an expression as an argument (and one or more parameters) and
returns an expression. In the case that the expression contains some
unknown function, 'diff' will appear as an unevaluated expression in
the result.

> diff(p(x,y),x);
diff(p(x,y),x)

It might seem rather strange to see 'f(x^2).diff(x)*(x+1/x)' evaluated
as an expression containing 'D' but this is exactly what Maple does:

> h:=diff(f(x^2),x)*(x+1/x);
h := 2*D(f)(x^2)*x*(x+1/x)

To represent this as an expression using 'diff' requires an extra
variable 't1' and an unevaluated substitution:

> convert(h,diff);
2*eval(diff(f(t1),t1),{t1 = x^2})*x*(x+1/x)

The conversion to D is not done if no unevaluated substition is required:

> h:=diff(f(x),x)*(x+1/x);
h := diff(f(x),x)*(x+1/x)

But it is available if you want it:

> convert(h,D);
D(f)(x)*(x+1/x)

On the other hand what Sage (qua Maxima) used to do is to simply leave
'diff' completely unevaluated:

sage: function('f')
f
sage: h = f(x^2).diff(x)*(x+1/x)
sage: h
(x + 1/x)*diff(f(x^2), x, 1)

Notwithstanding the limitations in how Sage handles functions, this
does not seem quite as satisfactory.

My conclusion: -1 No, for reverting to this old behaviour.

Instead I think the new symbolics in Sage should continue to be
improved and conversions such as shown above implemented for people
who need/prefer to work with expressions.

Regards,
Bill Page.

[Golam Mortuza Hossain]

Hi,

On Wed, Jul 22, 2009 at 11:49 PM, Bill Page<bill...@newsynthesis.org> wrote:

>> ---------
>> h = f(x^2).diff(x)*(x+1/x)
>>
>> sage: h.subs(f(x^2)==1)
>> 2*(x + 1/x)*x*D[0](f)(x^2)
>>
>> sage: h.subs(f(x^2).diff(x)==0)
>> 2*(x + 1/x)*x*D[0](f)(x^2)
>> ---------
>
> It does not make sense to ask to "substitute" 'f(x^2)=1' into 'h'
> because 'f(x^2)' is an expression - not a function.

May be I didn't understand you properly. Are you saying substituting
an expression (f(x^2)) within an expression (h) by a constant is
invalid?

If so, then isn't: "(x+x^2).subs(x==1)" invalid as well?

Anyway, it does not help whether you substitute by
a constant or by an expression, the problem remains.
Within sage the only way I know, to do above substitution is
to do
-------
sage: h.subs(f(x^2).diff(x)/(2*x)==0)
0
-------
However, even using such ugly tricks, I have encountered issues in
substituting expression that contains new derivative.

Cheers,
Golam

[Tim Lahey]

This is done because a substitution for the x in f(x) is done and as
such
makes sense.

>
> To represent this as an expression using 'diff' requires an extra
> variable 't1' and an unevaluated substitution:
>
>> convert(h,diff);
> 2*eval(diff(f(t1),t1),{t1 = x^2})*x*(x+1/x)
>

This is nice, because we can see it in a standard form.

> The conversion to D is not done if no unevaluated substition is
> required:
>
>> h:=diff(f(x),x)*(x+1/x);
> h := diff(f(x),x)*(x+1/x)
>

Which doesn't happen at all in Sage.

> But it is available if you want it:
>
>> convert(h,D);
> D(f)(x)*(x+1/x)
>
> On the other hand what Sage (qua Maxima) used to do is to simply leave
> 'diff' completely unevaluated:
>
> sage: function('f')
> f
> sage: h = f(x^2).diff(x)*(x+1/x)
> sage: h
> (x + 1/x)*diff(f(x^2), x, 1)
>
> Notwithstanding the limitations in how Sage handles functions, this
> does not seem quite as satisfactory.
>
> My conclusion: -1 No, for reverting to this old behaviour.
>
> Instead I think the new symbolics in Sage should continue to be
> improved and conversions such as shown above implemented for people
> who need/prefer to work with expressions.
>

One of the major problems is that in Sage, D is just a notation, not
a functional operator like Maple. So, in Maple, the returned expression
can be worked with. Also, Sage forces this notation on all expressions.
Maple doesn't not even for functions as shown above.

Based upon previous comments, it doesn't seem like the "new symbolics"
contain complete information about the derivative which makes the
conversion
impossible in some situations and difficult in others.

For interaction with Maxima, we need the diff notation. I don't mind
having
the D operator and using it, but I don't think it should be the
default for
all expressions/functions. But, most importantly, we need the
conversion to
diff form.

I think Golam's work is useful because it gives the diff notation.

[Bill Page]

On Wed, Jul 22, 2009 at 8:52 PM, Golam Mortuza Hossain wrote:
>
> Hi,
>

> On Wed, Jul 22, 2009 at 11:49 PM, Bill Page wrote:
>
>>> ---------
>>> h = f(x^2).diff(x)*(x+1/x)
>>>
>>> sage: h.subs(f(x^2)==1)
>>> 2*(x + 1/x)*x*D[0](f)(x^2)
>>>
>>> sage: h.subs(f(x^2).diff(x)==0)
>>> 2*(x + 1/x)*x*D[0](f)(x^2)
>>> ---------
>>
>> It does not make sense to ask to "substitute" 'f(x^2)=1' into 'h'
>> because 'f(x^2)' is an expression - not a function.
>
> May be I didn't understand you properly. Are you saying substituting
> an expression (f(x^2)) within an expression (h) by a constant is
> invalid?
>

No. I am saying two things: First, 'f(x^2)' does not occur in the
value of 'h'. '.diff(x)' has already been evaluated as
'2*D[0](f)(x^2)'. Second the 'f' that does occur in the value of 'h'
represents a function - not an expression.

> If so, then isn't: "(x+x^2).subs(x==1)" invalid as well?
>

No. The expression 'x' does occur in '(x+x^2)'. This substitution is valid.

> Anyway, it does not help whether you substitute by
> a constant or by an expression, the problem remains.
> Within sage the only way I  know, to do above substitution is
> to do
> -------
> sage: h.subs(f(x^2).diff(x)/(2*x)==0)
> 0
> -------

What you need to do is to substitute a *function* for 'f' in
'...D[0](f)...' For example:

q(x)=1
h.subs({f:q}})

This used to work in previous releases of Sage. E.g.

wspage@debian:~/sage-3.4$ ./sage
----------------------------------------------------------------------
| Sage Version 3.4, Release Date: 2009-03-11 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

sage: function('f')
f

sage: a=f(x)
sage: q(x)=1
sage: a.subs({f:q})
1

--

but it seems to have been broken recently (perhaps by the new coercion system?)

page@boxen:~$ sage
----------------------------------------------------------------------
| Sage Version 4.1, Release Date: 2009-07-09 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------

sage: function('f')
f

sage: a=f(x)
sage: q(x)=1
sage: a.subs({f:q})
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)

/home/page/<ipython console> in <module>()

/usr/local/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression.substitute
(sage/symbolic/expression.cpp:13494)()

/usr/local/sage/local/lib/python2.6/site-packages/sage/symbolic/expression.so
in sage.symbolic.expression.Expression.coerce_in
(sage/symbolic/expression.cpp:9538)()

/usr/local/sage/local/lib/python2.6/site-packages/sage/structure/parent_old.so
in sage.structure.parent_old.Parent._coerce_
(sage/structure/parent_old.c:4632)()

/usr/local/sage/local/lib/python2.6/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.coerce
(sage/structure/parent.c:4765)()

TypeError: no canonical coercion from <type
'sage.symbolic.function.SFunction'> to Symbolic Ring

> However, even using such ugly tricks, I have encountered issues in
> substituting expression that contains new derivative.
>

I don't doubt it. I think these issues should be documented so
(eventually) they can be fixed.

Regards,
Bill Page.

[Golam Mortuza Hossain]

Hi Burcin,

I am sorry if I have hurt you by my earlier statements in this thread.

Best,
Golam

[Burcin Erocal]

On Thu, 23 Jul 2009 11:25:35 +0000

Golam Mortuza Hossain <gmho...@gmail.com> wrote:

>
> Hi Burcin,
>
> I am sorry if I have hurt you by my earlier statements in this thread.

As William said, no worries.

I am sorry if my message sounded personal. I was just trying to point
out that I don't agree with your proposal and William's +1 vote to
change the default behavior of symbolic derivatives. I didn't have time
to go over the e-mail again, and check/adjust the tone.

I am not opposed to having the unevaluated diff as an alternative
operator.

Cheers,
Burcin

[Golam Mortuza Hossain]

Hi,

On Thu, Jul 23, 2009 at 3:06 PM, Burcin Erocal<bur...@erocal.org> wrote:

> I am not opposed to having the unevaluated diff as an alternative
> operator.

Thanks Burcin. Surely, it helps to have both derivatives available to
Sage users. As Tim said, similar options are available to Maple users.

It is easy to put a flag that will instruct which derivative to use.

For example, in my prototype I could add another condition

 // No derivative defined and user wants diff format? Then dont apply chain rule
       if (opt.derivative_f == NULL && use_diff_format) {
.....
...
}

The next question is then whether we evaluate symbolic derivative
using "D" by default or we store them un-evaluated using "diff"
and evaluate them in terms of "D" only on-demand?

Mock-up usage could look like
------
sage: diff( f(x), x)
diff( f(x), x, 1)

sage: diff( f(x), x, D_format=True)
D[0](f)(x)
------

Given pynac "D" construct doesn't store enough information
for guaranteed conversion to "diff" format, personally I don't
see any way out other than storing symbolic derivative
un-evaluated by default.

Cheers,
Golam,

[Golam Mortuza Hossain]

Hi,

On Mon, Jul 20, 2009 at 4:37 PM, Golam Mortuza
Hossain<gmho...@gmail.com> wrote:
> On Sun, Jul 19, 2009 at 3:11 PM, William Stein<wst...@gmail.com> wrote:
>> At first glance doing this sounds like a really good idea.  How hard
>> would it be for you to make a mock-up prototype of this to more
>> clearly demonstrate it?   I'm definitely not opposed.
>
> OK, here is a prototype implementation.
>
> This is based on the principle that we stop applying chain rule
> when we hit a symbolic function and whose derivative isn't defined
> in sage/pynac.

> Notes: This is not the fastest implementation but my current priority
> is to get my work done even if it takes bit longer rather than not
> able to do at all.

I am back again on this issue :-) I just completed a native c++
implementation of "diff" format derivative in pynac.

This is around 15 times faster than my original prototype implementation.
This is even faster than pynac D derivative. Here are the output
from my sage session:

------
sage: f(x) = function('f', x)
sage: f(x).diff(x)

D[0](f)(x)

sage: timeit('f(x).diff(x)')
625 loops, best of 3: 89.9 µs per loop
sage: timeit('f(x).diff(x,100)')
125 loops, best of 3: 2.68 ms per loop

sage: from sage.symbolic.pynac import set_diff_derivative_level
sage: set_diff_derivative_level(1)

sage: f(x).diff(x)
diff(f(x), x, 1)

sage: timeit('f(x).diff(x)')
625 loops, best of 3: 83.9 µs per loop
sage: timeit('f(x).diff(x,100)')
625 loops, best of 3: 513 µs per loop
------

This implementation also supports applying chain-rule (where
make sense) on-demand.
------
sage: g(x) = function('g',x)
sage: f(g(x)).diff(x)
diff(f(g(x)), x, 1)

sage: set_diff_derivative_level(2)
sage: f(g(x)).diff(x)
diff(f(g(x)), g(x), 1)*diff(g(x), x, 1)

sage: f(x+x^2).diff(x)
diff(f(x^2 + x), x, 1)
-------
This would be useful for example in computing symbolic
functional derivative.

BTW, what is the final decision on the default derivative format
in Sage?

Note: As you can see this implementation ensures both
formats can happily co-exist with each other and user
can switch between the different formats in run-time.

However, we need to make a decision on the default
format as symbolic integration algorithm would depend
on the derivative format.

Cheers,
Golam

[Nick Alexander]

> I am back again on this issue :-) I just completed a native c++
> implementation of "diff" format derivative in pynac.

Can you pattern match on it? It's really irritating to do subs/
pattern matching on the existing derivatives.

Nick

[Golam Mortuza Hossain]

On Tue, Aug 4, 2009 at 1:02 PM, Nick Alexander<ncale...@gmail.com> wrote:
>
> Can you pattern match on it?  It's really irritating to do subs/
> pattern matching on the existing derivatives.

Yep! In fact, that was the main reason for doing so :-). The new
"diff" derivative is really a symbolic "function". So regular pattern
matching/substitution will work without any extra effort.

Cheers,
Golam

[Nick Alexander]

+1

Nick

[Maurizio]

That's great! Congratulations!

maurizio

On 4 Ago, 18:09, Golam Mortuza Hossain <gmhoss...@gmail.com> wrote:

[Burcin Erocal]

Hi Golam,

I'm replying to this e-mail so I can answer each of your points below
easily. I was very busy when you sent this message to write a proper
reply.

On Sun, 19 Jul 2009 13:08:28 -0300

Golam Mortuza Hossain <gmho...@gmail.com> wrote:

>
> Hi,
>
> I have spent considerable amount of time in last one month
> working with new symbolics. Overall, I am impressed with
> it.
>

> However, my experience with new derivative makes me
> wonder whether the pynac "fderivative" construct is really
> worth the efforts!

Please see my arguments below.

> While implementing functional derivative and integration
> algorithm for generalized function using new symbolics, I
> have been brought to near a dead end because of new
> derivative.

Many thanks for all your efforts and persistence.

I agree that there are lots of rough edges in the current (new)
symbolics subsystem, and working with it is rather frustrating. We
definitely need more help to complete the transition to pynac and move
forward.

> It....
>
> (1) Breaks substitution:
>
> Arguments of derivative can't be substituted
>
> http://trac.sagemath.org/sage_trac/ticket/6480

Thanks to Mike Hansen's SubstituteFunction converter, at the moment you
can do this:

sage: f = function('f')
sage: t1 = f(x).derivative(x)
sage: t1.substitute_function(f, g)
D[1](g)(x)

(I have the typesetting changes at #6344 applied.)

Unfortunately, the cases

sage: t1 = f(x+y).derivative(x)

and

sage: t1.substitute_function(f, f+g)

fail for different reasons.

IIRC, the first one is caused by a check put in to limit which
expressions we convert to Maxima before calling its differential
equation solver. This check should be moved closer to the interface
since there is no reason to limit the arguments of the D[...](...)
construct.

The second one fails because we don't allow arithmetic with symbolic
functions yet, so the last argument f+g cannot be evaluated. I think we
should just implement arithmetic, though an easier fix is to come up
with a way to give arguments to .substitute_function() without
requiring the arithmetic.

One way to solve the problem of arithmetic with symbolic functions is
to integrate them with the current callable symbolic functions.
E.g., things you get by doing:

sage: f(x,y) = 2*x + y
sage: f
(x, y) |--> 2*x + y

We could either use the existing CallableSymbolicExpressionRing
implementation and force the user to give names to the arguments, to
get something like:

sage: f
(x,y) -> f(x,y)
sage: g
(x,y) -> g(x,y)
sage: f+g
(x,y) -> f(x,y) + g(x,y)

Or we define a new parent for these, and let them have variable number
of unnamed arguments, keeping the current behavior. This would also let
us do this (from Maple):

> (f+g)(x);
f(x) + g(x)

> (f+g)(x,y);
f(x, y) + g(x, y)

Note that MMA doesn't seem to support this (or I don't know the syntax
for it):

In[10]:= (f+g)[x]

Out[10]= (f + g)[x]

> (2) Nightmare for writing integration algorithm:
>
> If h = f(g(x)).diff(x) then integrate(h, x) is trivial. However, in
> new symbolics to do so, one needs compute
>
> integrate( D[0](f)(g(x, y))*D[0](g)(x, y), x)
>
> Let me claim: Integrating an expression involving new symbolic
> derivative is at best EQUAL and often MORE computationally EXPENSIVE
> than its "diff" counterpart.

Are you saying that if we stop evaluating (partial) derivatives,
integrating them would be easier? :)

We just need to implement a simple heuristic to handle the example
above. If you follow the link to the Algorithms in Computer Algebra
book by Geddes, Czapor and Labahn in the symbolics wiki page

http://wiki.sagemath.org/symbolics

(second item under the title Integration)

You'll see this text at the end of page 473:

[...] When the above methods [table lookup] fail, MAPLE uses a form
of substitution called the "derivative-divides" method. This method
examines the integrand to see if it has a composite function
structure. If this is the case, it then attempts to substitute for
any composite functions, f(x), by dividing its derivative into the
integrand and checking if the result is independent of x after the
substitution u = f(x) occurs.

Some examples of what other systems do:

Mathematica 7.0 for Linux x86 (32-bit)
Copyright 1988-2008 Wolfram Research, Inc.

In[1]:= t = D[f[g[x]],x]

Out[1]= f'[g[x]] g'[x]

In[2]:= Integrate[t,x]

Out[2]= f[g[x]]

Note that MMA doesn't store any more information than we do about the
derivative:

In[3]:= FullForm[t]

Out[3]//FullForm= Times[Derivative[1][f][g[x]], Derivative[1][g][x]]

|\^/| Maple 12 (IBM INTEL LINUX)
._|\| |/|_. Copyright (c) Maplesoft, a division of Waterloo Maple
Inc. 2008 \ MAPLE / All rights reserved. Maple is a trademark of
<____ ____> Waterloo Maple Inc.
| Type ? for help.
> t:=diff(f(g(x)),x);
/d \
t := D(f)(g(x)) |-- g(x)|
\dx /

> integrate(t,x);
f(g(x))

I don't know how to ask Maple for the internal representation of t, but
I doubt if it is different from what MMA, or we do.

>
> (4) Causes Maxima interface to break:
>
> http://trac.sagemath.org/sage_trac/ticket/6376

This is a serious bug in the maxima interface. It has nothing to do
with how we denote derivatives, if we use partial derivaties or
unevaluated ones.

Patches are welcome.

> (4) Gives mathematically non-sensical results:
>
> http://trac.sagemath.org/sage_trac/ticket/6465

This is also an independent problem. With recent changes in pynac, you
stated that you fixed this:

http://groups.google.com/group/sage-devel/msg/765378d6b303cb85

> (5) Looses information irrecoverably:
>
> From "D[0](f)(x-a)" its not possible to decide whether original
> variable of differentiation was "x" as in f(x-a).diff(x) or "a"
> as in -f(x-a).diff(a). This again affects integration algorithm.

What is the lost information in this case? D[0](f)(x-a) is both
f(x-a).derivative(x) and -f(x-a).derivative(a).

sage: f(x-a).derivative(x)
D[1](f)(-a + x)
sage: -f(x-a).derivative(a)
D[1](f)(-a + x)

Where do you need the variable?

If we had a proper inverse for differentiation you could recover both
of these easily.

In[7]:= u = Derivative[1][f][x-a]

Out[7]= f'[-a + x]

In[8]:= Integrate[u, a]

Out[8]= -f[-a + x]

In[9]:= Integrate[u, x]

Out[9]= f[-a + x]

Unfortunately, the integrate command in Sage fails miserably on the
above examples.

> (6) Compact?
>
> It is true that this format is sometime compact but consider
> the counter example:
> ------
> sage: f( g(x) + h(x) ).diff(x)
> (D[0](g)(x) + D[0](h)(x))*D[0](f)(g(x) + h(x))
> ------
>
> In old symbolics it takes less space to print
> -----
> sage: f( g(x) + h(x) ).diff(x)
> diff(f(h(x) + g(x)), x, 1)
> -----
>
>

> (7) Printing issues:
>
> We are still debating on this in separate thread.

The debate seems to be over. There is a patch at #6344. Can someone
please review it?

> My question now is it really worth solving all of the
> above issue to keep working with fderivative of pynac?

As you can see from the output from other systems above, they use a
similar notation and data structure to represent partial derivatives. I
think it's worth considering why they chose to do things that way.

> Or should we just restore old "diff" by simply sub-classing it
> from SFunction like what is being done for "integration"
> and others?

IIRC, you wrote that your implementation can coexist with the current
one in Sage. Why don't you submit your changes so people can try out
both approaches?

Maple also has an inert "Diff" operator, your implementation can be the
Sage equivalent.

Thanks.

Burcin

[Golam Mortuza Hossain]

Hi Burcin,

On Wed, Aug 5, 2009 at 7:25 AM, Burcin Erocal<bur...@erocal.org> wrote:
>> (1) Breaks substitution:
>....

> We could either use the existing CallableSymbolicExpressionRing
> implementation and force the user to give names to the arguments, to
> get something like:

I would appreciate if you implement a solution for this issue.

>> Let me claim:  Integrating an expression involving new symbolic
>> derivative is at best EQUAL and often MORE computationally EXPENSIVE
>> than its "diff" counterpart.
>
> Are you saying that if we stop evaluating (partial) derivatives,
> integrating them would be easier? :)

I said that in bold, it would be EXPENSIVE means it requires more
computational steps.

>> (4) Causes Maxima interface to break:
>> http://trac.sagemath.org/sage_trac/ticket/6376
>
> This is a serious bug in the maxima interface. It has nothing to do
> with how we denote derivatives, if we use partial derivaties or
> unevaluated ones.

For the record, diff format derivative is NOT affected by this bug.

>> (4) Gives mathematically non-sensical results:
>> http://trac.sagemath.org/sage_trac/ticket/6465
>
> This is also an independent problem. With recent changes in pynac, you
> stated that you fixed this:

Yep, and it is because you are now asking for derivative to be carried
out w.r.t. a variable such as "x".

I guess, you might agree that by these changes you have pointed out
a deficiency in the pynac "D" derivative concept where derivative is specified
by paramaters such as 0,1 compared to the "diff" concept where
derivative is specified by variables such as "x", "y".

> IIRC, you wrote that your implementation can coexist with the current
> one in Sage. Why don't you submit your changes so people can try out
> both approaches?

Sure. I am waiting for the next Sage release as I want to avoid
re-basing again. I have implemented this using pynac-0.1.9.a1 and
sage-4.0.2. Given, you have now moved back to pynac-0.1.8.p2, I need
to backport pynac changes and forward-port Sage changes.

Cheers,
Golam

[Tim Lahey]

On Aug 5, 2009, at 6:25 AM, Burcin Erocal wrote:

>
>> (5) Looses information irrecoverably:
>>
>> From "D[0](f)(x-a)" its not possible to decide whether original
>> variable of differentiation was "x" as in f(x-a).diff(x) or "a"
>> as in -f(x-a).diff(a). This again affects integration algorithm.
>
> What is the lost information in this case? D[0](f)(x-a) is both
> f(x-a).derivative(x) and -f(x-a).derivative(a).
>
> sage: f(x-a).derivative(x)
> D[1](f)(-a + x)
> sage: -f(x-a).derivative(a)
> D[1](f)(-a + x)
>
> Where do you need the variable?
>

In various kinds of manipulations, you often need the variable. I use
this kind of information all the time. A common example is changing from
one variable to another.

Is it really over? This thread brings up many of the same problems.

>
>> My question now is it really worth solving all of the
>> above issue to keep working with fderivative of pynac?
>
> As you can see from the output from other systems above, they use a
> similar notation and data structure to represent partial
> derivatives. I
> think it's worth considering why they chose to do things that way.

One of the things is that other systems usually have a way to represent
things in standard notation which one will want to do at least for
teaching
purposes.

>
>> Or should we just restore old "diff" by simply sub-classing it
>> from SFunction like what is being done for "integration"
>> and others?
>
> IIRC, you wrote that your implementation can coexist with the current
> one in Sage. Why don't you submit your changes so people can try out
> both approaches?
>
> Maple also has an inert "Diff" operator, your implementation can be
> the
> Sage equivalent.
>

I don't like this being the inert Diff. I want to see my output in
standard
differential notation. Sage doesn't allow for that, except through
Golam's
work. Golam and I are not the only ones who want it.