- GiNaC-devel - ginac.de

problem with dbgprint.
by Chris Dams 06 Oct '04

06 Oct '04

Dear all, I found out that the program #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(int argc, char** argv) { symbol x("x"); ex_to<power>(x*x).dbgprint(); return 0; } gives the output [power object] This is because in basic::dbgprint a print_context is constructed from std::cerr and not a print_dflt. Changing, in basic::dbgprint, the line this->print(std::cerr); into this->print(print_dflt(std::cerr)); solves this problem. Now the output is x^2 as expected. Best, Chris

3 3

segmentation fault in substituting.
by Chris Dams 30 Sep '04

30 Sep '04

Dear GiNaCers, I found that basic::subs_one_level sometimes gives a segementation fault. This is because the branch that takes care of the no_pattern option, tries to find *this in the exmap that contains the substitution. This invokes the construction of a temporary ex from *this. If it turns out that .eval() wants to change the ex in something else, the this pointer is going to be deleted, because, presumably, it was allocated with the dynallocated flag set, by basic::subs. If no substitution is found, it is tried to return the just deleted this pointer. Not a good idea... I suggest the change below in the basic::subs_one_level function in basic.cpp. *************** *** 603,611 **** exmap::const_iterator it; if (options & subs_options::no_pattern) { ! it = m.find(*this); if (it != m.end()) return it->second; } else { for (it = m.begin(); it != m.end(); ++it) { lst repl_lst; --- 617,627 ---- exmap::const_iterator it; if (options & subs_options::no_pattern) { ! ex thisex=*this; ! it = m.find(thisex); if (it != m.end()) return it->second; + return thisex; } else { for (it = m.begin(); it != m.end(); ++it) { lst repl_lst; Best, Chris

2 2

(no subject)
by Vladimir Kisil 26 Sep '04

26 Sep '04

Dear All, I wish to propose a further patches for clifford.cpp and clifford.h. Its make: 1. Fixes a nasty behaviour when a simplification creates nested indexed objects like (eta.psi.xi).nu.mu. 2. Contains two new functions described in the clifford.h. Hope they will be useful, at least I employ them to create some graphics of conformal maps already. 3. Other bits are small improvements and spaces fixed. I hope to contribute some documentation for expanded clifford.cpp as well. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ Index: ginac/clifford.h =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.h,v retrieving revision 1.51 diff -r1.51 clifford.h 278c278 < ex delete_ONE(const ex &e); --- > ex delete_ONE(const ex & e); 294a295,318 > /** An inverse function to lst_to_clifford(). For given Clifford vector extracts > * its components with respect to given Clifford unit. Obtained components may > * contain Clifford units with a different metric. Extraction is based on > * the algebraic formula (e * c.i + c.i * e)/ pow(e.i, 2) for non-degenerate cases > * (i.e. neither pow(e.i, 2) = 0). > * > * @param e Clifford expresion to be decomposed into components > * @param c Clifford unit defining the metric for splitting (should have numeric dimension of indices) > * @param algebraic Use algebraic or symbolic algorythm for extractions */ > lst clifford_to_lst(const ex & e, const ex & c, bool algebraic=true); > > /** Calculations of Moebius transformations (conformal map) defined by a 2x2 Clifford matrix > * (a b\\c d) in linear spaces with arbitrary signature. The expression is > * (a * x + b)/(c * x + d), where x is a vector buid from list v with metric G. > * (see Jan Cnops. An introduction to {D}irac operators on manifolds, v.24 of > * Progress in Mathematical Physics. Birkhauser Boston Inc., Boston, MA, 2002.) > * > * @param a (1,1) entry of the defining matrix > * @param b (1,2) entry of the defining matrix > * @param c (2,1) entry of the defining matrix > * @param d (2,2) entry of the defining matrix > * @param v Vector to be transformed > * @param G Metric of the surrounding space */ > ex moebius(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G); Index: ginac/clifford.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/clifford.cpp,v retrieving revision 1.79 diff -r1.79 clifford.cpp 680c680,685 < return clifford(unit, mu, metr, rl); --- > if (is_a<indexed>(metr)) > return clifford(unit, mu, metr.op(0), rl); > else if(is_a<tensmetric>(metr) || is_a<matrix>(metr)) > return clifford(unit, mu, metr, rl); > else > throw(std::invalid_argument("metric for Clifford unit must be of type indexed, tensormetric or matrix")); 990c995 < ex clifford_prime(const ex &e) --- > ex clifford_prime(const ex & e) 1005c1010 < ex delete_ONE(const ex &e) --- > ex delete_ONE(const ex & e) 1022c1027 < ex clifford_norm(const ex &e) --- > ex clifford_norm(const ex & e) 1024c1029 < return sqrt(delete_ONE((e * clifford_bar(e)).simplify_indexed())); --- > return sqrt(delete_ONE(canonicalize_clifford(e * clifford_bar(e)).simplify_indexed())); 1027c1032 < ex clifford_inverse(const ex &e) --- > ex clifford_inverse(const ex & e) 1031a1037,1038 > else > throw(std::invalid_argument("Cannot find inverse of Clifford number with zero norm!")); 1068a1076,1158 > /** Auxiliary structure to define a function for striping one Clifford unit > * from vectors. Used in clifford_to_lst(). */ > ex get_clifford_comp(const ex & e, const ex & c) > { > pointer_to_map_function_1arg<const ex &> fcn(get_clifford_comp, c); > > if (is_a<add>(e)) > return e.map(fcn); > else if (is_a<ncmul>(e) || is_a<mul>(e)) { > //find a Clifford unit with the same metric, delete it and substitute its index > size_t ind = e.nops() + 1; > for (size_t j = 0; j < e.nops(); j++) > if (is_a<clifford>(e.op(j)) && ex_to<clifford>(c).same_metric(e.op(j))) > if (ind > e.nops()) > ind = j; > else > throw(std::invalid_argument("Expression is a Clifford multi-vector")); > if (ind < e.nops()) { > ex S = 1; > for(size_t j=0; j < e.nops(); j++) > if (j != ind) { > exvector ind_vec = ex_to<indexed>(e.op(j)).get_dummy_indices(ex_to<indexed>(e.op(ind))); > if (ind_vec.size() > 0) { > exvector::const_iterator it = ind_vec.begin(), itend = ind_vec.end(); > while (it != itend) { > S = S * e.op(j).subs(ex_to<varidx>(*it) == ex_to<idx>(c.op(1)).get_value()); > it++; > } > } else > S = S * e.op(j); > } > return S; > } else > throw(std::invalid_argument("Expression is not a Clifford vector to the given units")); > } else { > throw(std::invalid_argument("Expression is not handlable as a Clifford vector")); > } > } > > > lst clifford_to_lst (const ex & e, const ex & c, bool algebraic) > { > GINAC_ASSERT(is_a<clifford>(c)); > varidx mu = ex_to<varidx>(c.op(1)); > if (! mu.is_dim_numeric()) > throw(std::invalid_argument("Index should have a numeric dimension")); > unsigned int D = ex_to<numeric>(mu.get_dim()).to_int(); > > if (algebraic) // check if algebraic method is applicable > for (unsigned int i = 0; i < D; i++) > if (pow(c.subs(mu == i), 2) == 0) > algebraic = false; > lst V; > if (algebraic) > for (unsigned int i = 0; i < D; i++) > V.append(delete_ONE(simplify_indexed(canonicalize_clifford(e * c.subs(mu == i) + c.subs(mu == i) * e))/(2*pow(c.subs(mu == i), 2)))); > else { > ex e1 = canonicalize_clifford(e); > for (unsigned int i = 0; i < D; i++) > V.append(get_clifford_comp(e1, c.subs(c.op(1) == i))); > } > return V; > } > > > ex moebius(const ex & a, const ex & b, const ex & c, const ex & d, const ex & v, const ex & G) > { > ex x, D; > if (is_a<indexed>(G)) > D = ex_to<varidx>(G.op(1)); > else > throw(std::invalid_argument("metric should be an indexed object")); > > varidx mu ((new symbol)->setflag(status_flags::dynallocated), ex_to<varidx>(D).get_dim()); > > if (! is_a<matrix>(v) && ! is_a<lst>(v)) > throw(std::invalid_argument("parameter v should be either vector or list")); > > x = lst_to_clifford(v, mu, G); > ex e = simplify_indexed(canonicalize_clifford((a * x + b) * clifford_inverse(c * x + d))); > ex cu = clifford_unit(mu, G); > return clifford_to_lst(e, cu); > }

1 0

patch for power
by Chris Dams 24 Sep '04

24 Sep '04

Dear all, I found that the program #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(int argc, char** argv) { symbol x("x"),y("y"); ex e=sin(x)*sin(x); if(e.info(info_flags::polynomial)) cout << e << " is polynomial" << endl; else cout << e << " is not polynomial" << endl; e=sin(x)*sin(y); if(e.info(info_flags::polynomial)) cout << e << " is polynomial" << endl; else cout << e << " is not polynomial" << endl; return 0; } gives the output sin(x)^2 is polynomial sin(x)*sin(y) is not polynomial which I find very awkward. The attached patch unpolynomializes sin(x)^2. Best, Chris

2 1

GiNaC-1.2.3 and nestedsums-1.4.5 on Mac OS X
by Gregory Wright 07 Sep '04

07 Sep '04

Hi, Since Bruno Haible posted his patches to cln-1.1.8, it's built cleanly on Mac OS X, and allowed me to build GiNaC-1.2.3. On my machine, an 800 MHz tiBook running OS X 10.3.5, and using g++ 3.3 from Xcode 1.5, it passes all the tests in 'make check'. When I try to build nestedsums-1.4.5, I get build failures caused by the inability to adjust pointers in convariant returns: make all-recursive Making all in nestedsums if /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT root_of_unity.lo -MD -MP -MF ".deps/root_of_unity.Tpo" -c -o root_of_unity.lo root_of_unity.cc; \ then mv -f ".deps/root_of_unity.Tpo" ".deps/root_of_unity.Plo"; else rm -f ".deps/root_of_unity.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/opt/local/include -I/opt/local/include -I/opt/local/include -I/opt/local/include -g -O2 -MT root_of_unity.lo -MD -MP -MF .deps/root_of_unity.Tpo -c root_of_unity.cc -fno-common -DPIC -o .libs/root_of_unity.o Euler_Zagier_sum.h:48: sorry, unimplemented: adjusting pointers for covariant returns Euler_Zagier_sum.h:48: sorry, unimplemented: adjusting pointers for covariant returns harmonic_sum.h:49: sorry, unimplemented: adjusting pointers for covariant returns harmonic_sum.h:49: sorry, unimplemented: adjusting pointers for covariant returns multiple_polylog.h:54: sorry, unimplemented: adjusting pointers for covariant returns multiple_polylog.h:54: sorry, unimplemented: adjusting pointers for covariant returns harmonic_polylog.h:50: sorry, unimplemented: adjusting pointers for covariant returns (There are more header files that it complains about; I can send the full output if you wish.) I emailed Stefan Weinzierl and he pointed out that this comes from the macros GINAC_DECLARE_REGISTERED_CLASS and GINAC_IMPLEMENT_REGISTERED_CLASS Two questions: 1. Is there a workaround for this? (Since I am trying to port xloops/nestedsums/GiNac/cln to the darwinports system, I would prefer no to have to add build another g++ compiler. I could, if absolutely necessary, do that.) 2. Why does this happen for the nestedsums library and not for GiNaC? Does GiNaC allow covariant returns but not actually use them? Any help is appreciated. Best Wishes, Greg Gregory Wright Antiope Associates gwright(a)antiope.com

2 1

Factoring, again (Factory)
by Ralf Stephan 24 Aug '04

24 Aug '04

Hello, my current work on partial fraction decomposition ultimately demands a working implementation of multivariate factoring and, therefore, I would like to refresh discussions about factoring in GiNaC, as there have been some developments since the last thread on it which was years ago[0]. "Singular is a Computer Algebra system for polynomial computations with emphasize on the special needs of commutative algebra, algebraic geometry, and singularity theory. [...]" That's the blurb about Singular[1], from their Readme and, guess, they even have multivar. factoring. Even better, the factoring module (named 'Factory') is independent from the rest, and can so be downloaded as C++ source[2]. From the Readme: "Factory is a C++ class library that implements a recursive representation of multivariate polynomial data. It is being developed by Ruediger Stobbe and Jens Schmidt at the University of Kaiserslautern as an independent and self-contained part of the computer algebra system Singular (developed by G.-M. Greuel, G. Pfister and H. Schoenemann). Factory handles sparse multivariate polynomials over different coefficient domains, such as Z, Q and GF(q), as well as algebraic extensions over Q and GF(q) in an efficient way. Factory includes algorithms for computing univariate and multivariate gcds, resultants, chinese remainders, and several algorithms to factorize univariate polynomials over the integers and over finite fields. Factorization of multivariate polynomials over the integers is in beta test stage. The interface to the polynomial system of Factory is provided by a single class `CanonicalForm' which can deal with elements of the coefficient domain as well as polynomials. Using operator overloading, you can handle polynomial data similarly to built-in types such as the machine integers. [...]" Factory optionally uses NTL for univariate factoring and GCD computation. Factory itself is used by another package within Singular that implements factoring over algebraic extensions and other algorithms, the name is libfac[3] by Michael Messollen. Both use the same recursive CanonicalForm. It immediately comes to mind that it should now be easy to get multivariate factoring for ginac. Just use NTL and those parts of Factory that are not already in ginac. Although there is another possibility (add Factory only) the Factory source says itself that NTL is faster. However, I see a third plan: if you already accept including another library then why not libpari? Univariate factoring in Pari is as fast as NTL, both use van Hoeij, and Pari has much more for the work, starting with a mature integer factoring package etc. All three mentioned packages are distributed under GPL. So, assuming I have summarized the situation correctly, which way? My other question is a plea: does anyone of you have a good overview over what is to do algorithmically to get multivariate factoring, given an existing univariate implementation? I'm not at a university but I'd shell out the EUR 8 at Subito for a copy of a good introductory or review article. So, please send refs/results to me or to the list. Thanks for your time. Sincerely, ralf [0] http://thep.physik.uni-mainz.de/pipermail/ginac-devel/2001-July/000270.html [1] http://www.singular.uni-kl.de [2] ftp://www.mathematik.uni-kl.de/pub/Math/Singular/SOURCES/Singular-factory-2-0-5.tar.gz [3] ftp://www.mathematik.uni-kl.de/pub/Math/Singular/SOURCES/Singular-libfac-2-0-5.tar.gz

4 4

GiNaC 1.2.3
by Jens Vollinga 13 Aug '04

13 Aug '04

Hi, GiNaC 1.2.3 is out and available. The changes are: - improved handling of dirac / color algebra - fixed bug in series expansion of powers - fixed and improved configuration of documentation building As always, this release can be downloaded from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Enjoy, Jens

1 0

strange bug
by Ralf Stephan 11 Aug '04

11 Aug '04

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

4 6

tutorial documentation and makeinfo --html
by Andrew Marshall 11 Aug '04

11 Aug '04

when GiNaC is configured with the --enable-html-doc option, make install fails. As far as I can tell, this is because the installation script is looking for ginac.html in the doc/tutorial directory, rather than the files in the doc/tutorial/ginac directory. regards, Andrew. ----------------------------- Andrew Marshall http://www.planetmarshall.co.uk _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

patch
by Chris Dams 02 Aug '04

02 Aug '04

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

3 4