alex/sots-re
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

lane BU: run 1's result reshapes the prediction; the run-2 test committed before run 2 finished

Browse source 
Run 1 falsified P3 as written -- the walk is NOT ascending element address,
0 of 5 sequences -- and handed back a sharper key: it is lexicographically
ascending in (fleet->Location*, fleet*), 5 of 5. Both are heap addresses.

Run 1 also found something the static read had missed: the newly minted fleet
ids are ALREADY on the fleet objects when the assignment walk claims them, so
the id-to-group pairing is decided upstream of AssignFleetsAndIssueOrders.

The cross-process test that separates 'the Location pointer is the key' from
'the Location pointer is a correlate' is committed here, while run 2 was still
loading and before its autosave existed.
This commit is contained in:
alex 2026-09-09 03:25:02 -04:00
parent ca6782f4ff
commit 232550595d
1 changed files with 40 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
findings/control-flow/fleet-visit-order-mechanism.md
View file

@ -279,3 +279,43 @@ here, exactly as in BP and BR.
*(To be filled in after the runs. This section is empty in the commit that carries the *(To be filled in after the runs. This section is empty in the commit that carries the
prediction.)* prediction.)*
---
## 2.6 A second prediction, committed after run 1 and **before run 2's autosave existed**
Run 1 is in and it did two things at once: it **falsified P3 as written** and it named a **sharper
key** than P3 had. Rule 2 says a prediction exists to be disagreed with, and the honest move when a
measurement hands you a better model mid-lane is to commit the new model as a prediction *before*
the next run, not to present it afterwards as what was meant all along. So:
**What run 1 measured** (details and the full log in §3). The walk order over the acquired-fleet
vector is **not** ascending element address — 0 of 5 multi-element sequences. It is
**lexicographically ascending in `(fleet->Location*, fleet*)` — 5 of 5**, with the fleet pointer
breaking the tie in the one sequence where two fleets share a Location. Both keys are heap
addresses. And the newly minted fleet ids are **already on the fleet objects at claim time**, so
the id↔group pairing is decided *upstream* of this function and this walk inherits it.
**The committed prediction for run 2**, written at 07:26 UTC while run 2 was still loading:
> **Q1.** Run 2's `aivisit` log is again `(loc, elem)`-lexicographically ascending in every
> multi-element sequence, and again not ascending in `elem` alone.
>
> **Q2 — the cross-process test, and it is the one that matters.** Identify the two groups by
> their ships, which are process-independent: the **system-384 group is the fleet holding ship
> 6976**, the **system-80 group is the fleet holding ship 5264**. In run 1, `loc(384-group)` =
> `0x3205b040` < `loc(80-group)` = `0x3205eb90`, and the autosave was `e913ff41…` — the branch on
> which **384 is visited first and takes id 1970**. Therefore:
>
> * if run 2's autosave is `724528ff…` (the 80-first branch, `(80,1970) (384,1986)` in list 10),
> then in run 2 **`loc(80-group) < loc(384-group)`** — the two Location objects land in the
> opposite relative order;
> * if run 2's autosave is `e913ff41…` again, then **`loc(384-group) < loc(80-group)`** again.
>
> **Falsifier:** the ordering relation between the two Location addresses failing to agree with
> the branch. That would say the Location pointer is a correlate on one process and not the key,
> and would push the mechanism back toward H1b or toward some third key.
>
> **Q3.** The fleet ids carried on the elements at claim time follow the same relation: on the
> `e913ff41…` branch the fleet holding 6976 carries `fid=1970`; on the `724528ff…` branch it
> carries `fid=1986`.