December 2013 - GiNaC-devel

RFC: step function and Pauli matrices
by Matthias Dellweg 05 Feb '14

05 Feb '14

Dear all, please consider the attached patches: GiNaC is able to check whether expressions are sums of possymbols. We can use that to evaluate some step functions immediately: 0001-Evaluate-step-whenever-possible.patch This should be a generic transformation from an integral with a step function to step functions times integrals without: 0002-Integrate-when-integrand-is-a-product-with-a-step-fu.patch This patch implements Pauli matrices in the same manner as in color.cpp (shamelessly borrowed...): 0003-Implementation-of-Pauli-matrices.patch As opposed to the color algebra, a product of pauli objects can always be reduced to a linear combination of single pauli objects: 0004-New-function-pauli_normalize.patch Best wishes, Matthias Dellweg

2 3

Fixing log evaluation for powers
by Vladimir V. Kisil 29 Dec '13

29 Dec '13

Dear All, Making check on current master, I noticed that the following test if (!ex(log(pow(p,a))).is_equal(a*log(p))) ++result; from exam_inifnc.cpp failed. I think that the evaluation rule log(p^a) -> a*log(p), if p>0 and a is real falls out of inifcns_trans.cpp. I am attaching the corresponding patch. 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

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-407-g9843321
by git＠ginac.de 29 Dec '13

29 Dec '13

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 98433210d31a34b55c8283eb7fb7767d6c830e14 (commit) from 9ada7a7f5c47e512b7bf6057d4c013612be9a33b (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 98433210d31a34b55c8283eb7fb7767d6c830e14 Author: Vladimir V. Kisil <kisilv(a)maths.leeds.ac.uk> Date: Sat Dec 28 23:58:40 2013 +0000 Fix evaluation of log(p^a) -> a*log(p), if p>0 and a is real. This evaluation was broken with commit e5c76f659e2e882d. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns_trans.cpp | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Fix for pattern matching
by Matthias Dellweg 20 Dec '13

20 Dec '13

Dear all, while using GiNaC, I came across a strange behaviour with pattern matching in products having more than one wildcard. The match succeeded in a probablistic fashion. My conclusion is, that expairseq::match dishonors the rule, that repl_lst will remain unchanged whenever false is returned. See the attached patch, which solves the problem for me. Anyway, I started to think about the whole matching mechanism. Wouldn't it be much easier, if the matching was done from the patterns perspective? A wildcard would know itself to match to anything. And it might be possible to match a single object to a product of this object and a global wildcard, since expairseq would know how to handle that. See for example 'sin(phi).match(sin(wild(0))*wild(1))'. There could be wildcards matching to everything not containing a specified Symbol. And in every case basic would only need to check for type equality and matchable operands. I think one can even implement that preserving the current interface by calling an internal virtual match with interchanged operands. Any thoughts on that? Best wishes, Matthias Dellweg

2 5

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-406-g9ada7a7
by git＠ginac.de 15 Dec '13

15 Dec '13

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 9ada7a7f5c47e512b7bf6057d4c013612be9a33b (commit) from e5c76f659e2e882da3d5dba60502d6851f782bf3 (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 9ada7a7f5c47e512b7bf6057d4c013612be9a33b Author: Matthias Dellweg <dellweg(a)tp1.uni-duesseldorf.de> Date: Tue Dec 10 10:55:28 2013 +0200 expairseq::match(): no side effects if match failed. Fixes spurious match failures. > match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1)) FAIL The reason is that expairseq::match() might assign a wildcard even if the match fails. The first attempted submatch is sin(y)*exp(b) with sin($0)*exp(a). It fails (as it should) but $0 == y gets assigned as a side effect (which is wrong). Next submatch is sin(x)*exp(a) with sin($0)*exp(a) (the same pattern as in the first submatch). This one fails because of spurious $0 == y assignment. Due to the unpredicatable term ordering the sequence of submatches might be different and the match might succeed (as it should). This makes debugging a bit more funny. Signed-off-by: Matthias Dellweg <dellweg(a)tp1.uni-duesseldorf.de> [Alexei Sheplyakov: figure out the cause of the problem, make a test case] ----------------------------------------------------------------------- Summary of changes: check/match_bug.cpp | 44 ++++++++++++++++++++++++++++++++++++++++++++ ginac/expairseq.cpp | 26 +++++++++++++++++++++----- 2 files changed, 65 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0