- GiNaC-devel - ginac.de

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-383-ge45f9fc
by git＠ginac.de 23 Jan '13

23 Jan '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 e45f9fca76b81e01ffa5edc417c29538fa05147b (commit) from 47522fcd15579cade744182eb0c714331ca230c7 (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 e45f9fca76b81e01ffa5edc417c29538fa05147b Author: Richard Kreckel <kreckel(a)ginac.de> Date: Wed Jan 23 09:19:26 2013 +0100 Add symbol::set_TeX_name(string) member function. This allows setting a symbol's TeX-name after construction. ----------------------------------------------------------------------- Summary of changes: ginac/symbol.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Invitación para conectarse en LinkedIn
by Jose Antonio Garcia Peiro 19 Sep '12

19 Sep '12

LinkedIn ------------ Me gustaría añadirte a mi red profesional en LinkedIn. -Jose Antonio Jose Antonio Garcia Peiro Estudiante de Universidad Miguel Hernández de Elche Murcia y alrededores, España Confirma que conoces a Jose Antonio Garcia Peiro: https://www.linkedin.com/e/-smpzss-h79z96aq-37/isd/4281103251/npAG8Ge4/?hs=… -- Estás recibiendo invitaciones a conectar. Haz clic para darte de baja: http://www.linkedin.com/e/-smpzss-h79z96aq-37/pQQaivesQERn6ZpSpQQtivesQEgGd… (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU.

1 0

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

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-382-g47522fc
by git＠ginac.de 27 Jul '12

