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: 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: References: 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: 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: 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 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] [1] -- Richard B. 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: 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 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 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: 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 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 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: 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 #include 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 >::_M_clear (this=0x10017588) at ptr.h:78 #3 0x0ff090e0 in ~container (this=0x100177e8) at stl_list.h:328 #4 0x10002aec in GiNaC::ptr::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/