From varg at theor.jinr.ru  Mon Nov 20 20:01:40 2006
From: varg at theor.jinr.ru (Alexei Sheplyakov)
Date: Mon, 20 Nov 2006 22:01:40 +0300
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
Message-ID: <20061120190140.GA19168@theor.jinr.ru>

Hello!

Heuristic code in gcd [very] often makes bad choice of the main variable.
In particular, if one of polynomials (say, p2) does not contain
the variable x which _is contained_ in another one (say, p1), than
gcd(p1, p2) will use such a variable as a main, so subsequent calculation
becomes unnecessary complicated. Fixing this substantially improves worst
case performance (less than minute versus infinity).

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

---
 ginac/normal.cpp |   46 +++++++++++++++++++++++++++++++++++++++++++---
 1 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/ginac/normal.cpp b/ginac/normal.cpp
index b2a4e8c..1cbf3c2 100644
--- a/ginac/normal.cpp
+++ b/ginac/normal.cpp
@@ -1589,11 +1589,51 @@ factored_b:
 		}
 	}
 
+	if (is_exactly_a<numeric>(aex)) {
+		numeric bcont = bex.integer_content();
+		numeric g = gcd(ex_to<numeric>(aex), bcont);
+		if (ca)
+			*ca = ex_to<numeric>(aex)/g;
+		if (cb)
+			*cb = bex/g;
+		return g;
+	}
+
+	if (is_exactly_a<numeric>(bex)) {
+		numeric acont = aex.integer_content();
+		numeric g = gcd(ex_to<numeric>(bex), acont);
+		if (ca)
+			*ca = aex/g;
+		if (cb)
+			*cb = ex_to<numeric>(bex)/g;
+		return g;
+	}
+
 	// Gather symbol statistics
 	sym_desc_vec sym_stats;
 	get_symbol_stats(a, b, sym_stats);
 
-	// The symbol with least degree is our main variable
+	// The symbol with least degree which is contained in both polynomials
+	// is our main variable
+	sym_desc_vec::iterator vari = sym_stats.begin();
+	while ( (vari != sym_stats.end()) && 
+			    (((vari->ldeg_b == 0) && (vari->deg_b == 0)) ||
+			     ((vari->ldeg_a == 0) && (vari->deg_a == 0))))
+		vari++;
+
+	// No common symbols at all, just return 1:
+	if (vari == sym_stats.end()) {
+		// N.B: keep cofactors factored
+		if (ca)
+			*ca = a;
+		if (cb)
+			*cb = b;
+		return _ex1;
+	}
+	// move symbols which contained only in one of the polynomials
+	// to the end:
+	rotate(sym_stats.begin(), vari, sym_stats.end());
+
 	sym_desc_vec::const_iterator var = sym_stats.begin();
 	const ex &x = var->sym;
 
@@ -1607,14 +1647,14 @@ factored_b:
 	}
 
 	// Try to eliminate variables
