August 2006 - GiNaC-devel

Improved dummy index renaming -> clifford exam fails
by Chris Dams 13 Aug '06

13 Aug '06

Dear all, I have improved the dummy index renaming. Now dummy indices are (if necessary) also renamed after mul::map is called. I made the code a bit nicer. All of the renaming is now done in either expairseq::make_flat(const exvector &v) or in expairseq::make_flat(const epvector &v). So, there is no renaming code anymore in subschildren because the renaming is taken care of by expairseq::make_flat. I did introduce a boolean parameter to some methods that says whether or not to do dummy index renaming. I also commented out some of the tests in exam_clifford.cpp. They started failing but I really don't consider this my fault. Anyone who writes code like indexed(squared_metric, alpha, alpha) where alpha is a varidx should realize that he is in a state of sin and really doing something that might break anytime. In clifford.cpp there is a lot of such code. Of course, I tried to fix it but then other things started breaking. My conclusion is that I'm going to wish "happy debugging" to Vladimir. In particular I don't really understand what the code in the .is_anticommuting() branches in cliffordunit::contract_with are supposed to be useful for. By the way. Wouldn't it be a good idea to remove the restriction that indices of clifford objects should be varidxes? When allowing a matrix as metric I do not really see the use of the varidxes. Doesn't an up-index mean exactly the same as a down one in that case? What I also would like to know, is what on earth it means that "generators satisfying the identities e~i e~j + e~j e~i = M(i, j) for some matrix (metric) M(i, j), which may be non-symmetric". From the e~i e~j + e~j e~i = M(i, j) it follows immediately that M(i,j) = M(j,i), doesn't it? Other changes: (1) moved the inline unsigned rotate_left(unsigned n) function from utils.h to ex.h because it can be quite useful for people writing their own classes and needing a hash function. (2) Changed the code for algebraic substitutions. This was necessary to keep it possible to use a pattern like U.$0.$1*Uinv.$1.$2 -> delta.$0.$2 for algebraic substitutions. (3) Added a few GiNaC::-prefixes in registrar.h to make it possible to declare algebraic classes outside the GiNaC namespace. Best wishes, Chris

3 4

The AUTHORS file
by Richard B. Kreckel 12 Aug '06

12 Aug '06

That file is a little bit outdated. Chris, you're more than welcome to patch it! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

CLN 1.1.13 released
by Richard B. Kreckel 09 Aug '06

09 Aug '06

Hi! This is to announce the availability of CLN 1.1.13. As several people have noticed, release 1.1.12 failed to compile on 64 bit platforms. This was due to an unnoticed update of autoconf and failure to apply some minor patches from the main branch to the cln-1.1 branch. Apart from fixing this, no other changes were made. Best -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

CLN 1.1.12 released
by Richard B. Kreckel 07 Aug '06

07 Aug '06

Hi! This is to announce the availability of CLN 1.1.12. It is a conservative maintenance release with only minor changes as compared to the previous version: A rare assertion when printing quite large floats (beginning at a few million decimal digits) was fixed and compilation on Intel Mac an MinGW should be no problem any more. As always, it is available from <http://www.ginac.de/CLN/>. I would like to take this opportunity and inform you about what's going on in the CVS repository. A while ago, a branch was made for all subsequent 1.1.x releases. That branch is called cln_1-1 and CVS users can access it with the usual -r switch. We could call it the "boring" branch and it was the basis for this release. On the main branch, a series of patches is being applied and that will ultimately become CLN 1.2.0: 1) Large fixnums: on 64 bit systems, fixnum range is extended from 32 bits to 61 bits. This may save some time and space. 2) Huge numbers: on 64 bit systems, iterators over the digits of a number don't roll over after 2^32 iterations. This will enable us to keep main memory busy during the next 40 years or so. 3) Big exponents: on 64 bit systems and some 32 bit systems, the exponent range becomes -2^63..2^63-1. This will remove the limit of 646 million decimal digits precision for objects of type cl_LF. The first two patches have already been applied. The third one is in the cooker and nearing completion but still needs some more testing. Curious people are invited to get the sources from CVS and find and report bugs. Happy hacking! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

Re: [GiNaC-list] Possible size issue in test in numeric.cpp
by Jens Vollinga 07 Aug '06

07 Aug '06

Dear Chris, Chris Dams schrieb: > I'm not a CLN expert either, but to me it does not seem that the code is > incorrect. On the AMD 64 platform it is apparently always okay to apply > the constructor cl_I(int) no matter how large the integer argument is. If > the compiler is smart enough, it will automatically do what your patch is > doing (i.e., throw the if out of the code), so I fail to see benefits from > your patch. you are right: the code is correct and a smart compiler will do the same what Pierangelo's patch does. Still, I am somewhat in favor of applying this patch, because it removes an irritating warning. It is not just an annoying warning. It looks as if it had some meaning to it and thereby provokes patch-production or raises doubt about the code quality of ginac. I'd like to release 1.3.5 soon (today, tomorrow?). Apart from an NEWS update (expand_dummy_sum fix missing) and a possible inclusion of Pierangelo's patch (objections?) are there any pending issues? Regards, Jens

