resourcePatches carries a systematic ~0.61 offset at every point, and exact-match scoring cannot see it

[wormeyman]

The measurement

test/resourcePatches.spec.ts grades makeResourcePatches against
oracle-resource-starting.seed123456.json - 4 cases x 3745 positions. After
#260 snapped the sample coordinates onto the game's 1/256 grid, the worst
absolute error dropped from 4.899 / 4.340 / 5.270 / 4.673 to
0.641 / 0.388 / 0.626 / 0.376.

What is left is not noise. It is a systematic ~0.61 absolute offset present at
essentially every point, including positions that were always on the grid:

position	on the 1/256 grid?	|error|
idx 0, (-239.5, -239.75)	yes	0.6139
idx 1860, (0.5, 0.25)	yes	0.6141
idx 3721, (1500.5, 0.25)	yes	0.6164

Field values there are near -12,300, so this is ~5e-5 relative.

Exact-match scoring is blind to it: 0 of 14,980 values satisfy
Math.fround(got) === expected, before or after the snap. So the programme in
#256 will not surface this one, and the combined-tolerance gate cannot either -
a point fails only if it busts ABS_TOL and REL_TOL together, and 5e-5
relative is 200x inside the 1e-2 gate.

Why it looks like one term rather than accumulated rounding

Flat ~0.61 across three positions spanning (0.5, 0.25) to (1500.5, 0.25),
on field magnitudes that do not change much, is the signature of a single
additive term being slightly wrong - not of error accumulating with distance or
frequency. Accumulated f32 rounding on a field of ~12,300 would vary with
magnitude and position; this does not appear to.

That is a hypothesis from three points, not a finding. Nobody has decomposed
it, and this issue exists so the number is on the record rather than living
only in a spec comment - which is exactly how the "f32 coordinate floor"
attributions #260 refuted survived for a year.

Where to start

makeResourcePatches is max(starting, regular). The decomposition that
settled the last residual in this family (see
docs/noise/random-penalty-NOTES.md, the "~1e-3 residual" section) was to split
each field value into spotField + blobTerm and find points sitting exactly on
the basement constant - error there is entirely in the blob term. The same
split should work here. Candidate terms, in rough order of suspicion:

• the blob amplitude path (regularSpotHeightTypicalAt / startingBlobAmplitude
  in resourceMath.ts), which is where the fastapprox cbrt lives and which
  multiplies a large scalar;
• the basement constant itself;
• randomPenalty's contribution - note Snap oracle capture coords to the 1/256 grid the game actually sampled #260 fixed a missing f32 narrowing on its
  return, worth up to 1.19e-7 relative on the product, which is far too small to
  be this but confirms that path had an unmeasured gap.

Do not

ABS_TOL is now 0.7, set just above the measured 0.641. Do not raise it to
make room for a change; a regression here should go red. And do not read the
tolerance passing as evidence the port is right - it was passing at 1.0 with an
error of 5.270 for as long as the fixture has existed.

Found while snapping the capture coordinates for #260.

[wormeyman]

Decomposed: the whole offset is basementValue, and the term is the fastCbrt inside it

