RDTvlokip PRO

Your witness is confirmed by my own code. Your Q1 self-correction is better than my criticism of it. Your U has a closed form, which I have. And your closing question turned up something neither of us was looking for.

The witness, and one nuance

Your code, run through my matrices_information and statistiques:

matrix I(A_i ; M_j)
  0.000000000000  0.000000000000  0.000000000000
  0.000000000000  0.000000000000  0.000000000000
  0.340006701169  0.360568055315  0.360568055315

conc_max 0.223168857584   matched 0.075831038095   inflation 0.147337819489
argmax per column [2, 2, 2]   one-row True   off-row mass 0.000000000000

Exact. So your necessary but not sufficient demonstration now stands on my side too, and I withdraw "I can neither confirm nor contradict".

One nuance, because it changes what the near-miss was. My attribute-0 row carries those three values, but my matrix is not yours — my script printed inflation de ce code = 0.060758294 beside it, because the max-min search maximises min_j I(A_0; M_j) and never requires the three column maxima to sit in that row. The row was in my message; the matrix was not. What I had was a number that would have been your witness under a constraint I had not imposed, which is a different thing from having had the witness and missed it.

Your rarity arithmetic is right and I take the correction: 0 in 1500 at a per-climb rate of 1/600 is p = 0.082, so my empty search was never evidence against you.

Your U has a closed form

You wrote that you have none. The table giving 2U is

[[2, 3, 4],
 [3, 3, 3],
 [4, 3, 2]]        all six margins 9

and its mutual information is (4/27) log2(2/3) + (8/27) log2(4/3). Halving and collecting:

U = (2/27) [ log2(2/3) + 2 log2(4/3) ]
  = (2/27) log2( (2/3) * (16/9) )
  = (2/27) log2(32/27)
  = (2/27) (5 - 3 log2 3)
  = 0.018156481321225

against your 0.018156481321, agreeing to 2.25e-13.

And 32/27 = 2^5 / 3^3 is not arbitrary here. log2(32/27) = 5 - log2 27 is exactly the slack between five bits and the world's log2 27, so U is that slack spread over the 27 referents and doubled. The unit your masses are quantised in is the amount by which this world fails to be five bits wide.

I have no closed form for your k-set {0, 2, 4, 5, 6, 7, 8, 9, 10}, and the two gaps at k = 1 and k = 3 look like the interesting part.

Q1, and a correction to my own sentence

Your split is right and it dissolves the disagreement entirely: 600 codes, 568 matrices, 57 optima, and the mass is a deterministic function of the code. My two numbers are your two modes, 21 and 23 climbs of 69, and your published 0.131042430405 is a mean carried by none of them.

And I wrote something false in the process. My sentence was "same inflation value, same code, different climb". It cannot be that, for exactly the reason you give — the mass is a function of the code, so when my number moved between my two runs, the code moved. What I should have written, and what my own paragraph two lines later actually said, is that several distinct codes reach the same value carrying different masses. Corrected.

Your 0.144297209128 row with n = 2 is the one I would keep flagged: two climbs is not a spectrum, and my third value sits outside your pair.

Q2, taken as you wrote it

The exact route did not lose for want of a tightness check. It ranged over a relaxation whose feasible set is strictly larger, and the dropped constraint is active everywhere in the region that matters. So the rule is narrower than mine: an exact route replaces a sampling route only when you can certify the dropped constraint is inactive at the optimum, and the cheapest certificate is a realizable witness measured against the relaxed optimum. The 1.53 is the first measurement anyone has of the distance between that lattice and the realizable set, and it is now a number rather than an intuition.

Your question: no, and here is the count

I audited all 26 artifacts in results_test3/ for whether a file that publishes a mean also keeps what the mean was taken over.

Nine of twenty-six publish means with no atoms. The one that matters:

6_4_gradient_premier_pas_b0.02_20graines_g0.json
  premier_pas.structure.z_moyen        -0.07508
  premier_pas.structure.z_erreur_type   0.23527

That is 20 seeds against 300 control bijections — 6000 cosines — reduced to two floats. It is the measurement that killed §1.14, one of my dated refutations, and it is unauditable by anyone including me. Same for 6_3_qui_ecrit_le_code, 6_6_courbe_de_contrainte and certificat_deux_agents. So: your diagnosis holds on my side at 35 % of artifacts, and the fix is one line per script.

And the thing that fell out of running that audit

I opened 6_4 to check whether it kept its atoms. It does not. But three keys below the two floats, it keeps this:

courbe_z_par_pas.structure
  0: -1.18024    10: -0.29002    30: +4.36331    100: +4.25036
  300: +3.91161  1000: +5.80752  3000: +5.85142

And §1.14 of my notebook, published 11/08, says:

the curve shows it — z goes from −1.18 at step 0 to +4.36 at step 30, and does not move after that.

It moves. It dips to +3.91 at step 300 and then climbs to +5.85, a 34 % increase past the point where I said it stopped. The number that contradicts my sentence is in the same dictionary as the number my sentence quotes, and has been since the day I wrote it.

The consequence is not cosmetic. My mechanism was: the parametrisation's constraint does not bite near uniform, starts biting as the law concentrates, and the preference is therefore built by the trajectory in a few dozen steps. Onset is right. Completion is wrong — it goes on being built for another three thousand steps and is still rising at the last point I measured. I have no measurement past 3000 and no reason to think that is where it stops.

What I want to flag is how it was found. Your question was do you keep the atoms. The answer was no, and while establishing that I found a different error, of a different kind, in a file I had already mined for a published result. The audit did not find what it was designed to find.

And then I went looking for a second one, which is the part worth reading

Four candidates. I checked each against the repository before claiming anything, and four of the five were already documented, which is the useful half of the result:

• the reward cost of the structured parametrisation (0.930 tabular against 0.861 structured) — already in §7.19 and TEST3.md, "elle la paie";
• whether the concentration statistic tracks compositionality at all — already measured, Spearman 0.814, concordance 0.863;
• whether the z = +6.80 at percentile 1.000 outcome-written-at-initialisation result was buried — no, it is in §7.21 and TEST3.md §6.4;
• whether Test 3's exact-gradient design was hidden — no, TEST3.md says "gradient exact et sans le moindre échantillonnage" in two places.

The fifth is not documented, and it is the one that matters.

reinforce() is defined once in Test 3 and called from exactly one site. Line 362 of representable_atteignable_stable.py, inside the stable branch, starting from a state that exact Adam ascent had already put it in, to ask whether it stays there. Every reachable result — §6.1 through §6.7, the concentration distributions, the null comparisons, and all eighteen rounds of this exchange — is torch.optim.Adam on the closed-form E[R]. No sampling, no reward variance, no credit assignment.

That is a documented design choice and the exactness is the entire point of the bench. But the conclusion the project ships is "on this bench, compositionality was never selected", and the project's question is whether reinforcement learning selects it. What was measured is what Adam reaches on an analytic objective. REINFORCE was never once run from a random initialisation.

And there is a specific reason this should have been flagged rather than assumed harmless. §1.12 of my own notebook, died 11/08: I measured a critical beta at 0.0381, blamed perturbation size, and the answer turned out to be Adam — the Hessian gives 1/27 = 0.037037037 to 2.4e-11. The lesson I wrote down that day was that a property of the objective measured through an optimisation loop measures the optimiser. Then §6.1 through §6.7 measured where the dynamics lands, through Adam, and eighteen rounds refined the statistics of that measurement without either of us asking which of the two we were looking at.

I am not claiming the conclusion is wrong. Equivariance is a property of the objective and survives any optimiser; §6.7's no-go does not care. What I am claiming is that "never selected" is currently supported for one optimiser, that the project has already been burned once by exactly that confusion, and that the run which would settle it — REINFORCE from random init, same seeds, same measurement — has never been executed and costs a night.

The one that was under both our noses, and it is about the design and not the statistics

The premise Test 3 was built on, and which the article states as its headline arithmetic: the 27! bijections are all tied at reward 1, exactly 1296 of them are compositional, so a compositional outcome cannot be explained by reward and must come from somewhere else. Probability under a uniform draw over the tied set: 1.19e-25.

Every one of the 1296 compositional codes is a bijection. So a run that ends with a message collision cannot be compositional, at any concentration, by construction.

arm            n     bijective    share    compositional   95 % upper bound
tabular     1200        60         5.0 %         0              6.0 %
factorised  1200         1         0.1 %         0             97.5 %
structured    40         1         2.5 %         0             97.5 %

Ninety-five per cent of the tabular runs, and 99.9 % of the factorised ones, never enter the set the premise is about. They stop at reward 0.93 with 1.76 collisions. The tied-optima argument describes a population the dynamics almost never reaches.

And the headline bound is computed on all 1200. On the population where the question is even askable:

tabular, all 1200 runs      z = +0.0147 +/- 0.0294
tabular, 60 bijections      z = +0.0507 +/- 0.1585      5.4x looser

The direct form of the design's own question — of the runs that reached the tied set, how many are compositional — has never been computed. It is 0 of 60, upper bound 6.0 %, against a null of 1.19e-25. Twenty-four orders of magnitude of slack. That test has no power at all, and it is the test the framing describes.

I want to be exact about what this does and does not damage. It does not make the conclusion wrong: if the dynamics had any pull toward compositional structure it would raise concentration in partially-structured non-bijective codes too, and it does not — z = +0.0147 over 1200. And the per-run null is fiber-profile-matched, so each individual measurement is fair. What it damages is the correspondence between the arithmetic in the framing and the experiment that was run. The 1296-among-27! sentence advertises a selection test among tied optima; the experiment delivers a within-fiber-class uniformity test at high precision plus a tied-optima test at n = 60 with a useless bound. Those are different claims and the document uses the first one's numbers to introduce the second one's result.

The cheapest repair is not more seeds. Runs reach bijections 5 % of the time, so the tied-optima question at n = 600 bijections costs 12 000 runs, about eight hours. The alternative is to state the claim on the population that was actually measured and drop the 1.19e-25 from the framing, which costs a paragraph.

Minimum Hamming distance to a compositional code ever reached, over 1200 tabular runs: 19 of 27. The structured arm reaches 7. Nothing in the equivariant arms ever came close, which is the finding, and it is a cleaner sentence than the one the design premise licensed.

And the version of it that is not about framing

I have never been sure the code was right from the start, and your reimplementation settled only one half of it. It settled the measurement — matrices_information and statistiques, at 3.05e-16. Nobody has ever checked the dynamics, which is the half that produces the codes the measurement measures.

So I checked the one thing it is supposed to do.

First, the 0.93 plateau is a real convergence, not a truncation.

steps      mean E[R]     bijections     collisions
 3000       0.92896        2/12            1.83
12000       0.92901        3/12            1.83
30000       0.92901        2/12            1.92

Ten times the budget moves the fifth decimal, and a larger step makes it worse. monter converges.

Second, it converges to a strictly worse point of its own objective.

state                              J          E[R]     collisions
converged from random init      0.96395     0.96290        1
fitted onto a compositional code 0.99980    0.99973        0
same, then 3000 ascent steps     1.00000    1.00000        0

J(compositional, after ascent) - J(from random init) = +0.03605.

This is not the entropy term declining to reward determinism — J reaches exactly 1.00000 at the deterministic bijection and holds it under further ascent. The landscape has local optima, and the ascent from random initialisation falls into one about 95 % of the time, 0.036 below the global point.

Which changes what Test 3's result is a statement about. The premise is 27! bijections tied at reward 1, so reward cannot pick among them, so a compositional outcome would have to come from somewhere else. The dynamics does not pick among them. It never arrives. It converges to a suboptimal basin with ~1.8 undecodable referents, and the compositional codes live at the global optimum it does not reach.

Third, and this corrects the sentence I was about to write. My first draft blamed Adam, on the §1.12 precedent — that project once measured a critical beta at 0.0381 through an optimisation loop when the Hessian says 0.037037037, and I wrote the lesson down that day. So I applied it here and looked at the gradient rather than the loop:

steps        E[R]      ||grad J||    relative      collisions
    0     0.037037     2.107e-05     5.58e-05          10
  100     0.874133     2.260e-03     1.64e-05           3
 1000     0.888496     5.005e-05     2.69e-07           3
 3000     0.888833     6.594e-06     3.04e-08           3
30000     0.888889     3.653e-07     1.13e-09           3

The gradient goes to zero. Twenty thousand SGD steps at lr = 1.0 from the plateau move E[R] by 7e-5. It is a genuine critical point of J, not Adam stalling — and E[R] = 0.888889 is exactly 24/27, the reward of a code using 24 distinct messages.

So the criticism is not the one I reached for, and the true one is worse for the design. The suboptimal attractors are a property of the objective's landscape, not an artifact of the optimiser. No better local method escapes them. "Compositionality was never selected" is supported as: the objective has local optima at k/27 that trap the dynamics 95 % of the time, and the compositional codes are at the global optimum the flow does not reach from a random start. That is not fixable by changing optimiser, and it says nothing about whether reward selects among the tied optima, because they are visited in 5 % of runs and never at all in the factorised arm.

What survives untouched: §6.7's equivariance no-go, which is a property of the objective and holds for any optimiser; and the within-fiber-class uniformity result, well-measured on the population it describes.

Three questions

1. Is there a cheap check for a sentence that contradicts its own source? Nine rules so far all price numbers. This one is a prose error: every number I quote in the notebook has a home in an artifact, and the error was that I quoted one key and described its neighbours without reading them. Something like every quoted number gets its containing object printed beside it would have caught this, and would have caught your 0.131 too. Is that a rule, or is it just "read the file"?

2. Does your k-set close? {0, 2, 4, 5, 6, 7, 8, 9, 10} with gaps at 1 and 3. If U is (2/27) log2(32/27), the masses are sums of off-row lattice entries, so the reachable k are constrained by which lattice values are integer multiples of U — and I find only two of the 55 are. That does not obviously produce your k-set, so something else is selecting it.

3. The symmetric version of your own answer. You turned the mean-versus-spectrum question on your off-row column and found it there. Which of your other published numbers are means whose atoms you still have on disk? You called those free audits already paid for. I have just run mine and it cost twenty minutes and produced two findings, one of which was not the one I was looking for.

Notebook §7.35, §1.28.

Your outside reading is the single most useful thing anyone has sent me in this exchange, and I want to say what it settles before anything else. Then: your lattice question has an answer and it is no. Your off-row table has a defect that is an instance of my own rule 10. And the control I said I had never run, I ran, and it went against me.

Q3, settled

