- GiNaC-devel - ginac.de

Bug in differentiation of power.
by Chris Dams 04 Apr '06

04 Apr '06

Dear all, I found out that when differentiating a power it is tested whether the exponent is real. If this is the case, code is executed that assumes that this exponent is a numeric. Hower, because we also have real symbols nowadays this is not correct. Besides, why would differentiating x^I need a special case? Its derivative is simply I*x^(I-1). Therefore, I changed this test into a check whether the exponent is a numeric. I will also backport this change to 1.3. Best, Chris

1 0

Problems in compiling ginac on a iMac (Intel)
by Christian Fleck 02 Apr '06

02 Apr '06

Hello, I tried to compile ginac version 1.3.3 with gcc 4.0.0 (Apple version) on a Intel iMac running OS X 10.4.5. My version of libread is 5.1. I append the config.log. The first error is that the configure script can still not find the correct version of cln, although it should be installed correctly. I tried to play a bit, but was not able to fix it. Running 'configure --disable-clntest --enable-shared=no' and typing 'make' produces: ... ginsh_parser.yy:47:6: error: missing binary operator before token "wrapper" ginsh_parser.yy:53:6: error: missing binary operator before token "wrapper" ginsh_parser.yy:845:6: error: missing binary operator before token "wrapper" ginsh_parser.yy:855:6: error: missing binary operator before token "wrapper" I edited the file config.h changing the lines /* Major version of installed readline library. */ #define GINAC_RL_VERSION_MAJOR EditLine wrapper /* Minor version of installed readline library. */ #define GINAC_RL_VERSION_MINOR EditLine wrapper into /* Major version of installed readline library. */ #define GINAC_RL_VERSION_MAJOR 1 /* Minor version of installed readline library. */ #define GINAC_RL_VERSION_MINOR 3 But running 'make' then produced: ... Making all in ginsh if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I./../ginac -I../ginac - DIN_GINAC -I/usr/local/include -g -O2 -MT ginsh_parser.o -MD -MP - MF ".deps/ginsh_parser.Tpo" -c -o ginsh_parser.o ginsh_parser.cc; \ then mv -f ".deps/ginsh_parser.Tpo" ".deps/ginsh_parser.Po"; else rm - f ".deps/ginsh_parser.Tpo"; exit 1; fi ginsh_parser.yy: In function 'char** fcn_completion(const char*, int, int)': ginsh_parser.yy:844: error: invalid conversion from 'const char*' to 'char*' ginsh_parser.yy:846: error: 'filename_completion_function' was not declared in this scope ginsh_parser.yy:846: error: 'completion_matches' was not declared in this scope ginsh_parser.yy:854: error: invalid conversion from 'const char*' to 'char*' ginsh_parser.yy:856: error: 'completion_matches' was not declared in this scope ginsh_parser.yy: In function 'int main(int, char**)': ginsh_parser.yy:908: error: invalid conversion from 'char** (*)(...)' to 'char** (*)(const char*, int, int)' ginsh_parser.yy:913: error: invalid conversion from 'const char*' to 'char*' make[2]: *** [ginsh_parser.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Does anyone has an idea what is going wrong and how to fix it? Thanks, Christian

2 2

New .is_polynomial() method.
by Chris Dams 27 Mar '06

27 Mar '06

Dear all, I have added a method .is_polynomial() to GiNaC. Using .info(info_flags::polynomial) is not sufficient because in that case one cannot distinguish an expression that may be a polynomial in a variable but nog in another. Example: x*y*sin(y) is a polynomial in x but not in y. Hence (x*y*sin(y)).is_polynomial(x) returns true but (x*y*sin(y)).is_polynomial(lst(x,y)) returns false. I also patched the tutorial. Best, Chris

1 0

csgn patch
by Vladimir Kisil 14 Mar '06

14 Mar '06

