- GiNaC-devel - ginac.de

Patch 2
by Jan Rheinländer 09 Sep '10

09 Sep '10

Problem: Return type of function is "ex". MSVC complains that it cannot convert "GiNaC::power*" to "ex" Solution: Changed expression to "GiNaC::power" and removed statusflags::dynallocated

3 2

Patch 3 updated description
by Jan Rheinländer 09 Sep '10

09 Sep '10

symmetry::compare_same_type(): const-correctness fix Problem: The method in question is const, therefore one should use const_iterator to access indices. Some compilers (for instance, MSVC) are very strict about this, and won't accept (invalid) code using non-const iterator. Solution: Changed it to const_iterator

1 0

Patch 5
by Jan Rheinländer 09 Sep '10

09 Sep '10

Problem: MSVC chokes on "struct" Solution: Removed it

1 0

Patch 3
by Jan Rheinländer 09 Sep '10

09 Sep '10

Problem: MSVC wants a const_iterator Solution: Changed it

1 0

Patch
by Jan private 02 Sep '10

02 Sep '10

Hello Alexei, thank you for your patience. Attached the patch Best regards, Jan ---------------------------- 1. Problem: MSVC chokes on "or" and "not" 2. Solution: Replaced with "||" and "!"

1 0

Patch
by Jan private 02 Sep '10

02 Sep '10

Hello Alexei, here is my first try at a patch (GiNaC 1.5.8.) Please let me know if it is OK this way Jan ---------------------------- 1. Problem: MSVC chokes on "or" and "not" 2. Replaced with "||" and "!" --- clifford.cpp.orig 2010-09-02 07:40:19 +0000 +++ clifford.cpp 2010-09-02 07:42:42 +0000 @@ -1291,11 +1291,11 @@ if (algebraic) // check if algebraic method is applicable for (unsigned int i = 0; i < D; i++) if (pow(c.subs(mu == i, subs_options::no_pattern), 2).is_zero() - or (not is_a<numeric>(pow(c.subs(mu == i, subs_options::no_pattern), 2)))) + || (! is_a<numeric>(pow(c.subs(mu == i, subs_options::no_pattern), 2)))) algebraic = false; lst V; ex v0 = remove_dirac_ONE(canonicalize_clifford(e +clifford_prime(e)).normal())/2; - if (not v0.is_zero()) + if (! v0.is_zero()) V.append(v0); ex e1 = canonicalize_clifford(e - v0 * dirac_ONE(ex_to<clifford>(c).get_representation_label())); if (algebraic) { @@ -1312,7 +1312,7 @@ e1 = canonicalize_clifford(expand_dummy_sum(e, true)); V.remove_all(); v0 = remove_dirac_ONE(canonicalize_clifford(e1 +clifford_prime(e1)).normal())/2; - if (not v0.is_zero()) { + if (! v0.is_zero()) { V.append(v0); e1 = canonicalize_clifford(e1 - v0 * dirac_ONE(ex_to<clifford>(c).get_representation_label())); }

1 0

Re: [GiNaC-devel] Compile with MSVC 98% successful
by Jan private 23 Aug '10

23 Aug '10

Hello Alexei, > I thought you've posted this to ginac-devel to get your changes applied, > so building (new versions of) GiNaC with msvc won't be an adventure any > more. well, my post was more for the off-chance that someone might be interested. If it seems that people are interested, I will try to make patches out of those changes that seem to be OK. I am aware that a lot of them are just bad hacks that happen to work. Also, I suspect that a lot of them are bad hacks because I don't know better. E.g. the problems that MSVC has with extern declarations inside classes (which I solved by putting them all in the global namespace) might be solveable with a compiler option, who knows? I don't. Thank you for the instructions. Jan

1 0

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

23 Aug '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 5f896fa7f59bbce727e4bba23df9c4bbdbb55c29 (commit) from beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032 (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 5f896fa7f59bbce727e4bba23df9c4bbdbb55c29 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sun Aug 22 23:09:18 2010 +0300 power::eval(): fix several memory leaks While working on fsolve bug I've noticed the following in valgrind log: ==17455== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19 ==17455== at 0x4C249C7: operator new(unsigned long) (vg_replace_malloc.c:220) ==17455== by 0x516CA70: GiNaC::power::eval(int) const (power.cpp:540) ==17455== by 0x4FC1E39: GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:310) ==17455== by 0x406FBF: main (ex.h:255) Heap allocated objects definitely need the status_flags::dyncallocated flag. ----------------------------------------------------------------------- Summary of changes: ginac/power.cpp | 2 ++ 1 files changed, 2 insertions(+), 0 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-247-gcc94094
by git＠ginac.de 23 Aug '10