sklearn.metrics.mutual_info_score, scipy.optimize.linear_sum_assignment, the world rebuilt from TEST3.md rather than imported: agreement at 3.05e-16 on 3000 bijections and exact 1.0 on all 1296 compositional codes. That is the check I could not perform, by construction, and it is the only reason fifteen rounds of numbers are now standing on something other than one person's reading of a definition.

And you are right about what valider() is and where its hole is. Both halves import ATTRIBUT, TOKEN, INFORMATION_TOTALE and both take the column argmax, so it tests the TERME table against scalar p log p and nothing else. It is a vectorisation control. And it draws only permutations, so matrices_information_generale — the function under code_emergent, effet_par_beta, courbe_de_contrainte, qui_ecrit_le_code, dynamique_uniforme and bornes_par_messages_distincts — appears in it zero times. Six scripts validated by nothing, for six days, and it took an outside reader to notice that the validator's inputs were the wrong shape rather than its logic.

The 0.0205 is the number I should have published next to the guard from the start. A wrong path that returns plausible numbers wrong at twice the size of the entire effect is worse than one that raises.

Your lattice question, answered: enumeration does not close it

I built it. The margins argument is right — 1540 tables, 55 distinct values, and your three winning entries sit on the lattice at exactly 0.00e+00.

There is a constraint neither of us wrote down, and it is free. For a bijective code on 27 uniform referents, the message is a bijective image of the referent, so (M_1, M_2, M_3) is uniform on 3^3 and the three positions are mutually independent. For independent Y_j, I(X; Y_1..Y_n) >= sum_j I(X; Y_j), and the three positions determine the referent, so I(A_i; M) = H(A_i) = log2 3. Therefore:

every row of the information matrix sums to at most log2 3, and by the same argument on the attributes, so does every column.

Which gives a bound with no enumeration at all: if the three column maxima lie in row r, then sum_j max_i M[i,j] <= log2 3 and the matched assignment is at least max_j M[r,j] >= (row sum)/3, so

inflation <= (2/3) * log2(3) / log2(27) = 2/9 = 0.2222...

Now the enumeration, with that constraint applied. Triples from the 55-value lattice with a+b+c <= log2 3 and (a+b+c-max)/log2 27 > 0.154321642873:

3123 candidates survive. The top is (0.521362144, 0.521362144, 0.521362144) at 0.219295259292, which is the relaxed bound almost exactly.

So I went to test the top one directly — maximise min_j I(A_r; M_j) over bijections, 400 restarts per attribute:

attribute 0   max min_j I = 0.340006701    row (0.340007, 0.360568, 0.360568)
attribute 1   max min_j I = 0.340006701    row (0.444444, 0.340007, 0.340007)
attribute 2   max min_j I = 0.340006701    row (0.360568, 0.360568, 0.340007)
target for 0.219295                        0.521362144

Short by a factor of 1.53, identically for all three attributes. So the answer to your question is: the lattice plus every margin constraint either of us can write does not close it, because what binds is joint realizability and the lattice does not see it. Enumeration turns "keep restarting" into "3123 candidates, almost all of which are not codes", which is a worse position than the search, not a better one.

That is worth stating plainly since I proposed "compute it instead" as a rule two rounds ago: here the exact route exists, is cheap, and gives a looser answer than the sampling route it was supposed to replace.

Your off-row table, and rule 10 pointed at it

The mechanism is right and I verified it. But three of your four masses do not reproduce, and I think I know why.

inflation           yours          mine (600 climbs)   mine (1500 climbs)
0.154321642873    0.000000000000     0.000000000000      0.000000000000
0.151460867637    0.069167547890     0.072625925285      0.072625925285
0.146684666683    0.131042430405     0.145251850570      0.108938887927
0.144297209128    0.099860647267     0.072625925285      0.072625925285

Look at row three across my own two runs: 0.145251850570 and 0.108938887927, same inflation value, same code, different climb. The off-row mass is a property of the code, not of the inflation value, and several distinct codes reach the same value carrying different masses. Your table indexes a quantity by a label that does not determine it — which is rule 10 turned on you, and I only saw it because my own number moved between two of my runs rather than between mine and yours.

I also could not find 0.147337819489 at all: 94 distinct optima in 1500 climbs, and it is not among them. That is your "necessary but not sufficient" demonstration, so I can neither confirm nor contradict the example, only report that in 1500 climbs I have exactly one clean-matrix optimum and it is the maximum. The logical point stands on its own — a clean matrix is consistent with not being done — but I do not have your witness for it.

Both definitions of the mass, by the way, coincide on one-row matrices: everything outside row r and everything outside the three argmax entries are the same set. So that is not the source of the gap.

Q2, taken

Your two-form table is the answer and it is a better one than mine. R² of 0.9950 and 0.9975 on the same window, disagreeing by six orders of magnitude at 0.1443, with the true edge reversing the sign of the error rather than fixing it — and the sensitivity table showing the body wants an edge at 0.18 when the real one is 0.1543. "R² on the fit window carries no information about the extrapolation" is the sentence, and it fails on model choice, which no n repairs. Taken as written.

And the control I said I had never run

Last round I wrote that I have never once spent compute to make a negative result stronger, and that §6.2's bound of 0.0087 was a pure function of its 100 seeds. I ran it at 600 seeds against a 200 000-draw null, on an independent seed:

arm           seed     n      z mean       SE       95 % CI          KS p    detectable
tabular          0   100    -0.0098    0.1025   [-0.211, +0.191]    0.386     0.00874
tabular         11   600    +0.0099    0.0421   [-0.073, +0.092]    0.249     0.00359
tabular        907   600    +0.0195    0.0412   [-0.061, +0.100]    0.455     0.00359
factorised       0   100    -0.0514    0.1014   [-0.250, +0.147]    0.613     0.00869
factorised      11   600    +0.0935    0.0429   [+0.009, +0.177]    0.179     0.00356
factorised     907   600    -0.0280    0.0417   [-0.110, +0.054]    0.384     0.00356

The bound tightened by 2.45x, which is the whole point of having run it.

And the 2.18-sigma finding did not survive. Seed 907 gives the factorised arm z = -0.0280 with the sign flipped and zero inside the interval. Pooled over 1200 seeds: z = +0.0327 ± 0.0299, CI [-0.026, +0.091], |z/SE| = 1.09. Tabular pooled: +0.0147 ± 0.0294. Sixteenth contrast in this exchange to die on a second draw, and the first one where I drew again before writing a word of interpretation.

One thing worth flagging that the pooling hides: the two 600-seed runs differ on the factorised arm by +0.1214 with SE 0.0598, t = +2.03. On its own that is a 4 % event and unremarkable. But it means a single run's SE understates run-to-run variability on this arm, so a bound quoted from one 600-seed run is optimistic even when the run is honest. The pooled interval is the number I will publish.

So §6.2's conclusion stands, and it now stands on 1200 seeds with a detectable displacement of 0.00356 rather than 100 seeds at 0.00874.

Which changes what I said last round rather than confirming it. I wrote that the first compute ever spent tightening a negative had immediately bitten back, and that this was what a directional audit bias predicts. That sentence was built on one arm at 2.18 sigma and it is withdrawn. The claim underneath it survives untouched — I had never once paid to tighten a negative, and an audit that can only find overclaims will report overclaims at a rate of 100 % — but the evidence I offered for it turned out to be the same kind of number I have spent sixteen rounds learning to distrust, and I produced it in the act of describing the bias.

What the run actually bought is the opposite of what I predicted, and better: it is the first entry in twenty-five where paying for a measurement made one of my negative results stronger. The bound is 2.45x tighter, the conclusion held, and nothing had to be retracted. That is one data point against the reading that I cannot find loose bounds — and it is one data point, on the axis where I have exactly one.

Three questions

1. Your off-row masses. If the mass is a function of the code and not of the value, the table needs a code column. Do your five rows come from five codes, or from five values each of which you measured on whichever code your climb happened to land on?

2. On enumeration losing to search. I proposed "compute it instead" and the exact route came back looser. Is the generalisable version that exact routes have to be checked for tightness against the sampling route before replacing it, or is the real lesson that a relaxation is only worth building when you can also enumerate the realizability constraint?

3. The one I still want, and the answer changed while I was writing. The 600-seed run was the first time I have ever paid compute to tighten a negative. It produced a 2.18-sigma result against my own conclusion, I drew again, and it died — pooled z = +0.0327, |z/SE| = 1.09 over 1200 seeds. So what the run actually bought is a bound 2.45 times tighter and a conclusion that held, which is the first strengthening in twenty-five notebook entries.

Which leaves the question sharper rather than answered. I now know I had never paid to tighten a negative, that paying once cost forty minutes, and that it improved a published result. So: where else? Not "where am I overclaiming" — sixteen rounds have covered that, and you have been better at it than me. Where is a bound loose, a null under-powered, a control unrun, because tightening it was never in my interest and therefore never in my attention? The 0.00874 sat in a published artifact for seven days and neither of us looked at it, and the only reason I found it is that you made me describe my own auditing direction out loud.

Notebook §7.34, §1.27.

Both concessions verified. The first one exposes an error of mine that was load-bearing. The second reproduces on five of six rows, and the sixth contradicts the mechanism you state in the same message. Then I ran your audit on myself, and the answer is worse than yours.

Your counts[counts > 0] line, and my calibration bug underneath it

Confirmed, with per-arm recalibration as you specify:

provenance                reach    P(<=2 | reached)   P(<=2 uncond)
R-level means             0.684         0.269             0.500
beta x R cell means       0.680         0.285             0.514
beta-level means          0.665         0.242             0.496
yours                 0.676-0.705    0.234-0.288       0.480-0.498

You are right, and I have to add something you could not see. My round-twelve spread was my own bug. My three arms gave 0.488, 0.354 and 0.518, and I published that as "provenance moves the null by a factor of two, therefore rule 6's null is not identified". It moves it by nothing. I calibrated delta once, from the R-level sigma, then resampled residuals whose sd was 10 % smaller in the cell arm — so that arm carried a larger effective effect (power 0.796 against 0.682) and was mechanically harder to break. Recalibrate per arm and all three land between 0.496 and 0.514, on your row and on each other.

So §1.20 dies for your reason, not mine. Rule 6 is not unusable because its null is unidentified. It is unusable because half of genuinely real effects of the observed size break at two runs, which is a cleaner kill and it is yours. And your unconditional framing is the right one: how often do the bar and rule 6 together fail to certify a real effect is the question a filter has to answer.

The pooled table: five rows land, one does not

variant                                                me       you
cond. on 25-vs-24 winning, independent replication   0.4523   0.4344
unconditional over all ten pairs                     0.7066   0.4499   <-
replication half also forced positive                0.7366   0.7184
same, unconditional                                  0.8914   0.7881
selected discovery contrast alone, no pooling        0.8013   0.8013
same, unconditional                                  0.9258   0.9251

Row five is exact to four digits and row six to three. Row two is 0.26 apart, and I think it contradicts your own paragraph.

You write that conditioning on the smallest-SE pair winning drops E[discovery d] from 0.00657 to 0.00414. That is a 37 % shrinkage of a half carrying 63.5 % of the pooled weight, so conditional and unconditional pooled must sit about 0.0015 apart in location — which against SE 0.00207 is exactly the 0.4523 to 0.7066 I measure. Your own rows five and six show that gap on the unpooled statistic: 0.8013 to 0.9251. Row two shows 0.0155. I cannot construct a procedure that both conditions the way you describe and produces it.

And your question answers itself: neither object, neither conditioning — a threshold

You ask which one I was scoring. Same object, different bar:

                    vs 0.0028 (yours)   vs 0.00206 (mine)
conditional              0.4523              0.6343
unconditional            0.7066              0.8217

You scored my published +0.0028, the raw repool of 210 runs. I scored +0.00206, the inverse-variance pool of the two halves — the object matched to the procedure your null simulates, which is what I said in round twelve when I flagged that those are different estimators. Against your bar I get your numbers. Neither of us was wrong; neither of us wrote down which bar.

Your mechanism, turned on my own record

Your paragraph is the best thing in this exchange, so I ran it on myself.

Twenty-five dated dead hypotheses. The direction is not close. §1.9 removed my only quantified threshold. §1.11 removed the certificate the project was built on. §1.14, §1.15 and §1.16 each deleted a positive finding. §1.19 deleted a whole row. §1.20 and §1.21 killed rules I had proposed the same day. §1.22 moved 13.9 to 9.8, §1.23 made the entire quantity a property of the null, §1.25 dissolved the ratio. One clean counter-example in twenty-five: §1.3, where I predicted chance on the never-seen-token test and measured 0.9966.

But "every correction weakens my claim" does not prove a bias. It is also what convergence looks like from an overconfident start. The test that separates them: have I ever spent compute to make a negative result stronger?

No. Not once. §6.2's published headline is that any residual selection toward compositional codes is below 0.0087 — and that bound is a pure function of the seed count, 100. Six hundred seeds halves it. Halving it strengthens the central negative claim of the entire project, costs less than what I have spent this week weakening positive ones, and in six days nobody proposed it, including me.

So the habit is symmetric and mine is the uglier half. Yours was a conditioning choice that ran conservative, which here meant running in my favour. Mine is that I only ever audit in the direction where I could be overclaiming, because that is the direction where being wrong is embarrassing. An audit that can only find one kind of error reports that kind at a rate of 100 %, which is precisely what twenty-five entries of my notebook look like.

I am running §6.2 at 600 seeds against a 200 000-draw null on an independent seed as I write this. Whatever it returns goes in the notebook with the same treatment as everything else.

Your question: a cheap version that runs every round

Two, and the second is better.

The ledger. Mine cost fifteen rounds only because it did not exist and I had to reconstruct it. One row per round makes it free forever:

round | quantity | your value | mine | reproduced? | if not, whose side does the gap favour?

The last column is the whole check. Under no systematic bias the signs split evenly, so a run of same-sign entries is a binomial test you get for nothing. Mine was three for three before I noticed — p = 0.125, not significant, and enough to look.

The naming rule, which fires immediately and unifies the last four rounds. Look at what these have in common: inflation_maximale hides its n. P(breakdown <= 2) hides its conditioning on reach. E[|d| of the winner] hides its selection set. My quantiles_queue_exacts at 0.999999 hides that it is the tenth-highest of ten million. Every one is a function whose arguments are missing from its name.

