analyze
Trace any calculation step by step. See each sub-expression's value, precision, and rounding to pinpoint why a result is unexpected.
Instructions
Evaluate an expression and return its AST as an indented tree of sub-results.
Same arguments and evaluation as calculate — mode (fixed-point default,
floating-point, rational) and min_fixed_point_precision behave identically —
but instead of one final value this returns the WHOLE parse tree, each node
annotated with the Value it computed in that mode. Reach for it to see WHERE a
surprising answer comes from: which sub-expression rounded, overflowed, or lost
precision, rather than only the rounded result. For just the final value use
calculate; to find the variable value(s) that drive an expression to a root or
extremum, use solver.
tree is a multi-line string, one node per line, indented by depth (root last-
applied operator at the top, literals at the leaves). Each line is
<OPCODE/LITERAL "lexeme"> Value = <value> (<type>[<scale>], <exact|inexact>)
followed by ·-separated per-mode details: the value in hex (fixed-point as
M@D with whole-byte digits, @<scale> dropped at scale 0; float as raw IEEE-754
bits), or a rational's decimal approximation. The <scale> is the fixed-point
decimal scale (omitted for modes without one). A fixed-point node that ROUNDED
its result also carries a final · rounding <residual> ≈ <approx> fragment: the
exact signed residual stored − true (a fraction, bounded by half a unit in the
last place) and its decimal approximation. It is named rounding, NOT error,
on purpose — the reply's top-level error field is the failure channel, so a
rounding label keeps "this node rounded" from being misread as "this node
failed". For example (1 + 1/2) * 3 in fixed-point:
BINARY_MUL Value = 3 (fixed-point[0], inexact) · hex 0x03
BINARY_ADD Value = 1 (fixed-point[0], inexact) · hex 0x01
LITERAL "1" Value = 1 (fixed-point[0], exact) · hex 0x01
BINARY_DIV Value = 0 (fixed-point[0], inexact) · hex 0x00 · rounding -1/2 ≈ -0.5
LITERAL "1" Value = 1 (fixed-point[0], exact) · hex 0x01
LITERAL "2" Value = 2 (fixed-point[0], exact) · hex 0x02
LITERAL "3" Value = 3 (fixed-point[0], exact) · hex 0x03— the 1/2 = 0 leaf (inexact, scale 0) makes plain that fixed-point rounded the
half away (its rounding -1/2 is the exact half discarded), so the product is 3,
not 4.5, and every node above it inherits the inexactness. Those ancestors show no
rounding fragment: they introduced no rounding of their own, only carried the
leaf's. (Raise min_fixed_point_precision, or use a different mode, to keep those
digits.)
On success tree is the rendering and error is null; on a bad mode, an invalid
min_fixed_point_precision, or a malformed/erroring expression, tree is null and
error carries the message (the same messages calculate returns).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Numeric type to evaluate in: 'fixed-point' (default), 'floating-point', or 'rational' — as in `calculate`. | fixed-point |
| expression | Yes | The expression or newline-separated program to parse and evaluate; same grammar as `calculate`. | |
| min_fixed_point_precision | No | Floor on fixed-point fractional digits (non-negative integer); fixed-point mode only, null for no floor — as in `calculate`. |