23 Aug '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 cc94094751459129e1392a93dfa0264adac789a5 (commit) via d71be995fcb751b52145eb0e50467d15fea541cb (commit) via 5d6d2c3ff6afd13933203f984a818dbfc76db3a1 (commit) via 87ed87c395d6121fe468efc68ee2cd33a7e91200 (commit) from 37506ee54aa46203736d657c6e8a64e695303b64 (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 cc94094751459129e1392a93dfa0264adac789a5 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sun Aug 22 23:09:18 2010 +0300 power::eval(): fix several memory leaks While working on fsolve bug I've noticed the following in valgrind log: ==17455== 136 (56 direct, 80 indirect) bytes in 1 blocks are definitely lost in loss record 16 of 19 ==17455== at 0x4C249C7: operator new(unsigned long) (vg_replace_malloc.c:220) ==17455== by 0x516CA70: GiNaC::power::eval(int) const (power.cpp:540) ==17455== by 0x4FC1E39: GiNaC::ex::construct_from_basic(GiNaC::basic const&) (ex.cpp:310) ==17455== by 0x406FBF: main (ex.h:255) Heap allocated objects definitely need the status_flags::dyncallocated flag. (cherry picked from commit 5f896fa7f59bbce727e4bba23df9c4bbdbb55c29) commit d71be995fcb751b52145eb0e50467d15fea541cb Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Sat Aug 21 19:13:29 2010 +0300 fsolve: avoid useless numerical evaluation of the function Don't compute f(x) if new x is outside of the interval. We don't need that value anyway, and the function might be difficult to compute numerically or even ill defined outside the interval. As a result fsolve is able to find root(s) of some weird functions. For example fsolve((1/(sqrt(2*Pi)))*integral(t, 0, x, exp(-1/2*t^2)) == 0.5, x, 0, 100) actually works now. (cherry picked from commit beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032) commit 5d6d2c3ff6afd13933203f984a818dbfc76db3a1 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Thu Aug 19 11:10:25 2010 +0300 integral::evalf(): don't attempt to ignore problems. Don't ignore exceptions thrown by numerical integration routine. In general, the code like this try { // blah-blah } catch (std::exception& err) { } is just plain evil. Case in the point: fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100) (cherry picked from commit 515171f0bcd42099c266713c3d605cd92cedd2e2) commit 87ed87c395d6121fe468efc68ee2cd33a7e91200 Author: Alexei Sheplyakov <alexei.sheplyakov(a)gmail.com> Date: Thu Aug 19 00:07:13 2010 +0300 fsolve: check if evalf() return value is actually a number. Fixes the segfault triggered by fsolve((1/(sqrt(2*Pi)))*integral(t,0,x,exp(-1/2*t^2))==0.5,x,0,100) In general, ex_to is unsafe, and should be used only after proper checks. evalf() may return non-numeric expression for various reasons (bad convergence, floating point over- or underflow, out of memory, etc). So let's add missing checks. Thanks to Ernst Moritz Hahn for a bug report. (cherry picked from commit 9993a7aac97abf383624fc5dae4beecb29531fbd) ----------------------------------------------------------------------- Summary of changes: ginac/inifcns.cpp | 38 ++++++++++++++++++++++++++++++++------ ginac/integral.cpp | 2 -- ginac/power.cpp | 2 ++ 3 files changed, 34 insertions(+), 8 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

1 0

Compile with MSVC 98% successful
by Jan private 23 Aug '10

23 Aug '10

I compiled ginac-1.5.7 with Microsoft Visual C++. You can find an account of my adventures on http://sourceforge.net/apps/mediawiki/ooo-imath/index.php?title=Installatio… 56 of 57 tests passed. The one that didn't said: time_uvar_gcd.exe: timing univarite GCD GCD of relatively prime polynomials a and b degree(a) = 100, degree(b) = 50 mod_gcd : 1 5.96e-002 heur_gcd : 1 1.71e-002 sr_gcd: : 1 3.73e+001 Non-trivial GCD, degree(a) = 100, degree(b) = 100 mod_gcd : 51 1.70e-001 heur_gcd : 51 1.56e-002 heur_gcd (old) : 51 2.40e-001 sr_gcd: : 51 6.62e+000 sr_gcd (old) : 51 1.16e+001 Non-trivial GCD, degree(a) = 908, degree(b) = 908 mod_gcd : 1 1.66e+000 heur_gcd : 1 4.67e-001 Assertion failed: sfinder.found.size() == 1, file time_uvar_gcd.cpp, line 1621 Jan

3 3