72 views

Skip to first unread message

Jul 19, 2009, 12:08:28 PM7/19/09

to sage-...@googlegroups.com

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

Jul 19, 2009, 1:58:35 PM7/19/09

to sage-...@googlegroups.com

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

Jul 19, 2009, 2:11:21 PM7/19/09

to sage-...@googlegroups.com

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

Jul 19, 2009, 3:24:22 PM7/19/09

to sage-...@googlegroups.com

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

Jul 19, 2009, 10:24:46 PM7/19/09

to sage-...@googlegroups.com

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

Jul 20, 2009, 3:37:21 PM7/20/09

to sage-...@googlegroups.com

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

Jul 20, 2009, 7:31:01 PM7/20/09

to sage-...@googlegroups.com

Excellent idea!

- Robert

Jul 21, 2009, 6:03:04 PM7/21/09

to sage-...@googlegroups.com

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,

Jul 21, 2009, 6:54:11 PM7/21/09

to sage-...@googlegroups.com

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

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,

>

> >

>

Jul 22, 2009, 6:47:18 AM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 12:31:56 PM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 12:37:24 PM7/22/09

to sage-...@googlegroups.com

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.

Jul 22, 2009, 2:21:03 PM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 2:33:54 PM7/22/09

to sage-...@googlegroups.com

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.

Jul 22, 2009, 5:06:55 PM7/22/09

to sage-...@googlegroups.com

students (in the past) experienced severe problems using this in Maple.

Jaap

> -- William

>

> >

>

Jul 22, 2009, 5:25:36 PM7/22/09

to sage-devel

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.

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

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.

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.

>

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.

>

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.

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

>

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.

>

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)

> -----

>

(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

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

Jul 22, 2009, 7:00:37 PM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 7:33:42 PM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 7:40:17 PM7/22/09

to sage-...@googlegroups.com

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.

Jul 22, 2009, 7:49:07 PM7/22/09

to sage-...@googlegroups.com

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

>>

>

>> (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.

Jul 22, 2009, 8:52:45 PM7/22/09

to sage-...@googlegroups.com

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

Jul 22, 2009, 9:43:57 PM7/22/09

to sage-...@googlegroups.com

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.

Jul 22, 2009, 9:45:46 PM7/22/09

to sage-...@googlegroups.com

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

>

> Hi,

>

>

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

>

>

>>> ---------

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

Jul 23, 2009, 7:25:35 AM7/23/09

to sage-...@googlegroups.com

Hi Burcin,

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

Best,

Golam

Jul 23, 2009, 11:06:14 AM7/23/09

to sage-...@googlegroups.com

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

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

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

Jul 23, 2009, 9:12:17 PM7/23/09

to sage-...@googlegroups.com

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,

Aug 4, 2009, 11:55:43 AM8/4/09

to sage-...@googlegroups.com

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

Aug 4, 2009, 12:02:53 PM8/4/09

to sage-...@googlegroups.com

> I am back again on this issue :-) I just completed a native c++

> implementation of "diff" format derivative in pynac.

> 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

Aug 4, 2009, 12:09:07 PM8/4/09

to sage-...@googlegroups.com

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.

>

> 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

Aug 4, 2009, 12:51:07 PM8/4/09

to sage-...@googlegroups.com

+1

Nick

Aug 4, 2009, 4:29:14 PM8/4/09

to sage-devel

That's great! Congratulations!

maurizio

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

maurizio

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

Aug 5, 2009, 6:25:34 AM8/5/09

to sage-...@googlegroups.com

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

Aug 5, 2009, 9:38:16 AM8/5/09

to sage-...@googlegroups.com

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

Aug 5, 2009, 10:03:23 AM8/5/09

to sage-...@googlegroups.com

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.

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu