From chrisd at sci.kun.nl  Thu Jul  1 18:40:59 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Thu, 1 Jul 2004 16:40:59 +0000 (UTC)
Subject: patch
Message-ID: <Pine.LNX.4.44.0407011639210.4321-100000@gamow.sci.kun.nl>


Dear GiNaCers,

The line

	if (return_type_tinfo() & 0xffffff00U != TINFO_clifford) {

that occurs in ncmul::conjugate() needs to be changed into

	if ((return_type_tinfo() & 0xffffff00U) != TINFO_clifford) {

for correct operator precedence.

Best,
Chris



From Christian.Bauer at Uni-Mainz.DE  Thu Jul  1 18:17:54 2004
From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer)
Date: Thu, 1 Jul 2004 18:17:54 +0200
Subject: patch
In-Reply-To: <Pine.LNX.4.44.0407011639210.4321-100000@gamow.sci.kun.nl>
References: <Pine.LNX.4.44.0407011639210.4321-100000@gamow.sci.kun.nl>
Message-ID: <20040701161754.GD24135@thep.physik.uni-mainz.de>

Hi!

On Thu, Jul 01, 2004 at 04:40:59PM +0000, Chris Dams wrote:
> The line
> 
> 	if (return_type_tinfo() & 0xffffff00U != TINFO_clifford) {
> 
> that occurs in ncmul::conjugate() needs to be changed into
> 
> 	if ((return_type_tinfo() & 0xffffff00U) != TINFO_clifford) {
> 
> for correct operator precedence.

Yup. But why does ncmul need to know about clifford anyway?

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/


From chrisd at sci.kun.nl  Thu Jul  1 20:53:51 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Thu, 1 Jul 2004 18:53:51 +0000 (UTC)
Subject: patch
In-Reply-To: <20040701161754.GD24135@thep.physik.uni-mainz.de>
Message-ID: <Pine.LNX.4.44.0407011835380.10437-100000@gamow.sci.kun.nl>


Dear Christian,

> Yup. But why does ncmul need to know about clifford anyway?

Because on clifford objects complex conjugation works as hermitian
conjugation. ncmul is the only class that can take care of swapping the
sequence around as in

	(ncmul(gamma~mu,gamma~nu))^dagger
		= ncmul((gamma~nu)^dagger,(gamma~mu)^dagger).

Best,
Chris



From kreckel at thep.physik.uni-mainz.de  Fri Jul  2 00:00:30 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Fri, 2 Jul 2004 00:00:30 +0200 (CEST)
Subject: CLN 1.1.8 released
Message-ID: <Pine.LNX.4.33.0407012248090.28903-100000@higgs.physik.uni-mainz.de>

Hello!

CLN version 1.1.8 is out and available from the usual FTP site [0].  It
incorporates a fix for a long standing bug recently discovered by Niklas
Knutsson and it finally has working support for the AMD64 platform, a.k.a.
the Opteron.

The reason for this broad advertisement is that whilst revamping the GiNaC
mailing lists, Christian Bauer has been so kind to set up a list dedicated
to CLN.  It's powered by Mailman and you can find information on how to
subscribe at [1].  Recently, it has become somewhat popular to use the
GiNaC mailing lists for CLN related topics.  While this has brought some
liveliness to those lists we should try to use <cln-list at ginac.de> instead
from now on.  I do not intend to continue with selective announcements -
from now on the list will be used instead and it is recommended that you
subscribe if your interest is fervent.  :-)

Regards
    -richy.

[0] <ftp://ftpthep.physik.uni-mainz.de/pub/gnu/>
[1] <http://thep.physik.uni-mainz.de/mailman/listinfo/cln-list>
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From ralf at ark.in-berlin.de  Fri Jul  2 11:31:36 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Fri, 2 Jul 2004 11:31:36 +0200
Subject: content() inconsistencies
Message-ID: <20040702113136.A989@ark.in-berlin.de>

Hello,

this
  symbol x("x"), a("a");
  cout << (a*x/2+a*a/3).content(x) << endl;
  cout << (x/2+ex(1)/3).content(x) << endl;
  cout << (10*x/2+ex(15)/3).content(x) << endl;
gives
  a
  1
  5
while Pari says
  1/6*a
  1/6
  5
but I'm of the opinion it should be
  1/6*a
  1/6
  5/6

I would fix it in ginac but what's the official definition of content?

Regards,
ralf



From Christian.Bauer at Uni-Mainz.DE  Fri Jul  2 14:59:30 2004
From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer)
Date: Fri, 2 Jul 2004 14:59:30 +0200
Subject: content() inconsistencies
In-Reply-To: <20040702113136.A989@ark.in-berlin.de>
References: <20040702113136.A989@ark.in-berlin.de>
Message-ID: <20040702125930.GE24135@thep.physik.uni-mainz.de>

Hi!

On Fri, Jul 02, 2004 at 11:31:36AM +0200, Ralf Stephan wrote:
>   cout << (10*x/2+ex(15)/3).content(x) << endl;

But that's 5x+5...?

Anyway, content() and primpart() in GiNaC currently only work correctly for
polynomials in Z[x]. But your Pari results are correct. The content of a
polynomial in Q[x] should be calculated in a way that the primitive part is
a polynomial in Z[x] with content 1.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/


From chrisd at sci.kun.nl  Fri Jul  2 15:49:20 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Fri, 2 Jul 2004 13:49:20 +0000 (UTC)
Subject: patch for complex conj of additions.
Message-ID: <Pine.LNX.4.44.0407021344150.5098-200000@gamow.sci.kun.nl>


Dear GiNaCers,

I found out that complex conjugating a-a*gamma5 gives a--a*gamma5. This is
because the minus in front of a*gamm5 is stored inside the add while the
minus that comes from cc-ing a*gamma5 is stored in the multiplication.
These are not cancelled. The solution is to have a separate add::conjugate
function. A patch is attached.

Best,
Chris
-------------- next part --------------
Index: ginac/add.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/add.cpp,v
retrieving revision 1.73
diff -r1.73 add.cpp
384a385,410
> ex add::conjugate() const
> {
> 	exvector *v = 0;
> 	for (int i=0; i<nops(); ++i) {
> 		if (v) {
> 			v->push_back(op(i).conjugate());
> 			continue;
> 		}
> 		ex term = op(i);
> 		ex ccterm = term.conjugate();
> 		if (are_ex_trivially_equal(term, ccterm))
> 			continue;
> 		v = new exvector;
> 		v->reserve(nops());
> 		for (int j=0; j<i; ++j)
> 			v->push_back(op(j));
> 		v->push_back(ccterm);
> 	}
> 	if (v) {
> 		ex result = add(*v);
> 		delete v;
> 		return result;
> 	}
> 	return *this;
> }
> 
Index: ginac/add.h
===================================================================
RCS file: /home/cvs/GiNaC/ginac/add.h,v
retrieving revision 1.43
diff -r1.43 add.h
59a60
> 	ex conjugate() const;

From chrisd at sci.kun.nl  Fri Jul  2 17:39:17 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Fri, 2 Jul 2004 15:39:17 +0000 (UTC)
Subject: yet another patch.
Message-ID: <Pine.LNX.4.44.0407021534250.6772-200000@gamow.sci.kun.nl>


Hello again,

I think it is not good that conjugate(some expression) returns a function
while (some expression).conjugate() returns an expression. This is
inconsistent to what users are used to with, say, expand(e) and
e.expand(). They will be surprised that

	conjugate(some expression).expand()

does not expand anything.

Bye,
Chris
-------------- next part --------------
Index: add.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/add.cpp,v
retrieving revision 1.73
diff -r1.73 add.cpp
384a385,410
> ex add::conjugate() const
> {
> 	exvector *v = 0;
> 	for (int i=0; i<nops(); ++i) {
> 		if (v) {
> 			v->push_back(op(i).conjugate());
> 			continue;
> 		}
> 		ex term = op(i);
> 		ex ccterm = term.conjugate();
> 		if (are_ex_trivially_equal(term, ccterm))
> 			continue;
> 		v = new exvector;
> 		v->reserve(nops());
> 		for (int j=0; j<i; ++j)
> 			v->push_back(op(j));
> 		v->push_back(ccterm);
> 	}
> 	if (v) {
> 		ex result = add(*v);
> 		delete v;
> 		return result;
> 	}
> 	return *this;
> }
> 
Index: add.h
===================================================================
RCS file: /home/cvs/GiNaC/ginac/add.h,v
retrieving revision 1.43
diff -r1.43 add.h
59a60
> 	ex conjugate() const;
Index: ex.h
===================================================================
RCS file: /home/cvs/GiNaC/ginac/ex.h,v
retrieving revision 1.76
diff -r1.76 ex.h
754a755,757
> inline ex conjugate(const ex & thisex)
> { return thisex.conjugate(); }
> 
Index: inifcns.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/inifcns.cpp,v
retrieving revision 1.75
diff -r1.75 inifcns.cpp
51c51
< 	return conjugate(arg).hold();
---
> 	return conjugate_function(arg).hold();
69c69
< REGISTER_FUNCTION(conjugate, eval_func(conjugate_eval).
---
> REGISTER_FUNCTION(conjugate_function, eval_func(conjugate_eval).
72c72,73
<                        conjugate_func(conjugate_conjugate));
---
>                        conjugate_func(conjugate_conjugate).
>                        set_name("conjugate","conjugate"));
Index: inifcns.h
===================================================================
RCS file: /home/cvs/GiNaC/ginac/inifcns.h,v
retrieving revision 1.46
diff -r1.46 inifcns.h
32c32
< DECLARE_FUNCTION_1P(conjugate)
---
> DECLARE_FUNCTION_1P(conjugate_function)
Index: symbol.cpp
===================================================================
RCS file: /home/cvs/GiNaC/ginac/symbol.cpp,v
retrieving revision 1.55
diff -r1.55 symbol.cpp
227c227
< 		return GiNaC::conjugate(*this).hold();
---
> 		return GiNaC::conjugate_function(*this).hold();

From chrisd at sci.kun.nl  Fri Jul  2 20:22:24 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Fri, 2 Jul 2004 18:22:24 +0000 (UTC)
Subject: yet another patch.
Message-ID: <Pine.LNX.4.44.0407021815450.3856-100000@gamow.sci.kun.nl>


Dear GiNaCers,

Could you change the line

	return clifford(e, varidx(0, dim), rl);

that occurs in the function dirac_slash into

	return clifford(e, varidx(0, dim), default_metric(), rl);

for correct constructor invocation. Thanks!

Best,
Chris



From ralf at ark.in-berlin.de  Fri Jul  2 17:24:48 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Fri, 2 Jul 2004 17:24:48 +0200
Subject: content() inconsistencies
Message-ID: <20040702172448.A12787@ark.in-berlin.de>

> >   cout << (10*x/2+ex(15)/3).content(x) << endl;
> 
> But that's 5x+5...?

Oh well... yes. 15x/2+25/3 would be solved correctly by Pari.

> Anyway, content() and primpart() in GiNaC currently only work correctly for
> polynomials in Z[x]. But your Pari results are correct. The content of a
> polynomial in Q[x] should be calculated in a way that the primitive part is
> a polynomial in Z[x] with content 1.

While going through the loop computing the gcd of the coeff numerators,
one would simultaneously collect the lcm of the denominators, numeric
or otherwise, with the end result gcd divided by lcm.

I'm quite satisfied with the following patch. YMMV.
The outcommented code was rather obscure to me.

Thanks,
ralf

--- GiNaC-1.2.1-orig/ginac/normal.cpp	Thu Jan  8 16:06:50 2004
+++ GiNaC-1.2.1/ginac/normal.cpp	Fri Jul  2 16:51:17 2004
@@ -851,21 +851,25 @@
 		return _ex0;
 
 	// First, try the integer content
-	ex c = e.integer_content();
-	ex r = e / c;
-	ex lcoeff = r.lcoeff(x);
-	if (lcoeff.info(info_flags::integer))
-		return c;
+//	ex c = e.integer_content();
+//	ex r = e / c;
+//	ex lcoeff = r.lcoeff(x);
+//	if (lcoeff.info(info_flags::integer))
+//		return c;
 
 	// GCD of all coefficients
 	int deg = e.degree(x);
 	int ldeg = e.ldegree(x);
 	if (deg == ldeg)
 		return e.lcoeff(x) / e.unit(x);
-	c = _ex0;
+	ex c = _ex0, l = 1;
 	for (int i=ldeg; i<=deg; i++)
-		c = gcd(e.coeff(x, i), c, NULL, NULL, false);
-	return c;
+  {
+    const ex& t = e.coeff(x,i).numer_denom();
+		c = gcd(t[0], c, NULL, NULL, false);
+    l = lcm(t[1], l);
+  }
+	return c/l;
 }
 
 


From ralf at ark.in-berlin.de  Sat Jul 10 11:50:39 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Sat, 10 Jul 2004 11:50:39 +0200
Subject: strange bug
Message-ID: <20040710115039.A10193@ark.in-berlin.de>

Hello,
the following program dumps core here.

#include <iostream>
#include <ginac/ginac.h>
using namespace std;
using namespace GiNaC;

int main()
{
  symbol x("x");

  ex e = (ex(1)/x).numer_denom();
  e = e[0];
  cerr << e; 
}

But it outputs 1 as it should if I replace the last two lines with
cerr << e[0];

I don't even understand the difference!


Thanks for your time,
ralf



From ralf at ark.in-berlin.de  Sat Jul 10 19:00:18 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Sat, 10 Jul 2004 19:00:18 +0200
Subject: index an ex? Re: strange bug
In-Reply-To: <20040710115039.A10193@ark.in-berlin.de>; from ralf@ark.in-berlin.de on Sat, Jul 10, 2004 at 11:50:39AM +0200
References: <20040710115039.A10193@ark.in-berlin.de>
Message-ID: <20040710190018.A9845@ark.in-berlin.de>

>   ex e = (ex(1)/x).numer_denom();
>   e = e[0];

Should it be allowed at all to index an ex? I believe what happens is that
indexing through [] gets compiled to a call to operator*() which may
not always be intended. I have encountered here another bug that was
nearly untraceable with gdb but went away when I replaced e[0] with
e.op(0).