-	if (var->deg_a == 0) {
+	if ((var->deg_a == 0) && (var->deg_b != 0)) {
 		ex bex_u, bex_c, bex_p;
 		bex.unitcontprim(x, bex_u, bex_c, bex_p);
 		ex g = gcd(aex, bex_c, ca, cb, false);
 		if (cb)
 			*cb *= bex_u * bex_p;
 		return g;
-	} else if (var->deg_b == 0) {
+	} else if ((var->deg_b == 0) && (var->deg_a != 0)) {
 		ex aex_u, aex_c, aex_p;
 		aex.unitcontprim(x, aex_u, aex_c, aex_p);
 		ex g = gcd(aex_c, bex, ca, cb, false);
-- 
1.4.3.3



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061120/3a58c97c/attachment.sig>

From bernard.parisse at wanadoo.fr  Mon Nov 20 21:02:23 2006
From: bernard.parisse at wanadoo.fr (bernard.parisse)
Date: Mon, 20 Nov 2006 21:02:23 +0100
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
In-Reply-To: <20061120190140.GA19168@theor.jinr.ru>
References: <20061120190140.GA19168@theor.jinr.ru>
Message-ID: <456209CF.9090308@wanadoo.fr>

Alexei Sheplyakov wrote:

>Hello!
>
>Heuristic code in gcd [very] often makes bad choice of the main variable.
>In particular, if one of polynomials (say, p2) does not contain
>the variable x which _is contained_ in another one (say, p1), than
>gcd(p1, p2) will use such a variable as a main, so subsequent calculation
>becomes unnecessary complicated. Fixing this substantially improves worst
>case performance (less than minute versus infinity).
>  
>
hello,

in this case, you should compute the content with respect to x of p1
and then the gcd of the content with p2. A good candidate for the gcd
will be the gcd of p2 with a random integer linear combination of the
coeffs of p1 with respect to x.
Anyway, heuristic gcd is most of the time not a good choice if there
are more than a few variables. Modular gcd is in my experience faster
(and this is theoretically also true).


From varg at theor.jinr.ru  Tue Nov 21 08:36:41 2006
From: varg at theor.jinr.ru (Sheplyakov Alexei)
Date: Tue, 21 Nov 2006 10:36:41 +0300
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
In-Reply-To: <456209CF.9090308@wanadoo.fr>
References: <20061120190140.GA19168@theor.jinr.ru>
	<456209CF.9090308@wanadoo.fr>
Message-ID: <20061121073641.GA2703@theor.jinr.ru>

Hi,

On Mon, Nov 20, 2006 at 09:02:23PM +0100, bernard.parisse wrote:
> >Heuristic code in gcd [very] often makes bad choice of the main variable.
> >In particular, if one of polynomials (say, p2) does not contain
> >the variable x which _is contained_ in another one (say, p1), than
> >gcd(p1, p2) will use such a variable as a main, so subsequent calculation
> >becomes unnecessary complicated. Fixing this substantially improves worst
> >case performance (less than minute versus infinity).
> > 
> in this case, you should compute the content with respect to x of p1
> and then the gcd of the content with p2.

The old code used to do so:

if (var->deg_a == 0) {
	ex bex_u, bex_c, bex_p;
	bex.unitcontprim(x, bex_u, bex_c, bex_p);
	ex g = gcd(aex, bex_c, ca, cb, false);
	if (cb)
		*cb *= bex_u*bex_p;
	return g;
	} else if (var->deg_b == 0) {
		ex aex_u, aex_c, aex_p;
		aex.unitcontprim(x, aex_u, aex_c, aex_p);
		ex g = gcd(aex_c, bex, ca, cb, false);
		if (ca)
			*ca *= aex_u * aex_p;
		return g;
	}

This is exactly what leads to inferior performance (example is
attached).

> A good candidate for the gcd will be the gcd of p2 with a random
> integer linear combination of the coeffs of p1 with respect to x.

I'm not trying to provide a [better] guess. The point is to prevent
the code from making particulary bad ones, especially when polynomials
in question are relatively prime.

> Anyway, heuristic gcd is most of the time not a good choice if there
> are more than a few variables. Modular gcd is in my experience faster
> (and this is theoretically also true).

I agree with you completely. But unfortunately GiNaC is not well suited
for doing modular arithmetics [yet] :(

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: thepoly_another.cpp.gz
Type: application/octet-stream
Size: 1037 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/b63e1092/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/b63e1092/attachment.sig>

From varg at theor.jinr.ru  Tue Nov 21 14:36:26 2006
From: varg at theor.jinr.ru (Alexei Sheplyakov)
Date: Tue, 21 Nov 2006 16:36:26 +0300
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
In-Reply-To: <20061121082813.GA3006@fourier.ujf-grenoble.fr>
References: <20061120190140.GA19168@theor.jinr.ru>
	<456209CF.9090308@wanadoo.fr> <20061121073641.GA2703@theor.jinr.ru>
	<20061121082813.GA3006@fourier.ujf-grenoble.fr>
Message-ID: <20061121133626.GA7269@theor.jinr.ru>


[adding ginac-devel to CC]

On Tue, Nov 21, 2006 at 09:28:13AM +0100, Bernard Parisse wrote:

> BTW, I checked your example with the gcd code of my giac library,
> it takes less than 3s. to normalize on a Intel(R) Pentium(R) M
> processor 1.60GHz, how long does it take with your patched ginac version?

[on a Pentium 4 3GHz box]
$ g++ -O2 -march=pentium4 -finline-limit=1200 thepoly_another.cpp -o thepoly_another -lginac
$ time ./thepoly_another >/dev/null 2>&1

real    0m7.846s
user    0m7.836s
sys     0m0.008s

With unpatched GiNaC it takes way to long (after several days of
calculation I get bored and killed the process).

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/55fcb7e9/attachment.sig>

From kisilv at maths.leeds.ac.uk  Tue Nov 21 14:32:32 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Tue, 21 Nov 2006 13:32:32 +0000
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly 
In-Reply-To: Your message of "Tue, 21 Nov 2006 16:36:26 +0300."
	<20061121133626.GA7269@theor.jinr.ru> 
Message-ID: <20225.1164115952@localhost>

>>>>> "ASh" == Alexei Sheplyakov <varg at theor.jinr.ru> writes:

    ASh> real 0m7.846s user 0m7.836s sys 0m0.008s

    ASh> With unpatched GiNaC it takes way to long (after several days
    ASh> of calculation I get bored and killed the process).

	I also have examples of the same code which may run either few
  seconds or infinity. Is gcd the only source in GiNaC of such
  behaviour?

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From varg at theor.jinr.ru  Tue Nov 21 17:10:39 2006
From: varg at theor.jinr.ru (Sheplyakov Alexei)
Date: Tue, 21 Nov 2006 19:10:39 +0300
Subject: [GiNaC-devel] GiNaC's performance bottleneck[s]
In-Reply-To: <20225.1164115952@localhost>
References: <20061121133626.GA7269@theor.jinr.ru> <20225.1164115952@localhost>
Message-ID: <20061121161039.GB16087@theor.jinr.ru>

Hi,

On Tue, Nov 21, 2006 at 01:32:32PM +0000, Vladimir Kisil wrote:
> 	I also have examples of the same code which may run either few
>   seconds or infinity.

Could you please show such an example?

> Is gcd the only source in GiNaC of such behaviour?

I suspect there are few others too. In particular, collect() is _very_
inefficient when the argument is a sparse multivariate polynomial.
(I've got a patch, but I need to do more tests before submitting it).

But gcd and other polynomial operations which make use of it (normal, 
collect_common_factors) are the most ugly ones :(

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/2268f45b/attachment.sig>

From kisilv at maths.leeds.ac.uk  Tue Nov 21 17:20:37 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Tue, 21 Nov 2006 16:20:37 +0000
Subject: [GiNaC-devel] GiNaC's performance bottleneck[s] 
In-Reply-To: Your message of "Tue, 21 Nov 2006 19:10:39 +0300."
	<20061121161039.GB16087@theor.jinr.ru> 
Message-ID: <30943.1164126037@localhost>

>>>>> "ShA" == Sheplyakov Alexei <varg at theor.jinr.ru> writes:
    >> I also have examples of the same code which may run either few
    >> seconds or infinity.
    ShA> Could you please show such an example?

	I do not have a short example. What I met is a part of a rather big
  program (cs.MS/0512073), specifically the chunk which check
  conformality of different distances. It uses series expansion of a
  fraction of two multi-variable polynomials so it can be either gcd()
  or collect() which cause infinite execution, I guess.
  
  Surprisingly infinite execution occurs only on my office computer but
  never at home, although they both have quite similar hardware
  configuration (Athlons 2800 and 3000).

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From varg at theor.jinr.ru  Tue Nov 21 20:01:11 2006
From: varg at theor.jinr.ru (Sheplyakov Alexei)
Date: Tue, 21 Nov 2006 22:01:11 +0300
Subject: [GiNaC-devel] GiNaC's performance bottleneck[s]
In-Reply-To: <30943.1164126037@localhost>
References: <20061121161039.GB16087@theor.jinr.ru> <30943.1164126037@localhost>
Message-ID: <20061121190111.GA12156@theor.jinr.ru>

On Tue, Nov 21, 2006 at 04:20:37PM +0000, Vladimir Kisil wrote:
> 	I do not have a short example. What I met is a part of a rather big
>   program (cs.MS/0512073),

I couldn't compile it (see the attached log), what I'm doing wrong?

$ g++ --version | head -n 1
g++ (GCC) 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)

$ ginac-config --version
1.3.5

This is not really GiNaC 1.3.5, but rather my hijacked version, but
the API is the same.

> specifically the chunk which check
> conformality of different distances. It uses series expansion of a
> fraction of two multi-variable polynomials so it can be either gcd()
> or collect() which cause infinite execution, I guess.

AFAIK, no series() method uses gcd() on its own. But there are a couple
of normal() (which obviously uses gcd()) in your code, so I guess bad
gcd() performance might be the root of the problem. The patches I've
posted (last month and yesterday) might solve it.

> Surprisingly infinite execution occurs only on my office computer

Could you please show the backtrace? Or maybe print the expression 
before calling normal() and post it here?

> but never at home, although they both have quite similar hardware
> configuration (Athlons 2800 and 3000).

This makes me think about compiler bugs/wrong compilation options, etc.
Are you sure the software (first of all, the compiler) versions and 
compilation options are _exactly_ the same on machines in question?

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

-------------- next part --------------
$ ccache g++ -I. parab-ortho1.cpp cycle.cpp -O0 -g -lginac
./cycle.h:43: warning: ?class cycle::visitor? has virtual functions but non-virtual destructor
./cycle.h:139: warning: ?class cycle2D::visitor? has virtual functions but non-virtual destructor
parab-ortho1.nw:2977: error: ?class GiNaC::function_options? has no member named ?power_func?
./cycle.h:43: warning: ?class cycle::visitor? has virtual functions but non-virtual destructor
./cycle.h:139: warning: ?class cycle2D::visitor? has virtual functions but non-virtual destructor
parab-ortho1.cpp: In function ?int main()?:
parab-ortho1.cpp:227: error: no matching function for call to ?cycle2D::center(const GiNaC::ex&) const?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:313: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:320: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:327: error: ?class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:339: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:366: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:378: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:454: error: no matching function for call to ?cycle2D::center(GiNaC::ex, bool)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:454: error: no matching function for call to ?cycle2D::center(const GiNaC::ex&, bool) const?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:498: error: no matching function for call to ?cycle2D::cycle2D(const cycle2D&, const GiNaC::ex&)?
./cycle.h:147: note: candidates are: cycle2D::cycle2D(const cycle&)
./cycle.h:145: note:                 cycle2D::cycle2D(const GiNaC::lst&, const GiNaC::ex&, const GiNaC::ex&, const GiNaC::ex&, const GiNaC::ex&)
./cycle.h:142: note:                 cycle2D::cycle2D(const GiNaC::ex&, const GiNaC::ex&, const GiNaC::ex&, const GiNaC::ex&)
./cycle.h:139: note:                 cycle2D::cycle2D()
./cycle.h:139: note:                 cycle2D::cycle2D(const GiNaC::archive_node&, GiNaC::lst&)
./cycle.h:138: note:                 cycle2D::cycle2D(const cycle2D&)
parab-ortho1.cpp:605: error: no matching function for call to ?cycle2D::focus(GiNaC::ex, bool) const?
./cycle.h:150: note: candidates are: GiNaC::ex cycle2D::focus(const GiNaC::ex&) const
parab-ortho1.cpp:629: error: no matching function for call to ?cycle2D::center(GiNaC::ex, bool)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:630: error: no matching function for call to ?cycle2D::focus(GiNaC::ex, bool) const?
./cycle.h:150: note: candidates are: GiNaC::ex cycle2D::focus(const GiNaC::ex&) const
parab-ortho1.cpp:1170: error: no matching function for call to ?cycle2D::focus(GiNaC::ex, bool) const?
./cycle.h:150: note: candidates are: GiNaC::ex cycle2D::focus(const GiNaC::ex&) const
parab-ortho1.cpp:1185: error: ?const class cycle2D? has no member named ?is_orthogonal?
parab-ortho1.cpp:1211: error: no matching function for call to ?cycle2D::focus(GiNaC::ex, bool)?
./cycle.h:150: note: candidates are: GiNaC::ex cycle2D::focus(const GiNaC::ex&) const
parab-ortho1.cpp:1498: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1501: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1502: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1504: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1582: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1585: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1586: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1588: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1654: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1655: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1685: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1686: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1688: error: no matching function for call to ?cycle2D::center(const GiNaC::ex)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:1688: error: no matching function for call to ?cycle2D::center(const GiNaC::ex)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:1689: error: no matching function for call to ?cycle2D::center(const GiNaC::ex)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:1689: error: no matching function for call to ?cycle2D::center(const GiNaC::ex)?
./cycle.h:85: note: candidates are: GiNaC::ex cycle::center() const
parab-ortho1.cpp:1728: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1754: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1756: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1759: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1796: error: ?const class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1799: error: ?const class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1837: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1839: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1841: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1845: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1876: error: ?const class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1880: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1913: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1915: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1918: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1935: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1937: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1940: error: ?class cycle2D? has no member named ?asy_draw?
parab-ortho1.cpp:1945: error: ?class cycle2D? has no member named ?asy_draw?
distcc[21420] ERROR: compile cycle.cpp on localhost failed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/fd908d7d/attachment.sig>

From varg at theor.jinr.ru  Tue Nov 21 20:27:46 2006
From: varg at theor.jinr.ru (Alexei Sheplyakov)
Date: Tue, 21 Nov 2006 22:27:46 +0300
Subject: [GiNaC-devel] [PATCH] collect: improve distributed collect of
	sparse multivariate polynomials.
Message-ID: <20061121192746.GA22171@theor.jinr.ru>

Hi,
as I promised here is a patch for basic::collect()

The old algorithm seems to be particularly inefficient when *this
is sparse multivariate polynomial. New algorithm handles such polynomials
much better (this is yet another "zero or infinity evaluation time"
issue). It should handle dense polynomials fairly well too. Another bonus
is that new code is simpler.

Best regards,
 Alexei

-- 
All science is either physics or stamp collecting.

---
 ginac/basic.cpp |   71 ++++++++++++++++++------------------------------------
 1 files changed, 24 insertions(+), 47 deletions(-)

diff --git a/ginac/basic.cpp b/ginac/basic.cpp
index f86483e..c7a33ca 100644
--- a/ginac/basic.cpp
+++ b/ginac/basic.cpp
@@ -30,6 +30,7 @@
 #include "ex.h"
 #include "numeric.h"
 #include "power.h"
+#include "add.h"
 #include "symbol.h"
 #include "lst.h"
 #include "ncmul.h"
@@ -369,56 +370,32 @@ ex basic::collect(const ex & s, bool dis
 
 		else if (distributed) {
 
-			// Get lower/upper degree of all symbols in list
-			size_t num = s.nops();
-			struct sym_info {
-				ex sym;
-				int ldeg, deg;
-				int cnt;  // current degree, 'counter'
-				ex coeff; // coefficient for degree 'cnt'
-			};
-			sym_info *si = new sym_info[num];
-			ex c = *this;
-			for (size_t i=0; i<num; i++) {
-				si[i].sym = s.op(i);
-				si[i].ldeg = si[i].cnt = this->ldegree(si[i].sym);
-				si[i].deg = this->degree(si[i].sym);
-				c = si[i].coeff = c.coeff(si[i].sym, si[i].cnt);
-			}
-
-			while (true) {
-
-				// Calculate coeff*x1^c1*...*xn^cn
-				ex y = _ex1;
-				for (size_t i=0; i<num; i++) {
-					int cnt = si[i].cnt;
-					y *= power(si[i].sym, cnt);
-				}
-				x += y * si[num - 1].coeff;
-
-				// Increment counters
-				size_t n = num - 1;
-				while (true) {
-					++si[n].cnt;
-					if (si[n].cnt <= si[n].deg) {
-						// Update coefficients
-						ex c;
-						if (n == 0)
-							c = *this;
-						else
-							c = si[n - 1].coeff;
-						for (size_t i=n; i<num; i++)
-							c = si[i].coeff = c.coeff(si[i].sym, si[i].cnt);
-						break;
-					}
-					if (n == 0)
-						goto done;
-					si[n].cnt = si[n].ldeg;
-					n--;
+			x = this->expand();
+			if (! is_a<add>(x))
+				return x; 
+			const lst& l(ex_to<lst>(s));
+
+			exmap cmap;
+			cmap[_ex1] = _ex0;
+			for (const_iterator xi=x.begin(); xi!=x.end(); ++xi) {
+				ex key = _ex1;
+				ex pre_coeff = *xi;
+				for (lst::const_iterator li=l.begin(); li!=l.end(); ++li) {
+					int cexp = pre_coeff.degree(*li);
+					pre_coeff = pre_coeff.coeff(*li, cexp);
+					key *= pow(*li, cexp);
 				}
+				exmap::iterator ci = cmap.find(key);
+				if (ci != cmap.end())
+					ci->second += pre_coeff;
+				else
+					cmap.insert(exmap::value_type(key, pre_coeff));
 			}
 
-done:		delete[] si;
+			exvector resv;
+			for (exmap::const_iterator mi=cmap.begin(); mi != cmap.end(); ++mi)
+				resv.push_back((mi->first)*(mi->second));
+			return (new add(resv))->setflag(status_flags::dynallocated);
 
 		} else {
 
-- 
1.4.3.3



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20061121/b1b1b777/attachment.sig>

From kreckel at ginac.de  Tue Nov 21 23:10:49 2006
From: kreckel at ginac.de (Richard B. Kreckel)
Date: Tue, 21 Nov 2006 23:10:49 +0100
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
In-Reply-To: <20061121133626.GA7269@theor.jinr.ru>
References: <20061120190140.GA19168@theor.jinr.ru>	<456209CF.9090308@wanadoo.fr>
	<20061121073641.GA2703@theor.jinr.ru>	<20061121082813.GA3006@fourier.ujf-grenoble.fr>
	<20061121133626.GA7269@theor.jinr.ru>
Message-ID: <45637969.4000501@ginac.de>

Dear Alexei,

Alexei Sheplyakov wrote:

>[on a Pentium 4 3GHz box]
>$ g++ -O2 -march=pentium4 -finline-limit=1200 thepoly_another.cpp -o thepoly_another -lginac
>$ time ./thepoly_another >/dev/null 2>&1
>
>real    0m7.846s
>user    0m7.836s
>sys     0m0.008s
>
>With unpatched GiNaC it takes way to long (after several days of
>calculation I get bored and killed the process).
>  
>

As a challenge, could you please have a look at the Lewis-Wester 
benchmarks M2, N, and O2 in files check/time_lw_M2.cpp, 
check/time_lw_N.cpp, and check/time_lw_M2.cpp, respectively? They all 
contain a boolean variable which is used to turn disable these tests. 
And they are all about GCDs. Some of them have never ever run to completion.

BTW: May we assume that your little patch makes the GCD also much more 
memory effective?

Regards
  -richy.

-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From kreckel at ginac.de  Tue Nov 21 23:12:22 2006
From: kreckel at ginac.de (Richard B. Kreckel)
Date: Tue, 21 Nov 2006 23:12:22 +0100
Subject: [GiNaC-devel] [PATCH] gcd: fix heuristics to chose main variable
	properly
In-Reply-To: <45637969.4000501@ginac.de>
References: <20061120190140.GA19168@theor.jinr.ru>	<456209CF.9090308@wanadoo.fr>	<20061121073641.GA2703@theor.jinr.ru>	<20061121082813.GA3006@fourier.ujf-grenoble.fr>	<20061121133626.GA7269@theor.jinr.ru>
	<45637969.4000501@ginac.de>
Message-ID: <456379C6.4020001@ginac.de>

Richard B. Kreckel wrote:

> As a challenge, could you please have a look at the Lewis-Wester 
> benchmarks M2, N, and O2 in files check/time_lw_M2.cpp, 
> check/time_lw_N.cpp, and check/time_lw_M2.cpp, respectively?


Sorry, the last file should've been check/time_lw_O.cpp.

  -richy.

-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From kisilv at maths.leeds.ac.uk  Tue Nov 21 23:55:02 2006
From: kisilv at maths.leeds.ac.uk (Vladimir Kisil)
Date: Tue, 21 Nov 2006 22:55:02 +0000
Subject: [GiNaC-devel] GiNaC's performance bottleneck[s] 
In-Reply-To: Your message of "Tue, 21 Nov 2006 22:01:11 +0300."
	<20061121190111.GA12156@theor.jinr.ru> 
Message-ID: <10057.1164149702@localhost>

>>>>> "ShA" == Sheplyakov Alexei <varg at theor.jinr.ru> writes:
    ShA> I couldn't compile it (see the attached log), what I'm doing
    ShA> wrong?
    ShA> $ ginac-config --version 1.3.5

	I think that my library uses something from 1.4 (CVS) branch.

    ShA> Could you please show the backtrace? Or maybe print the
    ShA> expression before calling normal() and post it here?

	It may be indeed a compiler-related issue since such a behaviour
  disappeared a month ago (I am updating my Debian-testing
  distribution almost daily on both computers, thus, theoretically they
  should have the same soft). Another strange thing was that an insertion of
  few debug outputs makes the program finishes in a reasonable time. The
  infinite run resumed again after I again deleted all those silly 

  cerr << 100 <<endl; 

  statements. All of this is much beyond of my understanding.

  Best wishes,
  Vladimir
-- 
Vladimir V. Kisil     email: kisilv at maths.leeds.ac.uk
--                      www: http://maths.leeds.ac.uk/~kisilv/


From Chris.Dams at mi.infn.it  Wed Nov 22 16:58:14 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Wed, 22 Nov 2006 16:58:14 +0100 (CET)
Subject: [GiNaC-devel] Improvements for positive symbols.
Message-ID: <Pine.LNX.4.44.0611221655140.21897-100000@lxmi.mi.infn.it>


Dear all,

.info(info_flags::positive) did not yet return true for a postive symbol. 
I fixed this and also made atan2 handle pos. symbols better. Now atan2(0, 
x) with x a positive symbol returns 0 automatically.

Best wishes,
Chris



From Chris.Dams at mi.infn.it  Wed Nov 22 17:01:38 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Wed, 22 Nov 2006 17:01:38 +0100 (CET)
Subject: [GiNaC-devel] Patches for collect_common_factors
Message-ID: <Pine.LNX.4.44.0611221658200.21897-100000@lxmi.mi.infn.it>


Dear all,

I applied the three patches that Alexei sent at the beginning of October
for improving collect_common_factors to both 1.3 and head.

Bye,
Chris



From Chris.Dams at mi.infn.it  Wed Nov 22 17:17:35 2006
From: Chris.Dams at mi.infn.it (Chris Dams)
Date: Wed, 22 Nov 2006 17:17:35 +0100 (CET)
Subject: [GiNaC-devel] backported fix for reposition_dummy_indices to 1.3
Message-ID: <Pine.LNX.4.44.0611221714460.21897-100000@lxmi.mi.infn.it>


Hello again,

I backported the fixes to reposition_dummy_indices that were discussed on 
this list in October to 1.3. This was Alexeis patch, so thanks to Alexei!

Best,
Chris