April 2001 - GiNaC-devel

polynomial arithmetic over ginac
by Parisse Bernard 23 May '01

23 May '01

I have now a little bit improved the package of my polynomial and rational fractions utilities over GiNaC (0.6.4) It provides now gcd normalization, factor (square-free and rational roots), partfrac & integrate (assuming factor works on the denominator), for example: integrate '1/(x^4-1)^5' returns -1155/8192*log(1+x)-1155/4096*atan(x)+1155/8192*log(-1+x)+1/2048*(-893*x-1375*x^9+1755*x^5+385*x^13)*(-1+x^4)^(-4) # Time for (integrate)0.04 You can retrieve and test it at ftp://fourier.ujf-grenoble.fr/pub/hp48/giac.tgz Bye, Bernard Parisse

4 9

Wishlist (relational, pseries, matrix)
by Pearu Peterson 07 May '01

07 May '01

Hi! I have been working with GiNaC's interface to Python for some time now and I have collected the following notes that I have found important in this kind of applications: 1) Having relational::get_operator() would be useful (read: necessary) for extensions that can perform symbolic operations like (a < b) && (b > a) -> a < b 2) If a,b are compatible pseries then ex(a) * ex(b) would automatically produce ex(a.mul_series(b)) The same for operations +,-,scalar_mul,scalar_div. If a,b are incompatible, then apply current behaviour (that is, do nothing). I have implemented this behaviour in the GiNaC->Python interface but it does not cover cases where multiplication is carried out inside GiNaC functions. I am thinking of applications where, for example, a matrix consists of compatible pseries and the task is to find its inverse. 3) If a,b are compatible matrices (for a given operation) then ex(a) * ex(b) -> ex(a.mul(b)) The same for operations +,-,scalar_mul,scalar_div. That's all for now. Regards, Pearu

2 2

version 0.8.2 again ginsh compile broken with libreadline4 in Debian?
by Julian Stoev 25 Apr '01

25 Apr '01

