From jrheinlaender at gmx.de  Tue Aug 17 05:11:46 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Tue, 17 Aug 2010 07:41:46 +0430
Subject: [GiNaC-devel] Compile with MSVC 98% successful
Message-ID: <1282014706.29458.317.camel@localhost.localdomain>

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=Installation#Compilation_with_Microsoft_Visual_C.2B.2B 

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




From alexei.sheplyakov at gmail.com  Wed Aug 18 23:07:13 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 19 Aug 2010 00:07:13 +0300
Subject: [GiNaC-devel] [PATCH 1/2] [bugfix] fsolve: check if evalf() return
 value is actually a number.
Message-ID: <20100818210713.GA25125@vargsbox.jinr.ru>

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



From alexei.sheplyakov at gmail.com  Thu Aug 19 10:10:25 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 19 Aug 2010 11:10:25 +0300
Subject: [GiNaC-devel] [PATCH 2/2] integral::evalf(): don't attempt to
	ignore problems.
Message-ID: <20100819081025.GA27794@vargsbox.jinr.ru>

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



From alexei.sheplyakov at gmail.com  Sat Aug 21 18:13:29 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Sat, 21 Aug 2010 19:13:29 +0300
Subject: [GiNaC-devel] [PATCH 3/3] fsolve: avoid useless numerical
 evaluation of the function
Message-ID: <20100821161329.GA31126@vargsbox.jinr.ru>

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



From git at ginac.de  Sat Aug 21 20:29:35 2010
From: git at ginac.de (Jens Vollinga)
Date: Sat, 21 Aug 2010 20:29:35 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-226-gbeeb081
Message-ID: <20100821182935.C9F98F00074@cebix.net>

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 at 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 at 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 at 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


From alexei.sheplyakov at gmail.com  Sun Aug 22 22:09:18 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Sun, 22 Aug 2010 23:09:18 +0300
Subject: [GiNaC-devel] [PATCH] [bugfix] power::eval(): fix several memory
	leaks
Message-ID: <20100822200917.GA12675@vargsbox.jinr.ru>

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



From alexei.sheplyakov at gmail.com  Sun Aug 22 22:15:49 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Sun, 22 Aug 2010 23:15:49 +0300
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
 computations branch, master, updated.
In-Reply-To: <20100821182935.C9F98F00074@cebix.net>
References: <20100821182935.C9F98F00074@cebix.net>
Message-ID: <20100822201549.GA16468@vargsbox.jinr.ru>

Hi Jens,

On Sat, Aug 21, 2010 at 08:29:35PM +0200, Jens Vollinga wrote:

> The branch, master has been updated
>        via  beeb0818e9cdb1b5de0ba2754286ad7bb2a9d032 (commit)
>        via  515171f0bcd42099c266713c3d605cd92cedd2e2 (commit)
>        via  9993a7aac97abf383624fc5dae4beecb29531fbd (commit)
>       from  dbde7117e88ba61597d6fee18615fe396c291a87 (commit)

Could you please apply these patches to the stable branch (ginac_1-5) too?

Best regards,
	Alexei



From alexei.sheplyakov at gmail.com  Mon Aug 23 12:52:59 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Mon, 23 Aug 2010 13:52:59 +0300
Subject: [GiNaC-devel] Compile with MSVC 98% successful
In-Reply-To: <1282014706.29458.317.camel@localhost.localdomain>
References: <1282014706.29458.317.camel@localhost.localdomain>
Message-ID: <20100823105259.GA1083@vargsbox.jinr.ru>

Hello,

On Tue, Aug 17, 2010 at 07:41:46AM +0430, Jan Rheinlaender wrote:

> 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=Installation#Compilation_with_Microsoft_Visual_C.2B.2B 

Could you please post patches instead of clumsy instructions like "edit file
foo, find bar, replace with baz"? Warning: very few of them will be applied
as is, see the comments below.

> Therefore, go to the Makefile again and edit the following entry 