Measured 2026-08-25 while porting src/noise/resources/ to Rust (#226). Both
resource fixtures, all eight cases, positions snapped.

The exact-match metric degenerates on the OTHER fixture too

This issue recorded 0 of 14,980 on oracle-resource-starting.
oracle-resource-regular is the same: 0 of 16,420 (4 cases x 4,105), snapped
or not. So the count is not a property of the starting patches - it is a
property of the field's magnitude.

The offset sits where no cone reaches, and nowhere else

Split each case's positions by whether the port's own spot field is exactly
basementValue - that is, whether any cone reached the point. The spot field is
recoverable without touching the port: field - blobTerm, with the blob rebuilt
from the exported basisNoise and regularBlobAmplitudeAt.

case	no cone reached	mean residual	sd	a cone won	mean residual
starting iron 123456	3,623	+0.614264	0.0017	122	-0.0227
starting iron 777771	3,664	+0.614335	0.0014	81	-0.0417
starting copper 123456	3,351	+0.361586	0.0036	394	+0.2741
starting copper 777771	3,418	+0.361658	0.0036	327	+0.2969
regular iron 123456	3,965	+0.614284	0.0087	140	+0.3925
regular iron 777771	3,955	+0.613867	0.0088	150	+0.3791
regular uranium 123456	3,404	+0.408071	0.0083	701	+0.4033
regular uranium 777771	3,360	+0.407877	0.0084	745	+0.4029

The "a cone won" column is muddy on purpose, and it is worth saying why rather
than quietly dropping it: a cone that only just beats the basement leaves the
value still sitting at basement height, so the basement error is still in it.
That is why regular uranium's two columns agree - its cones are small. Grading
by how far the value sits ABOVE basement separates them cleanly. At
game >= basement + 15000 the mean residual is +0.013 to +0.028 in the
seven cases that have any position that far up, against +0.36 to +0.61 at
basement. Twenty to forty times smaller, on the points where the basement
constant is never read.

One substitution predicts all three offsets, with no free parameter

basementValue = -6 * max(regularBlobAmplitudeAt(maxDistance), startingBlobAmplitude).
Both of those run their cube root through fastCbrt. Recompute the same two
formulas with exact Math.cbrt and nothing else changed:

resource	basement, fastCbrt	basement, exact cbrt	predicted shift	measured offset	miss
iron-ore	-12311.3742075	-12311.9859602	-0.611753	+0.614264	0.4%
uranium-ore	-11663.9435520	-11664.3504950	-0.406943	+0.407877	0.2%
copper-ore	-11429.0754334	-11429.4353105	-0.359877	+0.361586	0.5%

Three resources, three different predicted values, each within half a percent of
its own measured offset. The relative error fastCbrt carries on the winning
term is 4.97e-5, 3.49e-5 and 3.15e-5 - different per resource, which is why a
single global constant was never going to fit this.

The half-percent that is left is the same size as the blob term's own scatter at
those points (sd 0.0014 to 0.0088), so there is nothing else to attribute.

What this does NOT say

The blob AMPLITUDE looks right as it stands, and the at-basement column is what
says so. Over the starting fixture's own positions regularBlobAmplitudeAt runs
from about 0 to 2051.90 - the fixture reaches past the 1600-tile plateau - so a
5e-5 relative error in that amplitude would put up to 0.103 of scatter into the
at-basement residual. The measured sd is 0.0017, sixty times smaller, and the
residual is flat across positions whose amplitudes differ by three orders of
magnitude. So the game appears to use the fastapprox cube root for the
per-distance blob amplitude - matching us - and something more accurate for the
basement scalar. That asymmetry is the open part, and it is a reason to
re-measure rather than to go swap every fastCbrt in the file.

regularPatches.ts's header records the opposite result for the blob path -
exact Math.cbrt there left a ~7e-5 relative error that dominated the blob term

• so the two are not in conflict. They are different call sites of the same
  function.

Not fixed here

Left alone in the Rust port, per the rule that a finding in shipped TypeScript
gets its own graded change rather than a unilateral fix on the Rust side, which
would read as a port bug in tier 2. The Rust port reproduces fastCbrt at both
sites, and its tier-1 tests freeze these residuals as exact values, so whoever
does fix this will get a red test naming every number that moved.

Two notes for that change, both measured while planting breaks against these
fixtures:

• A frozen worst-absolute residual cannot police this layer on its own. Two
  real narrowing changes - dropping the f32() on 3 * s.quantity, and
  pre-narrowing Math.PI in the cone - alter field values (an order-sensitive
  raw-bits fold of all 31,400 values moves) and shift the worst-absolute
  residual in 0 of 8 cases. The 0.61 offset swamps them.
• Seven edits that look like breaks are genuine no-ops here, verified by
  that same fold: the regular cull radius 128 -> 120, the cone's > -> >=,
  Math.min(atMax, atD) argument order, REGULAR_SPACING's last digit, 1/3
  written as a decimal, regularRqFactorMultiplier / 10 -> * 0.1, and folding
  1000000 / spots / frequency into one divide. The last one only because every
  fixture case has frequency = 1, so the second divide is by one - the two
  sequential divides are still load-bearing off the default control.

[wormeyman]

Correction: the "a cone won" column above was measured through a lossy proxy

The conclusion stands and gets stronger, but one column of that table is wrong
and I would rather replace it than leave it.

What went wrong. To split positions by whether a cone reached them I needed
the spot field on its own. The TypeScript keeps spotFieldAt as a module-local
closure, so I recovered it as field - blobTerm and compared that to the
basement. (a + b) - b is not a in floating point, so that proxy classifies a
position as "a cone won" whenever the round trip loses a low bit - which it does
a lot, on a basement near -12,000 with a blob term in the thousands.

Measured against the direct spot field, the proxy undercounts the at-basement
group by 0 to 692 positions per case. It happens to be exact for starting iron,
which is why the sharp numbers in the table are the ones that survive unchanged.

The corrected split. Same eight cases, same snapped positions, the predicate
now taken from the spot field itself:

case	no cone reached	mean residual	sd	a cone won	mean residual
starting iron 123456	3,623	+0.614264	0.0017	122	-0.0227
starting iron 777771	3,664	+0.614335	0.0014	81	-0.0417
starting copper 123456	3,663	+0.361755	0.0038	82	-0.0665
starting copper 777771	3,700	+0.361834	0.0037	45	-0.1237
regular iron 123456	4,055	+0.614262	0.0087	50	-0.0050
regular iron 777771	4,048	+0.613868	0.0088	57	-0.0039
regular uranium 123456	4,096	+0.408155	0.0084	9	-0.0023
regular uranium 777771	4,096	+0.407873	0.0085	9	-0.0019

The at-basement column barely moves - the largest change is copper's +0.361586
to +0.361755, well inside its own scatter - so every prediction in the comment
above still holds to the same half a percent.

The cone column is the part that changes, and it changes in the direction the
argument wanted. It now reads -0.002 to -0.124 rather than the +0.27 to +0.40
I posted. Where no basement is read, the port is within a tenth of a unit of the
game on a field of twelve thousand. The paragraph explaining the column as
"muddy on purpose, because a cone that only just beats the basement still
carries the basement error" was rationalising an artifact: regular uranium's two
columns looked alike because the proxy had put 692 basement positions into the
cone group, not because its cones are small.

What this does not touch. The game >= basement + 15000 bucket figures are
computed from the game's own values with no proxy anywhere, so they are
unchanged, and so is the exact-cbrt prediction table - three resources, three
predicted shifts, each within half a percent of its measured offset.

The direct counts are now frozen in
crates/fmw-noise/src/fixtures.rs as part of the Rust port's tier 1, alongside
the note that a cone-versus-basement split taken from a subtraction is reading
noise.