- GiNaC-devel - ginac.de

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

about adding new function
by wangtielei(王铁磊) 07 Jul '06

07 Jul '06

Hello everyone: I am trying to add a new function which would be used for propositional reasoning. I got some information in GiNaC’s tutorial, included the source file “inifcns.cpp” and “inifcns.h” which are mentioned in tutorial. Now, my question is how to compile the new files. For example, the header file <xxx.h > #include <ginac/ginac.h> using namespace std; namespace GiNaC { /* a test function*/ DECLARE_FUNCTION_2P(myfcn) } #endif and the source file <xxx.cxx> #include "xxx.h" #include "ginac.h" namespace GiNaC { REGISTER_FUNCTION(myfcn, dummy()) } I don’t know the next step. Can you give me a whole process demo? Please help me. Thank you very much.

2 1

Substituting indices
by Chris Dams 07 Jul '06

07 Jul '06

Hello again, Sometimes I misuse indices by not just having them as operands of indexed objects but, for example, as elements of lists. In this case it can be quite useful to be able to substitute them for objects that are not indices. However, this is not really possible because substituting indices by objects that are not indices really substitutes the value. For this reason I introduced a subs_option really_subs_idx that turns this behaviour off. The change is in CVS. Best wishes, Chris

1 0

Printing exvectors and exmaps.
by Chris Dams 07 Jul '06

07 Jul '06

Dear all, It is quite useful to be able to print exvectors and exmaps without any fuss. Therefore I defined std::ostream & operator<<(std::ostream & os, const exvector & e); std::ostream & operator<<(std::ostream & os, const exmap & e); You find them in CVS. Best wishes, Chris

1 0

calchash and compare_same_type for symmetries.
by Chris Dams 23 Jun '06

23 Jun '06

Dear all, The commentary of compare_same_type used to say that "All symmetry trees are equal. They are not supposed to appear in ordinary expressions anyway...". This is wrong, however, because for archiving purposes we need to know that whether symmetry trees are equal or not. The reason is that any particular expression occurs only once in an archive for reasons of conserving space. I fixed this by adding a calchash method to the class symmetry and by making compare_same_type do the right thing. Best wishes, Chris

1 0