[GiNaC-devel] (no subject)

[Jens Vollinga]

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