From: "Stephen Gross" <sgross@darwin.epbi.cwru.edu>
1. Types are not template-ized. I don't want everything to be a double. This is an interesting point. My goal so far has been to prioritize simplicity above all. The purpose of the toolkit is for letting people write arithmetic equations easily. In light of that, I think sticking with doubles makes sense.
So if I want to use a rational class, or a higher-precision double provided by a library, or a fixed-precision class, or a boolean type (a la Excel: if(x<y,x,y)) I'm out of luck? I appreciate simplicity of use, but you can still accomplish this by letting double be the default type (which makes sense, I think). Then non-power-users get double all the time, and power users can still do some hacking.
Well, this is an interesting idea but it runs contrary to the metaphor I want. In the above example, the variables 'x' and 'y' work as global variables. I want the user to have to pass x and y directly to the equation.
I agree - which is why I wrote the bit about an evaluate function that takes positional arguments. Maybe named arguments are even better, though. I hadn't thought of that.
If you had global-level variables, then it would be difficult to make the above example work properly (passing z on as x and y when f2 invokes f1)..
Please don't call them globals - they aren't. They're in the same scope as the expression. However, as to your particular issue, this isn't a problem: variable x, y, z; expression expr1 = x + y; expression expr2 = z + expr1; A variable is just a special form of an expression, after all. As to mapping, it would be nice to be able to write code like: double v = expr1(x=5,y=10); double w = expr2(x=2,y=3,z=8); I should think the Boost parameter library could handle this. Actually, maybe you don't even need the Boost parameter library. Just define operator() on expression to ignore its arguments (then x=5, y=10 sets the values of x and y, and expr1 is then evaluated in that context). - James