Brummel/Aura
1
0
Fork 0
Code Issues 31 Pull Requests Actions Packages Projects Releases Wiki Activity

Random param-sweep enumeration (C12.1 other half): ranges + sample-count + seeded RNG #52

New Issue
Closed
opened 2026-06-10 18:54:47 +02:00 by Brummel · 3 comments
Brummel commented 2026-06-10 18:54:47 +02:00
Owner
Copy Link
Copy Source

Cycle 0028 (#32) shipped the grid axis of the param-sweep (GridSpace
cartesian enumeration over per-slot discrete value-lists, in
crates/aura-engine/src/sweep.rs). C12.1 names grid and random enumeration;
random was deferred at the 0028 brainstorm as a deliberate scope cut.

Random needs machinery grid does not: per-slot continuous ranges (min/max)
rather than discrete value-lists, a sample-count, and a deterministic
seeded RNG (C1 seed-as-input; zero-dependency C16 -> hand-rolled, no rand
crate). The valid search-range belongs to the run (C20) and is still
undeclared — random is where range declaration first becomes load-bearing.

Shape (none chosen): a RandomSpace sibling to GridSpace producing N seeded
points over declared ranges, fed to the same sweep() execution layer —
the disjoint std::thread::scope core is enumeration-agnostic and already
shipped.

context: deferred follow-up from cycle 0028; not blocking.

