January 2015 - GiNaC-devel

04 Jun '15

Hi, is there any reason not to define the derivative of the built-in abs() function as either abs(x)/x or csgn(x) ? Currently it has not derivative defined at all. Regards, Jan

5 8

Implicit derivation of functions (re-submission)
by Vladimir V. Kisil 02 Feb '15

02 Feb '15

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(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 6

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-441-gfb9800b
by git＠ginac.de 31 Jan '15

31 Jan '15

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, master has been updated via fb9800befac02abddc754d051501ec446ae2b9bf (commit) from 2afa71937b3c12cdc70f01213baa8a92be4b604a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit fb9800befac02abddc754d051501ec446ae2b9bf Author: Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk> Date: Sat Jan 31 13:04:13 2015 +0100 Put a reference on eta function into tutorial. ----------------------------------------------------------------------- Summary of changes: doc/tutorial/ginac.texi | 3 +++ 1 file changed, 3 insertions(+) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Tutorial micro patch: eta function
by Vladimir V. Kisil 31 Jan '15

31 Jan '15

Dear All, It appears that eta() functions is coded but was not mentioned in the tutorial, I am attaching a micro patch for it. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)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

1 0

test
by Richard B. Kreckel 25 Jan '15

25 Jan '15

please ignore

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-440-g2afa719
by git＠ginac.de 25 Jan '15

25 Jan '15

1 0

Small patch to indexed.cpp
by Vladimir V. Kisil 24 Jan '15

24 Jan '15

Dear All, Looking at Vladislav's example of contacting Dirac gammas, I noted certain inefficiency in indexed.cpp. The general procedure simplify_indexed() calls simplify_indexed_product() for every its product-type sub-expression. If simplify_indexed_product() modified the expression it recursively calls simplify_indexed() to look at the new expression. In the Vladislav's example the deepness of nested calls can be around 135. The proposed small patch make a bit of optimisation: if the new expression shall be a product, then simplify_indexed_product() calls itself directly. Previously it end up there only after a call through simplify_indexed(). Although this reduces deepness of nested calls to around 100, the gain in speed is hardly noticeable---just a couple of percents (unfortunately). Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)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

1 0

Small simplify_indexed() patch
by Vladimir V. Kisil 21 Jan '15

21 Jan '15

Dear All, I wish to propose for a discussion a small patch to indexed.cpp. I looked at the raised issue with slow performance in contracting Dirac gammas. The present algorithm does this recursively, in Vladyslav's example the deepness may reach 140 nested calls. The proposed patch reduced it around to 100 levels by avoiding to call simplify_indexed() if it will re-direct to simplify_indexed_product() anyway. However, I shall say that the patch only marginally improves timing: by a couple of percents at best. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)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

1 0