September 2010 - GiNaC-devel

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-231-g8fa654f
by git＠ginac.de 30 Sep '10

30 Sep '10

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 8fa654f2637fa755e890499ece1a7bc498779ea3 (commit) from e08cda1854bdb82f6706ec269233577690ae00e4 (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 8fa654f2637fa755e890499ece1a7bc498779ea3 Author: Alexei Sheplyakov <varg(a)metalica.kh.ua> Date: Sat Aug 8 13:03:38 2009 +0300 ncmul::eval(): don't write beyond the end of the vector. ----------------------------------------------------------------------- Summary of changes: ginac/ncmul.cpp | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Please apply patch 7a2ac488 to the master branch too
by Alexei Sheplyakov 30 Sep '10

30 Sep '10

Hello! Richard, Jens, could you please apply the patch 7a2ac488 ('ncmul::eval(): don't write beyond the end of vector') to the master branch? That patch fixes invalid code (which does work with GCC, but not with other compilers). Best regards, Alexei

1 0

Re: [GiNaC-devel] GiNaC msvc support patches
by Jan private 30 Sep '10

30 Sep '10

Hello Alexei, > > 6. make check compiles, but several of the executables crash. > > This is a bit strange. The only difference between master and 1.5 > is how parser handles functions (objects of type GiNaC::function). see attached patch. I _MSV_VER'ed it because it is pretty pointless. If something like this turns up every time there is a totally unrelated change, then I will get grey hairs pretty quickly :-( Anyway, with this patch all 58 tests pass successfully. > Could you please post the backtrace? How would I have done that (I guess it is unnecessary now)? Have you made any progress on the CLN patches? Best regards, Jan

1 0

Print function for user-defined function
by Jan private 28 Sep '10

28 Sep '10

Hello, I did this (code shortened to what is interesting): class imathprint : public print_dflt { GINAC_DECLARE_PRINT_CONTEXT(imathprint, print_dflt) public: optstack* poptions; // imathprint-specific print options imathprint(std::ostream & os, optstack* popt, unsigned opt = 0) : print_dflt(os, opt), poptions(popt) {}; static void init(); }; DECLARE_FUNCTION_3P(partialdiff) static void partialdiff_print_imath(..., const imathprint &c) {} static void partialdiff_print_ltx(..., const print_context &c) {} REGISTER_FUNCTION(partialdiff, ... print_func<print_latex>(&partialdiff_print_ltx). print_func<imathprint>(&partialdiff_print_imath). ...); This gives me an error func.cpp:1310: error: no matching function for call to ‘GiNaC::function_options::print_func(void (*)(const GiNaC::ex&, const GiNaC::ex&, const GiNaC::ex&, const imathprint&)) But doing the same kind of thing in GINAC_IMPLEMENT_REGISTERED_CLASS_OPT works! What I am trying to do is to create an extended print context imathprint which has more options and also options of non-integer type. Any better ideas? Thank you, Jan

1 0

Re: [GiNaC-devel] GiNaC msvc support patches
by Jan private 24 Sep '10

24 Sep '10

Hello Alexei, > I've applied your patches and created the master.msvc.support branch. thanks for the effort. 1. I used the download button on the web page you sent and got a .tar.gz. It didn't have a configure executable, so I was a bit at a loss on how to start 2. autoreconf complained about missing files in config/, so I copied these from ginac-1.5.8 3. After that, libtool gave a version mismatch so I copied aclocal.m4 and m4/* from ginac-1.5.8 4. The attached patch seems to somehow have slipped through the cracks Problem: MSVC chokes on the "struct" Solution: Removed it 5. After this, compilation went fine. There are still issues with the build environment (getting the right libraries for linking), but I am not motivated right now to fix those. I guess they have nothing to do with GiNaC, anyway. 6. make check compiles, but several of the executables crash. For example, in exam_matrices.cpp, in exam_evalm(), doing the matrix multiplication S*S crashes the program 7. I looked through a diff of ginac-1.5.8 and the new branch, but couldn't find anything obvious yet. Still looking. Best regards, Jan

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, master, updated. release_1-4-0-230-ge08cda1
by git＠ginac.de 23 Sep '10

23 Sep '10

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 e08cda1854bdb82f6706ec269233577690ae00e4 (commit) from 9506030d2059ef868d5da8dcbe714c9c5b50ff50 (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 e08cda1854bdb82f6706ec269233577690ae00e4 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Sep 23 00:40:38 2010 +0200 Make sure add::eval() collects all numeric terms. Apparently, add::eval() assumed that none of the elements of its epvector has a numeric rest. However, nothing guarantees that -- in particular evalchildren() doesn't (and actually cannot) do so. Since there are many places where a new add is constructed directly from an epvector, enforcing this doesn't make sense either. One example where it did fail was found by Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3. Thanks to Burcin Erocal for reporting this bug. ----------------------------------------------------------------------- Summary of changes: check/exam_paranoia.cpp | 13 +++++++++++++ ginac/add.cpp | 31 ++++++++++++++++++++++++++++--- 2 files changed, 41 insertions(+), 3 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-250-g89d5356
by git＠ginac.de 23 Sep '10

23 Sep '10

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, ginac_1-5 has been updated via 89d5356b4aa33cb4481575f9453f36c3404b015b (commit) from 90ad10b58d02365a407b2d84d8b93e50030feaa5 (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 89d5356b4aa33cb4481575f9453f36c3404b015b Author: Richard Kreckel <kreckel(a)ginac.de> Date: Thu Sep 23 00:40:38 2010 +0200 Make sure add::eval() collects all numeric terms. Apparently, add::eval() assumed that none of the elements of its epvector has a numeric rest. However, nothing guarantees that -- in particular evalchildren() doesn't (and actually cannot) do so. Since there are many places where a new add is constructed directly from an epvector, enforcing this doesn't make sense either. One example where it did fail was found by Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3. Thanks to Burcin Erocal for reporting this bug. (cherry picked from commit e08cda1854bdb82f6706ec269233577690ae00e4) ----------------------------------------------------------------------- Summary of changes: check/exam_paranoia.cpp | 13 +++++++++++++ ginac/add.cpp | 31 ++++++++++++++++++++++++++++--- 2 files changed, 41 insertions(+), 3 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-229-g9506030
by git＠ginac.de 15 Sep '10

15 Sep '10

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 9506030d2059ef868d5da8dcbe714c9c5b50ff50 (commit) from 8cce492692eb74d636a50f420fd79877e5d4981a (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 9506030d2059ef868d5da8dcbe714c9c5b50ff50 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Wed Sep 15 09:11:57 2010 +0200 Be more careful about final top-level substitution. Substituting x==log(x) in exp(x) erroneously returned log(x) because of a final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final substitution is wrong in the general case. On the other hand, the intent is to syntactically substitute functions of a given kind etc. This patch suppresses the final top-level substitution unless the intermediate result is a container. Thanks to Burcin Erocal for reporting this bug (originally described by Kees van Schaik on sage-support(a)googlegroops.com) ----------------------------------------------------------------------- Summary of changes: check/exam_misc.cpp | 9 +++++++++ doc/tutorial/ginac.texi | 2 +- ginac/container.h | 24 ++++++++++++++++++++---- 3 files changed, 30 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-249-g90ad10b
by git＠ginac.de 15 Sep '10

15 Sep '10

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, ginac_1-5 has been updated via 90ad10b58d02365a407b2d84d8b93e50030feaa5 (commit) from db47e259edabbed2b8eb2fa1e4ed93588c26e304 (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 90ad10b58d02365a407b2d84d8b93e50030feaa5 Author: Richard Kreckel <kreckel(a)ginac.de> Date: Wed Sep 15 09:11:57 2010 +0200 Be more careful about final top-level substitution. Substituting x==log(x) in exp(x) erroneously returned log(x) because of a final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final substitution is wrong in the general case. On the other hand, the intent is to syntactically substitute functions of a given kind etc. This patch suppresses the final top-level substitution unless the intermediate result is a container. Thanks to Burcin Erocal for reporting this bug (originally described by Kees van Schaik on sage-support(a)googlegroops.com) ----------------------------------------------------------------------- Summary of changes: check/exam_misc.cpp | 9 +++++++++ doc/tutorial/ginac.texi | 2 +- ginac/container.h | 24 ++++++++++++++++++++---- 3 files changed, 30 insertions(+), 5 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Patch 6
by Jan private 14 Sep '10

14 Sep '10

Problem: MSVC creates different symbols for "extern const ex _ex0" if it is declared at top-level (inside GiNaC namespace) and if it is declared inside the body of a function (also inside GiNaC namespace). When linking, unresolved external symbols occur. Solution: Moved the declaration out of the body of the function Note: Instead of #include utils.h the same effect would probably be achieved by namespace GiNaC { extern const ex _ex0; } at the beginning of the file.

2 3