- GiNaC-devel - ginac.de

Re: content() inconsistencies
by Ralf Stephan 02 Aug '04

02 Aug '04

> > 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; }

2 1

Majordomo is dead, long live Mailman!
by Christian Bauer 18 Jul '04

18 Jul '04

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/

1 0

yet another patch.
by Chris Dams 02 Jul '04

02 Jul '04

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

1 0

yet another patch.
by Chris Dams 02 Jul '04

02 Jul '04

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

1 0

patch for complex conj of additions.
by Chris Dams 02 Jul '04

02 Jul '04

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

1 0

content() inconsistencies
by Ralf Stephan 02 Jul '04

02 Jul '04

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

2 1

CLN 1.1.8 released
by Richard B. Kreckel 02 Jul '04

02 Jul '04

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(a)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/>

1 0

patch.
by Chris Dams 29 Jun '04

29 Jun '04

Dear GiNaCers, Could somebody change the line if (degsum>order) { that occurs in the function mul::series into if (degsum>=order) { for obvious reasons? Thanks. Best, Chris 3603 38th St. NW Suite 201 Washington, DC 20008

1 0

Writing bindings for C++ (template) libraries in Mathemagix (fwd)
by Richard B. Kreckel 25 Jun '04

25 Jun '04

Hi, I just received an email from Joris van der Hoeven. In case somebody wishes to give it a try. Have fun -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/> ---------- Forwarded message ---------- Date: Fri, 25 Jun 2004 16:45:34 +0200 (CEST) From: Joris van der Hoeven <vdhoeven(a)texmacs.org> To: mathemagix-devel(a)mathemagix.org Cc: kreckel(a)thep.physik.uni-mainz.de, haible(a)ilog.fr Subject: Writing bindings for C++ (template) libraries in Mathemagix Hi All, I am happy to announce that the new version 0.1.41 of Mathemagix (available from mathemagix.org) should allow you to easily glue C++ libraries as well as C++ template libraries to the interpreter. The main mechanism is as follows: from an abstract description of your library in a file like 'myglue.mmh' (see the examples provided in src/glue), the mmx-extend script automatically generates a C++ file which is compiled as a shared library 'mmx-myglue.so'. This library can be loaded dynamically into Mathemagix via 'use "myglue"'. Your library may also contain templates and the mmx-extend script *automatically* creates an extension of your library which enables you to use these templates in a generic way. I.e., having a template class "Matrix", you will typically be able to use matrices over matrices over matrices over integers. Moreover, this generic extension should imply only a minimal overhead. In the above matrix example, and as long as the operations on the scalars are implemented in your library, no re-entrant calls to Mathemagix are needed and operations are done quickly using some void* magic. The code has been (incompletely) tested together with several libraries (STL, Gmp, Synaps and Mmxlib) and contributions in this direction would be *very much* appreciated. Apart from completing the existing binding files, support for the following mathematical libraries would be nice: mpfr mpfi CLN NTL GiNaC Linbox libfactory CGAL etc. Further suggestions for interesting scientific libraries are welcome, the aim being to focus on incorporating as much existing software as possible before starting to write programs in Mathemagix itself. It would also be interesting to have bindings for libraries like gtk, qt, opengl, unicode, cryptography, etc. etc. Some shortcomings of the current implementation are as follows: * The GC garbage collector from Boehm seems to be bugged; it does not allow the use of dynamic libraries ;^( You may either configure Mathemagix using ./configure --disable-gc or add an additional section for your library in the current configure.in file, add your bindings to the src/glue directory and use static compilation. * It is only possible to import generic routines from Mathemagix. Such routines correspond to the operations you wish to perform on types which occur as template arguments (like the scalar type for matrices). It is not possible yet to import ordinary routines or types from Mathemagix. As a consequence, if you want to write bindings for several libraries, then you usually have to produce the glue for all of them together. From an efficiency point of view, this is better anyway. * The names of exported C++ classes and functions should be of the form "identifier" or "identifier<id1,...,idn>". Special syntactic forms for operations like "x.f", "x->f", "x::f", etc. are not provided yet. You may always add the necessary macros or code to the preamble though. * There may still be some bugs. Feedback on this is appreciated. Don't hesitate to ask further questions on this list. Any feedback is appreciated. Best wishes, Joris

1 0

cln::divisors()
by Ralf Stephan 22 Jun '04

22 Jun '04

The complete factor() patch was sent to Richy. Should the divisors be sorted? Do we leave that to the client? Can someone tell me why gcc barfs when I declare f const? vector<cl_I> divisors(const cl_I& n) { cl_FEV f = factor(n); vector<long> v(f.size()); vector<cl_I> res; res.push_back(1); while (true) { vector<long>::iterator vit = v.begin(); cl_FEV::iterator fit = f.begin(); while (*vit == (*fit)->exp) { *vit = 0; if (++vit == v.end()) return res; ++fit; } cl_I prod = expt_pos((*fit)->fact, ++(*vit)); ++vit; ++fit; while (vit != v.end()) { if (*vit > 0) prod = prod * expt_pos((*fit)->fact, *vit); ++vit; ++fit; } res.push_back(prod); } } ralf

1 1