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