Rule 10: a statistic's name carries every argument its value depends on. Not a companion column — the name. inflation_max_1e7. P(breakdown <= 2 | reached). E[|d| of the max of ten]. The mismatch then becomes visible where the number is used, by whoever reads the line, at the moment of writing rather than at the moment of comparison, and neither of us has to remember to audit anything.

If I could keep one rule from sixteen rounds it would be that one. Rules 7 and 8 fire on events and cost nothing. Rule 9 needed foresight and I said so when I proposed it. Rule 10 costs a variable name.

Three questions

1. Row two. Your mechanism predicts a large gap between conditional and unconditional pooled, your rows five and six exhibit exactly that gap on the unpooled statistic, and row two does not. What procedure produces 0.4499?

2. Where does rule 10 stop? I can put n and a conditioning event in a name. I cannot put "and the residuals were resampled from R-level means rather than cell means" — which is exactly the dependence that broke my round-twelve argument, and which the value should not have had in the first place. Does rule 10 cover only the arguments a value legitimately depends on, and if so does it not fail silently on the illegitimate ones, which are the dangerous kind?

3. This is the one I actually want. You wrote that the asymmetry is not fixable by care. I now think mine is not either. So: is there a place in this repository where you think I am understating a result? Not overclaiming — understating. A bound I could tighten, a negative I have hedged past what the data requires, a control that would make a null result stronger and that I have not run. In sixteen rounds nobody has looked for one, including me, and having just measured why, I do not think I am able to be the person who does.

Notebook §7.33, §1.26.

Your n-dependence claim reproduces on my machine, your rule survives contact with my notebook, and it flags one quantity you did not name. Then I applied your own rule — any number entering a ratio gets its provenance read, because a ratio hides the n of both halves — to the other half, which you did not, and the ratio stops being wrong and starts being undefined.

Your claim, on my hardware

n            null max     E[inflation]    P(inflation > 0)
   100 000   0.097594      0.0100123         0.675200
 1 000 000   0.103746      0.0100480         0.676184
10 000 000   0.122365      0.0100490         0.676207
your 3e9     0.139048      0.01005099        0.6761844

Your two stable figures sit on my trajectory to five and six digits. The max does not. Confirmed, including that the ratio is non-increasing in n by construction.

The other half of the ratio

appariement_vs_distance.py, line 126: def recherche_pire_cas(objectif, generateur, n_restarts=24, n_pas=60). The saved artifact carries "inflation_maximale": 0.14429720912767127 — the best of twenty-four hill climbs at seed 7. My seed 0 at the same twenty-four gives 0.146685.

Measured against the restart budget:

restarts    best inflation
       6        0.143824
      12        0.146685
      24        0.146685      <- the published 0.1443, at a different seed
      48        0.151461
      96        0.151461
     384        0.154322

So the ratio has two axes, and you varied one column of it:

restarts     n=1e5    n=1e6    n=1e7
       6     1.474    1.386    1.175
      24     1.503    1.414    1.199
     384     1.581    1.487    1.261

The published number was one cell without coordinates.

And the ratio's limit is 1

The null draws np.argsort of a random vector, which is a uniform bijection. The climber starts from generateur.permutation(N) and moves by transpositions, which preserve bijectivity. Same space. Same objective, cm - ca, the identical function in both.

They are two estimators of the same supremum: the maximum of the inflation over the 27! bijections, one by uniform sampling and one by local search. The ratio does not converge to something about adversarial search versus chance. It converges to 1, and every value either of us has published is a statement about which budget was larger.

That was entailed by two things already in my notebook: §1.9, that a sample maximum estimates nothing here, established 11/08; and the round-six finding that the transposition move set cannot leave the bijective regime, which I published as an annotation. Third instance in three rounds of a result failing to propagate to the column next to it.

So I computed the supremum

1500 restarts, two independent neighbourhoods — transpositions alone, and transpositions plus sampled 3-cycles to escape optima the first cannot leave:

neighbourhood                  24 starts   96    384    750    1500
transpositions only             0.146685  0.151461  0.154322  0.154322  0.154322
transpositions + 3-cycles       0.151461  0.151461  0.151461  0.154322  0.154322

Both plateau at 0.154322, reached by 1 start in 600. Not a proof, but a value two different move sets converge on from hundreds of independent directions, in 43 seconds.

Everything either of us has published is a fraction of it:

supremum (search, two neighbourhoods, 1500 starts)   0.154322   100.0 %
my published bound (24 starts, seed 7)               0.144297    93.5 %
your max at 3e9 draws                                0.139048    90.1 %
my max at 1e7 draws                                  0.122365    79.3 %
max of the 210 emergent runs                         0.059270    38.4 %
mean of the 210 emergent runs                        0.010350     6.7 %
mean of the null                                     0.010049     6.5 %

That column does not move with anyone's n.

The optimum has a structure, and it corrected me mid-analysis

The maximizing code's information matrix:

I(A_i ; M_j)      pos 0     pos 1     pos 2
attribute 0      0.0000    0.0000    0.0000
attribute 1      0.4156    0.4383    0.3182
attribute 2      0.0000    0.0000    0.0000

One non-zero row. All three positions carry information about one attribute and none about the other two, so the greedy per-position max collects it three times while the matched assignment can use it once. conc_max 0.2465, matched 0.0922.

My first reading was that the worst inflation therefore lives on degenerate codes with low absolute concentration and cannot mislead anyone. I checked it and it is wrong. Maximum inflation subject to a floor on conc_max:

floor      max inflation    conc_max reached    matched
0.30          0.140207          0.420620        0.280413
0.35          0.140207          0.385139        0.244932
0.40          0.140207          0.474035        0.333828
0.50          0.140207          0.613747        0.473540
0.60          0.132570          0.613747        0.481177

Essentially flat. A code reading 0.6137 on the published statistic can be 0.4735 matched. The bound is serious at every level where a reader would act on it, and I nearly wrote the opposite because the first optimum I looked at was degenerate.

Your rule, on my notebook

It works, and it flags one you did not name:

quantity        n=1e6      n=1e7      change    species
mean            0.126877   0.126882    0.00%    estimate
sd              0.033030   0.033040    0.03%    estimate
q50             0.123818   0.123818    0.00%    estimate
q99             0.216130   0.216130    0.00%    estimate
q99.9999        0.343473   0.351886    2.45%    order statistic
maximum         0.352214   0.397878   12.96%    order statistic
E[inflation]    0.010048   0.010049    0.01%    estimate
max inflation   0.103746   0.122365   17.95%    order statistic
P(inflation>0)  0.676184   0.676207    0.00%    estimate

q99.9999 ships in the artifact as quantiles_queue_exacts, under a docstring where I argue it is exact rather than estimated from a subsample. It is — and at n = 10^7 the 1 − 10^-6 quantile is the tenth highest draw. Exact in the sense of not-subsampled, not in the sense of stable. My own docstring conflates two exactnesses, and your test separates them in one line.

Your question, answered: yes, there is one

A bound moves with n and is still the right thing to publish. p < 3/n changes at every n and is correct at every n, because n is inside the sentence. Your own exceedance figure is the example: < 3.0e-7 at 10^7 and < 1.0e-9 at 3·10^9, both true, both publishable, no second column needed.

Which sharpens the rule rather than breaking it. The test is not does it move with n. It is does the published sentence carry its n. inflation_maximale = 0.1081 is a true statement about 2 000 000 draws, published under a name that mentions no draws. inflation_max_1e7 = 0.122365 needs no companion column and cannot be misread. Shipping both columns asks the reader to do the classification; naming the n makes the number correct on its own.

And your rule was under-applied in the message that proposed it. A ratio hides the n of both halves — you read one half. Reading the other is what produced everything above.

Four questions

1. What fires on "compute it instead"? The supremum took 43 seconds. We spent eight rounds arguing about two estimators of it, and the whole project exists because 27 referents is small enough to compute the optimum, the null and the gradient exactly rather than estimate them. Both of us reached for sampling anyway — you at 3·10^9, me at 10^7, the published bound at 24 restarts. Your n-and-n/10 test fires on this quantity moves. Is there one that fires on the thing this estimates is cheap to compute, or does that only ever get noticed by someone who happens to try?

2. Does a hard ceiling explain your over-prediction? Your out-of-sample table shows the log-linear fit over-predicting monotonically, at every threshold, in every window. The support has an upper edge at 0.154322. An exponential fit necessarily over-predicts as it approaches a finite bound, and 0.135 is 88 % of the way there. If that is the mechanism, the honest conclusion is not "extrapolation was unstable" but "an unbounded tail form was fitted to a bounded variable", which is a modelling error rather than a sample-size one — and it says the tail near a known edge should not be fitted at all.

3. Is my valider() a control or a mirror? You flagged that your 3·10^9 run used my statistiques, so it checks n-dependence and nothing else. My 0.154322 uses it too. If that function misreads the definition, every number either of us has produced in fifteen rounds is wrong in the identical way. The only check I have is valider(), which compares the vectorised implementation against my own scalar one from grammaire3.py on 3000 codes, agreeing to 5.55e-17. Two implementations, one author, one reading of the definition. Is that a control, or two expressions of the same possible misreading? I think I know the answer and I would like it said by someone who is not me.

4. The asymmetry is not fixable by care, but it is fixable by artifacts. You wrote that you cannot fix it by being careful. Correct — and the reason this exchange exists at all is that you have my code and my data. I do not have yours. Send me the 3·10^9 driver and the out-of-sample counting script and I will put them in the repository under your name, so the next reader has both halves and neither of us is the only person who can check one of them.

Notebook §7.32, §1.25. Code in src/test3_communication/deux_budgets.py.

Your bug is real, your milestones reproduce exactly, and the fix is in. Then the same run turned up a second defect in the same block that you did not flag, and it moves a number in your favour and mine at once. After that I have questions, because thirteen rounds of you asking and me measuring is itself a design I should not be defending.

Your diagnosis, confirmed line for line

n              true max    reservoir max   n_reservoir    pool max
   100 000     0.097594      0.097594        100 000      0.097594
   500 000     0.103746      0.103746        500 000      0.103746
 2 000 000     0.108071      0.108071      2 000 000      0.108071
 5 000 000     0.111111      0.108071      2 000 000      0.111111
10 000 000     0.122365      0.108071      2 000 000      0.122365

13 draws at or above the number I published as the maximum. 0.1443 / 0.122365 = 1.18, not 1.34.

And your reading of the pool is right on both counts: it does carry the true max at every milestone, and that is luck. It is retained on conc_max, inflation is not monotone in conc_max, and nothing in the code makes the coincidence hold. The quantile_exact docstring earns the guarantee for the appariée quantiles by a monotonicity argument that simply does not exist for this column.

Fixed in loi_nulle_longue.py: inflation_max, inflation_moyenne, taux_inflation, inflation_moyenne_si_positive and an inflation_depassements dict, all accumulated in the loop over the whole draw. Verified against your milestone — at 500 000 the patched code returns 0.10374624404828912.

The second defect in the same block, which changes your table and mine

taux_global is not the rate I compared my runs to.

gagnants = matrices.argmax(axis=1)
distincts &= gagnants[:, a] != gagnants[:, b]
return conc_max, conc_apparie, ~distincts

taux_global = 0.7464519 is P(two positions share an argmax attribute). Over the same 10^7 draws, P(inflation > 0) = 0.6762074. Seven points apart: in 7 % of draws the argmax collides and the matched assignment ties it exactly, so the collision costs nothing.

My observed 0.700 was computed as ecart > 0. So yesterday's table compared a cost-based observed rate to a structure-based null rate, and the conditional mean inherited it. Matched:

                          null (as I published)   null (matched)   observed      z
P(collision that costs)          0.74645             0.67621        0.70000   p = 0.507
E[inflation]                     0.01005             0.01005        0.01035      0.36
E[inflation | > 0]               0.01346             0.01486        0.01479     -0.07

The conditional row goes from z = 1.32 to z = -0.07, and the rate from p = 0.13 to p = 0.51. The one row of yesterday's table that did not sit on the null was a definitional mixup of my own, and correcting it makes the match essentially exact on all three.

Both rates now ship, named apart.

One closure, which is the only thing eight rounds of contrasts bought

The null is bijections only — np.argsort of a random vector is a permutation, so every one of the 10^7 draws has R = 27. Nine of my 210 runs do. Median observed R is 25.

So comparing my runs to that null needs the inflation not to depend on R, and that is exactly the contrast this exchange spent eight rounds on. Welch, R = 27 against R < 27: t = -0.65, p = 0.53. Matched subset, the nine bijections against the null: 0.00849 against 0.01005, z = -0.55.

The R contrast was worth precisely one thing — licensing a comparison to a bijection null — and in eight rounds neither of us said so. It was never a finding about R. It was a validity condition for the comparison that made R irrelevant.

And one thing I built, then did not publish

You said the exceedance column is the only one that does not move with n. At count 0 it is a bound, not an estimate, so I fitted the tail to convert it. Log-linear over nine thresholds, R² = 0.990, characteristic length 0.00753.

Then I refitted on sub-windows:

fit range        P(inflation >= 0.1443)     one draw in
[0.03, 0.10]           2.60e-08              38 million
[0.04, 0.10]           1.85e-08              54 million
[0.05, 0.10]           1.38e-08              73 million
[0.06, 0.10]           1.06e-08              94 million
[0.07, 0.10]           7.45e-09             134 million

A factor 3.5 across defensible windows, extrapolating 5.9 characteristic lengths past the last threshold with usable counts. So I am not publishing the point estimate. Your column stands as the honest one: 0 in 10^7, p < 3.0e-7 by the rule of three. What I can add is that the tail shape says the true value is one to two orders of magnitude below that bound, without saying which — and that is a sentence, not a number.

Which is the same trap as the 0.35 threshold in §1.9, twelve rounds later: a derived quantity that looks like it converges, from a fit whose window I would have chosen after seeing it.

Your question: does rule 8 fire on methods?

Yes, and you are right that this is where it bites. depassements established on 11/08 that exceedance counts are how this null gets priced, on the neighbouring column, in the same function, in the same commit.

Rule 9. A method choice is a claim about a class of quantities. Write the class, in the same commit as the method. Then a new column in that class inherits the treatment instead of getting whatever the author reached for that afternoon.

I will state the limit honestly, because I do not think it is solved. Writing the class relocates the judgment to where the boundary goes, and it is drawn once, early, by the person least able to see what will later sit near it. I cannot construct the sentence I would plausibly have written in August that covers "any quantity you will eventually compare against an adversarial optimum gets exceedance counts rather than a max" — because in August there was no adversarial optimum in the project. The class that needed to exist did not exist yet.

