xai-org/x-algorithm · error · IllegalArgumentException

expecting a non-negative number for Sqrt() function but rece

Error message

expecting a non-negative number for Sqrt() function but received %f

What it means

Sqrt.apply throws IllegalArgumentException when its numeric argument is negative, because Math.sqrt of a negative would yield NaN. The function demands a non-negative input at runtime.

Source

Thrown at botmaker/src/java/com/twitter/botmaker/function/math/Sqrt.java:50

  public Sqrt(String exprText, ImmutableList<ASTNode> children) throws SemanticCheckFailure {
    super(exprText, children);
  }

  @Override
  public Signature getSignature() {
    return SIGNATURE;
  }

  @Override
  protected CacheLevel getCacheLevel() {
    return CacheLevel.Global;
  }

  @Override
  protected Object apply(Context<Runtime> context, Number num) {
    if (num.doubleValue() < 0) {
      throw new IllegalArgumentException(
          String.format("expecting a non-negative number for Sqrt() function but received %f",
              num.doubleValue())
      );
    }
    return Math.sqrt(num.doubleValue());
  }
}

View on GitHub (pinned to 24c60942c5)

Solutions

  1. Clamp the argument to >= 0 before calling Sqrt: Sqrt(Max(x, 0)) or Math.max(x, 0.0)
  2. Validate user-supplied inputs for non-negativity earlier in the pipeline
  3. If NaN is acceptable, wrap in a custom try-catch and substitute NaN/0

Example fix

// before
Sqrt().apply(ctx, delta); // delta = -1e-16 -> IllegalArgumentException
// after
Sqrt().apply(ctx, Math.max(delta, 0.0));
Defensive patterns

Strategy: validation

Validate before calling

double safe = Math.max(num, 0.0);
return Sqrt().apply(ctx, safe);

Type guard

public static boolean sqrtDomainOk(double v) { return v >= 0.0 && !Double.isNaN(v); }

Try / catch

try {
  return Sqrt().apply(ctx, v);
} catch (IllegalArgumentException e) {
  return Double.NaN; // or 0.0 per business rule
}

Prevention

When it happens

Trigger: Sqrt(-1) or Sqrt(x) where x evaluates to any value < 0.0, including -0.0 boundaries being fine but small negative results of floating computations (e.g. -1e-16 from rounding) failing the check.

Common situations: Computing norms/distances where floating rounding produces tiny negatives, user-supplied parameters not validated, subtracting timestamps/values that can go negative.

Related errors


AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/0bbcea3d3cb97cef. Report an issue: GitHub.