I think editing automatically generated files is kind of pointless; cf.
when fixing a bug one edits the source code, not binaries. Ditto for
fiddling with *.lo files. Perhaps you need to instruct automake to use
asm sources only when compiling with GCC.

> cl_low.h defines extern "C" uint32 mulu32_high;

Which is allowed by the Standard (specifically, [dcl.link]). However,
it also says:

"At most one function with a particular name can have C language linkage. Two
declarations for a function with C language linkage with the same function
name (ignoring the namespace names that qualify it) that appear in different
namespace scopes refer to the same function. Two declarations for an object
with C language linkage with the same name (ignoring the namespace names that
qualify it) that appear in different namespace scopes refer to the same object.
[Note: because of the one definition rule (3.2), only one definition for
a function or object with C linkage may appear in the program; that is, such
a function or object must not be defined in more than one namespace scope."

Thus moving those functions into the global namespace does actually
make sense. However, it's better to prefix functions' names with "cl_"
(or "cln_") to avoid possible name collisions.

> cl_I.h declares 
> extern cl_private_thing cl_I_constructor_from_UL(uint32 wert); 
> extern cl_private_thing cl_I_constructor_from_Q(sint64 wert);
> somewhere in the file
> Comment out these declarations
> Replace them by the following at the beginning of the file:
> extern cln::cl_private_thing cl_I_constructor_from_UL(uint32 wert);
> extern cln::cl_private_thing cl_I_constructor_from_Q(sint64 wert);

Moving these functions outside of namespace cln is certainly unacceptable.

> Edit cl_LF.h, comment out 
> extern const cl_LF cl_I_to_LF (const cl_I& x, uintC len); 
> and add 
> extern const cln::cl_LF cl_I_to_LF (const cln::cl_I& x, uintC len);
> to the beginning of the file, outside the namespace cln

Ditto.

> The other examples need more modifications of the source along the same
> lines to link. Only e.cc presents new problems
> Add #include "../src/float/lfloat/cl_LF.h" to the beginning of the file
> Comment out the extern cl_LF cl_I_to_LF(const cl_I&, uintC);
> declaration lower down

Header files in the src directory are private, and should be included
only by other files in the src directory.

> function.cpp: Change 
> return (new GiNaC::power(*this, power_param))->setflag(status_flags::dynallocated | status_flags::evaluated);
> with
> return (power::power(*this, power_param)).setflag(status_flags::evaluated);

I'm afraid your variant is invalid, since it violates [basic.lookup.qual],
specifically

"1 The name of a class or namespace member can be referred to after the ::
scope resolution operator (5.1) applied to a nested-name-specifier that
nominates its class or namespace. During the lookup for a name preceding
the :: scope resolution operator, object, function, and enumerator names
are ignored. If the name found is not a class-name (clause 9) or namespace-name
(7.3.1), the program is ill-formed."

In the scope of function::power method definition the name `power'
refers to the function::power itself, so it is not a class or a namespace
name, and the program is invalid.

Also this change breaks compilation with GCC 4.5 (for reason explained above).
It's unacceptable, sorry.

> polynomial/primes_factory.h: MSVC does not accept void * as argument of sizeof()
> Edit configure.ac and add a line AC_CHECK_SIZEOF(void*, 1). Run
> autoreconf and re-run configure.

This sounds a bit self-contradictory. AC_CHECK_SIZEOF(void*) certainly invokes
sizeof(void*), so if your compiler doesn't grok sizeof(void*) (which I really
doubt) AC_CHECK_SIZEOF(void*) is not going to work. On the other hand, if
AC_CHECK_SIZEOF(void*) works, you don't actually need this trick.

> External constants must be outside namespaces

I'm afraid the Standard does not enforce this (and we don't want to pollute
the global namespace).

> 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

Should be:

Non-trivial GCD, degree(a) = 1000, degree(b) = 1000

So it looks like inputs are incorrect (I don't know why).

Best regards,
	Alexei



From jrheinlaender at gmx.de  Mon Aug 23 13:24:28 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Mon, 23 Aug 2010 15:54:28 +0430
Subject: [GiNaC-devel] Compile with MSVC 98% successful
In-Reply-To: <20100823105259.GA1083@vargsbox.jinr.ru>
References: <1282014706.29458.317.camel@localhost.localdomain>
	<20100823105259.GA1083@vargsbox.jinr.ru>
Message-ID: <1282562668.25620.404.camel@localhost.localdomain>

Hello Alexei,

> Could you please post patches instead of clumsy instructions like "edit file
> foo, find bar, replace with baz"? Warning: very few of them will be applied
> as is, see the comments below.
sorry, I am just trying to compile GiNaC somehow for my own purposes. I
am not a good enough programmer to deal with all the details you
mentioned (although I will try to as far as my abilities go). So if
someone wants to build on my "adventures", he can go ahead, otherwise
just leave it.

Is anybody except me interested in compiling GiNaC with MSVC, anyway?

In any case, how do I post patches?

Thank you for taking the time to comment on my post in this length!

Regards,
	Jan




From git at ginac.de  Mon Aug 23 15:26:05 2010
From: git at ginac.de (Jens Vollinga)
Date: Mon, 23 Aug 2010 15:26:05 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, ginac_1-5, updated. release_1-4-0-247-gcc94094
Message-ID: <20100823132606.0C76DF00115@cebix.net>

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 at 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 at 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 at 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 at 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


From git at ginac.de  Mon Aug 23 15:26:06 2010
From: git at ginac.de (Jens Vollinga)
Date: Mon, 23 Aug 2010 15:26:06 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-227-g5f896fa
Message-ID: <20100823132606.68C12F00071@cebix.net>

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 at 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


From coder.peter.grobarcik at googlemail.com  Mon Aug 23 15:03:51 2010
From: coder.peter.grobarcik at googlemail.com (Peter Grobarcik)
Date: Mon, 23 Aug 2010 15:03:51 +0200
Subject: [GiNaC-devel] Compile with MSVC 98% successful
In-Reply-To: <1282562668.25620.404.camel@localhost.localdomain>
References: <1282014706.29458.317.camel@localhost.localdomain>
	<20100823105259.GA1083@vargsbox.jinr.ru>
	<1282562668.25620.404.camel@localhost.localdomain>
Message-ID: <AANLkTim3XmkhuUabMdna7qo2+Poa5Hffvda-hBpr-u7c@mail.gmail.com>

Hallo Jan,

2010/8/23 Jan private <jrheinlaender at gmx.de>

> Hello Alexei,
>
> > Could you please post patches instead of clumsy instructions like "edit
> file
> > foo, find bar, replace with baz"? Warning: very few of them will be
> applied
> > as is, see the comments below.
> sorry, I am just trying to compile GiNaC somehow for my own purposes. I
> am not a good enough programmer to deal with all the details you
> mentioned (although I will try to as far as my abilities go). So if
> someone wants to build on my "adventures", he can go ahead, otherwise
> just leave it.
>
> Is anybody except me interested in compiling GiNaC with MSVC, anyway?
>
I am interresed, actually I wanted to do it myself, but You were faster ;-)
In second half of October I even can help.

Cheers,

Peter


> In any case, how do I post patches?
>
> Thank you for taking the time to comment on my post in this length!
>
> Regards,
>        Jan
>
>
> _______________________________________________
> GiNaC-devel mailing list
> GiNaC-devel at ginac.de
> https://www.cebix.net/mailman/listinfo/ginac-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100823/4386c538/attachment.htm>

From jrheinlaender at gmx.de  Mon Aug 23 16:33:36 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Mon, 23 Aug 2010 19:03:36 +0430
Subject: [GiNaC-devel] Compile with MSVC 98% successful
In-Reply-To: <20100823134011.GA14009@vargsbox.jinr.ru>
References: <1282014706.29458.317.camel@localhost.localdomain>
	<20100823105259.GA1083@vargsbox.jinr.ru>
	<1282562668.25620.404.camel@localhost.localdomain>
	<20100823134011.GA14009@vargsbox.jinr.ru>
Message-ID: <1282574016.25620.412.camel@localhost.localdomain>

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