# Proper interface for calculator library?

As practice, I'm planning to implement a multivariable calculator library. The idea is that you can define a function, such as `f(x, y) = sin(x)^2 + 3*y^3`, and then you can evaluate it with specific variable values (e.g. `f(4, 3)`) or take the derivative with respect to a certain variable and get another function. The idea is that it might be used by a physics program or a calculator app that would more directly expose the functionality.

I'm not sure how to build the best interface. Using the style I'm most familiar with, I might define the above function with `Function f = new Sum(new Exponent(new Sin(new Variable("x")), 2), new Product(new Constant(3), new Exponent(new Variable("y"), 3)`, but that's very long compared to the typical mathematical shorthand. Here are a few ways I could imagine the API working:

1. `Function f = new Sum(new Exponent(new Sin(new Variable("x")), 2), new Product(new Constant(3), new Exponent(new Variable("y"), 3)` (same as before)
2. `Function f = Sum.create(Exponent.create(Sin.create(Variable.create("x")), Constant.create(2)), ...` (same as before but with static builder methods)
3. `Function f = sum(power(sin(getVariable("x")), getConstant(2)), product(getConstant(3), power(getVariable("y"), constant(3)))` (shorter, but requires quite a few static imports)
4. `Function f = FunctionGenerator.parse("sin(x)^2 + 3*y^3")`

I like 4 because it's so much shorter, but I'm wary because I very rarely see it used; the two examples I've seen that jump to mind are Regex and MySQL, and those are both basically porting older text-based languages. Regex especially seems to make sense for a text-based API because it's used to text processing.

In short, I like #4 but I'm having a hard time justifying to myself this departure from convention.

(Note: I know that option #4 will require a parser. I've used ANTLR before, so this shouldn't be a problem.)

• I'm on the mobile app, and it looks like this list is misaligned, but I can't figure out why. Does anyone know how to fix this? – raptortech97 Sep 16 '14 at 22:41
• Alignment fixed. Extra space in front of 1. – Greg Hewgill Sep 16 '14 at 22:45

Speaking at a high level, I would perhaps build the interface so that option 1 is the "native" way to build your expression tree. Additionally, option 4 could provide an optional interface that offers a much more succinct notation. The result would be exactly what would be manually generated using option 1.

Couple of points.

1. Since you already know about ANTLR you will probably already realise that your internal representation is going to be an AST, or something very near.
2. Using 'new' all the way is messy. Better to use factories, for clarity of code.
3. Yes, you will need a parser but it's nicer to get things started by building the AST directly. Then you can do the interesting things, like figuring out how to do differentation etc.

So I would recommend first:

``````var ast = AstFactory.create();
var f = ast.add(ast.exp(ast.sin(ast.var("x")), const(2)), ast.mul(ast.const(3), ast.Exp(ast.Var("y"), ast.const(3))
``````

Then you can build the AST efficiently using a fluent interface and postfix notation:

``````var f = AstGenerator.var("x").sin().const(2).exp().const(3).var("y").const(3).exp().mul().add();
``````

And finally, you still need this one (eventually):

``````var f = FunctionGenerator.parse("sin(x)^2 + 3*y^3")
``````

How is it going to be used? I think you need to look at it terms of the client code's usage patterns.

The code for a calculator app probably doesn't actually include much if any complex formulas. So the problem you are trying to address doesn't really come up. Something that a calculator app would want to is to be able to build a map of names to function implementations and none of your designs seem to facilitate that.

Some sort of physics modeling system probably does have complex formulas. But they also have the problem of symbol collision. I may have `E=mc^2` as a formula. But what happens when I'm concerned about two objects? They shouldn't share a mass, but I think in all your designs they probably do.

It looks to me like you are designing a system without a clear notion of what the client code could look like. I think that's not helpful. I think libraries like this are usually more helpful in the case that they are based on experience with writing applications that would use such a library. That way you've got a clear idea what you need.