Cycle 0028 (#32) shipped the **grid** axis of the param-sweep (`GridSpace` cartesian enumeration over per-slot discrete value-lists, in `crates/aura-engine/src/sweep.rs`). C12.1 names grid **and** random enumeration; random was deferred at the 0028 brainstorm as a deliberate scope cut. Random needs machinery grid does not: per-slot **continuous ranges** (min/max) rather than discrete value-lists, a **sample-count**, and a **deterministic seeded RNG** (C1 seed-as-input; zero-dependency C16 -> hand-rolled, no `rand` crate). The valid search-range belongs to the run (C20) and is still undeclared — random is where range declaration first becomes load-bearing. Shape (none chosen): a `RandomSpace` sibling to `GridSpace` producing N seeded points over declared ranges, fed to the **same** `sweep()` execution layer — the disjoint `std::thread::scope` core is enumeration-agnostic and already shipped. context: deferred follow-up from cycle 0028; not blocking.
Brummel added the feature label 2026-06-10 18:54:47 +02:00
Brummel commented 2026-06-14 22:23:28 +02:00
Author
Owner
Copy Link
Copy Source

Pairs with #57 (named sweep-point view), which is the prerequisite: random enumeration needs a named per-point view to report readable params. Sequence #57 first, then this. Both are the named↔positional half of the same sweep-ergonomics surface in sweep.rs.

Pairs with #57 (named sweep-point view), which is the prerequisite: random enumeration needs a named per-point view to report readable params. Sequence #57 first, then this. Both are the named↔positional half of the same sweep-ergonomics surface in sweep.rs.
Brummel added this to the The World, part II — orchestration families milestone 2026-06-14 23:08:30 +02:00
Brummel commented 2026-06-15 09:27:05 +02:00
Author
Owner
Copy Link
Copy Source

Design constraint (World-II eager-agnostic firewall — refs #71)

Keep the random-sweep contract param-only: RandomSpace::points() -> Vec<Vec<Scalar>> and the unchanged run_one: Fn(&[Scalar]) -> RunReport. Do NOT widen the sweep-layer signature to name a stream or producer type (e.g. no Fn(&[Scalar], &[impl Source])). Stream provision stays wholly inside the closure body, so a later lazy Harness::run is invisible to RandomSpace and sweep. The #52 param-sampling RNG and the Fork-B data-edge seed are distinct concerns that merely share the u64 manifest field; keep them code-path-disjoint.

## Design constraint (World-II eager-agnostic firewall — refs #71) Keep the random-sweep contract param-only: `RandomSpace::points() -> Vec<Vec<Scalar>>` and the unchanged `run_one: Fn(&[Scalar]) -> RunReport`. Do NOT widen the sweep-layer signature to name a stream or producer type (e.g. no `Fn(&[Scalar], &[impl Source])`). Stream provision stays wholly inside the closure body, so a later lazy `Harness::run` is invisible to `RandomSpace` and `sweep`. The #52 param-sampling RNG and the Fork-B data-edge seed are distinct concerns that merely share the `u64` manifest field; keep them code-path-disjoint.
Brummel commented 2026-06-17 10:56:39 +02:00
Author
Owner
Copy Link
Copy Source

Design reconciliation (specify, in-context entry)

Spec: 0049-random-param-sweep. The fork(s) below are still listed open on this
issue ("Shape (none chosen)" in the body); they were resolved in an in-context
design discussion with the user on 2026-06-17. The orchestrator laid out the
forks with recommendations and the user ratified.

  • Fork: Space abstraction (trait vs sibling function) → extract a Space
    trait (points() -> Vec<Vec<Cell>>, param_specs() -> &[ParamSpec])
    implemented by both GridSpace and RandomSpace; sweep becomes generic over
    impl Space, behaviour-preserving (C1) for the existing grid path.
    Provenance: presented as "A — Space trait" vs "B — sibling sweep_random"; the
    user chose A, verbatim "A und passt" (2026-06-17).
  • Fork: range declaration type → a typed ParamRange { lo, hi } carried
    positional-parallel to the param-space (not bare (Cell, Cell) tuples),
    validated in RandomSpace::new, with the lo <= hi invariant as a new
    SweepError variant.
    Provenance: recommended ParamRange over the tuple alternative; the user
    accepted it in the same "A und passt" (2026-06-17).
  • Fork: sampling semantics → uniform only; I64 inclusive [lo, hi], F64
    half-open [lo, hi); Bool/Timestamp rejected in new with a kind error
    (Timestamp is a structural axis, C20); no dedup of sampled points. The
    param-sampling RNG reuses the existing dependency-free SplitMix64, kept
    code-path-disjoint from the data-edge seed instance (this issue's World-II
    firewall comment).
    Provenance: recommended "uniform-only" resolution; the user accepted it in the
    same "A und passt" (2026-06-17).
## Design reconciliation (specify, in-context entry) Spec: `0049-random-param-sweep`. The fork(s) below are still listed open on this issue ("Shape (none chosen)" in the body); they were resolved in an in-context design discussion with the user on 2026-06-17. The orchestrator laid out the forks with recommendations and the user ratified. - **Fork: Space abstraction (trait vs sibling function)** → extract a `Space` trait (`points() -> Vec<Vec<Cell>>`, `param_specs() -> &[ParamSpec]`) implemented by both `GridSpace` and `RandomSpace`; `sweep` becomes generic over `impl Space`, behaviour-preserving (C1) for the existing grid path. Provenance: presented as "A — Space trait" vs "B — sibling `sweep_random`"; the user chose A, verbatim "A und passt" (2026-06-17). - **Fork: range declaration type** → a typed `ParamRange { lo, hi }` carried positional-parallel to the param-space (not bare `(Cell, Cell)` tuples), validated in `RandomSpace::new`, with the `lo <= hi` invariant as a new `SweepError` variant. Provenance: recommended `ParamRange` over the tuple alternative; the user accepted it in the same "A und passt" (2026-06-17). - **Fork: sampling semantics** → uniform only; `I64` inclusive `[lo, hi]`, `F64` half-open `[lo, hi)`; `Bool`/`Timestamp` rejected in `new` with a kind error (Timestamp is a structural axis, C20); no dedup of sampled points. The param-sampling RNG reuses the existing dependency-free `SplitMix64`, kept code-path-disjoint from the data-edge seed instance (this issue's World-II firewall comment). Provenance: recommended "uniform-only" resolution; the user accepted it in the same "A und passt" (2026-06-17).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
BLOCKER
Core functionality blocked; preempts other selection
 bug
Observable misbehaviour
 feature
Substantial extension; no full spec required
 idea
Droppable; no commitment
No Label feature
Milestone
No items
No Milestone The World, part II — orchestration families
Projects
Clear projects
No project
Assignees
Clear assignees
claude (Claude) Brummel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Brummel/Aura#52
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?