Here are the compiler messages: make[2]: Entering directory `/var/tmp/GiNaC-0.8.2/ginsh' sed -n -f ./ginsh_fcn_help.sed <ginsh.1 >ginsh_fcn_help.c sed -n -f ./ginsh_op_help.sed <ginsh.1 >ginsh_op_help.c c++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac -DIN_GINAC -g -O2 -c ginsh_parser.cc In file included from /usr/include/readline/keymaps.h:37, from /usr/include/readline/readline.h:37, from ginsh.h:36, from ginsh_parser.yy:41: /usr/include/readline/rltypedefs.h:48: invalid exception specifications /usr/include/readline/rltypedefs.h:51: invalid exception specifications /usr/include/readline/rltypedefs.h:52: invalid exception specifications /usr/include/readline/rltypedefs.h:54: invalid exception specifications /usr/include/readline/rltypedefs.h:55: invalid exception specifications /usr/include/readline/rltypedefs.h:57: invalid exception specifications /usr/include/readline/rltypedefs.h:59: invalid exception specifications /usr/include/readline/rltypedefs.h:62: invalid exception specifications /usr/include/readline/rltypedefs.h:65: invalid exception specifications /usr/include/readline/rltypedefs.h:70: invalid exception specifications /usr/include/readline/rltypedefs.h:73: invalid exception specifications /usr/include/readline/rltypedefs.h:75: invalid exception specifications /usr/include/readline/rltypedefs.h:76: invalid exception specifications /usr/include/readline/rltypedefs.h:78: invalid exception specifications /usr/include/readline/rltypedefs.h:79: invalid exception specifications /usr/include/readline/rltypedefs.h:80: invalid exception specifications /usr/include/readline/rltypedefs.h:81: invalid exception specifications In file included from /usr/include/readline/readline.h:38, from ginsh.h:36, from ginsh_parser.yy:41: /usr/include/readline/tilde.h:55: invalid exception specifications ginsh_parser.yy: In function `char ** fcn_completion(char *, int, int)': ginsh_parser.yy:705: `filename_completion_function' undeclared (first use this function) ginsh_parser.yy:705: (Each undeclared identifier is reported only once ginsh_parser.yy:705: for each function it appears in.) ginsh_parser.yy:705: implicit declaration of function `int completion_matches(...)' ginsh_parser.yy:711: return to `char **' from `int' lacks a cast ginsh_parser.yy: In function `int main(int, char **)': ginsh_parser.yy:777: assignment to `char *' from `const char *' discards qualifiers make[2]: *** [ginsh_parser.o] Error 1 make[2]: Leaving directory `/var/tmp/GiNaC-0.8.2/ginsh' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/GiNaC-0.8.2' make: *** [all-recursive-am] Error 2 When I compile ginac without ginsh, it compiles fine. --JS

2 3

ginsh broken with libreadline4 in Debian?
by Julian Stoev 24 Apr '01

24 Apr '01

I can not compile ginsh on Debian unstable. I can not cut/paste the compile messages right now, but it would be interesting if somebody compiled it on Debian unstable (libreadline4). --JS

2 1

Version 0.8.2...
by Richard B. Kreckel 24 Apr '01

24 Apr '01

...claims to feature the following new stuff: * degree(), ldegree(), coeff(), lcoeff(), tcoeff() and collect() work with non-symbols as the second argument in ginsh. * the argument to collect() can be a list of objects in which case the result is either a recursively collected polynomial, or a polynomial in a distributed form with terms like coeff*x1^e1*...*xn^en, as specified by the second argument to collect(). * Several bugfixes (including a nasty memory leak in .normal()). * class matrix: solve() doesn't call algorithms redundantly any more and inverse() falls back to solve() which works in more general cases. Enjoy -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Algebra of differential operators
by Will Woods 19 Apr '01

19 Apr '01

Hi, I am working on a problem that requires manipulation and differentiation of large numbers of Lie derivative operators, followed by collecting coefficients of like orders of the operators. Since Ginac does not currently seem to be able to handle this, I have added a (fairly horrible) hack to the Symbol class to to make a Symbol behave as a differential operator under certain circumstances. In outline, what I did was: If the label for a newly defined symbol is "D" then give that symbol a fixed serial number which is identical for every operator defined. For symbols which are operators, keep track of the symbols with respect to which it is differentiating in an ordered vector. Symbols passed to the derivative method are inserted into the vector. Modified the compare_same_type method so that two operator symbols are compared by comparing the contents of their associated vectors of symbols. Modified the printing to print out something like 'D[x x y]' for a third order operator. Limitations: Currently the operators do not 'act' on anything - I assume this would require modification of the mult class and carefull consideration of ordering in expressions. I don't need this functionality, so I haven't looked into it. It may well be much better to have a new class derived from Symbol, but I'm new to Ginac (and was in a hurry!) and wasn't sure what this would do to comparisons between Symbols and Operators, so I went the 'quick and dirty' route. I think perhaps the general concept may be of use to other people, but my modifications are far to sloppy to be incorporated into the main code. I would be interested to know what other people think about the general idea of extending Ginac properly in this direction. Regards, Will

2 1

The easter release 0.8.1 has finally landed.
by Richard B. Kreckel 16 Apr '01

16 Apr '01

Hello all, Now let's quickly start finding all those easter eggs that Christian has promised to stuff into the code! This is what's documented in the NEWS file: * degree(), ldegree(), coeff(), lcoeff(), tcoeff() and collect() can now be used with constants, functions and indexed expressions as well, so you can use it to collect by powers of Pi or sin(x), or to find the coefficient of gamma~0. Limitations: - it only works with symbols, constants, functions and indexed expressions, trying to find the coefficient of, e.g., "x^2" or "x+y" won't work; - it does not know about dummy index summations; the coefficient of gamma~0 in p.mu*gamma~mu should be p.0 but is returned as 0; - using coeff(), tcoeff(), lcoeff() or collect() on elements of noncommutative products might return wrong or surprising results. * subs() no longer only substitutes symbols and indices but performs a more general "syntactic substitution", i.e. it substitutes whole objects in sub- expressions. You can subs((a+b)^2,a+b==3) and get 9, but subs(a+b+c,a+b==3) doesn't do anything. Limitations: - substituting numerics (subs(expr, 2==4)) will not replace then in all occurences; in general, you shouldn't substitute numerics, though. * Added preliminary (re)implementations of color and clifford classes. * simplify_indexed(): contraction of symmetric and antisymmetric tensors is zero. * Replaced the various print*() member functions by a single print() that takes a print_context object that determines the output formatting. This should make it easier to add more output types, such as LaTeX output, which is based on work by Stefan Weinzierl. * Added functions to retrieve the properties stored in archive objects outside of unarchive() (for printing or debugging purposes). * Some bugfixes (indexed objects, archive writing). * .collect() on non-polynomials is now algebraically correct. Happy hacking -richy. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0

Re: collect() eats fractions
by Pearu Peterson 14 Apr '01

14 Apr '01

Hi again, I am now convinced that what's in the subject is a bug. It is related to the assumption in the basic::collect function that this->ldegree(s) <= this->degree(s) but it is not always true: >>> ldegree(1/(1+x),x),degree(1/(1+x),x) (0, -1) As a fix, the collect function should be ex basic::collect(const ex & s) const { ex x; int ldeg = this->ldegree(s); int deg = this->degree(s); int n_start = min(ldeg,deg); int n_end = max(ldeg,deg); for (int n=n_start; n<=n_end; n++) x += this->coeff(s,n)*power(s,n); return x; } Note that then >>> coeff(1/(1+x),x,0),coeff(1/(1+x),x,-1) (1 + x) ** (-1), 0 and consequently collect(1/(1+x),x) will result correctly in (1+x) ** (-1) Regards, Pearu On Thu, 12 Apr 2001, Pearu Peterson wrote: > > Hi! > > In ginsh (ginac V0.8.0): > > > x/(1+x); > (1+x)^(-1)*x > > collect(x/(1+x),x); > 0 <----??? > > collect(1+x/(1+x),x); > 1 <----??? > > collect(x+x/(1+x),x); > (1+(1+x)^(-1))*x > > Is this GiNaC bug or feature? > > Pearu > > - > To UNSUBSCRIBE, email to ginac-list(a)ginac.de with a subject of "unsubscribe". >

2 5

Re: GiNaC/doc/tutorial ginac.texi
by Pearu Peterson 10 Apr '01

10 Apr '01

On Mon, 9 Apr 2001, Christian Bauer wrote: > - added examples for specialized expression output by tree-traversal and > with the aid of archives These examples are very useful for understanding GiNaC archive stuff for GiNaC beginners like me. Thanks! However, I might have found even simpler way to extract protected attributes. Take, for example, indexed class that has protected attribute `seq'. It can be read outside of the indexed class as follows: class wrap_indexed: public indexed { public: const exvector & get_seq(void) const { return this->seq; } }; void somefunction (const indexed & obj) { const exvector & seq = ((const wrap_indexed &)obj).get_seq(); /* Use `seq' for something */ } Unfortunately it will not work for private attributes, of course. Is there any reason why minkmetric::pos_sig color::representation_label tensepsilon::minkowski could not be protected? Are they archived attributes? Regards, Pearu