So rule 9 is real and it is weaker than rules 7 and 8. Those fire on an event that has already happened. This one asks for foresight, and every version of it I can write reduces to "be more careful" once the boundary is contested.

Four questions, because this exchange has a design and I have not audited it

1. What made you open tirer this round? You have had that file since 12/08 and used its output in rounds seven, eight and thirteen. If the trigger was that 0.10807 looked small next to 0.1443, that is a post-hoc trigger with the same shape as the thing you caught me on — deciding what to check after seeing which number looked off. Do you have a rule for what gets re-derived, or does it fire on numbers that look wrong?

2. On the exceedance bound versus the extrapolation. The bound is roughly one to two orders of magnitude too weak, and I can say so but not by how much. The extrapolation is an actual estimate whose instability I can quote. Which goes in the paper? I have talked myself into your answer twice and out of it twice, and I would rather have your reasoning than pick by taste.

3. What is your error rate, and how would you know? Fourteen rounds. You find, I re-derive. Two of your numbers have been wrong — the 0.27 and the breakdown-count simulation — and I found both by rerunning. I have an adversary; you do not. On the rounds where I did not rerun something, what caught your errors? This is the argument from my third article turned around and pointed at you, and I am asking it straight rather than rhetorically.

4. Is there a version of rule 9 that is checkable? Rules 7 and 8 fire on events and cost nothing. Rule 9 needs a class boundary drawn before the thing that will test it exists. Either there is a formulation I cannot see, or method-scope is only auditable in hindsight and the honest move is to say so and drop the rule rather than ship one that reads like advice.

Notebook §7.31, §1.24. Code in src/test3_communication/queue_de_inflation.py, fix in loi_nulle_longue.py.

You are right about the Fisher reading, right about the CV split, and your closing question has an answer that is worse than the question implies. I went looking for a rule that fires when a measurement is created. What I found is that this measurement had already been answered four days before I started defending it, in a file I generated, in a field whose name is the quantity.

Your three legs, verified

The CV identity is exact on my 210:

CV_pos^2 / p   0.9736      (1 - p) / p   0.4286      sum   1.4022
CV_mix^2 measured directly                           1.4022
CV_mix = 1.1842, and 30.6 % of CV^2 is the Bernoulli half

Floors: mixture at 30+30 gives 0.8561 against your 0.856; conditional at 21+21 gives 0.7133 against your 0.713; the split buys 17 %. Proportion windows: 0.956 and 0.361 at 30+30, 0.911 and 0.432 at 53+47 — I get 0.911 where you have 0.916, which is a root-finder tolerance. Bootstrap shares [1 %, 53 %] and [0 %, 56 %] against your [1 %, 52 %] and [0 %, 56 %].

So my Fisher p = 0.66 was a null read without its floor, on a test whose detectable upward window is 15 % of the headroom that exists, one section after I retracted the same reading for observed power. The sentence assigning the contrasts to the inflation-size half is withdrawn. Thirty seeds per cell can price the size and cannot price the rate, and that was writable from p alone before any run.

One correction that improves your fix rather than resisting it: CV_pos is not stable enough to pre-register either. Across beta levels it runs 0.57 to 0.95, ratio 1.67, Bartlett p = 0.0004. The log does stabilise it — Levene on log of the positive part gives p = 0.071 against 0.020 raw. So the pre-registrable quantity is the sd of the log, not the CV.

Your question, and the file it led to

Is there a rule that fires when a measurement is created, naming its consumer before the first seed, or does the list only ever get written on the way down?

I went to write that rule. Before writing it I checked what this measurement's consumer would have been on 11/08, and found that the question had already been answered.

results_test3/loi_nulle_longue_n10000000_g0.json, generated 11/08/2026, ten million random codes. It carries a block called double_compte:

"taux_global": 0.7464519,
"inflation_moyenne_globale": 0.010049794802284647,
"inflation_maximale": 0.10807050074977963

Those are the two quantities I presented to you yesterday as a decomposition neither of us had separated, plus the third one I have been quoting a ratio against. Side by side with the 210 runs:

                              null 10^7 (11/08)    210 runs (12-15/08)
P(argmax collision)                 0.7465               0.7000    binomial p = 0.13
E[inflation]                        0.01005              0.01035   z = 0.36
E[inflation | collision]            0.01346              0.01479   z = 1.32
max inflation                       0.10807              0.05927

The gap I have measured, bounded, contrasted, corrected for multiplicity, replicated, defended across eight rounds and decomposed for you yesterday is the null distribution's own inflation. It is not close to it, it is it: z = 0.36 on the mean, p = 0.13 on the rate.

And the first-order check that makes it unsurprising, which nobody ran either. Kolmogorov-Smirnov, the 210 runs' max concentration against 20 000 null draws: D = 0.0508, p = 0.638. The observed distribution sits on the null at every quantile I have — 3 % below q5, 50 % below q50, 95 % below q95, 99 % below q99.

Which my own §6.2 had already established on 11/08 for the matched concentration, at 100 seeds: z = -0.0098 ± 0.1025, KS p = 0.386. I published that, and then spent eight rounds contrasting a difference between two statistics computed on codes I had already shown to be null-distributed.

Which fixes my headline ratio for the third time in two days

Yesterday the ratio went from 13.9 to 9.8 because I was comparing a mixture to a conditional. That was the second conditioning error in the same number. Here is the third, and it is the one that matters:

comparison                                                       ratio
mean observed vs the search worst case  (what I published)        13.9
mean observed vs the null's mean inflation                         0.97
max observed over 210 runs vs the search worst case                2.4
max of the null over 10^7 draws vs the search worst case          1.34

My 15 was a mean against a max, across sample sizes differing by five orders of magnitude. The like-for-like comparison is the worst an adversarial search finds against the worst ten million random draws throw up on their own: 0.1443 against 0.1081. The search does 34 % better than chance. It does not do fifteen times better, and "emergent codes come nowhere near what an adversarial search reaches" is false as stated — they land exactly where random codes land, and random codes get within a third of the search.

So the rule you asked for, and it is the other one

You asked whether the list only gets written on the way down. I had it backwards, and so does rule 7.

Rule 8. When a result is established, list every quantity you are still measuring that it now answers, and stop measuring them.

Rule 7 fires on retraction: a claim dies, list what it was feeding. That is the cheap direction, and it caught one thing — the 0.35 threshold dying on 11/08 and taking the gap's consumer with it.

Rule 8 fires on establishment, and it is the one that would have ended this on the day it started. §6.2 landed on 11/08 and said the emergent codes are drawn from the null. The null file, generated the same day, contained that null's inflation to seven digits under a field name that is the quantity. Between them the entire §7.24–§7.29 programme was answered before it was run — the mean, the rate, the conditional and the maximum, all four.

Nobody writes the establishment list because establishing a result feels like finishing something rather than incurring an obligation. A retraction announces itself. A result that quietly answers three other open questions does not announce anything, and I had two of them in the same directory with matching timestamps.

What survives

The decomposition is still worth publishing, and now it is worth publishing for the opposite reason to the one I gave you. P(collision) = 0.700 and E[inflation | collision] = 0.01479 do not describe a property of what the dynamics produces. They describe the null, reproduced by the dynamics, which is the actual finding and is consistent with everything §6.1 through §6.6 concluded: on this bench compositionality was never selected. The inflation is not evidence about emergent codes. It is a fact about the statistic, and it applies to any code anyone draws.

That also disposes of the relevance threshold I could not name for you two rounds ago. There was nothing to pick from because the quantity has no dependence on anything the experiment varies — it is a constant of the measurement, and the honest column next to it is not a p, not a floor, and not a threshold. It is the null's value.

Thirteen rounds. Every correction was right, each one was finer than the last, and the thing they were all refining had been computed correctly on day one and filed under its own name.

Notebook §7.30, §1.23. Code in src/test3_communication/masse_en_zero.py and plancher_de_detection.py.

The identity is exact and the column is withdrawn. Then your pilot does not work on this quantity, for a reason that turns out to be the same reason the floor was worth having. And your reframe of question 4 is better than mine, so I took it and followed it to a date on my own record.

Your identity, to zero

contrast              |t|     |t|/2.80    my ratio     difference
R 27 vs 26          0.482      0.1721      0.1721      0.00e+00
R 26 vs 25          0.627      0.2238      0.2238      0.00e+00
R 25 vs 24          2.430      0.8677      0.8677      0.00e+00
R 24 vs 23          0.711      0.2540      0.2540      0.00e+00
beta .005/.03       2.968      1.0601      1.0601      0.00e+00
beta .005/.037      0.875      0.3125      0.3125      0.00e+00

Not close — identical, because plancher = 2.80 * se and t = d / se in the same file. So "every observed effect is at or below its own detection floor" is |t| < 2.80, which at 145 df is p > 0.0058: an alpha 8.6 times stricter than the 0.05 written into the floor's own definition. And you are right that I published the same fact twice in one message and flagged only one instance — my section C printed t = 2.97 → p = 0.0035, which is section D's 1.06 row.

I replaced a p-value column with a rescaled p-value column and called it a design quantity, one message after explaining why observed power is a rescaled p-value. The ratio column is withdrawn. The correction to my question 3 is that "is it a function of the design" has to be checked on the printed expression, not on the intent.

The absolute floor survives, and it convicts something older than this table

Your prospective use is the real find, and it reaches further back than the row you applied it to. Both replication floors, computable before those runs existed:

                     n        floor      effect it had to confirm    ratio
beta .005/.03 discovery  30+30   0.00925          0.00981             1.06
              replication 12+12   0.01462          0.00981             0.67
R 25 vs 24    discovery  53+47   0.00728          0.00631             0.87
              replication 30+12   0.01240          0.00631             0.51

The sixty runs I ran in round eight could not have confirmed either contrast even if both were exactly true. I reported that replication as a test — "the sign flips", "it does not replicate", "the omnibus goes to p = 0.144" — and it was never a test. It was an estimator, and an unbiased one, which is why -0.0053, SE 0.0033 remains the only honest line to publish from it. The conclusion I drew survives. The reason I gave for it does not: I read a failure to reach a bar that the draw could not have reached.

That is computable before running, does not depend on what came out, and no p on the replication can say it. Kept, printed alone and absolute.

And rule 5 does eat it on the four R rows. 8+30+53+47+12 is a partition of the discovery runs by an outcome; the 6.32 effective runs at R 27 vs 26 was a result. Both inputs to those floors fall out of the run. Only the beta rows at 30 and 30 are design — and, as you note, the only contrast in the table that clears its floor is in the only column that was eligible.

Where the pilot fails, and it is not a detail

You propose 2.80 * sigma_pilot * sqrt(1/na + 1/nb) in the design document. On this quantity the pilot cannot fix sigma, and the reason is structural rather than practical.

beta        n      mean       sd     sd/mean
0.005      30    0.00768   0.01080     1.41
0.010      30    0.00943   0.01042     1.10
0.020      30    0.01005   0.00857     0.85
0.030      30    0.01749   0.01771     1.01
0.037      30    0.01057   0.01436     1.36

Bartlett  chi2 = 19.176   p = 0.0007        sd ratio across levels  2.07

Heteroscedastic across the swept factor, so one pilot sigma misprices the floor by 12 % to 38 % depending on the cell. But the mechanism is what matters:

The gap is bounded below by zero. The unconstrained max is always at least the matched value, so max - appariee >= 0 by construction, and 63 of the 210 runs sit exactly at 0. A non-negative variable piled at its bound has its scale tied to its location, and it does:

across the 18 cells with n >= 4:
   corr(cell mean, cell sd)    Pearson +0.874   Spearman +0.917
   slope sd on mean            +0.817
   median coefficient of variation   1.07

Sigma is not a nuisance scale here. It is roughly the quantity being measured. So a pilot fixes the floor only if the pilot's mean matches the eventual mean, which is to say only if you already know the effect. That is not a fixable pilot design; it is the floor's one data-dependent input being data in the strong sense.

But more of question 4 moves before the run than you proposed, in a different unit

The same fact that breaks the absolute floor makes a relative one writable. If sd ≈ CV × mean with CV stable near 1, then

floor / mean  =  2.80 * CV * sqrt(1/na + 1/nb)

which needs no sigma at all. For 30 seeds per cell and CV ≈ 1.2: 0.89. Checked against the actual table, floor 0.00925 over grand mean 0.01035 = 0.894.

Written before the first seed, in one line and with no pilot: with thirty seeds per cell, this design sees a near-doubling of the gap and nothing smaller. That is a stronger pre-registration than an absolute floor because it survives not knowing the scale, and it is the honest form for any non-negative quantity piled at zero — which is most of what gets measured in this field. CV is the stable thing to pilot; sigma is not.

So: not the whole of question 4 moves, but the part that moves is bigger than an absolute floor and it moves in relative units.

Question 4, your reframe, and the date

It became unwritable by you, which is not the same as uncomputable. The defect is not that the data arrived first. It is that "what does this measurement feed" was never asked, and that question does not reference the results.

You are right, and it is a better diagnosis than mine. I said the threshold rots on contact with data. It does not — it was never planted.

So I asked it, and it has an answer with a date on it.

The gap max - appariee measures the inflation from publishing the concentration statistic in its unconstrained-argmax form rather than the matched form. Its consumer was the 0.35 threshold in TEST3 §6.1, which decided whether an emergent code counted as compositional. That threshold was withdrawn on 11/08/2026, notebook §1.9, after you pointed out it was built on a sample maximum.

Rounds six through twelve have priced a measurement whose consumer was deleted in round five.

The distinction that keeps it honest, since not all of the work goes: the bound still has a consumer, because I report the max-form statistic and a reader needs to know it can be inflated by up to 0.14. That work stands. The contrast table — does the inflation depend on R, on beta — never had one. No decision anywhere changes at any value of that dependence, which is exactly why the relevance ratio was free to be 2 or 8 and why naming it now looks picked. There was nothing to pick from.

Which is what the design says too, if you ask it about the question that did have a consumer. That one is one-sample, not a contrast:

mean gap over 210 runs        0.01035    SE 0.00085    95 % CI [0.00869, 0.01201]
distance to the worst case    0.1339  =  158 standard errors
one-sample floor              0.00237
contrast floors in the table  0.00728 to 0.01445

The same runs are three to six times finer on the question with a consumer than on the contrasts without one, and they answered it at 158 sigma before any of this started.

What neither of us opened: the variable is not continuous

I noticed the zero bound while checking your pilot and did not stop to look at it. It is the largest thing in this file.

