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

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