2 2

Re: GiNaC/ginac print.h ...
by Pearu Peterson 09 Apr '01

09 Apr '01

Hoi GiNaC people, On Fri, 6 Apr 2001, Christian Bauer wrote: > Log Message: > - replaced the various print*() member functions by a single print() that > takes a print_context object that determines the output formatting; this > should make it easier to add more output types In Python standard there are two output types: one for pretty print (str), e.g. str(add(power(2,symbol('n')),3)) -> "2**n+3" and another for reproducible print (repr), e.g. repr(add(power(2,symbol('n')),3)) -> "add(power(numeric('2'),symbol('n')),numeric('3'))" In order to use GiNaC from Python, I used print() function for str() and printraw() function for repr(). For that I re-implemented GiNaC::*::print*() functions, and when linking, I used their compiled codes before -lginac. This hacky method worked perfectly and it was the only way to introduce a new output type (for Python) without modifying GiNaC sources. Now, with this new print() standard, nothing has changed. I still have to re-implement print() function in the same way again:(. But looking forward to future where you might support output types such as LaTeX, MathML, etc. that could be useful also from Python, my approach doesn't feel right. And on the other hand, you hardly want to support Python (or any other third party language) output formats. So, I am wondering if it would be possible for GiNaC to support *external* output types? For example, by a special print_context object, say, print_callback, that contains an user-defined function for printing ex object and it is called from print() function with an additional argument (TINFO_*) saying who called it (e.g. symbol::print or matrix::print). In this way all printing stuff could be collected in a separate file and it should be possible to define optional output formats without modifying GiNaC sources. What do you think? Regards, Pearu

3 7