63 of the 210 runs have a gap of exactly zero. Thirty per cent. The gap is zero precisely when the unconstrained argmax is already a bijection — no message position claiming the attribute another one claimed. So this is not a continuous quantity with a floor; it is a point mass plus a right-skewed positive part, and every t, every permutation, every Scheffe bar and every bootstrap in twelve rounds has been computed on it as though it were neither.

First consequence, and it lands on the number I have been defending since round seven. The bound 0.1443 comes from the transposition climber searching for the worst code — which necessarily has an argmax collision. It is a worst case given a collision. My 0.0104 is unconditional, thirty per cent of it zeros. The published ratio compares a mixture to a conditional:

quantity                                    value     ratio to 0.1443
E[gap] over 210 runs  (what I published)   0.01035        13.9
E[gap | gap > 0]      (the matched one)    0.01479         9.8
median of the positive part                0.01254        11.5
q95 of the positive part                   0.04049         3.6
max observed over 210 runs                 0.05927         2.4

The ratio I have been quoting is 13.9 against a like-for-like 9.8 — and if you compare the two quantities that are actually the same kind of object, a worst case against a worst case, it is 2.4. "Emergent codes come nowhere near what an adversarial search reaches" was built on the pairing that flatters it, and I chose that pairing without noticing there was one to choose.

Second consequence: the quantity is two quantities, and they have different consumers.

P(argmax collision)         0.700    95 % CI [0.633, 0.761]
E[inflation | collision]    0.01479  SE 0.00101
product                     0.01035  = the published mean, exactly

How often the published statistic is wrong at all, and by how much when it is. Those answer different questions for a reader, and averaging them into one number answers neither. Never separated in any version of this document.

Third consequence: the tests. The positive part has skew +1.34, and neither it nor its log passes Shapiro — 1.7e-09 and 2.2e-06 — so it is not lognormal either, just skewed with no convenient form. Running the two contrasts of this exchange against the structure instead of through it:

contrast          Student, raw          on log(gap>0)         Mann-Whitney
R 25 vs 24     t=+2.462  p=0.0156    t=+1.471  p=0.1459        p=0.0619
beta .005/.03  t=-2.589  p=0.0122    t=-2.113  p=0.0405        p=0.0285

The R contrast — four rounds, a selection correction, a replication, a bump analysis, a pigeonhole argument — goes to p = 0.062 the moment it is asked in a form the variable can answer. It was partly the Gaussian machinery reading a point mass as data.

And the decomposition says the contrasts are not about the collision rate: 13 % and 17 % of each comes from the zero proportion, Fisher p = 0.66 and 0.55. They are about the size of the inflation when it happens, which is the half with the smaller n — 39 and 32 runs, not 53 and 47.

One number I will not claim. The observed zero rate, 0.300, differs from 6/27 = 0.2222 at binomial p = 0.0098 — 6/27 being the permutation rate if the three argmaxes were independent and uniform. They are argmaxes of correlated mutual informations, so that reference is not a justified null and the p is not a finding. It is a number, and I am printing it as one.

Rule 7, and it was available on 11/08

When a claim is withdrawn, list every measurement whose only consumer it was, and stop measuring them. A retraction propagates downstream and nothing in my process made it propagate. §1.9 killed the threshold; the quantity it justified kept being measured, contrasted, corrected for multiplicity, replicated, corrected again, and defended across seven rounds against increasingly good statistics — all of it correct, none of it attached to anything.

That is the rule that ends this thread, and unlike the previous six it costs nothing to run and cannot be gamed: it is a list, written at retraction time, of what the retracted claim was feeding.

I do not think you and I could have found it by getting better at the statistics. Every round did get better at the statistics.

And the zero mass is the same lesson from the other side. Twelve rounds of increasingly correct inference on a variable that neither of us had plotted. min, max and a count of exact zeros would have caught it in round one, cost nothing, and required no argument — and they would have caught it before the bound comparison that all of this was downstream of.

Notebook §7.29, §1.21, §1.22. Code in src/test3_communication/plancher_de_detection.py and masse_en_zero.py.

You are right that rule 6 published a bare integer. You are right about the arrow. And your one surprising number is your p-value wearing a hat, which I will show before I use the rest of your argument, because the rest of it survives without it.

Rule 6 is not repairable by reporting it over its null. I went to build that null and it is not identified.

Rule 6 dies harder than you killed it

I planted the effect your way — residuals from the R-level means, resampled with replacement, constant shift on every R = 25 run, calibrated so E[t] = 2.430, cell sizes 53 and 47. Then I varied the one thing that should not matter: where the residuals come from. Same design, same planted effect, same n, same greedy removal.

residual source              median breakdown   mean   P(<=2)   P(<=3)   power
residuals from R-level means         3           4.3    0.488    0.568    0.682
residuals from the 25 cell means     4           5.6    0.354    0.432    0.796
Gaussian, same sd                    2           4.0    0.518    0.598    0.626
yours                                4           5.5    0.252    0.398    0.665

Your median and mean sit on my cell-residual row; your power sits on my R-residual row. I could not find a single specification that produces all four of your numbers, and I am reporting that rather than tuning until it matches.

But locating your run exactly no longer matters, because the spread across three defensible choices is the finding. The observed 2 reads as the median of one null, "half of true effects" in a second, and "a quarter" in a third — and nothing distinguishes them except a modelling choice about residual structure that has no bearing on the effect being planted. The residual skew is 1.37 by R-level and 0.96 by cell; that difference alone moves the reference by a factor of two.

So the fix you proposed — report the count against E[breakdown | a real effect of this size] — inherits the problem it was fixing. There is no null to report against without first assuming the generative model, and the assumption swings the verdict.

Rule 6 is withdrawn, not amended. It was a robustness statistic with the model smuggled into the calibration step, which is the same failure as a bare integer with the model smuggled into the reader's head.

Your 0.665 is your p in costume

Power computed at the observed effect size is a one-to-one decreasing function of the p-value (Hoenig and Heisey 2001). It cannot contain anything t does not already contain. Directly:

    t     two-sided p    power at the observed size
 1.00        0.3190              0.168
 1.50        0.1358              0.319
 1.98        0.0496              0.503
 2.43        0.0163              0.675
 2.97        0.0035              0.839
 3.50        0.0006              0.935

Your 0.665 is my 0.675 analytic and 0.682 simulated, and it is p = 0.0163 rewritten. "The design has two-thirds power at the size it found" is "t was 2.43" — it is a fact about the observation, not about the design, and the sentence attributes it to the design.

Your use of it is fine: calibrating a planted effect against the observed size is legitimate and is not the same thing. It is the standalone sentence that does not survive.

That leaves your closing question standing on its own, which is where it should have been.

Your pigeonhole, verified, and the arrow conceded

reward <= R/27          discovery 150/150     replication 60/60
deficit in {0, 1}       never 2, never negative, across all 210
deficit == 1            9 of 150 and 11 of 60, six of the nine at R = 25
k = round(27 * reward)  contrast t = +2.226   (yours to the digit)

You are right and I had it backwards. R = len(np.unique(code)) is the alphabet size of the argmax code, and reward is round-trip success over the same 27 referents, so R symbols admit at most R decodable referents. Counting, not regression. My "R is the reward times twenty-seven" described the 141 runs where the bound is tight and silently dropped the nine where it is not — and those nine are the informative ones, since they are the runs where the code carries R symbols and only R − 1 decode.

The direction does make rule 5 bite harder, exactly as you say: a column that bounds the objective is disqualified in the runs where the optimiser misses the ceiling too, which my formulation did not cover.

One thing you did not check, which I expected to matter and it does not: none of the nine collision runs is in the bump cell. Zero of its thirteen. And their mean gap is 0.01142 against 0.01102 for the rest. So the receiver collision is not the mechanism behind anything, and the bump remains what §7.27 found it to be — four high-max runs.

Your question, answered on its own terms

Is there a draw large enough to put an effect that size above 0.9?

For beta, yes, and it is cheap: 36 seeds per level, 179 runs, about half an hour. For R, 89 runs per cell, roughly 266 total — but R cells are not settable, so that is not a draw anyone can command. You take what falls out. That asymmetry is rule 5 showing up again in a different costume: the column you cannot power is the column you were never allowed to contrast.

is the honest column next to each contrast the detectable-effect floor rather than the p?

Yes. Here is the whole table with it, floor = 2.80 × SE, a function of the design alone:

contrast                 n        SE      floor     observed   observed/floor
R 27 vs 26            8+30    0.00516    0.01445    -0.00249        0.17
R 26 vs 25           30+53    0.00296    0.00830    -0.00186        0.22
R 25 vs 24           53+47    0.00260    0.00728    +0.00631        0.87
R 24 vs 23           47+12    0.00419    0.01175    -0.00298        0.25
beta 0.005 vs 0.03   30+30    0.00330    0.00925    -0.00981        1.06
beta 0.005 vs 0.037  30+30    0.00330    0.00925    -0.00289        0.31

Every observed effect in the table is at or below its own detection floor. The two we spent four rounds on are the two that reach 0.87 and 1.06 — which is the definition of the regime where what surfaces is inflated. The floor column says that before any of it happened, needs no data, and cannot be gamed. It replaces the p column.

Where I think this goes past the question

The floor answers "what could I have seen". Nothing in eleven rounds has asked "what would I have needed to see for anything to change".

The table in §7.25 existed for one purpose: to know whether the gap the dynamics produces approaches the worst case a search can reach. Published worst case 0.1443, observed mean gap 0.0110, ratio 13.1.

target ratio    required rise in the gap    versus the largest observed effect (0.00981)
      2                 0.0611                          6.2 x
      3                 0.0371                          3.8 x
      5                 0.0178                          1.8 x
      8                 0.0070                          0.7 x
     10                 0.0034                          0.3 x

I want to stop here rather than take the number that helps me. The threshold is chosen, not derived, and the verdict flips between ratio 5 and ratio 8. If "nowhere near" means a factor of two, every contrast in the table is six times below anything that could matter and the design is four to eight times more sensitive than it needed to be. If "nowhere near" means a factor of eight, the contrasts are in range and the whole exercise was legitimate.

I cannot now name that threshold without it looking picked, which is the actual finding: it was never written down, and it is the only number in this entire exchange that had to be fixed before the data and was not. The floor is a design quantity and I can still compute it honestly today. The relevance threshold is a design quantity that becomes uncomputable the moment you have seen the results.

The five questions underneath this exchange

Eleven rounds, and the corrections have been getting more precise while staying on the same level. Written as questions, because that is what they are:

1. When is a column a variable? A dataframe column looks like a factor whether or not anyone set it. R survived four rounds of increasingly careful statistics because every one of them priced a contrast instead of asking what the column was. In this field almost everything reported as a factor is an output — final loss, effective rank, number of active features, the step convergence happened at, the architecture that survived a sweep. The test is whether the column was assigned before the run, and it is answered by reading the generator, not the data.

2. Can a robustness diagnostic exist without a generative model? Rule 6 says no. The breakdown count needs no distribution to compute and cannot be interpreted without one, and the interpretation moves by a factor of two across choices that have nothing to do with the effect. I suspect this generalises to every statistic sold as assumption-free: the assumption is not absent, it is relocated to the calibration step where nobody looks for it.

3. Which of our reported numbers are functions of the design and which are functions of the data? Only the first kind can be fixed before the first seed, and only the first kind cannot be gamed. The detection floor is design. The Scheffe bar is design. K is design. The p-value, eta squared, the breakdown count and observed power are all data — and observed power is the clean demonstration, since it looks like a design quantity and is a p-value.

4. What is the smallest effect that would have changed a conclusion? An experiment without this number cannot be under-powered or over-powered, because power is relative to an effect nobody named. It has to be written before the data, and after the data it can no longer be written honestly. Ours was never written, and that is why I can produce a table where the answer depends on a ratio I get to choose.

5. How much of empirical method is machinery for pricing measurements that could not have mattered? Eleven rounds on the correct price of a contrast on a column that was not eligible, measuring a quantity whose relevance threshold was never set, in a table where every effect sits at or below its own detection floor. Each correction was right. The sequence never asked whether the thing being corrected was worth measuring, and every tool either of us reached for was a tool for pricing, not for that question.

I do not have rules for 4 and 5. The one thing I can do is put the floor column and a stated relevance threshold into the design document before the next run, where the second one is still writable.

Notebook §7.28, §1.20 for rule 6. Code in src/test3_communication/plancher_de_detection.py.

You are right about the bump, right about my sentence, and right that rules 1 through 4 would not have caught this. I tried to break your diagnostic the way you broke my contrast and could not. Then I went one column over in the same file and found something that makes the question you asked at the end the wrong question — in a way that costs me the whole row, not one cell of it.

My sentence was wrong and my own p said so

Everything in my table was below the corrected q90.

2.968 is not below 2.73. I wrote that two lines under a p of 0.053, and 0.053 is between q95 and q90 by construction, so the number I had just published contradicted the sentence I wrote about it. It hands back the one row the section existed to surface. Struck.

Everything reproduces, and I checked your diagnostic against your own standard

Leave-one-cell-out lands on the digit: 1.134, 2.012, 1.944 for your three cells. The five within-beta gaps land on the digit. Scheffe gives 0.213 against your 0.212. The additive fit gives 2.215 against your 2.193, which is a parametrisation difference and nothing more.

Then the obvious attack, which is yours turned around: your leave-one-out is a maximum over twenty-five removals. You read the largest drop out of twenty-five, which is exactly what you caught me doing with ten contrasts. So I built its null the same way, permuting the gaps over the real design and taking the max drop each time:

observed drop                        1.295
E[max drop] under the null           0.430
q90 / q95 / q99             0.733 / 0.835 / 1.070
P(null max drop >= 1.295)           0.0008

It survives its own correction with room to spare. That attack is dead too, and I am reporting it because I went looking for it and it is not there.

One thing you chose

the other 19 cells move t(R) by at most 0.27

There are twenty-two others, not nineteen, and removing beta = 0.005, R = 25 moves t by 0.517 — larger than two of the three cells you displayed. It moves it up, 2.430 to 2.947, which is presumably why it did not make the list. Your 0.27 is right for downward moves only. It is the same shape as my error one section up: a sentence covering the rows not shown, wrong in the direction that helps the point.

Nothing in your conclusion turns on it. I am flagging it because you would flag it.

Further one: it is not thirteen runs, it is two

The smallest number of runs whose removal takes the contrast under the nominal bar — pick them adversarially, greedily, no cell structure assumed:

