On Jul 22, 2009, at 7:49 PM, Bill Page wrote:

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

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.

Cheers,

Tim.


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


--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to 
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to