27 Jul '12

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 47522fcd15579cade744182eb0c714331ca230c7 (commit) via dab7b85132ee3a0def2e450e9a236f53354bf258 (commit) via af3801eb5e40bb3717bf207470252172a0af2559 (commit) from bf0d26572edecc37d98aec715e14fbd71a8c0315 (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 47522fcd15579cade744182eb0c714331ca230c7 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Fri Jul 27 22:04:54 2012 +0300 Make FindCLN actually work without pkg-config. commit dab7b85132ee3a0def2e450e9a236f53354bf258 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Fri Jul 27 21:56:40 2012 +0300 Trick CTest so the test suite runs when cross-compiling. The test suite can be run in some cross-compilation setups (say, MinGW on Linux). Howerver CTest's add_test command does not add the .exe suffix on its own, as a result `make test' fails. Let's help add_test a bit. commit af3801eb5e40bb3717bf207470252172a0af2559 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Fri Jul 27 21:55:35 2012 +0300 Work around Tex Live 2012 versus doxygen problem. TeX Live 2012 seems to dislike files produces by doxygen (1.8.x.y). In particular, makeindex(1) program creates invalid index entries like \hyperpage{NNN_} (note the trailing underscore in the page number). This breaks automatic builds and is very annoying. This patch works around the problem by post-processing the generated *.ind file. This hack is a bit crude, however it gets the job done (a proper fix is welcome, though). ----------------------------------------------------------------------- Summary of changes: check/CMakeLists.txt | 2 +- cmake/modules/FindCLN.cmake | 2 +- doc/CMakeLists.txt | 2 ++ doc/reference/Makefile.am | 1 + scripts/fixupind.py | 30 ++++++++++++++++++++++++++++++ 5 files changed, 35 insertions(+), 2 deletions(-) create mode 100755 scripts/fixupind.py 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-372-ge5eeee5
by git＠ginac.de 17 Jul '12

17 Jul '12

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 e5eeee53d814cedc12cd725e76b0eb87859cdd77 (commit) from 05b3a16973aad40a9c17ee0f0bd06b02ac4706ef (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 e5eeee53d814cedc12cd725e76b0eb87859cdd77 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Tue Jul 17 06:32:45 2012 +0300 [bugfix] Always #include <lst.h> before using lst. Fixes build error on MinGW. [temp.expl.spec] says: 6 If a template, a member template or the member of a class template is explicitly specialized then that specialization shall be declared before the first use of that specialization that would cause an implicit instantiation to take place, in every translation unit in which such a use occurs; no diagnostic is required. If the program does not provide a definition for an explicit specialization and either the specialization is used in a way that would cause an implicit instantiation to take place or the member is a virtual member function, the program is ill-formed, no diagnostic required. An implicit instantiation is never generated for an explicit specialization that is declared but not defined. Apparently we are breaking this rule (presumably since the commit 99901bd5c742 `Parser can now read GiNaC lists (lst) defined by braces.'). In particular, parser.cpp does not include lst.h (neither directly nor indirectly) which contains explicit specialization of lst::info(). However, parser.cpp (indirectly) includes both container.h and registar.h, so the GiNaC::lst type is declared (and is complete) before the first usage. Thus lst::info() gets implicitly instantiated (using the general definition provided in container.h) when compiling the parser.cpp file, and libginac fails to link properly due to mutliply defined symbols: libtool: link: ccache i686-w64-mingw32-g++ -shared -nostdlib /usr/lib/gcc/i686-w64-mingw32/4.6/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o /usr/lib/gcc/i686-w64-mingw32/4.6/crtbegin.o .libs/add.o .libs/archive.o .libs/basic.o .libs/clifford.o .libs/color.o .libs/constant.o .libs/ex.o .libs/excompiler.o .libs/expair.o .libs/expairseq.o .libs/exprseq.o .libs/fail.o .libs/factor.o .libs/fderivative.o .libs/function.o .libs/idx.o .libs/indexed.o .libs/inifcns.o .libs/inifcns_trans.o .libs/inifcns_gamma.o .libs/inifcns_nstdsums.o .libs/integral.o .libs/lst.o .libs/matrix.o .libs/mul.o .libs/ncmul.o .libs/normal.o .libs/numeric.o .libs/operators.o .libs/power.o .libs/registrar.o .libs/relational.o .libs/remember.o .libs/pseries.o .libs/print.o .libs/symbol.o .libs/symmetry.o .libs/tensor.o .libs/utils.o .libs/wildcard.o .libs/parse_binop_rhs.o .libs/parser.o .libs/parse_context.o .libs/default_reader.o .libs/lexer.o .libs/parser_compat.o .libs/mod_gcd.o .libs/cra_garner.o .libs/upoly_io.o .libs/gcd_uvar.o .libs/chinrem_gcd.o .libs/collect_vargs.o .libs/divide_in_z_p.o .libs/mgcd.o .libs/optimal_vars_finder.o .libs/pgcd.o .libs/primpart_content.o -L/home/build/GiNaC.pkg/mk/ginac/../../build-tree/inst/all/opt/i686-w64-mingw32/ginac/lib -lcln -L/usr/lib/gcc/i686-w64-mingw32/4.6 -L/usr/lib/gcc/i686-w64-mingw32/4.6/../../../../i686-w64-mingw32/lib/../lib -L/usr/lib/gcc/i686-w64-mingw32/4.6/../../../../i686-w64-mingw32/lib -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt /usr/lib/gcc/i686-w64-mingw32/4.6/crtend.o -O2 -march=i686 -Wl,--enable-auto-import -Wl,--export-all-symbols -o .libs/libginac-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libginac.dll.a Creating library file: .libs/libginac.dll.a .libs/parser.o: In function `_ZNK5GiNaC9containerISt4listE4infoEj': /home/build/GiNaC.pkg/mk/ginac/../../ginac/ginac/container.h:359: multiple definition of `GiNaC::container<std::list>::info(unsigned int) const' .libs/lst.o:/usr/include/c++/4.6/bits/vector.tcc:390: first defined here collect2: ld returned 1 exit status make[4]: *** [libginac.la] Error 1 make[4]: Leaving directory `/home/build/GiNaC.pkg/build-tree/build/ginac-1.6.2/ginac' make[3]: *** [all] Error 2 Thanks to Robert Durkacz for reporting. ----------------------------------------------------------------------- Summary of changes: ginac/parser/default_reader.cpp | 1 + ginac/parser/parser.cpp | 1 + 2 files changed, 2 insertions(+), 0 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Relationals
by Jan 09 Mar '12

09 Mar '12

Hello, is it possible to query a relational whether it has an undecidable value, e.g. assuming a is a symbol: if (a > 3) ... currently always gives false, but I would like to be able to find out whether the comparison actually makes sense. Thanks, Jan

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-371-g05b3a16
by git＠ginac.de 28 Feb '12

28 Feb '12

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 05b3a16973aad40a9c17ee0f0bd06b02ac4706ef (commit) from 4077d8b144e2e5f3db75cf95fbb590981b2eb8d4 (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 05b3a16973aad40a9c17ee0f0bd06b02ac4706ef Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Tue Feb 28 16:12:56 2012 +0200 [BUGFIX] numeric::info(nonnegative): correctly handle complex numbers. numeric::info(info_flags::nonnegative) returns true for an arbitrary complex number with non-zero imaginary part. Thanks to Burcin Erocal for reporting. ----------------------------------------------------------------------- Summary of changes: check/exam_numeric.cpp | 5 +++++ ginac/numeric.cpp | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

2 1

abs evaluation bug
by Burcin Erocal 28 Feb '12

28 Feb '12

Hi, automatic evaluation of the abs() function returns wrong results: ginsh - GiNaC Interactive Shell (ginac V1.5.8) __, _______ Copyright (C) 1999-2010 Johannes Gutenberg University Mainz, (__) * | Germany. This is free software with ABSOLUTELY NO WARRANTY. ._) i N a C | You are welcome to redistribute it under certain conditions. <-------------' For details type `warranty;'. Type ?? for a list of help topics. > abs(Pi+I); I+Pi abs_eval() thinks that I + Pi is nonnegative, since numeric::is_negative() returns false for complex numbers: http://www.ginac.de/ginac.git?p=ginac.git;a=blob;f=ginac/numeric.cpp;h=f057… Any suggestions for a fix? Would it be acceptable to raise an error when comparing complex numbers? This was reported to Sage: http://trac.sagemath.org/sage_trac/ticket/11155 Cheers, Burcin

2 1

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-370-g4077d8b
by git＠ginac.de 23 Feb '12

23 Feb '12

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 4077d8b144e2e5f3db75cf95fbb590981b2eb8d4 (commit) via bf6c511306f357fdb4df8307c5cb6afa508e2e5d (commit) via 4ec372a00b1a13e6374ce880cbd68c2e14114dad (commit) via 5146d1bd6eb0a93d6033c1a9b33b643c5faf15a6 (commit) from 012ea7fa628fe97e72469af6b6703515eee24d3a (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 4077d8b144e2e5f3db75cf95fbb590981b2eb8d4 Merge: 012ea7fa628fe97e72469af6b6703515eee24d3a bf6c511306f357fdb4df8307c5cb6afa508e2e5d Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Thu Feb 23 17:44:00 2012 +0200 Merge branch 'master' of git://github.com/AlexeiSheplyakov/GiNaC commit bf6c511306f357fdb4df8307c5cb6afa508e2e5d Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Thu Mar 3 23:16:34 2011 +0200 [docs] Update the supported platforms/compilers list. commit 4ec372a00b1a13e6374ce880cbd68c2e14114dad Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Sat Feb 26 10:39:29 2011 +0200 Parser: don't bother to generate 3 (C++) functions with autogen. commit 5146d1bd6eb0a93d6033c1a9b33b643c5faf15a6 Author: Alexei Sheplyakov <Alexei.Sheplyakov(a)gmail.com> Date: Wed Feb 9 07:48:08 2011 +0200 [trivia] Fix a typo in the GCD testcase. ----------------------------------------------------------------------- Summary of changes: hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0