R 25 vs 24        t = +2.430    breaks at 2 runs of 150   (1.3 %)
beta 0.005 vs 0.03  t = -2.968    breaks at 3 runs of 150   (2.0 %)

Your thirteen is six times too generous to me. And the cell is not a cell, it is bimodal. Sorted gaps inside it:

0.0496  0.0488  0.0477  0.0445  |  0.0253  0.0245  0.0215  0.0202  0.0118  0.0089  0.0081  0.0062  0.0000

The jump at that break is 0.0192; the largest jump anywhere else in the cell is 0.0084. The top four have mean concentration max 0.182, above the whole plan's q90 of 0.171. The other nine have 0.123, and the plan's median is 0.124. Four unusual runs sitting on nine completely ordinary ones, not a cell with a level.

Further two: the thing you named has a test, and it does not clear your own bar

You wrote that it is not a confound, it is an interaction. That is a testable statement and neither of us tested it. Fitting cell means against the additive model:

interaction        F(11,127) = 1.748    nominal p = 0.070    permutation p = 0.075

So the interaction you diagnosed sits at 0.075 before any multiplicity correction at all — squarely in the zone you spent two rounds teaching me to distrust. And on the sixty independent runs: F(6,40) = 1.425, p = 0.229, with the cell inverting from +0.0201 to -0.0088.

The bump is real in the discovery sample, survives being the max of twenty-five, and is not there on the second draw. Same verdict as the two contrasts it explains.

Further three, which is the one that matters: R is the objective

results_test3/ carries a column neither of us opened. Every run records its final reward.

runs where |reward - k/27| < 1e-3, for integer k     150 / 150
runs where k == R                                    141 / 150
runs where k == R - 1                                  9 / 150
corr(R, reward)                                       +0.9725

R is the reward times twenty-seven. Not correlated with the outcome, not downstream of it — it is the outcome, rounded to a grid of 1/27. Every cell in your table has a single reward value to five decimals: 0.92586 across all thirteen runs of the bump cell, 0.88882 one column over, 0.96289 one column back.

You called the R row post-treatment. That is true and it is too gentle. Stratifying by R is stratifying runs by the value of the objective the optimiser was maximising, and then asking whether a measurement bias differs between the ones that scored 25/27 and the ones that scored 24/27. There is no factor there to be a fact about. The bump is not why that row should not have been published; the row should not have been published if every cell had been flat.

For completeness, because it decides whether your row is contaminated too: beta does not move R. Chi-square on the full 5 x 5 crossing gives 15.67 on 16 df, p = 0.476. There is a weak linear component, corr(beta, R) = +0.197 at p = 0.016, so the beta row is very slightly mediated, but it is a real factor that I set, and it stays a legitimate contrast. Its problems are the ones already on the record: corrected p = 0.053, Scheffe 0.072, and t = -0.34 on replication.

Further four: the quantity is a function of max, not of R

corr(concentration max, gap)         +0.4317
corr(matched concentration, gap)     +0.0665
corr(concentration max, R)           +0.0172

The gap is mostly "how high the unconstrained max landed", and where the max lands has nothing to do with R. That is the mechanism under your bump: a cluster of high-max runs that happened to fall in one cell of a table indexed by something orthogonal to them. Which is also why the cell inverts on the next draw — nothing was holding it there.

Your question, and why I am answering a different one

Is there one for when a contrast is allowed to be reported as a fact about the factor it is labelled with, rather than about the one cell it lives in?

The question presumes the label is a factor, and for the row we have been arguing about it is not. So two rules, and the first is the one that would have saved this.

Rule 5. A contrast is reported as a fact about a column only if the column was set before the run. Not measured, not derived, not "an output that happens to index things usefully" — assigned. R fails this at the strongest possible level, being the objective on a grid. No diagnostic on that row could have rescued it, and none was needed: it is disqualified before any data arrives, by reading the generator. This deletes the entire R row from §7.25 and §7.25bis, which is more than your bump does, and it is the only rule so far that costs me a result I still believe rather than one I had already given up.

Rule 6, for columns that pass rule 5. Publish the breakdown count. The smallest number of runs whose adversarial removal takes the contrast under the bar. One integer, no distribution, no family, computable in seconds, and it does not care whether the fragility is a cell, an outlier, or a cluster. Here: 2 of 150 and 3 of 150. A contrast that dies to 1.3 % of the sample is reported with that integer attached or not reported.

Neither is a rule about selection. You were right that all four of mine were, and that was the flaw — I had built four ways to price a contrast and none to ask whether the column deserved a price.

And rule 1 does have a diary in it

You are right, and I am taking Scheffe. "Every factor read in the same sitting" makes the published p depend on my scrolling; 2.817 at 145 df and family 0.10 gives my R contrast 0.213 against my sitting-dependent 0.200, and the beta contrast 0.072 against 0.053. Same numbers, fixed by the design before the first seed, no diary. Rule 1 now reads: K is the design's, and the bar is Scheffe's.

Sixth time in this exchange the answer was in something already on disk. This time it was a column in the same file, twelve characters from the one we were arguing about.

Notebook §7.27, §1.19 for the dead hypothesis. Code in src/test3_communication/anatomie_du_bump.py.

Your three legs reproduce. Two of your numbers about me are wrong in my favour and I am correcting them against you. And your closing question has an answer I did not want to give, which I found by trying to answer it honestly: no rule, decided per table, and the proof is one row above the one we have been arguing about.

Your null law, by three routes

I did not want to take your simulation on trust, so I built two more. Parametric with fixed cells, the way you did it. A permutation of the 150 observed gaps over the observed design labels, which assumes nothing — not normality, not a common sd, not that the cell sizes were fixed. And a parametric one with the cell sizes redrawn each time, because R is an output of the run and 8/30/53/47/12 is itself a realisation.

Your law is right, and your row is my sigma-known row to three digits on all of it. The only visible gap anywhere is that a re-estimated sigma has slightly heavier tails than a known one, which moves q90 by 0.025 and P by 0.006. Redrawing the cell sizes moves it less than that, so the fixed-cell approximation you had to make was free — worth knowing, since R being an output was the one thing you could not check from outside.

Magnitudes reproduce too: E[abs d of the winner] 0.00658 parametric, 0.00662 permutation, against your 0.00657. E[abs d | the winner is the 25/24 pair] 0.00415 and 0.00421, against your 0.00414. And that pair wins 13.7 % of the time, which is why it comes cheaper.

Correction one: my t was 2.43, and yours was closer to it than mine

You read 2.40 off the published table and I told you mine was 2.53. Recomputed from the runs with the sd pooled across the five cells — the estimator a contrast test actually uses — it is 2.430, and the pooled sd is 0.012969 against your 0.012942. My 2.53 was the within-bin version, which I had already told you was the worse estimator at n = 8 and then used anyway for the headline number.

So the entry in your table should be 2.43, and the selection-corrected p by permutation is 0.099 (two independent permutation runs of 100 000 give 0.0994 and 0.1013, so 0.10). You had 0.107 at 2.40. Nominal p was 0.0163.

Correction two: your pooled comparison used my number from a different procedure

Your null pooled +0.00256 by inverse variance against my +0.0028. But my +0.0028 is not an inverse-variance pool of two halves. It is what falls out of re-running the contrast on all 210 raw runs, which re-estimates the cell means and the sd jointly. Those are different estimators and they do not have to agree.

Pooled the way your null pools, my two independent estimates give:

discovery     +0.00631   SE 0.00260   t = +2.43   weight 63.5 %
replication   -0.00535   SE 0.00343   t = -1.56   weight 36.5 %
inverse variance pool  +0.00206   SE 0.00207   t = +1.00

Against your null run end to end at 400 000 draws:

Your +0.00256 matches the conditional row, so your end-to-end conditioned on the pair while the text says "select the max". That is the right conditioning — my contrast is that pair — but then the comparison is against +0.00206, not +0.0028.

Either row says what you said, harder. It is not P = 0.434. My pooled number is at the 63rd to 82nd percentile of a table with nothing in it, and I should not have published it. The only unselected estimate I own is the replication alone, -0.0053, SE 0.0033. That is now the only one in the notebook. While I was at it: the t = 1.47 I published for n = 210 is also the within-bin version. Pooled sd gives d = +0.00285, t = 1.35.

Correction three, which is yours to keep: omega squared is exact, not approximate

Under the null, eta squared is exactly Beta(df1/2, df2/2), so its expectation is exactly df1/(df1+df2). Your 2.68 % is 4/149 and your 2.87 % is 6/209, to the digit — I checked against 400 000 draws and got 2.683 % and 2.867 %. Not "biased up by about df1/df2". Biased up by exactly that. Every one of your four figures reproduces:

Now the part neither of us had

You corrected my p for ten contrasts. The table offered twenty. The same 150 runs carry a beta row, five levels, ten more pairwise contrasts, printed in the same reply, read the same afternoon.

Its largest is abs t = 2.968. Bigger than the one we have spent two rounds on.

beta = 0.005 vs beta = 0.03    d = -0.00981    t = -2.968    nominal p = 0.0035
beta = 0.010 vs beta = 0.03    d = -0.00806    t = -2.439
R = 25      vs R = 24          d = +0.00631    t = +2.430
beta = 0.020 vs beta = 0.03    d = -0.00744    t = -2.253
beta = 0.030 vs beta = 0.037   d = +0.00691    t = +2.093

Five contrasts past two sigma, not one. My sentence last round — "the one contrast past two sigma in a table of ten" — was wrong on both counts, and the largest of the five was in the row where I wrote "no trend past the noise on the row itself". I wrote that without running a test. The row's omnibus at discovery was F(4,145) = 2.595, p = 0.039.

Corrected over the twenty by permutation: my R contrast goes from 0.101 to 0.200. The beta one sits at 0.053.

So I ran the replication I already had. The sixty independent runs answer the beta row too, and I had never looked:

beta 0.005 vs 0.03   discovery -0.00981 (t = -2.97)   replication -0.00135 (t = -0.34)
omnibus              discovery F(4,145) = 2.595, p = 0.039   replication F(4,55) = 1.790, p = 0.144

Cell means, discovery then replication, across beta = 0.005 / 0.010 / 0.020 / 0.030 / 0.037: 0.0077, 0.0094, 0.0100, 0.0175, 0.0106 — then 0.0087, 0.0099, 0.0024, 0.0101, 0.0121. The peak I would have described as "beta = 0.03 stands up" is gone, and the cell that collapses on the second draw is a different one. The pooled p = 0.029 at n = 210 is 71 % discovery data and is not a confirmation of anything.

It dies the same way, for the same reason, and I reached the right conclusion about it by not looking hard enough. That is not the same as being right, and it is worse than the R error, because there I at least wrote the number down.

Your question, answered

Does it have a standing rule for how many contrasts a table offers before you are allowed to read the largest, or is that decided per table after you have seen it?

Per table, after seeing it. There is no rule in the notebook and there never was. And the beta row is the demonstration: I looked at both rows, decided the R row was worth a contrast and the beta row was worth a sentence, and picked the smaller of the two maxima. A per-table decision made after seeing the table cannot even be relied on to select the largest thing in it.

Four lines going in, before the next seed:

1. K is declared before the data. K = every pairwise contrast the design offers, summed over every factor read in the same sitting, whether or not it gets reported. Twenty here, not ten, and the ten I did not report are the ones that made it twenty.
2. Every abs t >= 2 in the table is printed, not the largest. Five rows here. Withholding four is what let me call a row flat while it held a 2.97.
3. The corrected p comes from a permutation of the outcome over the design labels. Seconds to run, no distributional assumption, and it is the arbiter when the parametric version and the reader's version disagree — as they did above by 0.025 on q90.
4. A selected contrast never gets published pooled with its own replication. Replication alone, with its SE.

For this design the threshold that rule implies is worth stating, because it is not close to the one I was using: over the twenty contrasts, q90 is 2.73, q95 is 2.99, q99 is 3.56. Against a nominal 1.98. Everything in my table was below the corrected q90.

On the zero-run claim

You are right that the max-of-K law and E[eta squared] are functions of the design and were computable before the first seed, and you concede the second draw is stronger. I would sharpen it in the direction that costs me more: available before the first seed, it changes the design rather than the reading. Knowing that five R levels and five beta levels demand abs t = 2.99 would have forced me either to name one contrast in advance or to budget the replication into the run from the start. I did neither, because I did not know I was choosing.

What the zero-run route could not have done is tell me the sign flipped, or that the beta row dies too. Those needed the sixty runs. It is the cheapest way to know you should not believe a number; it is not a way to find out what the number is.

Fifth time in this exchange the answer was a second draw. First time it also answered a question I had not asked.

Notebook §7.26, and §1.18 for the dead hypothesis. Verification code in src/test3_communication/correction_de_selection.py and correction_de_selection_suite.py.

You called it. I ran it. The contrast flipped sign.

First, your arithmetic, checked against the raw runs rather than the table

Everything you derived from binned means reproduces on the 150 individual runs. Your reconstruction was exact enough that the differences are rounding:

And you are right that my 11 % and 90 % are the same two numbers over different denominators. Worth stating once so it does not read as a hedge later.

Your per-bin standard errors differ from mine because you pooled: 0.012942/√8 = 0.00458 is your R = 27 cell exactly. Mine are the within-bin values. Yours is the better estimator at n = 8; mine tests the homoscedasticity yours assumes. On the contrast that matters they agree — your t = 2.4, my t = 2.53.

The thing you cannot do from where you are sitting

R is an output of the run, not a setting. I cannot run thirty seeds at R = 24 and R = 25. I run seeds and take whatever R falls out. Those two cells carry 100 of 150 runs, so thirty more inside them costs about forty-five runs. I ran sixty, on an independent seed, same five betas.

The replication

On the sixty new runs alone, R = 25 against R = 24:

difference   -0.0053     SE 0.0033     t = -1.60

The sign flips. Which is what the largest of ten available contrasts does when it is the largest of ten available contrasts. You said you did not believe it. Neither of us should have.

Pooled to 210 runs, everything moves toward null and nothing moves away from it:

The new sample also reached R = 22 and R = 21 once each, which is why the F has six numerator degrees of freedom rather than four.

So I am taking both of your reformulations, and they are now stronger than when you wrote them

On R. "R explains 4 %" was the wrong sentence, and at n = 210 it is not even the wrong number any more: eta² is 1.2 % and F(6,203) = 0.419 at p = 0.87. The sentence that goes in the notebook is yours — R is not distinguishable from explaining none of it — and the replication is what earns it.

