/* #p8v2_gen3 @pprog_p8v2_gen2_report_20260806 @pprog_p8v2_gen1_choices @variant_protocol @f-p8 @pp_wordsv2 @hutter_e64_viewer_prereq_20260805 MJC We're going to start folding things back into the P-program, reducing the ambiguity of what lives where. This document is written mainly in response to the viewer at https://cmpr.ai/hutter/pprog/p8v2-e64/. Main drive on gen3: we will nail down the f and settling stuff. There may be new axes that we vary on, but within a tighter range. (All of this is of course a response to gen2.) A1 isn't what we want, so that's gone. A2 is the promising direction. A3 was not anything that I wanted, although I may have mentioned something about renormalization, but it wasn't this. A as described on the e64 page: - still using the message terminology which we do not use - of the patterns having this event as a consequent, longest wins - correct UM-native description of A1 - this is still valid for k=2 vs k=1 as k=2 is a subset of k=1, but it's not totally correct either - k=1 has information from a broader range of positions - if k=2 fires, it is sharper, but it is also necessarily lower-support because it is a more specific event - since k=2 replaces on some but not all events, it competes with k=1 on a larger set of events in the same ES, and these will have more support; this is apples-to-oranges since these haven't been normalized into probabilities in each ES; see discussion about microstates/probability theory/LATD below. A1 was already pruned, but it's still interesting as a use case for visualization. A2 is the interesting line. This is biologically plausible: neurons fire at different rates, and neuron activation is dependent on the rate of inputs that fire during some span; what is missing is some rationale that maps this back onto probability theory (see below). The rule here isn't exactly what we want yet. The idea is this: We have inputs (from a specific pattern length, let's say k=1) at a rate f (here k=1 is the fastest rate). (The collision with f the update rule is more than a coincidence.) But this depends not only on the pattern length (therefore frequency by way of f (the update rule)) but also on the activations of the antecedents, and the strengths of the patterns. If the incoming patterns have w=1 on every event, the model is saying that we have seen every possibility happen once. At the other extreme, if we have w=255 coming from an antecedent event at 255, the model is saying we have an absolute rule from an absolute event. The idea of 2f is this: - have some information flowing in from the left and from the right - we don't know (in general) what the left and right values are - we do know that the left and right ESs are ESs, and they have total probability = 1 - whatever distribution we have on the left and right ES, under whatever patterns we have in each direction determines how the fall-off should work - the patterns that we have coming in at different pattern-lengths, i.e. from different support on the actual dataset, determines what the correct behavior is; i.e. the behavior that under the \omega we choose will give the settling result that recreates the data The implementation of A2 interpreted this as "subtracting 2" from every event, which is not what we meant, but it's something. I think what we actually want is this: - firing depends on the probability interpretation of each ES - however, we don't need to do a bunch of fp exp/log operations, we can stay in the cheap integer ops on bytes domain - obviously if we have one event at 255 and all others at 1 or 2, then only the one event fires The general idea is that things settle across the uncertainty window from the fixed anchors, through the Markov chain, i.e. through the LPPs that we have. This is what we want to be able to play with in the visualizer. On the e64 page we have a worked example at pos 37. Mostly what this worked example shows is that we need better visualization; scrolling through a multi-hundred-line JSON object is not what we want. ## Probability / LATD / microstates The interpretation as probability distribution of LSA support values is via softmax, which is expensive, and often unnecessary. What we want is to replace this expensive approach with something that is justifiable under probability theory, biologically plausible, and cheaper. One way to resolve all these issues at once through visualization is our old principle of LATD (a term from ../hutter, which see). Practically this means: Every operation of f is an operation on activations and patterns. Currently e64 page is showing a bunch of things that are not that; we want to get back to f described in one place, and each application of patterns via f starting from SN, going into interpretable arithmetic operations (i.e. ordinary arithmetic, or LSA operations if a table is provided on the page that states what those operations are, no more "lsa_ceil_log2"). SN means that every pattern is interpretable. LATD means that every pattern can be expanded to the set of input positions which it records. If all of this is in the viewer, then we have what I want. The connection to microstates is that in a physics model, statistical mechanics connects probabilities to sets of arrangements of things, but in those cases the numbers are large and the individual possibilities are not really practical to observe or visualize (though they can be sampled from a distribution). Here we have a dataset of a very practical size to see everything that has ever happened. So even if we have to reconstruct it after the fact by querying, we can trace every pattern back to specific input positions which are responsible for it. Then the probability interpretation becomes intuitive to read out, and becomes a question of which patterns are correlated, which are independent, which have logical relationships that we can describe, and so on. This is the way that we will understand how the model should continue to grow, based on practical examples. On the C axis, we have a similar question and the same answer. - the token_and-min rule makes sense but somewhat ignores the rest of each ES; whether this is handled by decay is an open question - C2 is definitely wrong because it drops weak signals and therefore can't support settling in the way we want it to work. On the D axis, we have a key question: is the trace every causal surprise or those minus what settling can recover. The answer is a radical one, that settling will be extended to multiple indeterminacy windows, and it should become a tunable that lets us control decode cost against compression rate. D3 is in the general direction of what we want, but making further progress here requires all of the above to be addressed first. -MJC -- Claude ## THE GEN 3 PLAN, AND THE CHOICES IT WAITS ON Added 2026-08-10, reading the push above as an implementation plan. Six workstreams in dependency order; 2 and 5 cannot start until the choices at the bottom are made. 1. THE FOLD-BACK PASS (no runs, no measurement). "Reducing the ambiguity of what lives where" is an inventory: decisions that today live in the parent-side C (#pp_wordsv2) or in the generated skeleton rather than in the P-program. Found so far: the application rule min(w_p, w_s), frozen since generation 1 and stated only in #pp_wordsv2's "frozen across every variant" paragraph; W = 128 with one sweep per position and non-overlapping window tiling, in #pp_settle / #pp_dump; the clamping policy and settle_argmax's tie-break to the smallest index, which decides the answer at e64 and is the same class of thing as generation 2's lsa_add nesting; and initialisation to 256 zeros, recorded as a consequence in #pp_wordsv2 rather than as a rule. Products: #f-p8 rewritten as the single normative statement of f in activations, patterns and applications, with MESSAGE GONE as a word; each item above moved into an OFRA block; and an LSA operations block giving every operation in ordinary arithmetic, which is what retires "lsa_ceil_log2" as a name the page has to show. Cost: only blocks whose own NL moves get regenerated, per the cache-key finding in #pprog_p8v2_gen2_report_20260806. We can do this by adding questions or variant OFRA blocks for #f-p8. A lot of the choices above (W = 128 with one sweep, the use of the term "sweep", the non-overlapping windows, the fact that there's a tie-break instead of dynamic settling effects breaking ties) are things I want to explore dynamically, so we may be adding some ambiguity back into f, from choices that were previously made by Claude in C code just to get an implementation up and running; these choices should get ramified through the visualization layer as variants. P remains constant in most of our axes (only sparsification really touches it) and f is currently where the action is. -MJC 2. AXIS A, THE TIGHTER RANGE. The push gives desiderata and not a rule: firing depends on the probability interpretation of each ES, in cheap integer ops, with the 2f fall-off falling out of the constant-sum invariant rather than being a subtracted constant. Under #variant_protocol these are alternatives, not a decision, and A2 stays as the control. Candidates in question A below. Runs at e64 and e1k so they return while you are waiting; e10k and up fired off in the background and folded into the render when they land. 3. LATD EXPANSION IN THE QUERY LAYER. Given an atomic pattern, the set of input positions that formed it, reconstructed parent-side by replaying learning against (program text, model file) the way --explain already replays bytes -- on-demand reconstruction, never de-optimization. This is what makes the microstates argument concrete: every pattern traces back to the positions responsible for it, so which patterns are correlated and which independent is read off the data. 4. THE VIEWER. A panel that IS f: for one position and one sweep, every pattern application in SN with its arithmetic, in order, ending in the new activation vector. The LSA table from step 1 on the page. Click a pattern, get its input positions (step 3). The pos-37 worked example replaced by that panel, so the multi-hundred-line JSON goes. Controls for the new alternatives, keeping the every-axis-gets-a-control convention. Data ours, publication ../hutter's, linked the way axes.json is. 5. AXIS D, AFTER A IS PICKED. Two changes, both from the push: the removal test settles from what the DECODER actually sees, which is why generation 2's D2/D3 did not round-trip -- the encoder clamped the sample's neighbours and the decoder cannot -- and settling extends across multiple indeterminacy windows with the count as the tunable that trades decode cost against rate. 6. AXIS C. C2 takes its PRUNED line now (drops weak signals, so it cannot support settling). The live question -- min ignores the rest of each ES, is that handled by decay -- is answered by showing the whole ES at each gate evaluation on the page, not by a new alternative. Generation 2 found the gate never binds only because the learned weights are 1 or 2; if the step-2 rules change what the weights look like, C becomes measurable for the first time. "Feedback from the programmer here." 255. ## The choices A. The f rule. Is this the tighter range, or is the rule already in mind? a4 renormalize each unclamped ES to the constant sum; the fall-off is implied, no rate constant a5 each pattern fires at a rate set by its own support, the second parameter #f-p8 names a6 an event fires only when it dominates its ES by a margin (the one-at-255, rest-at-1-or-2 case) other state the rule and we build that instead Yes to a5. There is no constant sum ever in an ES. The only thing constant is total probability = 1 and that is after softmax. In an ES we are only ever talking about log support values, which don't have a constant sum. However, there is a constant sum in something like an m-1 model which is generated from a known DSS. -MJC B. The application rule min(w_p, w_s), frozen since generation 1. b1 stays frozen; the probability argument in #f-p8 pins it b2 becomes an axis in generation 3 (w_p - (255 - w_s) is the recorded rejected form) b1 is the rule. -MJC C. The baseline, given that A2's decay is "not what we meant". c1 #wordsv2-v002 stays the baseline and every new rule varies off it c2 the first new rule that works becomes the baseline and v002 becomes the control D. The multi-window settling tunable. d1 an axis, with two or three fixed window counts d2 a hyperparameter in #omega-p8-hyper, one value per run, swept outside the axes D needs visualization and more options. My eventual idea is that we will have not a sliding window at all, but a sequence of windows, once each one settles, then the next one comes up. However, we may have cross-window settling, which involves total-entropy arguments and decode-time computational tradeoffs for higher compression. Needs experimentation via the vizualization layer, after other axes settle a bit further. -MJC E. The LATD surface (pattern -> the input positions it records). e1 a new verb beside --patterns and --explain; name it e2 a section added to --patterns output Probably a new verb, or it can be the explanation of a pattern (which it literally is). Interface shape left up to Claude for now. Output should be SN clusters: the set of events that caused a pattern to be what it is. (These can be stored in a compressed way, e.g. literally as just input positions, but presented by viz layer as SN.) (Could also be presented very nicely e.g. concordance-style or other NLP viz conventions; also left up to Claude for a first pass.) -MJC F. The fold-back scope: which of step 1's four move into the P-program now? f1 the application rule | f2 W, sweeps and window tiling | f3 clamping and the argmax tie-break | f4 initialisation | all of them All of them. G. The viewer. g1 rebuild p8v2-e64 in place; the gen2 page stops existing g2 a new gen3 page; p8v2-e64 stays as the generation-2 record g2 Let's establish a convention for versioning viewers along with the contemporaneous other artifacts; something lightweight. */