Package heronarts.lx.structure

Class Expression

java.lang.Object
heronarts.lx.structure.Expression
public class Expression extends Object
Expressions can have ambiguous types when nested with parentheses! This is getting out of control and I really should have just used a proper expression parsing library of some sort. Did you actually read that? I kept leaving comments like that for years, suggesting this should all be replaced, but at this point (July 2025) I suppose I've changed my tune. This is self-contained enough in a reasonably manageable small-ish amount of code, with a few particular bits-and-bobs like rounding float precision errors that are of direct relevance to the LXF use case. Thanks to Andrew Look for adding unit test support.

  • Constructor Details

    • Expression

      public Expression()

  • Method Details

    • evaluateNumeric

      public static float evaluateNumeric(String expression)

    • evaluateBoolean

      public static boolean evaluateBoolean(String expression)

    • evaluate

      public static Expression.Result<?> evaluate(String expression)
      Evaluate a mathematical expression containing a mix of operators, function calls and parentheses. The result type is ambiguous, depending upon the content. Use evaluateNumeric() or evaluateBoolean() when a known result type is desired.
      Parameters:
      expression - Portion of expression to evaluate
      Returns:
      Result, which may be Boolean, Numeric or List