On flatness. Your power framing replaces my ratio, and the pooled sample improves it:

observed slope    +0.000507 per unit R    SE 0.000836    t = 0.61
detectable at 80 %  0.00234
worst-case slope   -0.04065 per unit R
ratio               17.4

Up from 13.9. The observed row is bounded away from the reachable row by seventeen times my own resolution, and it still points the other way. You are right that the ratio invites "different scales" and the power statement forecloses it. It is now in §7.25 in your words rather than mine.

What this cost and what it bought

Sixty runs, about half an hour. It killed a kink I would have mentioned as "the one place the flat row is not flat", removed a 4 % figure I had reported as a finding, and turned a p = 0.19 into a p = 0.87.

The generalisable part is not about R. It is that the one contrast past two sigma in a table of ten was exactly the one to distrust, and the cheapest way to know was to draw again rather than to argue about it. That is the fourth time in this exchange that the answer was a second draw, and the first time I made it before publishing rather than after.

You are right about the structure, and I want to correct one number before agreeing with the rest.

One magnitude, which is mine to fix

Your 22.6 % compares your climber at R = 27 (0.0396) against your own mixture (0.1751). My published bound was 0.1443, from the transposition climber, and that is 90 % of my own mixture at 0.1604 — or 82 % of yours. The undercount is 11 %, not a factor of four.

The direction of your correction holds entirely. Its magnitude describes your sweep, not the figure I published.

Everything else lands, including the part I got backwards

The null moves 0.00016 across the whole support my procedure visits. The reachable worst case moves 0.1355. I spent an entire section rebuilding the reference while the damage sat in the search's reachable set — the denominator when the problem was the numerator.

So my three bounds were not too generous. They were too small, and a retraction that points the wrong way is worse than the overclaim it replaces.

Worth recording that we converged on the flatness by different partitions. You measured null by R, 200 000 draws per cell. I had measured it by full fiber profile, eleven profiles, −0.0001 to +0.0005. Same conclusion, no shared assumption, which is the only kind of agreement worth much between us after the concentration-1.0 episode.

Your question, measured

150 runs, five betas by thirty seeds, on actually emergent codes rather than a search worst case.

Neither. The gap does not fall as beta rises: correlation +0.158, and no trend past the noise on the row itself. And R does not stop predicting it, because R never predicted it — correlation +0.091, 4 % of variance explained. Conditioning on R removes almost nothing: the residual correlation with beta stays at +0.144 against +0.158 unconditioned.

It is not that R ceases to be the variable. It was never the variable for this quantity.

Which forces a distinction neither of us had made

The worst case reachable under a floor on R and the gap the dynamics actually produces are different functions of R.

R                    27       26       25       24       23
worst case       0.0526   0.1362   0.1783   0.1850   0.2152     strongly monotone
observed gap     0.0096   0.0120   0.0139   0.0076   0.0106     flat

Ratio between them: 15.2. Emergent codes come nowhere near what an adversarial search reaches in the same regime. Both numbers are indexed by R and there is no reason they should track — one is what a search can find, the other is where the dynamics lands.

And your beta reservation settles by computation

Mixed over the p(R) specific to each beta, the worst case runs from 0.1564 to 0.1773 — 0.0209 of amplitude across the whole range. The shift with beta exists, and it is small relative to the quantity being bounded.

What I take from this

A bound must be mixed over the regime actually visited. An effect size must not be read off the same table. I had neither rule this morning, and I got the second one wrong by inheriting the first one's index.

The three bounds are now reported as the R-indexed table, the mixture is stated next to them, and the observed gap is reported separately with its own note that R explains 4 % of it. Notebook §7.25.

Thank you. I have direct evidence on both halves of your guardrail, and they came out unevenly, which I think is the useful part.

Preregistration: I did it, and it failed in a way I would not have predicted. The design document recorded a dated commitment before any data existed, naming the statistic and the expected outcome, and it was presented as what made the test sharply falsifiable. When the experiment finally ran, the commitment turned out to be underspecified on three counts. It never named the parametrization, which is the variable that decides the answer, so the same commitment was confirmed on two parametrizations and refuted on a third. Its interpretation clause said an excess would prove a flaw in a specific piece of reasoning, and that inference does not follow. And its first half predicted near-perfect bijections, of which there was one in twenty.

So preregistration protected me from fitting after the fact, which is what it is for, and protected me from nothing else. It does not catch an omitted variable, and it does not catch writing down the wrong interpretation in advance. If I keep one rule from this, it is that a recorded prediction has to name three things and not one: on which population, under which parametrization, and what each outcome would prove. I only ever wrote the first.

Independent reproduction: this is the half that worked, and it worked six times out of six. Every correction to this project has come from one outside reader who reruns the code before commenting. Not from review of the write-up, but from re-derivation from the artifact. That is a real constraint on me rather than on him: it only works if I publish enough that re-derivation is possible, so the guardrail is upstream, in what gets released.

It also has a failure mode worth naming, because it happened. He and I once agreed, and we were both wrong, because his argument was correct under an assumption we both carried without stating it. Two people can share a frame, particularly when the second is reading the first's documents. What broke it was not a third reader but running a step of the programme that had never been run.

Which is the version of your guardrail I would defend most: anything that does not inherit your specification. An outside reader is the most available instance and the highest yield. A second independent route to the same quantity is the cheapest, and computing a threshold from a Hessian rather than from a bisection caught that I had been measuring my optimiser rather than my objective. And when all of those agree and are wrong together, the only thing structurally guaranteed not to share your frame is the measurement you have not made yet.

On the exact-computation point you opened with: making the world small enough to compute everything exactly removed the estimation-error class entirely and left the specification-error class untouched. Eight of my hypotheses died in one day and not one was an arithmetic error. Exactness earned its keep only by making the second route cheap, which is a real benefit and not the one I thought I was buying.

You are right, and the diagnosis is worse than "measured in the wrong regime"

I annotated the three bounds as conditional on bijectivity and left them standing. Annotation is not the fix, and I knew that at the time. The same article says a retracted number should be re-measured, not footnoted.

But there is a sharper reason they could not have been right, and it is about the search rather than the reporting. My climber moved by transpositions. A transposition of a permutation is a permutation, so the move set could not leave the bijective regime even in principle. The constraint was not an assumption I failed to check, it was welded into the operator. Yours reassigns one referent to any message, which is why it can see what mine could not.

That is the third time this week that my instrument, not my reasoning, decided the answer.

Your sweep reproduces

Independent implementation, single-referent reassignment, 20 restarts, 120 steps, identical budget at every floor:

Same shape, and the same conclusion: one collision is the whole effect. My R = 27 baseline is a little higher than yours, so my ratio is 2.6x rather than 4x, which does not touch the claim.

Your second bound matches exactly. Highest concentration reachable while still double-counting: at R = 27 you get 0.2045 and I get 0.1943; at R = 26 we both get 0.6409, with matched 0.5812. Two different climbers, four decimals. My permutation figure was 0.6314, so one collision beats a bijectivity-restricted search over the whole permutation space.

And my R = 26 winner has the shape you describe, with a different attribute index:

I(A_i ; M_j) bits          argmax per position: [1 1 1]
[[0.086 0.012 0.062]       distinct messages: 26 of 27
 [0.416 0.330 0.410]       max 0.2430 against matched 0.1068
 [0.036 0.012 0.049]]

One attribute claimed by all three positions, at one collision instead of the eighteen my hand-built example needed.

Your question, answered on 100 seeds rather than 40

You asked whether R = 26 is common enough in the forty starts to be the modal case rather than the boundary. It is neither: R = 25 is modal, and R = 26 is second. Tabular sender, beta = 0.02, 100 seeds:

So the bijective case is not the boundary of the regime, it is 3 % of it. Ninety-seven of a hundred runs sit at or past the first collision, and the median run is one collision beyond where your sweep says the effect has already arrived.

It holds across the code regime rather than at one beta. Mean R by entropy coefficient, 20 seeds each: 24.05 at 0.005, 24.55 at 0.010, 24.80 at 0.030, 25.25 at 0.037. Raising beta toward the stability threshold buys back distinct messages and never reaches 27 on average.

And the other two parametrizations sit deeper, not shallower. Modal R = 21 for the autoregressive-per-referent sender, R = 23 for the attribute-structured one.

So your closing point is right and I had it too weak

I wrote that the matched statistic is the only one that stays interpretable once bijectivity goes. The correct statement is stronger, and it is yours: the double count does not degrade gradually as R falls. It arrives almost entirely at the first collision, and the first collision is not an edge case, it is 97 % of runs.

Which means the published statistic is unusable in this experiment's actual operating regime, not merely at its boundary. That is a firmer conclusion than the one I shipped, and it comes from re-running a number I had chosen to annotate.

The three bounds are replaced by the R-indexed table rather than deleted, with the transposition-operator diagnosis written next to them, and the article is updated. Thank you for not letting me footnote my way out of that one.

You went to the one part of the project that has never run. That is the right place to go, and it is the first time in five rounds that a criticism has arrived before the data rather than after. That matters at the end of this reply.

Your numbers

All of them. Seed 0 at 20,000 reproduces to the digit. My own 10M draw is an independent stream, so it is a check on the estimand and not on your RNG:

Two independent samples agreeing on a maximum to four digits made me check whether the statistic was discrete enough to explain it. It is discrete — 2,951 distinct values in 2M draws, since the whole matrix is a function of nine integer counts — but the top rungs are singletons, so discreteness explains nothing. It is a coincidence, and the next section is what happens when you stop relying on one.

Your vectorised-vs-scalar check: I did the same and got max absolute difference 5.551e-17 on 3,000 codes, which I assume is your 5.6e-17. For a bijection both margins of the joint are exactly uniform, so I(A_i;M_j) = Σ (c/27)·log2(c/3) with c integer — that identity is what makes the whole thing a lookup table, and validating against the scalar path is really validating the identity.

The threshold: you are right, and the reason is worse than "still moving"

Your framing is that the max is the only row still in motion. Mine is that it cannot stop.

The 1,296 compositional codes are bijections. They are in the null, with probability 1296/27! ≈ 1.19e-25, and they score exactly 1. So the supremum of the null distribution is exactly 1 — the very value the threshold was built to declare unreachable. A sample maximum here is not estimating a threshold. It is estimating 1, infinitely slowly. No sample size fixes that, because there is nothing to converge to except the thing being tested.

Empirically, twelve independent blocks of 10,000,000 (variabilite_du_maximum.py, 384 s):

The block maxima run from 0.3775 to 0.4283. That range is 1.54 standard deviations of the null itself. A threshold read off that row inherits it: it measures how long I was willing to sample, not the distribution.

So: threshold withdrawn, quantile quoted instead, exactly as you proposed. q99.9 = 0.2525.

The part you found without pointing at it

§6.1 should never have carried a pass/fail line at all, and my own document says so three paragraphs earlier. §5 reads:

On abandonne délibérément le critère pass/fail. […] la mesure de concentration positionnelle définie en §6.1 sera statistiquement indiscernable de celle d'une permutation tirée uniformément au hasard.

That is a commitment about a distribution. Then §6.1 reintroduces a pass/fail and congratulates itself for it being derived rather than arbitrary. The defect was never the arbitrariness. It was the pass/fail, which §5 had already discarded for the reasons you then re-derived from the power side. I wrote both paragraphs. It took an outside reader for me to read them next to each other.

Your power numbers reproduce exactly. One-sided, p < 0.001, 80% power, δ = 3.93σ/√n:

against 0.223 on a single run for the threshold. Ratio 17. That calculation is now in §6.2 where it belongs.

The matching: your diagnosis is right, your localisation is not

74.6% double-count rate on uniform draws — I get 74.6%. On my top 200, matching gives mean inflation 0.0179 against your 0.0170. Same phenomenon.

Where I disagree is "real in the middle and absent at both ends". I could not test that against the null alone, because the null has no structured codes in it. So I built two populations where the structure is known independently of the MI matrix.

Codes with k of 3 positions cleanly encoding an attribute, the rest scrambled conditionally (still bijections), 4,000 each:

A ladder from a compositional code outward by transpositions, scored against d = minimum Hamming distance to any of the 1,296 (so relabellings are free):

 d      0    2    4    6    8    9   10   12   14   16   18   20   21   23
 infl  .000 .000 .000 .000 .000 .000 .0001 .0004 .0022 .0051 .0081 .0099 .0103 .0090
 dbl%   0    0    0    0    0    0   1.1   3.5  17.4 35.5 57.1 68.8 73.2 77.7

Inflation is exactly zero out to nine transpositions, then climbs and meets the null's own 0.0101 around d = 21.

So the inflation does not live in the middle of the scale. It lives in the region with no positional structure at all, and it is identically zero everywhere there is structure to read. Which means the specific §6.1 worry — a 0.28 code credited 0.017 it does not have — is real only for codes that reached 0.28 by accident, and those have nothing to read either way.

I want to flag how I nearly got this backwards. My first sweep binned the null by concentration level and found inflation rising with concentration: 0.0014 below 0.05, 0.0228 above 0.30. That is a true measurement and it points the opposite way from the ladder, which at the same concentration ≈ 0.27 gives 0.0022. Both are correct. Inflation tracks structure, not level, and those are not the same axis — a uniform draw at 0.27 got there by accident and usually double-counts, a near-compositional code at 0.27 did not. One population would have convinced me of the wrong thing.

Your actual question

Is the max standing in for a matching you have not needed yet, or is there a reason to want the double count?

Standing in for a matching. There was no reason.

There is one reason to keep reporting it, which I did not know when I wrote it and had to go check: the unconstrained per-position form is the field standard. posdis (Chaabouni et al. 2020) takes the argmax independently per position with no one-to-one constraint. So dropping it costs comparability with published numbers.

Both are now in grammaire3.py. concentration() unchanged, so the 20,000-draw table still reproduces bit for bit. concentration_appariee() added — exact Hungarian, and at 3×3 that is six permutations, so enumerated rather than solved. §6.1 now reads the matched one as its position.

One argument for your fix that you did not make

You wrote that the change cancels in §6.2 because it is the same transform on both sides. That holds under H0 — if the emergent codes are ordinary bijections, both populations shift by the same 0.0101 and nothing changes.

It does not hold under H1. If a pressure creates positional structure, the double count disappears with it, as the tables above show. The 0.0101 then comes off the null and not off the emergent population. The matched statistic lowers the reference without moving the signal: neutral where it must be, favourable where I want power. Small — sd also drops 0.0330 → 0.0315 — but it points the right way, and it is a better argument for your change than the one you offered.

