Split out of the generative-process instantiation work
(docs/design/generators_instantiation.md §9 Q3).
The question
simplexity/generative_processes/transition_matrices.py provides 16 process families:
coin, days_of_week, even_ones, fanizza, leaky_rrxor, matching_parens, mess3,
mr_name, no_consecutive_ones, post_quantum, rrxor, sns, tom_quantum, zero_one_random,
plus get_stationary_state and build_transition_matrices.
generators' transition_matrices/ covers roughly five —
zero_one_random, cycle, mess, bloch_walk, moon — plus expand_vocab / compress_vocab
augmentations. So deprecating this file as-is loses 11 process families.
What makes this different from the rest of the package: these are data, not behaviour. They are
functions returning transition tensors, with no interface, no state and no coupling to the runner.
Generators' USAGE.md says "Process definitions are your data, not our code — transition matrices
are inputs you construct; the repo does not own a process zoo" — and yet it ships
transition_matrices/ anyway. The status of that directory is genuinely ambiguous upstream, so it is
not obvious which way this file should go.
Because the deprecation is gated on parity, this also affects what "parity" means: if the zoo counts,
11 families need upstreaming first.
Options
- Keep it in simplexity as data. Nothing about a matrix constructor conflicts with processes
living in consumers; a vendored process needs matrices as input and can get them from anywhere.
Lowest cost, no duplication, and it does not block the gate. My lean.
- Upstream the missing families into generators. One home for process definitions, but it
contradicts generators' stated position on owning a zoo, and 11 families is real work.
- Each consumer vendors what it uses. Most faithful to the copying model. These are small enough
that duplication is cheap, but the numerically delicate ones (fanizza, post_quantum,
tom_quantum) are exactly where silent divergence between copies would hurt most.
Whichever way it goes, it should be recorded alongside the parity gate, since it changes the
gate's meaning.
Split out of the generative-process instantiation work
(
docs/design/generators_instantiation.md§9 Q3).The question
simplexity/generative_processes/transition_matrices.pyprovides 16 process families:coin,days_of_week,even_ones,fanizza,leaky_rrxor,matching_parens,mess3,mr_name,no_consecutive_ones,post_quantum,rrxor,sns,tom_quantum,zero_one_random,plus
get_stationary_stateandbuild_transition_matrices.generators'
transition_matrices/covers roughly five —zero_one_random,cycle,mess,bloch_walk,moon— plusexpand_vocab/compress_vocabaugmentations. So deprecating this file as-is loses 11 process families.
What makes this different from the rest of the package: these are data, not behaviour. They are
functions returning transition tensors, with no interface, no state and no coupling to the runner.
Generators'
USAGE.mdsays "Process definitions are your data, not our code — transition matricesare inputs you construct; the repo does not own a process zoo" — and yet it ships
transition_matrices/anyway. The status of that directory is genuinely ambiguous upstream, so it isnot obvious which way this file should go.
Because the deprecation is gated on parity, this also affects what "parity" means: if the zoo counts,
11 families need upstreaming first.
Options
living in consumers; a vendored process needs matrices as input and can get them from anywhere.
Lowest cost, no duplication, and it does not block the gate. My lean.
contradicts generators' stated position on owning a zoo, and 11 families is real work.
that duplication is cheap, but the numerically delicate ones (
fanizza,post_quantum,tom_quantum) are exactly where silent divergence between copies would hurt most.Whichever way it goes, it should be recorded alongside the parity gate, since it changes the
gate's meaning.