August 2010 - GiNaC-devel

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

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

22 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 beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032 (commit) via 515171f0bcd42099c266713c3d605cd92cedd2e2 (commit) via 9993a7aac97abf383624fc5dae4beecb29531fbd (commit) from dbde7117e88ba61597d6fee18615fe396c291a87 (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 beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032 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. commit 515171f0bcd42099c266713c3d605cd92cedd2e2 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) commit 9993a7aac97abf383624fc5dae4beecb29531fbd 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. ----------------------------------------------------------------------- Summary of changes: ginac/inifcns.cpp | 38 ++++++++++++++++++++++++++++++++------ ginac/integral.cpp | 2 -- 2 files changed, 32 insertions(+), 8 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations

2 1

[PATCH] [bugfix] power::eval(): fix several memory leaks
by Alexei Sheplyakov 22 Aug '10

22 Aug '10

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. --- ginac/power.cpp | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ginac/power.cpp b/ginac/power.cpp index d24c969..c6bf7b9 100644 --- a/ginac/power.cpp +++ b/ginac/power.cpp @@ -539,6 +539,7 @@ ex power::eval(int level) const if (num_coeff.is_positive()) { mul *mulp = new mul(mulref); mulp->overall_coeff = _ex1; + mulp->setflag(status_flags::dynallocated); mulp->clearflag(status_flags::evaluated); mulp->clearflag(status_flags::hash_calculated); return (new mul(power(*mulp,exponent), @@ -548,6 +549,7 @@ ex power::eval(int level) const if (!num_coeff.is_equal(*_num_1_p)) { mul *mulp = new mul(mulref); mulp->overall_coeff = _ex_1; + mulp->setflag(status_flags::dynallocated); mulp->clearflag(status_flags::evaluated); mulp->clearflag(status_flags::hash_calculated); return (new mul(power(*mulp,exponent), -- 1.7.1

1 0

[PATCH 3/3] fsolve: avoid useless numerical evaluation of the function
by Alexei Sheplyakov 21 Aug '10

21 Aug '10

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. --- ginac/inifcns.cpp | 21 ++++++++++++++------- 1 files changed, 14 insertions(+), 7 deletions(-) diff --git a/ginac/inifcns.cpp b/ginac/inifcns.cpp index f366e77..a436239 100644 --- a/ginac/inifcns.cpp +++ b/ginac/inifcns.cpp @@ -1011,13 +1011,20 @@ fsolve(const ex& f_in, const symbol& x, const numeric& x1, const numeric& x2) if (!is_a<numeric>(dx_)) throw std::runtime_error("fsolve(): function derivative does not evaluate numerically"); xx[side] += ex_to<numeric>(dx_); - - ex f_x = f.subs(x == xx[side]).evalf(); - if (!is_a<numeric>(f_x)) - throw std::runtime_error("fsolve(): function does not evaluate numerically"); - fx[side] = ex_to<numeric>(f_x); - - if ((side==0 && xx[0]<xxprev) || (side==1 && xx[1]>xxprev) || xx[0]>xx[1]) { + // Now check if Newton-Raphson method shot out of the interval + bool bad_shot = (side == 0 && xx[0] < xxprev) || + (side == 1 && xx[1] > xxprev) || xx[0] > xx[1]; + if (!bad_shot) { + // Compute f(x) only if new x is inside the interval. + // The function might be difficult to compute numerically + // or even ill defined outside the interval. Also it's + // a small optimization. + ex f_x = f.subs(x == xx[side]).evalf(); + if (!is_a<numeric>(f_x)) + throw std::runtime_error("fsolve(): function does not evaluate numerically"); + fx[side] = ex_to<numeric>(f_x); + } + if (bad_shot) { // Oops, Newton-Raphson method shot out of the interval. // Restore, and try again with the other side instead! xx[side] = xxprev; -- 1.7.1

1 0

[PATCH 2/2] integral::evalf(): don't attempt to ignore problems.
by Alexei Sheplyakov 19 Aug '10

19 Aug '10

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) --- ginac/integral.cpp | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/ginac/integral.cpp b/ginac/integral.cpp index 07670f3..f45d1ab 100644 --- a/ginac/integral.cpp +++ b/ginac/integral.cpp @@ -188,9 +188,7 @@ ex integral::evalf(int level) const // results after subsituting a number for the integration variable. if (is_exactly_a<numeric>(ea) && is_exactly_a<numeric>(eb) && is_exactly_a<numeric>(ef.subs(x==12.34).evalf())) { - try { return adaptivesimpson(x, ea, eb, ef); - } catch (runtime_error &rte) {} } if (are_ex_trivially_equal(a, ea) && are_ex_trivially_equal(b, eb) -- 1.7.1

1 0

[PATCH 1/2] [bugfix] fsolve: check if evalf() return value is actually a number.
by Alexei Sheplyakov 18 Aug '10

18 Aug '10

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. --- ginac/inifcns.cpp | 29 ++++++++++++++++++++++++----- 1 files changed, 24 insertions(+), 5 deletions(-) diff --git a/ginac/inifcns.cpp b/ginac/inifcns.cpp index 981e7b2..f366e77 100644 --- a/ginac/inifcns.cpp +++ b/ginac/inifcns.cpp @@ -1007,8 +1007,16 @@ fsolve(const ex& f_in, const symbol& x, const numeric& x1, const numeric& x2) do { xxprev = xx[side]; fxprev = fx[side]; - xx[side] += ex_to<numeric>(ff.subs(x==xx[side]).evalf()); - fx[side] = ex_to<numeric>(f.subs(x==xx[side]).evalf()); + ex dx_ = ff.subs(x == xx[side]).evalf(); + if (!is_a<numeric>(dx_)) + throw std::runtime_error("fsolve(): function derivative does not evaluate numerically"); + xx[side] += ex_to<numeric>(dx_); + + ex f_x = f.subs(x == xx[side]).evalf(); + if (!is_a<numeric>(f_x)) + throw std::runtime_error("fsolve(): function does not evaluate numerically"); + fx[side] = ex_to<numeric>(f_x); + if ((side==0 && xx[0]<xxprev) || (side==1 && xx[1]>xxprev) || xx[0]>xx[1]) { // Oops, Newton-Raphson method shot out of the interval. // Restore, and try again with the other side instead! @@ -1017,8 +1025,16 @@ fsolve(const ex& f_in, const symbol& x, const numeric& x1, const numeric& x2) side = !side; xxprev = xx[side]; fxprev = fx[side]; - xx[side] += ex_to<numeric>(ff.subs(x==xx[side]).evalf()); - fx[side] = ex_to<numeric>(f.subs(x==xx[side]).evalf()); + + ex dx_ = ff.subs(x == xx[side]).evalf(); + if (!is_a<numeric>(dx_)) + throw std::runtime_error("fsolve(): function derivative does not evaluate numerically [2]"); + xx[side] += ex_to<numeric>(dx_); + + ex f_x = f.subs(x==xx[side]).evalf(); + if (!is_a<numeric>(f_x)) + throw std::runtime_error("fsolve(): function does not evaluate numerically [2]"); + fx[side] = ex_to<numeric>(f_x); } if ((fx[side]<0 && fx[!side]<0) || (fx[side]>0 && fx[!side]>0)) { // Oops, the root isn't bracketed any more. @@ -1042,7 +1058,10 @@ fsolve(const ex& f_in, const symbol& x, const numeric& x1, const numeric& x2) static const double secant_weight = 0.984375; // == 63/64 < 1 numeric xxmid = (1-secant_weight)*0.5*(xx[0]+xx[1]) + secant_weight*(xx[0]+fx[0]*(xx[0]-xx[1])/(fx[1]-fx[0])); - numeric fxmid = ex_to<numeric>(f.subs(x==xxmid).evalf()); + ex fxmid_ = f.subs(x == xxmid).evalf(); + if (!is_a<numeric>(fxmid_)) + throw std::runtime_error("fsolve(): function does not evaluate numerically [3]"); + numeric fxmid = ex_to<numeric>(fxmid_); if (fxmid.is_zero()) { // Luck strikes... return xxmid; -- 1.7.1

1 0