Just FYI,
ralf



From Christian.Bauer at Uni-Mainz.DE  Mon Jul 12 18:09:14 2004
From: Christian.Bauer at Uni-Mainz.DE (Christian Bauer)
Date: Mon, 12 Jul 2004 18:09:14 +0200
Subject: strange bug
In-Reply-To: <20040710115039.A10193@ark.in-berlin.de>
References: <20040710115039.A10193@ark.in-berlin.de>
Message-ID: <20040712160913.GH2712@thep.physik.uni-mainz.de>

Hi!

On Sat, Jul 10, 2004 at 11:50:39AM +0200, Ralf Stephan wrote:
>   e = e[0];

It's better to use op() here because ex::operator[] on a non-const object
calls let_op() which is a more expensive operation.

Anyway, it shouldn't crash (and it doesn't do that here, even with efence).
A gdb backtrace would be nice.

Bye,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/


From ralf at ark.in-berlin.de  Tue Jul 13 16:42:42 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Tue, 13 Jul 2004 16:42:42 +0200
Subject: strange bug
In-Reply-To: <20040712160913.GH2712@thep.physik.uni-mainz.de>; from Christian.Bauer@Uni-Mainz.DE on Mon, Jul 12, 2004 at 06:09:14PM +0200
References: <20040710115039.A10193@ark.in-berlin.de> <20040712160913.GH2712@thep.physik.uni-mainz.de>
Message-ID: <20040713164242.A3407@ark.in-berlin.de>


