#6756: [with patch, needs review] Implement ``diff`` format symbolic derivative
in
new symbolics
----------------------------+-----------------------------------------------
Reporter: gmhossain | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: symbolics | Keywords:
Reviewer: Nick Alexander | Author: Golam Mortuza Hossain
Merged: |
----------------------------+-----------------------------------------------
Comment(by gmhossain):
Replying to [comment:10 burcin]:
> It seems that applying chain rule to these inert derivatives can lead to
wrong answers:
>
{{{
sage: f = function('f')
sage: set_diff_derivative_level(2)
sage: f(y,y).diff(y,1)
2*diff(f(y, y), y, 1)
}}}
>
> Compare with the answer we get now:
{{{
sage: set_diff_derivative_level(0)
sage: f(y,y).diff(y,1)
D[0](f)(y, y) + D[1](f)(y, y)
}}}
>
> This example is from p. 26 (second page) in ....
> I suggest removing the chain rule from this implementation altogether
and keeping it as an alternative ''inert''
Thanks for the reference and I am certainly aware of this issue. If you
read the
docstring then you will find that I have even documented it. Furthermore,
I also
posted this issue for discussion to sage-devel (but without any definite
conclusion)
http://groups.google.com/group/sage-
devel/browse_thread/thread/c8d257981e3e3d98
Following are my comments:
(1) f(y,y) is not a genuine function of two variables. So asking for its
chain rule, pretending it to be a function of multiple variables, is
itself incorrect assertion.
(2) I don't think even D[] derivative output is much better in this
regard, specially if you implement and allow substitution of f(y,y). For
example. consider the substitution: f(y,y) = y in "D[0](f)(y, y) +
D[1](f)(y, y)", then you will get the same wrong answer from D[] as from
"diff".
(3) Applying chain rule is just an option in new diff implementation and
certainly not the default option. However, this could be useful sometime
(for example in computing Euler-Lagrange equation using functional
derivative of a formal functional "S(f(y), g(y))" this feature is needed.
In fact, this was the reason for implementing this feature.)
So I am sorry to differ from your opinion about removing this feature.
[[BR]]
> Then the implementation can be moved within the Sage library completely
as a
> subclass of SFunction.
[[BR]]
As I posted in the sage-devel, I initially implemented this within Sage as
SFunction
sub-class (as you suggest). Then I re-implemented this in c++ as pynac
native implementation
because this is 10-15 times faster than the Sage implementation.
Why do you want to have a slower implementation of diff than a faster one?
[[BR]]
> We should also implement conversions between the partial derivative
format and this one.
> This page gives a recipe on how this can be done:
>
>
http://209.85.129.132/search?q=cache%3Ahttp%3A%2F%2Fwww.mapleprimes.com%2Fforum
%2Fd-diff-conversion%23comment-8243
[[BR]]
I agree that we need this conversion at least to restore compatibility of
D[] with Maxima which is badly broken now because of D[] derivative.
However, I don't agree that I should implement this conversion and
certainly not as a pre-requirement for accepting this patch.
Given above arguments, I am reverting back to "needs review" status.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/6756#comment:11>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