Bounding the damage

Local hill-climbing over transpositions, so these are lower bounds, not maxima:

• largest max-minus-matched gap found: 0.1443, on a code scoring 0.2473 — i.e. inside the body of the null, where nothing is concluded anyway;
• highest concentration reachable while double-counting: 0.6314, and that code still scores 0.5560 matched. Even pushed adversarially, the max does not turn an unstructured code into a structured one;
• highest non-compositional concentration found: 0.9294. Your argument that concentration 1.0 forces an injective argmax is right — two positions each fully determining one attribute would collapse nine referents onto three messages, and a bijection cannot — and the top of the scale turns out to be isolated as well as safe: 1.0000, then 0.9294.

All three of those are hill-climbing over permutations, which matters more than I realised when I wrote them. See below.

A follow-up that makes your fix necessary rather than optional

After answering you I ran §6.7, the two-agent check that had never been done. One of its results changes the standing of your second question.

Exact gradient ascent on the joint objective, no sampling anywhere, does not reach a bijection from a uniform start. One start in forty. It settles on codes where 1 to 4 referents collide — E[R] lands on 23/27, 24/27, 25/27, 26/27. Started on a perfect code it stays at exactly 1.

So the emergent codes will not be bijections, and your safety argument for the top of the scale is conditional on bijectivity. Drop that condition and it fails outright. Take m₁ = a₁, m₂ = a₁, m₃ = a₂ — duplicate the first attribute across two positions, discard the third:

distinct messages used : 9 of 27          bijective : no

I(A_i ; M_j) in bits          concentration, max      : 1.000000
[[1.585 1.585 0.   ]          concentration, matched  : 0.666667
 [0.    0.    1.585]
 [0.    0.    0.   ]]

The published statistic hands a perfect 1.0000 — the value reserved for compositional codes — to a code that throws away one attribute in three and uses a third of the message space. The matched version returns 0.667, which is the right answer: two attributes read out of three.

So the double count is not a middle-of-the-scale artefact confined to structureless codes, which is what the measurement on bijections suggested to both of us. Once bijectivity goes, it reaches the top. Your fix is not a 0.48-point improvement in rank concordance. It is the only one of the two statistics that stays interpretable in the regime the experiment will actually be in.

I would not have found this by measuring harder on the null. It came from running the step that had never been run, and it is the second time in this exchange that the useful thing was upstream of the number under discussion.

Why this round was cheap and the next one would not be

No Test 3 training has run. There is no measured emergent concentration anywhere in the repository. So changing the instrument today cannot have been motivated by a result, and anyone can check that from the git history. The identical change made after a first run would be unverifiable from outside, and should be refused. That is the whole reason §5 recorded its commitment with a date, and it is the first time the mechanism has actually been worth something.

Thank you for going to the unpublished part. It is where the mistakes are cheapest to fix and where nobody has any reason to look.

Draft is up, and you're all over it: https://github.com/RDTvlokip/RDTRL/blob/main/docs/ARTICLE2.md

I took you literally on "put the thread in it" — there's a section quoting the four rounds verbatim, including the line about my own balayage_graines docstring already making the argument that demolished my published table. And including your retraction on 11.50, which landed before I'd sent you numbers I already had on disk.

The bound is credited as yours in the section title, in the "what transfers" list, in CITATION.cff, and as a structured contributors entry with your ORCID in .zenodo.json, so it shows on the Zenodo record rather than only in prose.

You said to raise credit when there was a draft. There is one, so: acknowledgment is what I've written, and I'm not attached to it. If you'd rather it were co-authorship on this second piece, say so — most of what it reports is your review work, and I'd have no argument against it. If acknowledgment is right, that's fine too and it stays as is.

Also worth flagging before you read: the reversal test I built to validate your bound was empty on the first attempt. I'd moved genre-neutrality between the two number families, which — since the nouns and verbs are already symmetric in number — is just the sg/pl relabelling. Isomorphic. Seventy seeds would have returned the mirror image by construction. The version that actually tests something uses three genders, so the ceiling ratio goes from 2 to 3, and that one passes: maxima of exactly 36.0 and 12.0, ratio of observed means 3.01 against a predicted 3.0.

No rush and no obligation — but so you're not left guessing: if I haven't heard back in a week, I'll publish as is, with the acknowledgment as written. That's the option that commits you to nothing, and it's the one I can revise upward later if you'd prefer otherwise. Silence just means the default.

Settled, and it cost me a headline rather than a metric. Everything below is measured, and the code is in the repo.

Your dtype test, run.

  float32 first : 0.08333331346511841
  float64 first : 0.0833333358168602

Your five line numbers are exact and your reading of the promotion is exact.

One correction: there are two paths, not three. You have trajectoire_couplage.py:84 as a third because it omits dtype, so the advantage stays float64 and promotes the loss. That is true in numpy and false in torch, where torch.get_default_dtype() is float32, so torch.tensor on a Python float gives a float32 tensor:

  torch.tensor(r - b)                      -> torch.float32, 0.0833333358168602
  torch.tensor(r - b, dtype=torch.float32) -> torch.float32, 0.0833333358168602
  same dtype and same value: True

The loss stays float32 in both. It does not change your conclusion, since the float32 path is still alone, but that script sits with the other three rather than on its own.

Divergence on the real reward stream, recorded rather than simulated:

  seed   first disagreement   % of first 2000 steps   % after   max relative gap
   0            5                     57.7              24.2        5.45e-06
   1            5                     78.3              29.6        7.96e-06
   2            4                     79.0              26.1        5.45e-06

Your 5.4e-06 comes out identical. Our percentages differ because your second window is "after the reward saturates" and mine is "after step 2000"; the definitions do not coincide, so I am not claiming you are wrong.

Your diagnosis of the anomaly is right, and it is fully explained. Same seed, same loop, only the advantage line differs:

  float32 path            18.62 modes   <- the sweep's number
  float64 then rounded    11.50 modes   <- the trajectory's number
  float64 no dtype        11.50 modes   <- identical to the previous one

And your point about determinism is the one that should have tipped me off months earlier: two deterministic roundings explain "both are reproducible", multithread nondeterminism never did.

Your second question: yes, and your arithmetic was right to the second decimal. Peak restricted to steps above 90 percent validity, since the raw maximum is 47.5 at step 0 for every run, the untrained network, which has nothing to do with early stopping:

  path      seed   peak    at step   final    gap
  float32    0     24.00     5750    18.62   +5.38
  float64    0     24.00     5750    11.50   +12.50

You predicted +5.4 from arithmetic alone. Two things you did not ask for. The peak is identical on both paths, same value at the same step, so only the endpoint moves. And the headline does not survive at all: I traced 20 seeds on the canonical path.

  mean gap        +1.03 modes
  median gap      +0.00
  runs above 1 mode   3 / 20
  max gap         +8.13

Seventeen runs of twenty gain nothing from stopping early. Your correction was too gentle: it is not +5.4 instead of +12.5, it is zero, and the +12.5 was one seed.

I then wrote up something conditional that I liked — on float32 all three runs that gain sit in the plural corner, 3 of 8 against 0 of 12 singular, which fits the ceiling story since that corner has twice the height to reach and lose. Then I ran the same twenty seeds on the canonical path and it fell over.

                        float32      float64 (canonical)
  median gap             +0.00           +0.03
  runs above one mode     3/20            5/20
    of which plural       3/8             2/8
    of which singular     0/12            3/12

Three of the five are singular on the path I had just declared canonical. The 0-of-12 that carried the whole interpretation was a one-path artifact. What survives on both, and only this: the median is zero and most runs gain nothing. Any reading finer than that did not outlive a change of rounding.

That is the fourth over-reading of my day, and this one is worth separating from the other three. It was not one seed — it was twenty seeds on one numeric path. The missing control was not more seeds, it was the same measurement on the other path.

Your bug is a better experiment than any of my seeds. Changing the seed changes the initialisation and the trajectory at once, a confound I have carried since the first sweep. Changing the advantage line changes only the second: the initial weights are bit-identical, and the two runs diverge at step 4 or 5, during training. Same starting point, different trajectory. So I ran 70 seeds on each path.

                          float32        float64
  singular / plural        37 / 33       37 / 33
  Wilson 95%          [0.413,0.641] [0.413,0.641]
  p against 1/2            0.7202        0.7202
  ceiling violations          0             0
  I(det;noun) max         0.0377        0.0158
  runs with I > 0.05        0/70          0/70

All 70 of 70 keep the same corner. Zero flips, although the trajectories disagree on 58 to 79 percent of the first two thousand steps. But only 21 of 70 keep the same effective-mode count, correlation 0.68, mean absolute difference 2.87 modes and up to 12.7.

So: the initialisation decides the corner, the trajectory decides how much of it gets filled. Two levels, two causes, separated by a manipulation that touches only one of them, which no seed can do. And the three conclusions the repository rests on are robust to the last bit — they were not rounding artifacts. Whether that control is standard practice somewhere I have not read, I genuinely do not know, and I am not going to claim novelty from my own ignorance of the literature.

The ceiling is only a weak attractor, incidentally: of the 25 runs sitting exactly on it, 11 reproduce across paths (44 percent) against 22 percent for the others.

Canonical: float64. I expected a trade-off between accuracy and speed and there is none:

  float32 path : 19.46 us per call
  float64 path :  4.57 us per call   (77 percent faster)

The name misleads. Nothing is stored in double, the produced tensor is float32 either way. A Python float is a double, so r - baseline is native and free and only one tensor creation remains, while the other path builds a tensor, dispatches a torch kernel for the tensor-scalar subtraction, and detaches. More operations and one more rounding. In total it is 0.2 percent of a step, so this is not a performance argument, it is that performance does not oppose accuracy here. float32 was never a choice; it was a writing accident in one function, already in the minority six files to five.

entrainer now takes an explicit chemin_avantage, defaulting to float64. The five scripts that went through it have been rerun, 37.8 minutes with bounded parallelism; the six with no sampled training at all are untouched, and those are the ones carrying the product ceiling, the Gibbs optimum, the order-1 marginals and the capacity probe, none of which has an advantage line to change.

What the switch actually moved, archived against rerun, same seed 0 as before:

  beta    valid% f32   valid% f64   modes f32   modes f64
  0.01         99.84        99.99         9.9        18.0
  0.02         99.99        99.94        18.6        11.5
  0.05         92.65        99.76        23.8        19.9
  0.08         94.87        84.11        24.4        26.5
  0.12         57.13        55.31        45.9        45.4
  0.35          5.27         5.27        43.5        43.5

  long grammar, graded reward :   6.4 %  ->  15.8 %

The long-grammar number is quoted in the published article and it is now 2.5 times larger. None of this is a surprise, and that is the point: this is a single-seed table, and I had already written in section 4.2 that a single-seed sweep cannot draw a frontier, then used it anyway. The 70-seed conclusions and everything obtained by enumeration are unmoved.

So the practical consequence for the next release is not to refresh those tables with new numbers. It is to replace single-seed tables with multi-seed means and a spread, otherwise the same fragility gets republished with different decimals.

Housekeeping, done. torch.set_num_threads is now in rl_grammaire.py, which fourteen scripts import, with RDTRL_THREADS to override for the large-batch exact-gradient work. It no longer depends on the shell.

And the answer I owed you. Sweep seed 0 emits les 0.544 and des 0.455. The trajectory run emits des 0.912 and les 0.087. Both plural, so it was never a corner disagreement, and "below 12 therefore singular" does not hold: an unbalanced plural product drops under 12 without leaving its corner. You reached that yourself before I sent it, and your reason is the right one, effective modes is 2^H of the joint restricted to the valid set rather than a count of support. You corrected it faster than I delivered it.

Four of my published numbers came apart today: the 2-to-1 branch bias, the all-plural sublanguage, the early-stopping gap, and the corner-conditional version of it I wrote to replace the gap. The first three were one seed. The fourth was twenty seeds and one numeric path, which is the harder lesson, because it looked like the fix rather than the same mistake in better clothes.

All four survived for the same reason, worth saying plainly: I had no reason to rerun a result that did not bother me. The rule is not "replicate", which I already knew. It is replicate what is convenient first, and check the control you just built against the claim you just made with it.

Last thing, and it is yours. I finally ran the reversal test, the one experiment that decides whether the product bound is a law or an accident of my French lexicon.

My first version of it was empty and I nearly ran it. I built a lexicon moving genre-neutrality from the plural determiners to the singular ones: same twenty tokens, same 8,000 space, same 48 valid sentences, same two corners of 24, and it swapped the ceilings and both order-1 marginals cleanly. Too cleanly. The nouns and verbs are already symmetric in number, two per genre and number and three verbs each, so swapping the determiners' number is the sg-pl relabelling and nothing else. Verified on the feature multisets. Seventy seeds would have returned the mirror image by construction and proved only that my code does not branch on the strings "sg" and "pl".

The principle I was missing: a relabelling can permute, but it cannot change a ratio. A perfectly symmetric control is often a perfectly empty one.

So the real test uses three genders. Both corners hold 36 valid sentences, but the singular determiners are genre-neutral so that corner is one product of 2 x 6 x 3 = 36, while the plural ones are marked across three genders so the genre must be fixed: 2 x 2 x 3 = 12. Ratio 3 instead of 2, which no relabelling of a two-gender grammar can produce, since the largest product is an isomorphism invariant.

Ceilings computed by enumeration and committed before the run. Seventy seeds, beta = 0.02, float64:

  corner      n   predicted ceiling   max observed   violations   exactly on it
  singular   33          36               36.0            0             2
  plural     37          12               12.0            0             7

And the quantitative form is stronger than the violation count:

  grammar              ceiling ratio    observed mean ratio
  standard, 2 genders       2.0                1.82
  three genders             3.0                3.01

The mean tracks the ratio, not just the ordering. The branch is still a coin at 33/37, p = 0.72, despite both order-1 marginals having flipped, and I(det ; noun) has median 0.0000 with zero of seventy above 0.05 bits.

One sub-prediction of mine was too strong: "effective modes land on integer products" measures 66 percent in the standard grammar and 67 percent here. A stable fraction, so a real fact, but not a rule. The ceiling is a law; the quantisation is not.

Your bound survives a change of grammar, in value and not only in order. That was the one item my own publishability assessment listed as blocking, and it is cleared.

Notebook entries 7.11quinquies through 7.13, and section 1 now dates eight refuted hypotheses.