> Anyway, it shouldn't crash (and it doesn't do that here, even with efence).
> A gdb backtrace would be nice.


GNU gdb 6.1.1
...
(gdb) r
Starting program: /home/ralf/ginac/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x0fdf1dcc in GiNaC::ex::print (this=0x50, c=@0x7ffff6a0, level=0) at ptr.h:92
92		T *operator->() const throw() { return p; }
(gdb) bt
#0  0x0fdf1dcc in GiNaC::ex::print (this=0x50, c=@0x7ffff6a0, level=0)
    at ptr.h:92
#1  0x0fec40cc in GiNaC::operator<< (os=@0x100132d0, e=@0x7ffff700)
    at operators.cpp:346
#2  0x10002188 in main () at bug3.cpp:12


ralf
-- 
Fight those communist terrorists that try to replace a thriving commercial 
market (open source) with a state-supported monopoly (MS)!



From ralf at ark.in-berlin.de  Thu Jul 15 15:18:01 2004
From: ralf at ark.in-berlin.de (Ralf Stephan)
Date: Thu, 15 Jul 2004 15:18:01 +0200
Subject: strange bug
In-Reply-To: <20040713164242.A3407@ark.in-berlin.de>; from ralf@ark.in-berlin.de on Tue, Jul 13, 2004 at 04:42:42PM +0200
References: <20040710115039.A10193@ark.in-berlin.de> <20040712160913.GH2712@thep.physik.uni-mainz.de> <20040713164242.A3407@ark.in-berlin.de>
Message-ID: <20040715151801.A1262@ark.in-berlin.de>

