- GiNaC-devel - ginac.de

excompiler.cpp: unistd.h
by Jan Rheinländer 06 Nov '16

06 Nov '16

Hi, #include <unistd.h> trips up compilation with MSVC. Is it really required? I commented it out and the file compiled anyway. Also, configure.ac checks for unistd.h, and reports it is not there on Windows. Shouldn't excompiler.cpp make use of that information? Greetings, Jan

2 8

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-572-g8305ec3
by git＠ginac.de 08 Oct '16

08 Oct '16

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 8305ec388e5c205b7392566d32582f9d08adb88d (commit) from d7a37762af4cdcaccb97c941427f8dfcf8448205 (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 8305ec388e5c205b7392566d32582f9d08adb88d Author: Till Hofmann <thofmann(a)fedoraproject.org> Date: Sat Oct 8 20:34:40 2016 +0200 Replace mktemp with mkstemp. As the manpage says, mktemp is deprecated ("Never use mktemp") and gcc warns about the usage of mktemp. Replace mktemp with its safe variant mkstemp. ----------------------------------------------------------------------- Summary of changes: ginac/excompiler.cpp | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations tag, release_1-7-1, created. release_1-4-0-571-gd7a3776
by git＠ginac.de 02 Oct '16

02 Oct '16

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 tag, release_1-7-1 has been created at d7a37762af4cdcaccb97c941427f8dfcf8448205 (commit) - Log ----------------------------------------------------------------- commit d7a37762af4cdcaccb97c941427f8dfcf8448205 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Sun Oct 2 00:46:08 2016 +0200 Finalize 1.7.1 release. ----------------------------------------------------------------------- hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-571-gd7a3776
by git＠ginac.de 02 Oct '16

02 Oct '16

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 d7a37762af4cdcaccb97c941427f8dfcf8448205 (commit) via 94f2d7ab9102d58550fa66d2718701571e87825d (commit) from c018acc8ddca143ba6a202ad095b192205708bc4 (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 d7a37762af4cdcaccb97c941427f8dfcf8448205 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Sun Oct 2 00:46:08 2016 +0200 Finalize 1.7.1 release. commit 94f2d7ab9102d58550fa66d2718701571e87825d Author: Richard Kreckel <kreckel(a)ginac.de> Date: Sun Oct 2 00:45:11 2016 +0200 Suppress compiler warnings about inconsistent override. The introduction of the 'override' keyword in GiNaC in d5b86dd10 was deliberately incomplete: Duplication of code in macros was avoided. It turns out that some compilers (e.g. g++ -Wsuggest-override or clang++ -Wall) complain if the 'override' keyword is used inconsistently. Let's make this consistent now, even if it leads to the introduction of two more macros. ----------------------------------------------------------------------- Summary of changes: NEWS | 7 +++++++ ginac/print.h | 29 +++++++++++++++++++---------- ginac/registrar.h | 26 ++++++++++++++++---------- ginac/version.h | 4 ++-- 4 files changed, 44 insertions(+), 22 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-569-gc018acc
by git＠ginac.de 14 Sep '16

14 Sep '16

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 c018acc8ddca143ba6a202ad095b192205708bc4 (commit) from 6ad2b996d58c0b144770e7cf3079386fcd385908 (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 c018acc8ddca143ba6a202ad095b192205708bc4 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Wed Sep 14 22:00:29 2016 +0200 Fix compilation of programs using __attribute__((deprecated)). Ouu, we mustn't redefine 'deprecated' in order for this to work... Thanks to Alexander Proskurin for reporting this. ----------------------------------------------------------------------- Summary of changes: ginac/compiler.h | 4 ++-- ginac/container.h | 34 +++++++++++++++++----------------- ginac/matrix.h | 2 +- 3 files changed, 20 insertions(+), 20 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-568-g6ad2b99
by git＠ginac.de 17 Aug '16

17 Aug '16

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 6ad2b996d58c0b144770e7cf3079386fcd385908 (commit) via c9e4e59df24f6845b4bfe73619749d4b7447b8a4 (commit) from 11c0c610d6f47476b82f3ab118b0be37ed3ef747 (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 6ad2b996d58c0b144770e7cf3079386fcd385908 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Wed Aug 17 22:08:57 2016 +0200 Update ax_cxx_compile_stdcxx.m4. Serial 3 fixes make CXXFLAGS=..., c.f. the macro's upstream revision history. commit c9e4e59df24f6845b4bfe73619749d4b7447b8a4 Author: Vladimir Kisil <kisilv(a)maths.leeds.ac.uk> Date: Wed Aug 17 22:05:13 2016 +0200 Improve performance of clifford_to_lst(). Rewrite get_clifford_comp() so it is less obscure and more efficient. ----------------------------------------------------------------------- Summary of changes: ginac/clifford.cpp | 116 +++++++++++++++++++++----------------------- m4/ax_cxx_compile_stdcxx.m4 | 48 +++++++++--------- 2 files changed, 82 insertions(+), 82 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Toggling index covariance in simplify_indexed()
by Vladimir V. Kisil 12 Aug '16

12 Aug '16

Dear All, I am confused by the following. The routine simplify_indexed() calls reposition_dummy_indices(), which has the freedom to toggle dummy indices covariance to achieve canonical order. Leaving aside the question "does the position of an index have geometrical/physical significance and can be harmlessly toggled?", I come to the following unpredictability of the GiNaC output in the different runs of the same compiled programme: #include <ginac/ginac.h> #include <fstream> using namespace std; using namespace GiNaC; int main(){ realsymbol x("x"), y("y"); varidx mu(symbol("mu", "\\mu"), 2); ex e = clifford_unit(mu, diag_matrix(lst{-1,-1})); ex V = lst_to_clifford(lst{x,y}, e); cout << V << endl; // -> e~mu*[[x],[y]].mu cout << simplify_indexed(V) << endl; // in different runs can be either // (A) -> e~mu*[[x],[y]].mu (as above) or // (B) -> e.mu*[[x],[y]]~mu cout << canonicalize_clifford(V*V) << endl; // depanding on the above outcomes: // (A) -> (e~mu*e~symbol6)*[[x],[y]].symbol6*[[x],[y]].mu // (B) -> -2*ONE*y^2-[[x],[y]]~symbol6*[[x],[y]]~mu*(e.symbol6*e.mu)-2*x^2*ONE cout << canonicalize_clifford(simplify_indexed(V)*simplify_indexed(V)) << endl; // (A) -> (e~mu*e~symbol10)*[[x],[y]].mu*[[x],[y]].symbol10 // (B) -> -(e~symbol13*e~mu)*[[x],[y]].mu*[[x],[y]].symbol13-2*ONE*y^2-2*x^2*ONE cout << canonicalize_clifford(simplify_indexed(V)*V) << endl; // (A) -> -[[x],[y]]~symbol14*(e.symbol14*e~mu)*[[x],[y]].mu-2*ONE*y^2-2*x^2*ONE // (B) -> -2*ONE*y^2-[[x],[y]]~mu*[[x],[y]]~symbol20*(e.symbol20*e.mu)-2*x^2*ONE cout << canonicalize_clifford(expand_dummy_sum(simplify_indexed(V)*V)) << endl; // (A) -> -y^2*ONE-x^2*ONE // (B) -> y^2*(e.1*e~1)+x^2*(e.0*e~0)+x*y*(e.0*e~1)-x*y*(e~0*e.1) return 0; } Any advice on usability/necessity of this behaviour? Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/

2 2

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-566-g11c0c61
by git＠ginac.de 12 Aug '16

12 Aug '16

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 11c0c610d6f47476b82f3ab118b0be37ed3ef747 (commit) via 96fc556787518794919137fc6d0e98e002c32ff5 (commit) from 33a92d56aeaadfe8dad246ae17b091e14b220e82 (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 11c0c610d6f47476b82f3ab118b0be37ed3ef747 Author: Stefan Weinzierl <weinzierl(a)uni-mainz.de> Date: Thu Aug 11 23:55:59 2016 +0200 Fix convergence of Li_projection at ±I. For arguments near ±I, direct summation does not practically converge. Use the Bernoulli transformation instead. Thanks to Peter Banks for reporting this: <http://www.cebix.net/pipermail/ginac-list/2016-August/002085.html> commit 96fc556787518794919137fc6d0e98e002c32ff5 Author: Vladimir Kisil <kisilv(a)maths.leeds.ac.uk> Date: Thu Aug 11 20:47:08 2016 +0200 Add proper functions to make clifford_bar() and clifford_star(). Previously operations clifford_bar() and clifford_star() called conjugate() method. This results in reversion of all non-commutative entries (not only Clifford units) and produced complex conjugation of all non-real items. The new routine operates on Clifford units only. ----------------------------------------------------------------------- Summary of changes: check/exam_clifford.cpp | 41 ++++++++++++++++++++++++++++++++++++++++- doc/tutorial/ginac.texi | 7 +++---- ginac/clifford.cpp | 41 +++++++++++++++++++++++++++++++++++++++++ ginac/clifford.h | 10 +++++++--- ginac/inifcns_nstdsums.cpp | 7 ++++--- 5 files changed, 95 insertions(+), 11 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Improvement for get_clifford_comp()
by Vladimir V. Kisil 11 Aug '16

11 Aug '16

Dear All, The previous version of get_clifford_comp() was written in obscure and inefficient way. I am attaching a new version which still passes all tests in exam_clifford.cpp ;-) Best wishes, Vladimir -- Vladimir V. Kisil http://www.maths.leeds.ac.uk/~kisilv/ Book: Geometry of Mobius Transformations http://goo.gl/EaG2Vu Software: Geometry of cycles http://moebinv.sourceforge.net/

1 0

Bug fix multiple polylogarithms
by Stefan Weinzierl 11 Aug '16

11 Aug '16

Dear all, the attached patch fixes the problem reported in <http://www.cebix.net/pipermail/ginac-list/2016-August/002085.html> This concerns the function Li_projection, which no longer uses for arguments x near +/- I the direct summation (which practically does not converge), but uses the Bernoulli transformation instead. Best regards, Stefan

1 0