Document Statement
This article is not a Rust tutorial, nor a trading strategy guide.
It documents an engineering proposal:
how a quant operator should be defined and reasoned about in Rust.
All code snippets exist solely as reference implementations to validate definitions — not as learning objectives.
Author
yuer
Author of EDCA OS
Proposer of controllable AI standards
Engineering repository:
Contact: lipxtk@gmail.com
Most technical indicators today are modeled as functions:
take an array
return a value or another array
This breaks down once indicators need:
persistent state (rolling, EMA)
sensitivity to time ordering
consistent semantics across batch and streaming
composition and scheduling
A pure function model cannot express these constraints.
In Rust, this limitation becomes explicit:
ownership forces state responsibility to be explicit
implicit globals are unacceptable
performance requires clear execution boundaries
In this document, an Operator is defined as:
A schedulable execution unit that processes input data under explicit execution semantics.
The term “function” is intentionally avoided.
An operator must:
Have explicit input/output semantics
Be invoked as a semantic execution unit
Own its state boundaries explicitly
Fail in a structured, observable way
An operator must never:
make decisions
schedule itself
manage system resources
perform system-level recovery
An Execution is defined as:
An indivisible invocation of an operator under a given input and execution context.
Key properties:
execution is semantic, not syntactic
operators may execute multiple times
relationships between executions are out of scope here
Operator failure is not panic.
It is a first-class execution result that may propagate outward.
Whether a failure halts the system is a responsibility of the caller.
The following code exists to prove that the above definitions are implementable in Rust.
pub trait Operator {
type Error;
fn execute(&mut self, input: Input) -> Result;
}
Notes:
&mut self explicitly allows internal state
no time, batch, or scheduling semantics yet
intentionally minimal
A trivial stateless example:
pub struct Sum;
impl Operator<&[f64], f64> for Sum {
type Error = ();
fn execute(&mut self, input: &[f64]) -> Result {
Ok(input.iter().sum())
}
}
Its purpose is conceptual, not functional.
This article intentionally does not define:
state models
time semantics
batch consistency
DataFrame or Polars integration.
More...
This article is not a Rust tutorial, nor a trading strategy guide.
It documents an engineering proposal:
how a quant operator should be defined and reasoned about in Rust.
All code snippets exist solely as reference implementations to validate definitions — not as learning objectives.
Author
yuer
Author of EDCA OS
Proposer of controllable AI standards
Engineering repository:
Contact: lipxtk@gmail.com
- Where the problem comes from
Most technical indicators today are modeled as functions:
take an array
return a value or another array
This breaks down once indicators need:
persistent state (rolling, EMA)
sensitivity to time ordering
consistent semantics across batch and streaming
composition and scheduling
A pure function model cannot express these constraints.
In Rust, this limitation becomes explicit:
ownership forces state responsibility to be explicit
implicit globals are unacceptable
performance requires clear execution boundaries
- Core Definition: Operator
In this document, an Operator is defined as:
A schedulable execution unit that processes input data under explicit execution semantics.
The term “function” is intentionally avoided.
An operator must:
Have explicit input/output semantics
Be invoked as a semantic execution unit
Own its state boundaries explicitly
Fail in a structured, observable way
An operator must never:
make decisions
schedule itself
manage system resources
perform system-level recovery
- Execution as a semantic unit
An Execution is defined as:
An indivisible invocation of an operator under a given input and execution context.
Key properties:
execution is semantic, not syntactic
operators may execute multiple times
relationships between executions are out of scope here
- Failure is not panic
Operator failure is not panic.
It is a first-class execution result that may propagate outward.
Whether a failure halts the system is a responsibility of the caller.
- Minimal Reference Implementation (v0.1)
The following code exists to prove that the above definitions are implementable in Rust.
pub trait Operator {
type Error;
fn execute(&mut self, input: Input) -> Result;
}
Notes:
&mut self explicitly allows internal state
no time, batch, or scheduling semantics yet
intentionally minimal
A trivial stateless example:
pub struct Sum;
impl Operator<&[f64], f64> for Sum {
type Error = ();
fn execute(&mut self, input: &[f64]) -> Result {
Ok(input.iter().sum())
}
}
Its purpose is conceptual, not functional.
- Non-goals
This article intentionally does not define:
state models
time semantics
batch consistency
DataFrame or Polars integration.
More...