Implicit derivation of functions (re-submission)
Dear All, I am resending the patch for implicit derivation of functions. Quote from the previous submission: http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html " I wish to propose another GiNaC extension. Consider function abs(). Since it can be presented as abs(z)=sqrt(z*z.conjugate()), the derivative of abs(f) may be calculated as (abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f) However, this formula cannot be packed into the present GiNaC code, since it only knows about the chain rule. Thus, the patch adds a possibility to define derivatives of functions in some general expression. In particular, the above derivative of abs() is defined. Example: cout << abs(log(z)).diff(z) << endl; // (before) -> D[0](abs)(log(z))*z^(-1) // (now) -> 1/2*(z^(-1)*conjugate(log(z))+log(z)*conjugate(z)^(-1))*abs(log(z))^(-1) " This issue independently appeared in this discussion: http://www.ginac.de/pipermail/ginac-devel/2014-April/002106.html If it is not included in the core code, then a user need to redefine the entire GiNaC function class to have this feature. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/
Dear Vladimir, On 10/29/2014 11:25 AM, Vladimir V. Kisil wrote:
I am resending the patch for implicit derivation of functions. Quote from the previous submission: http://www.ginac.de/pipermail/ginac-devel/2013-November/002053.html
" I wish to propose another GiNaC extension. Consider function abs(). Since it can be presented as abs(z)=sqrt(z*z.conjugate()), the derivative of abs(f) may be calculated as
(abs(f))'=(f'*f.conjugate()+f*f'.conjugate())/2/abs(f)
However, this formula cannot be packed into the present GiNaC code, since it only knows about the chain rule. Thus, the patch adds a possibility to define derivatives of functions in some general expression. In particular, the above derivative of abs() is defined. Example:
cout << abs(log(z)).diff(z) << endl; // (before) -> D[0](abs)(log(z))*z^(-1) // (now) -> 1/2*(z^(-1)*conjugate(log(z))+log(z)*conjugate(z)^(-1))*abs(log(z))^(-1) " This issue independently appeared in this discussion: http://www.ginac.de/pipermail/ginac-devel/2014-April/002106.html
If it is not included in the core code, then a user need to redefine the entire GiNaC function class to have this feature.
Thanks a lot for re-submitting this interesting patch about implicit derivatives! I've had a close look at it now. It is interesting because the problem it solves does indeed seem to be somewhat universal. In hindsight it may have been a mistake to teach every function its formal derivative only and perform the chain rule in function::derivative(). Your proposal is to have two ways to implement a function's derivative: 1) by registering the existing derivative_func (pure formal derivative) 2) or your new impl_derivative_func (smart derivative, has to care about chain rule) I wonder if there is a way to make this more uniform. What do you think? Even if there is no way to improve the uniformity of derivatives, your patch has three (very minor) problems which should be fixed before committing: The method should be documented in the tutorial, there ought to be a test case, and there should really be an impl_derivative_func for the Order function instead of handling this as another special case in function::derivative(). Best wishes -richard. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Dear Richard,
On Wed, 31 Dec 2014 19:41:11 +0100, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Your proposal is to have two ways to implement a function's RK> derivative: 1) by registering the existing derivative_func (pure RK> formal derivative) 2) or your new impl_derivative_func (smart RK> derivative, has to care about chain rule) RK> I wonder if there is a way to make this more uniform. What do RK> you think? Of course, the chain rule may be included as a particular case in the more general method. This will require a user slightly revise their custom function definitions for the new version of GiNaC. Do you consider this to be a reasonable price for a more straightforward code? RK> derivatives, your patch has three (very minor) problems which RK> should be fixed before committing: You are right. I may do this within a couple of weeks, I hope. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835
Dear Vladimir, On 01/02/2015 04:19 PM, Vladimir V. Kisil wrote:
Dear Richard,
On Wed, 31 Dec 2014 19:41:11 +0100, "Richard B. Kreckel" <kreckel@in.terlu.de> said:
RK> Your proposal is to have two ways to implement a function's RK> derivative: 1) by registering the existing derivative_func (pure RK> formal derivative) 2) or your new impl_derivative_func (smart RK> derivative, has to care about chain rule)
RK> I wonder if there is a way to make this more uniform. What do RK> you think?
Of course, the chain rule may be included as a particular case in the more general method. This will require a user slightly revise their custom function definitions for the new version of GiNaC. Do you consider this to be a reasonable price for a more straightforward code?
We shouldn't change the semantics of how the chain rule is applied to derivative_func because this would break existing code out there. And you're probably right that the not having to code the chain rule manually in most cases makes the code so much more straightforward that it's worth maintaining this more general case in the long run. I think this settles it: we should support both functions. In hindsight, what made your patch a little bit hard to understand to me may have been the function's naming _impl. What is the reason you named it like this? Isn't it applying the chain rule explicitly, rather than implicitly/automatically? Could we name it differently?
RK> derivatives, your patch has three (very minor) problems which RK> should be fixed before committing:
You are right. I may do this within a couple of weeks, I hope.
Thanks. -richard. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
On 01/04/2015 11:32 AM, Richard B. Kreckel wrote:
And you're probably right that the not having to code the chain rule manually in most cases makes the code so much more straightforward that it's worth maintaining this more general case in the long run.
Should be: ...it's worth maintaining this special case in the long run. Sorry. -richard. -- Richard B. Kreckel <http://in.terlu.de/~kreckel/>
Dear All, I have modified the patch for derivatives of functions along the line Richard suggested: * The method renamed to explicit derivative; * Derivatives of Order() (and conjugate(), real_part(), imag_part()) are handled through it; * Exams are added to the check suit; * Tutorial is updated. The patch is attached. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835
Dear All, A small improvement of the previous patch: it uses function::current_serial, which I did not noticed before. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk www: http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://www.worldscientific.com/worldscibooks/10.1142/p835
On Sat, 31 Jan 2015 18:07:42 +0000, "Vladimir V. Kisil" <kisilv@maths.leeds.ac.uk> said:
VVK> Dear All, I have modified the patch for derivatives of VVK> functions along the line Richard suggested: VVK> * The method renamed to explicit derivative; VVK> * Derivatives of Order() (and conjugate(), real_part(), VVK> imag_part()) are handled through it; VVK> * Exams are added to the check suit; * Tutorial is updated.
participants (2)
-
Richard B. Kreckel
-
Vladimir V. Kisil