I have uploaded c2_functions.zip to the file vault. It contains the code for c2_functions (header & source), an html folder with Doxygen documentation, and a white paper describing the theory of this package. Anyone who is interested, look over this and let me know how the group wishes to proceed.
That's interesting, although I have to admit I think of a particular use case at present. I particularly like the idea that the library is effectively doing symbolic math internally, could the library be adapted to output symbolic derivative information: so given a formula for f(x) tell you what the derivatives are? With regard to the interface, it looks quite reasonable to me, questions likely to crop up during a review are: 1) Why restrict the library to double precision, could it made into a template that works at arbitrary precision? 2) Would it be possible to make c2function a handle-body class? The classes that currently inherit from c2function would then all become implementation details, and c2function would become a smart ptr to the actual representation. The advantage is that you can pass c2functions around without worrying about it's actual type (a lot like Boost.Function). Composition of primitives could be handled by non-member free functions, or by operators: so given: c2function a, b; then: c2function c = a*b; // does the right thing internally. 3) How easy is the library to extend to new primitives, for example if someone wanted to add sinh or something would that be straightforward? 4) The library probably needs some concrete use cases to get people interested :-) 5) Boost has a tuple class, so there's no need to restrict the tuple interface to python only as suggested in the white paper :-) That's all I can think of for now, John.