dau_core.hero¶

The temporal-finance hero workflow: the predeclared end-to-end pipeline composed from the dau_core.temporal goldens, plus the avoided-materialization cost model that is the paper’s core evidence:

quotes ─┐
        ├─> backward as-of ─> [market-feature map] ─> time bars ─> rolling moments
trades ─┘   (align)           (derive, fused)         (bar)        (roll)

The argument the model makes precise: the pipeline is a cardinality funnel. The align stage emits one market row per matched trade (N_mkt); the bar stage reduces those to a handful of bars per symbol (N_bar << N_mkt); the roll stage runs over the bars. A staged execution writes each stage’s output to DDR and the next stage reads it back — so it pays to materialize the large N_mkt market intermediate the bar reduction is about to discard. A fused execution keeps every intermediate on-chip and touches DDR only for the input stream and the final rolling output. The gain is not a magic primitive: it is the avoided DMA of the intermediate the bar reduction discards.

The per-row market-feature derivation (midpoint/spread/sign/signed_volume/dollar) is a map that fuses into the bar tile’s front chain stage (the q1/q6 shape) — it adds no materialized intermediate in either execution — so the cost model’s materializing stages are align → bar → roll. market_features is still run and returned as the feature output branch (not discarded).

Both paths are DMA-bound (compute overlapped), so the model computes each from the exact golden cardinalities and the measured per-tile record widths — a first-order estimate the silicon run validates, not a measured result.

No dataframe or numerical-runtime dependency: pure integer arithmetic over the temporal goldens.

Attributes¶

`INPUT_BYTES`
`MARKET_BYTES`
`BAR_BYTES`
`ROLL_INPUT_BYTES`
`ROLL_BYTES`
`ROLL_FIELDS`

Classes¶

`WorkflowStage`	One materializing stage and its cardinality: `in_rows` records of
`HeroResult`	The executed workflow: the materializing-stage cardinalities (the funnel),
`MaterializationCost`	The avoided-materialization accounting for one workflow run. `staged`

Functions¶

`run_hero_workflow`(trades, quotes, *, bar_width, ...[, ...]) → HeroResult	Run the predeclared workflow end to end over the goldens, recording each
`materialization_cost`(result) → MaterializationCost	Fused vs staged DMA accounting for an executed workflow. Staged pays each

Module Contents¶

dau_core.hero.INPUT_BYTES = 24¶

dau_core.hero.MARKET_BYTES = 32¶

dau_core.hero.BAR_BYTES = 48¶

dau_core.hero.ROLL_INPUT_BYTES = 8¶

dau_core.hero.ROLL_BYTES = 24¶

dau_core.hero.ROLL_FIELDS = ('open', 'high', 'low', 'close')¶

class dau_core.hero.WorkflowStage(/, **data: Any)[source]¶

Bases: dau_core.models.CheckedModel

One materializing stage and its cardinality: in_rows records of in_bytes in, out_rows records of out_bytes out (the tile’s own input/output record widths). A staged run DMAs both; a fused run DMAs neither (except the pipeline endpoints).

Create a new model by parsing and validating input data from keyword arguments.

Raises [ValidationError][pydantic_core.ValidationError] if the input data cannot be validated to form a valid model.

self is explicitly positional-only to allow self as a field name.

name: str¶

op: str¶

in_rows: int¶

in_bytes: int¶

out_rows: int¶

out_bytes: int¶

property read_bytes: int¶

property write_bytes: int¶

class dau_core.hero.HeroResult(/, **data: Any)[source]¶

Bases: dau_core.models.CheckedMixin, ccflow.ResultBase

The executed workflow: the materializing-stage cardinalities (the funnel), the per-row feature branch, and the stage outputs (for a bit-exact comparison against a CPU reference).

Create a new model by parsing and validating input data from keyword arguments.

Raises [ValidationError][pydantic_core.ValidationError] if the input data cannot be validated to form a valid model.

self is explicitly positional-only to allow self as a field name.

model_config¶: Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].

stages: tuple[WorkflowStage, ...]¶

market_rows: tuple[dau_core.temporal.MarketRow, ...]¶

features: tuple[dau_core.temporal.MarketFeatures, ...]¶

bars: tuple[dau_core.temporal.TemporalBar, ...]¶

moments: tuple[dau_core.temporal.RollingMoment, ...]¶

property funnel: tuple[int, ...]¶

input → market → bars → rolling (the fused feature map does not change cardinality).

Type:: Row counts down the reduction path

dau_core.hero.run_hero_workflow(trades: list[dau_core.temporal.TradeRow], quotes: list[dau_core.temporal.QuoteRow], *, bar_width: int, roll_window: int, tolerance: int | None = None, roll_value: str = 'close') → HeroResult[source]¶: Run the predeclared workflow end to end over the goldens, recording each materializing stage’s cardinality. roll_value selects the per-bar OHLC price the roll stage windows (ROLL_FIELDS); roll_window is the count-based window (>= 2, the tile’s minimum). Both input streams must be pre-sorted by (symbol_id, time) (the shared as-of / bar precondition).

class dau_core.hero.MaterializationCost(/, **data: Any)[source]¶

Bases: dau_core.models.CheckedMixin, ccflow.ResultBase

The avoided-materialization accounting for one workflow run. staged DMAs every stage’s read and write; fused DMAs only the pipeline endpoints (the input stream in, the final rolling output out). avoided is the intermediate materialization the fusion removes; dma_ratio is the DMA-bound speedup (both paths are DMA-bound with compute overlapped).

Create a new model by parsing and validating input data from keyword arguments.

Raises [ValidationError][pydantic_core.ValidationError] if the input data cannot be validated to form a valid model.

self is explicitly positional-only to allow self as a field name.

model_config¶: Configuration for the model, should be a dictionary conforming to [ConfigDict][pydantic.config.ConfigDict].

staged_bytes: int¶

fused_bytes: int¶

avoided_bytes: int¶

input_bytes: int¶

final_bytes: int¶

staged_jobs: int¶

fused_jobs: int¶

property dma_ratio: float¶: Staged / fused DMA. A no-work run (both zero) has no speedup (1.0); a genuinely nonzero staged cost with a zero fused cost is unbounded.

estimate_seconds(*, dma_bytes_per_sec: float, per_job_seconds: float = 0.0) → tuple[float, float][source]¶: (staged, fused) wall-clock estimates: DMA time plus a per-job tail (device setup + the one-job compute tail the overlap runner cannot hide). A DMA-bound first-order model — the prediction the silicon run checks.

dau_core.hero.materialization_cost(result: HeroResult) → MaterializationCost[source]¶: Fused vs staged DMA accounting for an executed workflow. Staged pays each stage’s read + write (the intermediate is written by one job and read back by the next); fused pays only the input read and the final write.