- GiNaC-list - ginac.de

Lie algebra realisation with GiNaC
by Vladimir Kisil 07 May '07

07 May '07

Dear All, Here is a revised example of Lie algebras realisation in GiNaC as derived class from clifford. It is essentially the same as before: http://www.ginac.de/pipermail/ginac-devel/2005-July/000793.html but now works with 1.4 branch (new TINFO system). Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

1 0

question about quantum operator algebra
by Canhua 06 May '07

06 May '07

hi, I am searching for a software or library that can handle operator algebra in quantum mechanics. For example, I would like to caculate the commutator [a,H], where the Hamiltonian "H"=\epsilon a^{\dag}a, and "a" is annihilation operator for, say, an osilator. I tried GiNaC, and read much documentation, and get little clue. I wonder if there is a direct implementation of these kind of operator algebra in GiNaC. Thank you in advance.

4 3

Fwd: cygwin and GiNaC
by lolson＠ualberta.ca 04 May '07

04 May '07

Hello, hopefully someone can help me out with this. I am trying to get GiNaC working with cygwin. I installed the cln and ginac libraries with no problems at all. I can run ginsh no problem. However, when I go to compile a sample program in the tutorial. I get a TON of errors, most saying undefined reference. I'll copy part of the error log so you can see: /usr/local/lib/libginac.a(inifcns.o): In function `_ZN5GiNaC6fsolveERKNS_2exERKNS_6symbolERKNS_7numericES8_': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(inifcns.o):/usr/local/include/cln/object.h:216: more undefined references to `cln::cl_free_heap_object(cln::cl_heap*)' follow /usr/local/lib/libginac.a(numeric.o): In function `_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ES3_RKS6_': /usr/local/include/cln/object.h:(.text+0x7): undefined reference to `cln::cl_R_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZNK5GiNaC7numeric11is_rationalEv': /usr/local/include/cln/ring.h:417: undefined reference to `cln::cl_RA_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZNK5GiNaC7numeric10is_integerEv': /usr/local/include/cln/ring.h:417: undefined reference to `cln::cl_I_ring' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ev': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ev': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o):/usr/local/include/cln/object.h:216: more undefined references to `cln::cl_free_heap_object(cln::cl_heap*)' follow /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ei': /usr/local/include/cln/integer_class.h:52: undefined reference to `cln::cl_I_constructor_from_L(long)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/integer_class.h:52: undefined reference to `cln::cl_I_constructor_from_L(long)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC1Ei': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' /usr/local/lib/libginac.a(numeric.o): In function `_ZN5GiNaC7numericC2Ej': /usr/local/include/cln/object.h:216: undefined reference to `cln::cl_free_heap_object(cln::cl_heap*)' and thats just the start of it. Does anyone know what is causing this. Please help! Thanks, Lane.

2 1

Some static functions
by Martin Sandve Alnæs 14 Apr '07

14 Apr '07

collect_symbols and get_symbol_stats are mentioned in the manual, but are defined as static functions in normal.cpp with no mention in normal.h. Does this mean they're meant to be internal and not part of the "official" API? I'd like to use them... -- --- Martin Sandve Alnæs PhD student, Cardiac Computations Simula Research Laboratory, Norway

3 3

Re: [GiNaC-list] Problem using a user-defined class on Mac OS X.
by Chris.Dams＠mi.infn.it 09 Apr '07

09 Apr '07

Dear David > This alone doesn't exhibit the issue in the original example. > What you've written above is just a plain partial specialization, no > violation at all. Now, suppose that the last definition above > (foo<T*>::data) was replaced in a *different* translation unit with: > > template <> void* foo<void*>::data = &something_else; > > which is similar to the original code in this thread. The instantiation > of foo<void*>::data can now be different-valued. (Is this analogous to > the GiNaC source or proposed patch in question?) No, there is only one instantiation in the GiNaC source. Both in the unmodified one and the one that I modified to work on Mac OS X. So it cannot have different values. The point is that in the original GiNaC code there would be two instances of, say, foo<void*>::data inside the executable. One comming from the shared library and the other one coming from the executable itself. Library code would modify the first one and code from the executable would modify the other one. To reproduce it in toy code, I think you would have to create a dynamic library on the Mac, but I havn't tried yet. I guess, it could have something to do with the so-called two-level namespaces that the man page of the linker talk about. I could test that. Best wishes, Chris

2 3

Problem using a user-defined class on Mac OS X.
by Chris.Dams＠mi.infn.it 05 Apr '07

05 Apr '07

Dear all, I seem to be having a problem with unarchiving a user-defined class on Mac OS X. The problem is that the static member class_info<registered_class_options>::first is (besides inside the GiNaC dynamic library) also created within my executable. This second version is then used when registering my own class, so that my own class does not appear in the linked list of which *(class_info<registered_class_options>::first) is the first element. I debugged this by printing both the address of first and the name of the class being registered from the constructor of class_info and the for my own class the address of first turned out to be different. The consequence of this is that members of my own class cannot be unarchived. The problem does not occur on Linux. Anyone any bright ideas? Should this be considered a bug GiNaC? Does anyone know a combination of linker flags that can prevent this? Best wishes, Chris

4 10

Problem: Floating point overflow
by Alberto Orlandi 31 Mar '07

31 Mar '07

Hi, I have a question about error handling. I have a problem with the "Floating point overflow". May be is better if I give an example: #include<iostream> #include<fstream> #include<string> #include<ginac/ginac.h> int main(void) { try{ GiNaC::realsymbol x("x"); GiNaC::ex pp("sin(sin(sin(sin(log(-0.760)))))",GiNaC::lst(x)); cout << pp << endl; }catch(exception &p){ cout << p.what() <<endl; } cout << "With or without exceptions\n" <<endl; } (If you are thinking where I found that absurd function...well, this is another story) When run this program it stops and gives : "Floating point overflow". This is related to the fact that Ginac tries to evaluate the numeric expression. So I have two questions: 1) Why does it not throw and exception? 2) Is it possible to stop ginac tries to evaluate the numeric expressions? Thanks in advance, Alberto

5 5

FORTRAN output
by Warren Weckesser 28 Mar '07

28 Mar '07

I am working on a program that uses ginac to generate source code. One part of the program generates fortran-90 code. Currently I am experimenting with using the csrc output format, but with the print function of the power class redefined as in section 6.3.1 of the online tutorial. Is there a better way? Has anyone implemented a full-blown fortran output format? Best regards, Warren

2 1

Bug with evalm()?
by Martin Sandve Alnæs 26 Mar '07

26 Mar '07

I use ginac 1.3.4. I believe there is a bug in the implementation of evalm(). Its behaviour should be to do nothing if it is not applicable to the ex it is called on, right? The minimal example below throws an exception: #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main(int argc, char **argv) { ex x = symbol("x"); ex e = sin(x); ex s = e.series(x == 0, 3); cout << "This will crash:" << endl; ex m = s.evalm(); return 0; } The error is: terminate called after throwing an instance of 'std::range_error' what(): basic::let_op(): pseries has no operands Aborted (core dumped) The call stack from gdb is: (gdb) where #0 0xffffe410 in __kernel_vsyscall () #1 0xb7b12770 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7b13ef3 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb7d02520 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0xb7cfff55 in std::set_unexpected () from /usr/lib/libstdc++.so.6 #5 0xb7cfff92 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0xb7d000ca in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0xb7d9a4a6 in GiNaC::basic::let_op (this=0x80597d8, i=1) at basic.cpp:256 #8 0xb7d96dfd in GiNaC::basic::map (this=0x80595e0, f=@0xb7f8e824) at basic.cpp:316 #9 0xb7d962a9 in GiNaC::basic::evalm (this=0x80595e0) at basic.cpp:482 #10 0x0804b47a in GiNaC::ex::evalm (this=0xbfd820d4) at /usr/include/ginac/ex.h:118 #11 0x0804b214 in main () at test.cpp:12 Of course, it doesn't make much sense to call evalm() on this expression, but it is a problem in an application where we want to call evalm() "just in case" on all ex objects that pass a certain point in the application. Thus a "do nothing" behaviour for evalm() is of great importance. martin

6 20

Bug with matrix subtraction
by Martin Sandve Alnæs 26 Mar '07

26 Mar '07

If I subtract two equal matrices, I get the scalar 0. This messes up later calculations, since a scalar doesn't have op(i), transpose(), etc. If I do a+(-b) instead of a-b, I get a zero matrix as wanted. Note that the code is in Python using the swiginac bindings, which now calls evalm() automatically between operations. In [32]: m = matrix(2,2,[x,0,0,0]) In [33]: m-m Out[33]: 0 In [34]: m+(-m) Out[34]: [[0,0],[0,0]] So we have the silly relation that "a-b != a+(-b)", which can only be called a bug. -- --- Martin Sandve Alnæs PhD student, Cardiac Computations Simula Research Laboratory, Norway

3 4