July 2005 - GiNaC-list

print_csrc, print_csrc_double... how to use?
by John Pye 25 Jul '05

25 Jul '05

Hi all Probably a silly question here. I'm trying to work out how to use the 'print_csrc' functionality in GiNaC. I don't seem to be able to make it work. Please could someone offer me some suggestions on how to fix the following? > [xxx@xxx nla-ginac]$ cat print.cpp > #include <ginac/ginac.h> > #include <iostream> > > using namespace GiNaC; > > int main(){ > symbol x("x"); > ex f = log(pow(x,2)); > print_csrc(std::cout); > std::cout << f << std::endl; > } > > [xxx@xxx nla-ginac]$ g++ print.cpp -lginac -lcln > [xxx@xxx nla-ginac]$ ./a.out > *log(x^2)* Notice that it's outputing 'x^2' and not 'pow(x,2)' or 'x*x'. It seems that the print_csrc call isn't doing anything. What am I doing wrong? Cheers, JP -- John Pye School of Mechanical and Manufacturing Engineering The University of New South Wales Sydney NSW 2052 Australia t +61 2 9385 5127 f +61 2 9663 1222 mailto:john.pye_AT_student_DOT_unsw.edu.au http://pye.dyndns.org/

2 1

Checking consistency of units in GiNaC
by John Pye 21 Jul '05

21 Jul '05

Hi all, Has anyone tried to add *units-of-measurement checking* to GiNaC? I have some nice unit-checking code here as part of the freesteam project, http://pye.dyndns.org/freesteam/docs/class_units.html This class prevents things like "1 * bar + 3 * kg", and also ensures validity of things like "Density rho = 5 * kg / (2 * metre2)" This units class could conceivably be extended to pass through expressions rather than simple numerical results, but operations like differentiation might need to become units-savvy I suspect. Does anyone have any comments on the advisability / feasibility of trying to do this, or have any references I should follow up relating to other people attempting this? Cheers JP -- John Pye School of Mechanical and Manufacturing Engineering The University of New South Wales Sydney NSW 2052 Australia t +61 2 9385 5127 f +61 2 9663 1222 mailto:john.pye_AT_student_DOT_unsw.edu.au http://pye.dyndns.org/

2 1

[PATCH] simpler debian/*
by varg＠theor.jinr.ru 21 Jul '05

21 Jul '05

Here is yet another patch. This ought to be in the ChangeLog: * provide -dbg package (unstripped shared object with debugging symbols) * switch to CDBS, so debian/rules is *much* simpler Best regards, Alexei -- ROOT: an octopus made by nailing extra legs onto a cat.

2 3

Advertisement for GiNaC
by Chris Dams 19 Jul '05

19 Jul '05

Dear developers, At the moment I am finishing my PhD-thesis. The interesting thing about the promotion regulations at my university is that it allows PhD-theses to contain two pages for advertisement. I thought it was a good idea to spend such a page on the greatest computer algebra library that I know. So, you have an opportunity to get some free publicity ;-). You can find the page on http://www.theorphys.science.ru.nl/people/dams/ginacpage.ps . My questions: do you have a vector image of the logo? Do you have some other suggestions for the text? Now I have just cutted and pasted the text of the webpage. Best wishes, Chris

2 2

Re: [GiNaC-list] Question
by Vladimir V. Kisil 18 Jul '05

18 Jul '05

Hi, >>>>> "JRG" == Javier Ros Ganuza <jros(a)unavarra.es> writes: JRG> I want to do algebra with cartesian (3x1) "vectors". Cartesian JRG> "vector"s are to be represented by a 3x1 Ginac vector (3-tuple) JRG> and a reference to a basis that tell us in which base the JRG> components have physical sense. Extension of GiNaC classes is not very difficult and you may implement from scratch. However it may be better to do this through the Clifford algebras in GiNaC. There are many references (e.g. books of Hestenes) on doing geometry with Clifford algebras. JRG> for example (in my particular jargon): JRG> vector1.expresion=matrix(3,1,lst(a1,b1,c1)); JRG> vector1.basis=basis_k; JRG> vector2.expresion=matrix(3,1,lst(a2,b2,c2)); JRG> vector1.basis=basis_l; This can be implemented as follows: varidx nu(symbol("nu", "\\nu"), 3), mu(symbol("mu", "\\mu"), 3); xi(symbol("xi", "\\xi"), 3), rho(symbol("rho", "\\rho"),3); basis1 = clifford_unit(mu, diag_matrix(lst(1, 1, 1))); basis2 = clifford_unit(nu, diag_matrix(lst(1, 1, 1))); vector1 = lst_to_clifford(lst(a1,b1,c1), xi, basis1); vector2 = lst_to_clifford(lst(a1,b1,c1), rho, basis2); Then the expression JRG> result=2*vector1+vector2; will be well defined and behave as expected even without reduction to the single basis. The reduction is needed only if someone try to extract its components in either basis1, basis2, or even another basis3. To this end values of all products like basis1[i]*basis2[j] (i.e. transition matrix) should be defined. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

5 9

Re: GiNaC 1.3.1
by Chris Dams 13 Jul '05

13 Jul '05

Dear Jens, You wrote: > - Fixed a library initialization problem. Why do you think so? The safety suggested by the library_init class is still nothing more than a sham. Best wishes, Chris

3 13

matrix::solve(): how to use?
by mdias＠ift.unesp.br 12 Jul '05

12 Jul '05

Hi guys, I am tryng to solve a linear system with lsove(), with many variables being zero, so lsolve() tell that is indeterminate, but some of these entries are of interest. So, I am looking for matrix::solve and construct a matrix to solve this. Somebody have a piece of code how to make a linear system a matrix to matrix::solve ? Thanks, Marco

4 3

GiNaC 1.3.2 release
by Jens Vollinga 11 Jul '05

11 Jul '05

Hi, GiNaC 1.3.2 is out and available. The changes are: - GCD avoids to produce expanded expressions. - Fixed bug in expanding expressions containing dummy indices. - Fixed static initialization order bug. - collect_common_factors now works with powers. - Modernized configuration scripts. Thanks to all the contributers, especially C.Dams, V.Kisil and A.Sheplyakov. As always, this release can be downloaded from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Enjoy, Jens Vollinga

1 0

[PATCH] small improvements of gcd and collect_common_factors
by varg＠theor.jinr.ru 08 Jul '05

08 Jul '05

Hello! collect_common_factors does not work with powers, e.g. (in ginsh) > collect_common_factors((a*x+a*y)^2); (a*x+a*y)^2 I don't like such a behaviour, so I made the patch. With that patch, the above code actually works: > collect_common_factors((a*x+a*y)^2); a^2*(y+x)^2 To guarantee mathematical correctness, this transformation is applied to polynomial expressions only: > collect_common_factors((a*x+a*y)^n); (a*x+a*y)^n Apart from collect_common_factors hack, this patch somewhat improves worst-case performance of gcd and sr_gcd. Best regards, Alexei -- ROOT: an octopus made by nailing extra legs onto a cat.

2 3