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 <iostream> #include <ginac/ginac.h> 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<numtries; ++i) myfun(2); cout << "using uncompiled" << endl; for(int i=0; i<numtries; ++i) f.subs(x==2); return 0; } compiled it using g++ -O2 `ginac-config --cppflags` test.C `ginac-config --libs` -o test and noticed that the compiled function takes a lot less time to complete then the other one (actually I am still waiting for the other one...). Is 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? Best wishes, Chris
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
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
participants (2)
-
Chris Dams
-
Jens Vollinga