From neofytos.mylona at gmail.com Sat Jun 10 23:36:19 2006 From: neofytos.mylona at gmail.com (Neofytos Mylona) Date: Sat, 10 Jun 2006 22:36:19 +0100 Subject: [GiNaC-devel] Help Message-ID: <8b1d54540606101436r1c7f9535ub55b14f7f3d1b5de@mail.gmail.com> I have the following problem. I have installed the CLN library in the following directory: /homes/nm305/MSc_project/code/call1/cln and ginac in /homes/nm305/MSc_project/code/call1/ginac I have my project code in /homes/nm305/MSc_project/code inside my code i add #include /homes/nm305/MSc_project/code/call1/ginac/include/ginac/ginac.h when i compile with make -f run.make it says error: cln has not been declared nad some other stuff Note that in my .cshrc file i have added setenv LD_LIBRARY_PATH /homes/nm305/MSc_Project/code/call1/cln/lib setenv CLN_CONFIG /homes/nm305/MSc_Project/code/call1/cln/bin/cln-config this was needed to install ginac otherwise it wouldnt let me. any help appreciated. thanx!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From C.Dams at science.ru.nl Wed Jun 14 21:12:58 2006 From: C.Dams at science.ru.nl (Chris Dams) Date: Wed, 14 Jun 2006 21:12:58 +0200 (MEST) Subject: [GiNaC-devel] Help In-Reply-To: <8b1d54540606101436r1c7f9535ub55b14f7f3d1b5de@mail.gmail.com> Message-ID: Dear Neofytos, On Sat, 10 Jun 2006, Neofytos Mylona wrote: > I have installed the CLN library in the following directory: > > /homes/nm305/MSc_project/code/call1/cln > > and ginac in > > /homes/nm305/MSc_project/code/call1/ginac Yes, this is all very possible although I would not recommend it. The unix directory structure has generally header files in an include-directory, executables in a bin-directory, libraries in a lib-directory. A problem with the approach that you seem to be taking is that the directories you name will all separately get include/lib/bin-directories. If you decide to stay with this approach you will have to make sure that the installed files will be found. In particular, it will be quite usefull to add the directories /homes/...whatever.../cln/bin and /homes/...whatever.../ginac/bin to your path. That way the executable cln-config and ginac-config can be found. Personally, I make the prefix of packages that I install into my home directory always the home-directory itself. In that case I simply get subdirs bin, lib, include and so on in my homedir and I only once need to make sure that they get found. > I have my project code in > > /homes/nm305/MSc_project/code > > inside my code i add > > #include /homes/nm305/MSc_project/code/call1/ginac/include/ginac/ginac.h Firstly, this needs quotes (") around the filename. Secondly, this is not such a good idea. What if you move your code to someplace else? Then you will have to change all those includes. To solve this you could, inside your makefile, make use of ginac-config. Try typing "ginac-config --cppflags" at the prompt and see what happens. The flags that you see need to be used when compiling. Then you should also use #include . There also is the --libs option. If you have this, the only thing you should need is setting your LD_LIBRARY_PATH to include the places where the cln and ginac libraries are installed. Below I note that you alreadly did this for the cln library but you will also need to add the dir of the ginac library. > setenv LD_LIBRARY_PATH /homes/nm305/MSc_Project/code/call1/cln/lib Good luck, Chris From neofytos.mylona at gmail.com Wed Jun 14 21:55:14 2006 From: neofytos.mylona at gmail.com (Neofytos Mylona) Date: Wed, 14 Jun 2006 20:55:14 +0100 Subject: [GiNaC-devel] Help In-Reply-To: References: <8b1d54540606101436r1c7f9535ub55b14f7f3d1b5de@mail.gmail.com> Message-ID: <8b1d54540606141255r227ec216y638ac3a920cadf70@mail.gmail.com> Dear Chris, Thank you very much for your email and response. That was very kind.. I didnt actually expect to get a respond. Thank God I have managed to fix the problems with the help of a friend so all is well now. I have also made progress with my project as ginac is soo powerful with regard to manipulating matrices. Once again thank you for your help. Regards Neofytos. On 6/14/06, Chris Dams wrote: > > > Dear Neofytos, > > On Sat, 10 Jun 2006, Neofytos Mylona wrote: > > > I have installed the CLN library in the following directory: > > > > /homes/nm305/MSc_project/code/call1/cln > > > > and ginac in > > > > /homes/nm305/MSc_project/code/call1/ginac > > > Yes, this is all very possible although I would not recommend it. The unix > directory structure has generally header files in an include-directory, > executables in a bin-directory, libraries in a lib-directory. A problem > with the approach that you seem to be taking is that the directories you > name will all separately get include/lib/bin-directories. If you decide to > stay with this approach you will have to make sure that the installed > files will be found. In particular, it will be quite usefull to add the > directories /homes/...whatever.../cln/bin and > /homes/...whatever.../ginac/bin to your path. That way the executable > cln-config and ginac-config can be found. Personally, I make the prefix of > packages that I install into my home directory always the home-directory > itself. In that case I simply get subdirs bin, lib, include and so on in > my homedir and I only once need to make sure that they get found. > > > I have my project code in > > > > /homes/nm305/MSc_project/code > > > > inside my code i add > > > > #include /homes/nm305/MSc_project/code/call1/ginac/include/ginac/ginac.h > > Firstly, this needs quotes (") around the filename. Secondly, this is not > such a good idea. What if you move your code to someplace else? Then you > will have to change all those includes. To solve this you could, inside > your makefile, make use of ginac-config. Try typing "ginac-config > --cppflags" at the prompt and see what happens. The flags that you see > need to be used when compiling. Then you should also use #include > . There also is the --libs option. If you have this, the > only thing you should need is setting your LD_LIBRARY_PATH to include the > places where the cln and ginac libraries are installed. Below I note that > you alreadly did this for the cln library but you will also need to add > the dir of the ginac library. > > > setenv LD_LIBRARY_PATH /homes/nm305/MSc_Project/code/call1/cln/lib > > Good luck, > Chris > > _______________________________________________ > GiNaC-devel mailing list > GiNaC-devel at ginac.de > https://www.cebix.net/mailman/listinfo/ginac-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Chris.Dams at mi.infn.it Mon Jun 19 13:37:50 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Mon, 19 Jun 2006 13:37:50 +0200 (CEST) Subject: [GiNaC-devel] Positive symbols. Message-ID: Dear all, Some weeks a go I comitted a patch that declares a flag domain::positive and a few automatic simplifications related to positive symbols. Now I also declared a class possymbol in symbol.h to do the same as realsymbol that we already had. I documented this in the tutorial. Best, Chris From Chris.Dams at mi.infn.it Tue Jun 20 12:41:08 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Tue, 20 Jun 2006 12:41:08 +0200 (CEST) Subject: [GiNaC-devel] (no subject) Message-ID: Dear all (but especially Jens), I noticed that Jens wrote functions for compiling expressions but that they are undocumented. So I decided to write a small test to see if it works for me. I wrote the following program #include #include using namespace std; using namespace GiNaC; int main() { int numtries = 100000000; symbol x("x"); ex f = 2*x; FP_dim1 myfun = compile(f, x); cout << "using compiled" << endl; for(int i=0; i References: Message-ID: <449873EC.8050403@physik.uni-wuppertal.de> Dear all (but especially Chris), > this the right way of using this function? I am guessing now that an > FP_cuba-thingy takes the number of arguments as a first parameter, the > values of the arguments as a second parameter, the number of results as a > third parameter and the results as a fourth parameter. Is this guess > right? I also note the presence of a ginac-excompiler script. What is the > use of this if compiling is as simple as shown above? Wouldn't it be > awfully nice if this would be documented, instead of having the users > guess? this compile-thingy is unfinished business of course. It is my (bad?) habit of putting even buggy or not-documented code into CVS, so that other developers may ponder about it. :-) I am slow on documenting features, but in this case I left that task open on purpose. I didn't want any user to use that feature yet! The interface is bad. The function pointer should be a return parameter. And there are other smaller issues. While thinking about these (yes, small) changes, I was carried away by its connection to The Big Picture (tm). There are functions in GiNaC that don't have an equivalent in libc. Extra code has to be produced and somehow included in the C file to be compiled. Time consuming subexpressions should only be evaluated once, but how can one tell how expensive a certain evaluation is? Only possible if functions can be asked for such information. So, the function system needed some attention. Fixes there relied on a change in the type info system ... I will not have time to fix it soon (I even didn't do much for the pseries changes I announced LOUD and proudly, yet!). So, if this code stands in the way of a next GiNaC release I would more likely remove it from CVS temporarily. On the other hand, if you have interest in this feature please feel free to take it into your hands. Regards, Jens From Chris.Dams at mi.infn.it Wed Jun 21 15:39:20 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 21 Jun 2006 15:39:20 +0200 (CEST) Subject: [GiNaC-devel] (no subject) In-Reply-To: <449873EC.8050403@physik.uni-wuppertal.de> Message-ID: Dear Jens, On Wed, 21 Jun 2006, Jens Vollinga wrote: > this compile-thingy is unfinished business of course. It is my (bad?) > habit of putting even buggy or not-documented code into CVS, so that > other developers may ponder about it. :-) I am slow on documenting > features, but in this case I left that task open on purpose. I didn't > want any user to use that feature yet! The interface is bad. The > function pointer should be a return parameter. And there are other > smaller issues. While thinking about these (yes, small) changes, I was > carried away by its connection to The Big Picture (tm). There are > functions in GiNaC that don't have an equivalent in libc. Extra code has > to be produced and somehow included in the C file to be compiled. Time > consuming subexpressions should only be evaluated once, but how can one > tell how expensive a certain evaluation is? Only possible if functions > can be asked for such information. So, the function system needed some > attention. Fixes there relied on a change in the type info system ... > > I will not have time to fix it soon (I even didn't do much for the > pseries changes I announced LOUD and proudly, yet!). So, if this code > stands in the way of a next GiNaC release I would more likely remove it > from CVS temporarily. On the other hand, if you have interest in this > feature please feel free to take it into your hands. Well, you seem to be the one doing the releasing of new versions lately, so who am I to complain if you decide to make that task more difficult by committing and having to remove again some immature/unfinished code. ;-o As long as the CVS-version remains compilable... Sending an email to this list about major changes in CVS would not be such a bad idea, though. I just looked at it because I noticed something new in the source tree and started wondering what it was about. At the moment I am not that much interested in this kind of stuff. Maybe if I need to do some Monte Carlo integration at some point. Best wishes, Chris From Chris.Dams at mi.infn.it Fri Jun 23 11:03:12 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Fri, 23 Jun 2006 11:03:12 +0200 (CEST) Subject: [GiNaC-devel] calchash and compare_same_type for symmetries. Message-ID: 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