I've traced it to a point where stack corruption occurs; somewhere
in the printing line, operator= on the smart pointer is called, and
the chaos appears while executing 'delete p' in that function:

#0  __gnu_cxx::__exchange_and_add (__mem=0x100176f0, __val=-1)
    at atomicity.cc:55
#1  0x0ff43880 in ~symbol (this=0x10017588) at basic_string.h:215
#2  0x0ff09098 in std::_List_base<GiNaC::ex, std::allocator<GiNaC::ex> >::_M_clear (this=0x10017588) at ptr.h:78
#3  0x0ff090e0 in ~container (this=0x100177e8) at stl_list.h:328
#4  0x10002aec in GiNaC::ptr<GiNaC::basic>::operator= (this=0x40001, 
    other=@0x11) at ptr.h:86
#5  0x1000281c in GiNaC::ex::operator= (this=0x10013238, _ctor_arg=@0x10017858)
    at matrix.h:107
#6  0x100021ec in main () at bug3.cpp:13

Note the func arguments in frame 4. Note also that they were intact when
starting the destructor. Finally, this is not the point where the main 
ex is overwritten causing segv but earlier. 

I cannot rule out a libstdc++ bug in the (newly installed) version 
of g++ 3.4. Can you test that?


ralf



From Christian.Bauer at uni-mainz.de  Sun Jul 18 15:04:03 2004
From: Christian.Bauer at uni-mainz.de (Christian Bauer)
Date: Sun Jul 18 15:04:03 2004
Subject: [GiNaC-devel] Majordomo is dead, long live Mailman!
Message-ID: <20040718130318.GF2722@thep.physik.uni-mainz.de>

Hello!

The GiNaC mailing lists are now running under the Mailman mailing list
software.

You should have received an Email with your personal subscription password
and some instructions on how to change your subscription settings and how to
unsubscribe.

To fend off spam, only subscribed members can post to the lists now. If you
are using multiple Email addresses for posting, you can subscribe all of
them, and set all except one to "nomail" on the subscription options page,
so you won't get duplicate messages.

The list archives have been preserved and can be accessed here:
  http://thep.physik.uni-mainz.de/pipermail/ginac-list/
  http://thep.physik.uni-mainz.de/pipermail/ginac-devel/

Have fun,
Christian

-- 
  / Physics is an algorithm
\/ http://www.uni-mainz.de/~bauec002/