User-authored calculations for .NET
CalcEngine Plus supports subexpressions, i.e. named calculations.
Example:
"current" is defined as "voltage / "resistance"
"area" is defined as "pi * r * r"
"cylinder_volume" is defined as "area * height"
In these examples, current, area and volume are new tags that are defined and given names by the users in your application's UI. They can be re-used in other calculation expressions - note how area is being re-used in the cylinder_volume calculation.
As users build more calculated entities and the calculations become more complex, various management problems occur:
Scenario: In an industrial application, a low-flow indicator is calculated - but it's only valid if the plant is running. A level-too-low alarm is calculated - but it's only valid if the plant is running. A motor-speed alarm is calculated ... and so forth.
The definition of "the plant is running" is an obvious candidate to be factored into a single entity. It's the DRY principle, just like anything you build with software.
If duplicate expressions emerge, it's easy to miss one when they all have to be changed. This can lead to errors in the model.
In the above example, if "the plant is running" is a long and complex series of "if()" expressions, then the simplicity of the logic can be hidden under the sheer weight of text. This ability to distill syntactic and logical simplicity out of chaos is another good reason to define sub-expressions, even if they are never re-used.
If your application can provide a suitable UI and a storage mechanism, then your users can name and define sub-expressions, and benefit from all their advantages.
Note that CalcEngine Plus doesn't store or manage sub-expressions. As a developer, you are free to store sub-expressions in any way that makes sense for your application - in your database, in memory or in a config file. You simply have to build a simple class that tells the calc engine about the sub-expression whenever it asks. Learn more about implementing sub-expression support.