From: "Stephen Gross"
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 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