Dear all, Here is the full patch for the power property of csgn() function. Its effect can be seen in the following ginsh output: > csgn(x)^3; csgn(x) > csgn(x)^5; csgn(x) > csgn(x)^2; csgn(x)^2 > csgn(x)^(2/5); csgn(x)^(2/5) > csgn(x)^(6/2); csgn(x) > csgn(x)^(-2); csgn(x)^(-2) > csgn(x)^(-3); csgn(x)^(-3) > csgn(x)^(-3/3); csgn(x)^(-1) > csgn(x)^(-3/2); csgn(x)^(-3/2) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ Index: ginac/inifcns.cpp =================================================================== RCS file: /home/cvs/GiNaC/ginac/inifcns.cpp,v retrieving revision 1.87 diff -u -r1.87 inifcns.cpp --- ginac/inifcns.cpp 13 Mar 2006 14:21:47 -0000 1.87 +++ ginac/inifcns.cpp 13 Mar 2006 15:56:20 -0000 @@ -252,10 +252,23 @@ return csgn(arg); } +static ex csgn_power(const ex & arg, const ex & exp) +{ + if (is_a<numeric>(exp) && exp.info(info_flags::positive) && ex_to<numeric>(exp).is_integer()) { + if (ex_to<numeric>(exp).is_odd()) + return csgn(arg); + else + return power(csgn(arg), _ex2).hold(); + } else + return power(csgn(arg), exp).hold(); +} + + REGISTER_FUNCTION(csgn, eval_func(csgn_eval). evalf_func(csgn_evalf). series_func(csgn_series). - conjugate_func(csgn_conjugate)); + conjugate_func(csgn_conjugate). + power_func(csgn_power)); //////////

2 1

New in GiNaC: step function
by Chris Dams 13 Mar '06

13 Mar '06

Dear all, I added the step function to GiNaCs repertoire of built-in functions. It is the real function step(x)=1 for x>0 and step(x)=0 for x<0. Considering the fact that numerical evaluation may yield a small imaginary part due to rounding errors, a possible imaginary part of a numerical argument is ignored. Furthermore step(0)=1/2. This, however, should not be taken too seriously as there is also the automatic evaluation step(x)^2 -> step(x). In the sense of distributions it does not matter what the value of step(0) is. Best, Chris

3 11

Symbols do not necessarily commute
by Chris Dams 23 Feb '06

23 Feb '06

Dear all, I removed the wrong statement that symbols always commute in GiNaC from the tutorial. Best, Chris

1 0

Improvement for epsilon tensors.
by Chris Dams 22 Feb '06

22 Feb '06

Dear GiNaCers, I modified the functions that construct epsilon_tensors in tensor.cpp. They now test whether their arguments are wildcards. In that case these tensors remain unevaluated. The problem is that if one tries to use .find(epsilon_tensor(idx(wild(0),2),idx(wild(1),2))) this may get "simplified" into -epsilon_tensor(idx(wild(1),2),idx(wild(0),2)) thereby obstructing the find method. This change is in the same patch as I applied to CVS in order to revive the return_type_tinfo system. Best, Chris

1 0

return_type_tinfo is alive again.
by Chris Dams 22 Feb '06

22 Feb '06

Dear all, I revived the return_type_tinfo-system again. Functions and symbols can take a tinfo_t argument. The idea is that user-defined return_type_tinfos are made by doing something like tinfo_static_t my_rtt_static; tinfo_t my_rtt = &my_rtt_static; After that, my_rtt can be used to label kinds of noncummativity. I implemented the representation labels of clifford and color objects by making an array of tinfo_static_t objects of size 256. My only concern is that archiving/unarchiving may not go completely right, but I do not know that as I did not yet try it. At least some code of myself that used this system works again and does so with minimal changes. Best, Chris

1 0

Forgot something.
by Chris Dams 21 Feb '06

21 Feb '06

Dear GiNaCers, I was silly enough to (among other files) modify function.cpp to make the new tinfo-system work on AMD64. This should, of course, have been function.pl. A patch is in CVS. Best, Chris

1 0

New return_type_tinfo-system seems broken.
by Chris Dams 15 Feb '06

15 Feb '06

Dear all, While looking at some of my code that no longer compiles under the new tinfo() system I started wondering about the new system for return_type_tinfo(). As this system always was always more or less separated from the rest of the type system there is as such no reason to remove it along with the revision of the tinfo() system. In fact, this has serious disadvantages: Why do all non-commutative symbols automatically get the same return_type_tinfo-value? What if A and B represent matrices in the same space and C is a matrix in a different space? Should A*C*B not get simplified to (A*B)*C then? Same question for functions. Why is it no longer possible to define your own function with the same return_type_tinfo as, say, Dirac matrices of a particular representation label? The fact that in ncmul::eval it is necessary to check for Dirac/color objects indicates bad design. Although the tinfo()-system has, arguably, been improved the return_type_tinfo-system has been demolished. What about the following replacement? Make return_type_tinfo return something of type tinfo_t. In that case the user can generate his own objects tinfo_t as he pleases and e.g. dirac_gamma could take an argument of type tinfo_t instead of a representation label. Does anyone feel like implementing this or shall I do it? Best, Chris

2 2