Dear Roland, Let's see if we can resurrect this thread... On Thu, 11 Jan 2001, Roland Richter wrote:
I recently had a look at the ginac 'function' class and at the corresponding REGISTER_FUNCTION mechanism. (background: I want to use ginac to represent fuzzy membership functions, i.e. essentially functions R -> [0,1]).
Newbie question: Why was the design made as it is?
For instance, why are all functions stored in a vector<function_options>, instead of deriving them from class function?
We had the design you suggest before we switched to the current one. One drawback is that you cannot have classes share the name of global functions. Instead of writing sin(x) we had to write Sin(x). IIRC the code was much uglier with the old design and things got clearer when Alex came up with the cpp-register-functions-in-a-vector design. Alex, do you remember the precise circumstances?
Sure, when dealing with functions like exp, sin, ..., it is clear that there is just *one* instance of each such function. (Singleton pattern?)
No, it has nothing to do with the Singleton pattern. Singleton pattern means that there is only one object of a class at a time. This is not the case. We can have exp(x)+exp(y), an object of class add and two objects of class function corresponding to exp. In an object-oriented world, Singleton classes take the place of global variables.
But how to deal with parametrized functions when parameters are specified at runtime?
For instance, it would be nice to implement splines s.t. it is possible to specify two coordinates (x1,y1), (x2,y2) s.t. spline(x1) = y1, spline(x2) = y2, and first derivates are 0 at x1 and x2 ...
Does that fit into the framework, too?
Frankly, we never had generation of functions at runtime in mind. OTOH I don't see why you wouldn't be able to do just what you want to do with additional function arguments. What's the difference between a parameter and an argument anyways? Regards -richy. -- Richard Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/> - To UNSUBSCRIBE, email to ginac-list@ginac.de with a subject of "unsubscribe".