3 2

Class container vs. the holy standard?
by Richard B. Kreckel 05 Aug '06

05 Aug '06

Hi, Triggered by Debian bug #362220 [0] I submitted GCC bug report #27178 [1] only to be told that container.h made use of a GCC extension that will have been removed from GCC in the upcoming 4.2.0 release [2]. Basically, where we were simply writing this: template <template <class> class> class container; typedef container<std::list> lst; we now have to write the more cumbersome: template <template <class, class> class> class container; typedef container<std::list> lst; This is because std::list has two template parameters, the element type and the allocator type. Ugh. It's ugly, because the intent was clearly to not bother the user with implementation details like the allocator. From the user's perspective, the intent is to express "container of T", never mind what type of container. I've attached a patch against CVS GiNaC-1.3 that converts all places flaged as errors in GCC 4.2 20060415 (experimental) to: template <template <class T, class = std::allocator<T> > class> class X; typedef X<std::list> lst; This is ugly as sin, because I don't think that we really wanted to express "STL-container of T", as the changed code now appears to imply. Any suggestions? -richy. [0] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362220> [1] <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27178> [2] <http://gcc.gnu.org/gcc-4.2/changes.html>, first bullet under C++ -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

5 12

Matrices vs indexed
by Alejandro Limache 02 Aug '06

02 Aug '06

according to Ginac-mini FAQ: >The indexed class (and most derived classes) is intended for tensor >manipulation without >referring to a particular basis. Thus, the indexed >class is well suited for calculations >involving (formally defined) tensor >algebra of "non-integer-dimensional space". >.... >In that framework, unrolling ai*ai to a1^2+a2^2+a3^2+... is not possible, >since the dimension >is not integer! I am physicist (not a relativist one though).. but, is there something more useful than tensors representations (i.e tensor components) defined for integer indexes?!!!. Let us see... In two dimensions the tensor velocity vector V can be written in cartesian cordinates (x,y) with basis vectors (e.x,e.y) as: V.x e.x + V.y e.y but aren't we finally more interested in the values of the "components": V= [V.x ,V.y] ===> a matrix with 2 integer indices. But...let see in polar coordinates with basis vectors (e.r,e.theta) the same velocity vector can be written as V.r e.r + V.theta e.theta but aren't we finally more interested in the values of the "components": V= [V.r ,V.theta] ===> a matrix of 2 integer indices. but ....opps we always ended by looking at the multi-index arrays of integer indeces!!! It is because that I always want to get the components of tensors (which can be arranged as multidimensional arrays/matrices) is that I want to be able to unroll indexed objects. So I agree with the type of interest reported by another newbie to Ginac: (http://www.cebix.net/pipermail/ginac-list/2004-December/000576.html) >I'd like to know if is it possible to unroll indexed >objects. As example, I would like to do something like this >a_i a~i = (a_1)^2 + (a_2)^2 + (a_3)^2 + ... >or just substituting a_i values in a_i * b~i a_i = =(1,0,0) >a_i b~i -> b~1 Definitely I like to be able to do things like the above. Chris mentioned to me two things that could be very useful in indexed expressions: 1) ex_to<numeric>(e.subs(lst(i==0,j==0))).to_double() This works in matrices but one should be abel to put numeric values inside indexed expressions and do matrix type operations... 2) expand_dummy_sum(const ex & e, bool subs_idx) there could be a similar function "expand_indexes" that expand summed and not summed indices. Example given ex e=indexed(A,i,j)*indexed(v,j) by applying the "expand_indices" function get: e=[[A.1.1*v1 A.1.2*v.2], [A.2.1*v1 A.2.2*v.2]] cheersss Alejandro

3 2

Fixes w.r.t. indexed objects.
by Chris Dams 01 Aug '06

01 Aug '06

Dear all, As discussed in ginac-list the function expand_dummy_sum is broken. A fix is now in CVS. The code was also rather horrible, so I fixed that too. I will also port this change to the 1.3-branch. I guess that there are no binary compatibility issues involved in making STLT protected, as explained below? Otherwise somebody has to complain and then I can remove the "protected:"-line again. Another thing: What is the idea of the answer to the question "I wish to mix matrices and indexed objects. How can that be done?"? I see a very strange expression there with three indices that are apparently contracted. However, we don't want to encourage our users to start typing that kind of garbage, do we? More changes: * Removed the remark from the tutorial that scalar_products can be used for tensors of a rank greater then one. * Made the declaration of STLT in container.h protected. It can be quite useful to have access to this when writing derived types. * Improved comments and an error message. Best wishes, Chris

3 6