Skip to content

Add composed operations to Function - #1158

Draft
termoshtt wants to merge 6 commits into
mainfrom
codex/function-composed-operations
Draft

Add composed operations to Function#1158
termoshtt wants to merge 6 commits into
mainfrom
codex/function-composed-operations

Conversation

@termoshtt

@termoshtt termoshtt commented Aug 12, 2026

Copy link
Copy Markdown
Member

Summary

  • Extend Function beyond compact polynomials with absolute value, signum, pointwise minimum and maximum, division, and parameterized signed 32-bit integer powers.
  • Represent every non-polynomial composition as one validated, flat reverse Polish notation (RPN) program. Compact polynomial values are pushed as atoms; unary operations consume one value, while associative and binary operations each consume exactly two values.
  • Preserve explicit grouping, operand order, partial-function behavior, and floating-point error order without recursive expression nodes or common-subexpression sharing.
  • Evaluate, partially evaluate, substitute, format, compare, bound, serialize, and reduce binary powers by iterating over the same instruction stream.
  • Extend ommx.v1.Function with an additive flat-expression payload reused by v2 roots. Parsing rejects stack underflow, leftover values, unknown operators, and malformed Powi parameters.
  • Expose the operations through Rust and Python, including abs(f), signum(), minimum(), maximum(), division, f.powi(n), and integer-only f ** n.
  • Add FunctionParameters: the default Arbitrary strategy samples every operation kind with shrinkable composed expressions, while polynomial_only makes coefficient-map preconditions explicit. Constraint, named-function, and instance generators use the same distinction.
  • Make polynomial inspection explicit: degree and term accessors report that composed expressions are not compact polynomials, and solver/exporter capability boundaries reject them rather than assigning a misleading degree.

Semantics

  • signum(±0) is zero.
  • Division by zero, zero raised to a negative integer power, and non-finite operands or results return typed evaluation errors.
  • Integer powers evaluate their operand before applying the exponent, including exponent zero. 0^0 is one; reverse, floating-point, and function-valued exponentiation are not supported.
  • Apart from identity and finite-constant folding, powi remains a composed expression and therefore has no compact polynomial degree.
  • Associative operations are stored as successive binary applications. For example, (a + b) + c and a + (b + c) produce different RPN instruction orders and retain their grouping.
  • Arithmetic containing only polynomials keeps the existing compact normalization paths.
  • The flat representation removes the former protobuf/tree recursion-depth boundary; malformed programs are instead rejected by the expression stack validator.
  • Older protobuf readers reject the new Function oneof variant instead of silently interpreting a weaker model.

Python example

f = abs(x - 2).maximum(y) / (z + 1)
g = f ** 2
h = f.powi(-2)

The generated Python stubs and API metadata, PyO3 bridge fixtures, English and Japanese guides, solver adapters, capability documentation, release notes, and property-test generators are updated for the new surface.

@termoshtt termoshtt added rust PR changes the Rust SDK public API python PR changes the Python SDK public API, generated stubs, or adapter public API proto Protobuf schema or generated protobuf contract changes breaking change Accepted work intentionally breaks compatibility labels Aug 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

breaking change Accepted work intentionally breaks compatibility proto Protobuf schema or generated protobuf contract changes python PR changes the Python SDK public API, generated stubs, or adapter public API rust PR changes the Rust SDK public API

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant