August 2012 - GiNaC-devel

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-379-gbf0d265
by git＠ginac.de 08 Aug '13

08 Aug '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 bf0d26572edecc37d98aec715e14fbd71a8c0315 (commit) via 0289100f425e420da988a709cd52616b6d69d348 (commit) via a06a27122b0a9087e9c64743940016c7e0176ce2 (commit) via eded9cd9d5df793c1ea5a1f766eff261ded46bde (commit) via e0f0681b814fecff5523d21b4368ebbeecc330eb (commit) via f282e2b3a3873619006b6ffd3fa7fe65010c1299 (commit) via a2314765ecb37b89ce5ab0d5491e58b6ac550b73 (commit) from e5eeee53d814cedc12cd725e76b0eb87859cdd77 (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 bf0d26572edecc37d98aec715e14fbd71a8c0315 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Tue May 31 02:50:01 2011 +0300 [build] GiNaC can be built with CMake now. Known issues: * no make dist * no make install-pdf commit 0289100f425e420da988a709cd52616b6d69d348 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Thu Feb 23 22:20:44 2012 +0200 [build] Move library version info into the version.h file. The point is to have this info easily available for both build systems. commit a06a27122b0a9087e9c64743940016c7e0176ce2 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Tue Jan 10 08:48:29 2012 +0300 [build] Rewrite ginsh related sed scripts in python. This makes build scripts more portable and human readable. commit eded9cd9d5df793c1ea5a1f766eff261ded46bde Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun May 29 17:15:42 2011 +0300 [build] Move archive version info into version.h (for non autotools build). The canonical location for all version info is the ginac/version.h file now (so we can have two build systems without duplicating the version info in configure.ac and CMakeLists.txt). commit e0f0681b814fecff5523d21b4368ebbeecc330eb Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun May 29 16:27:49 2011 +0300 [build] Define package version number in version.h (for non autotools build). commit f282e2b3a3873619006b6ffd3fa7fe65010c1299 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun May 29 16:18:39 2011 +0300 [build] include config.h conditionally to not break non-autotools build. commit a2314765ecb37b89ce5ab0d5491e58b6ac550b73 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sun May 29 15:26:37 2011 +0300 Convert function.pl into C++ (well, almost) source and header. The code is much more readable now, as it's (almost) plain C++ (except simple pythonic `preprocessor' instructions). As a side effect perl is no longer necessary for building GiNaC. ----------------------------------------------------------------------- Summary of changes: CMakeLists.txt | 177 +++++ INSTALL | 2 +- INSTALL.CMake | 64 ++ acinclude.m4 | 18 + check/CMakeLists.txt | 94 +++ cmake/modules/FindCLN.cmake | 118 ++++ cmake/modules/FindGiNaC.cmake | 157 +++++ cmake/modules/FindReadline.cmake | 49 ++ config.cmake.in | 5 + configure.ac | 61 +-- doc/CMakeLists.txt | 63 ++ doc/examples/CMakeLists.txt | 1 + doc/reference/CMakeLists.txt | 40 ++ doc/tutorial/CMakeLists.txt | 59 ++ doc/tutorial/version.texi.cmake | 2 + ginac.pc.cmake | 11 + ginac/CMakeLists.txt | 176 +++++ ginac/Makefile.am | 14 +- ginac/archive.cpp | 11 +- ginac/function.cppy | 827 ++++++++++++++++++++++ ginac/function.hppy | 277 ++++++++ ginac/function.pl | 1416 -------------------------------------- ginac/function.py | 35 + ginac/numeric.cpp | 2 + ginac/version.h | 92 +++ ginac/version.h.in | 43 -- ginsh/CMakeLists.txt | 66 ++ ginsh/Makefile.am | 10 +- ginsh/ginsh_fcn_help.py | 63 ++ ginsh/ginsh_fcn_help.sed | 33 - ginsh/ginsh_lexer.ll | 2 + ginsh/ginsh_op_help.py | 54 ++ ginsh/ginsh_op_help.sed | 18 - ginsh/ginsh_parser.yy | 11 +- scripts/yaptu.py | 93 +++ tools/CMakeLists.txt | 7 + 36 files changed, 2594 insertions(+), 1577 deletions(-) create mode 100644 CMakeLists.txt create mode 100644 INSTALL.CMake create mode 100644 check/CMakeLists.txt create mode 100644 cmake/modules/FindCLN.cmake create mode 100644 cmake/modules/FindGiNaC.cmake create mode 100644 cmake/modules/FindReadline.cmake create mode 100644 config.cmake.in create mode 100644 doc/CMakeLists.txt create mode 100644 doc/examples/CMakeLists.txt create mode 100644 doc/reference/CMakeLists.txt create mode 100644 doc/tutorial/CMakeLists.txt create mode 100644 doc/tutorial/version.texi.cmake create mode 100644 ginac.pc.cmake create mode 100644 ginac/CMakeLists.txt create mode 100644 ginac/function.cppy create mode 100644 ginac/function.hppy delete mode 100644 ginac/function.pl create mode 100755 ginac/function.py create mode 100644 ginac/version.h delete mode 100644 ginac/version.h.in create mode 100644 ginsh/CMakeLists.txt create mode 100755 ginsh/ginsh_fcn_help.py delete mode 100644 ginsh/ginsh_fcn_help.sed create mode 100755 ginsh/ginsh_op_help.py delete mode 100644 ginsh/ginsh_op_help.sed create mode 100644 scripts/yaptu.py create mode 100644 tools/CMakeLists.txt hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

2 2

Fwd: Add method ex::symbols for obtaining all symbols appearing in an expression
by Timo Kluck 11 Sep '12

11 Sep '12

On ma, aug 13, 2012 at 9:02 , Richard B. Kreckel <kreckel(a)ginac.de> wrote: >Wouldn't it be better to go one step further and cache those variables when > the variables() function is first used? This avoids quite a lot of overhead in > space and time! And then, variables() wouldn't have to be a member > function, right? That is probably best, especially in the light of the (x+y) - y example that Alexei mentioned. I could easily do that in Sage, but I think it wouldn't help in my case because I'm constructing so many expressions. However, I'm thinking it may make sense to do that in GiNaC, because from what I've seen it has some sort of a copy-on-right mechanism for subexpressions? As in: f = sin(x+y) g = f * cos(x-y) h = f * tan(z) will make g and h share the instance (and therefore the cache!) for f? Please correct me if I've misunderstood that. But if it has, this is abstracted away in Sage, so caching the variables() function in Sage would have much less benefit than caching it in GiNaC. I'm not sure whether this will actually give me any speed benefit in practice, because even though I'm using very similar subexpressions over and over again, I'm not sure if I could construct them as the same object without writing really awkward code. I'm interested in your opinions, though. So my next question is: would you accept a patch implementing a recursive, cached version of symbols(), for Sage to call directly, and then have responsibility for optimizing / caching that going to the level of GiNaC? I would normally think that it would be a method of ex (and basic). Where would you say the cache lives if it where a global function? Timo

3 4

Add method ex::symbols for obtaining all symbols appearing in an expression
by Timo Kluck 13 Aug '12

13 Aug '12

Hi, You may know the CAS Sage [1] which uses GiNaC. It wraps ginac expressions in Python, and it adds some extra methods of its own. One of those methods is variables(), which returns a list of symbols appearing in the expression. It does so by recursively walking down the expression tree. At one point, that was a bottle neck in my algorithm, and I realized that it would be very easy to cache those variables at construction time from the subexpressions. I think the natural place to implement such a thing would be in GiNaC itself, so that everyone (not only sage users) may benefit. Is this planned and/or would you accept such a patch? Best regards, Timo Kluck [1] www.sagemath.org

3 2