Narrow basis_noise's output_scale the way the game does, 196/196 (#269) (#288)

`basisNoiseExpr` returned `output_scale * basis` as an un-narrowed f64. The game
evaluates `f32(f32(output_scale) * basis)`. Graded against the game at 196
positions and five output scales using the fixture captured in #287:

  f32(f32(output_scale) * basis)   196/196 at all five scales   <- the game
  f32(output_scale * basis)        196, 110, 151, 196, 196      <- #269's proposal
  output_scale * basis (shipped)   196,  28,   6,  96,   1
  f32(output_scale) * basis        196,   0,   0,   0,   1

Every count is an exact f64 equality, never a bound. Both sides produce f32
values, so a tolerance would pass for all four models at once and measure
nothing (#162).

**Narrowing the product is necessary and NOT sufficient, which is the half the
issue does not say.** The `output_scale` CONSTANT is held at f32 as well - the
same shape as #273 - so this is both cases of the two-case rule in
`src/noise/eval/f32.ts` at a single call site. The two forms coincide only where
`output_scale` is already f32-exact, which is why the second row above is
complete at 1 and 125 and short at 0.6, 0.51 and 0.75.

The assertion in `test/basisOutputScale.spec.ts` that froze `[196, 28, 6, 96, 1]`
was written to go red when this landed, and it did. It is now all-196 rather
than loosened.

## Re-scored, because a green gate cannot see this change

This alters shipped behaviour in five expression files that each pass their own
oracle spec, and #273 measured that this class of change moves counts in BOTH
directions. So every affected field was re-scored by exact f32 matches, before
and after, by reverting only `basisNoiseExpr` on this same tree:

  vulcanus mountain_plasma      7 -> 11  of 38
  vulcanus elev               114 -> 116 of 434
  vulcanus elevation          114 -> 116 of 434
  nauvis elevation_lakes       13 -> 13  of 17    (control)
  nauvis elevation_nauvis       3 ->  3  of 17    (control)
  cliffiness gate seed=123456  1024 -> 1024       (control)
  cliffiness gate seed=777771  1024 -> 1024       (control)

Nothing regressed. `test/basisOutputScaleCallers.spec.ts` freezes those counts
as a live spec rather than leaving them in a commit message, for the reason
`fixtures.rs` carries #273's planted fix as a test: a measurement nobody runs
goes stale. Reverting `basisNoiseExpr` takes it red at 7 and 114 - watched, not
assumed - while its control test stays green.

Which sites the fix can reach is decided by the output scale alone. A
power-of-two scale is a pure exponent shift and can never leave the f32 grid, so
the eleven `plasma` calls the crack layer makes at 1, 0.5 and 0.25 are blind by
construction and did not move. `cliff_fields` (0.51), `nauvis_shared` (0.6),
`elevation_lakes` (1.5), `vulcanus_elevation` (250, 150) and the `plasma`
magnitudes routed into it (125/625, 0.15/0.75) are the exposed ones.

## A measured instance of #256

The full TypeScript suite passed with ZERO failures under this change. Every
oracle spec covering these five callers asserts a combined abs/rel bound wide
enough to swallow the whole difference, so `pnpm run verify` going green was not
evidence of anything. Only the two frozen-count specs could see it. That is
recorded in CLAUDE.md next to the three port findings, because the next person
to change a shared op needs to know the gate will not catch them.

## Rust

`basis_noise_expr` now returns `f64::from((output_scale as f32) * basis)`. An
f32 multiply IS `f32(f32(os) * basis)`: the exact product of two f32s fits in an
f64 mantissa, so there is no double rounding and it matches
`Math.fround(Math.fround(os) * basis)` bit for bit.

Its docblock argued at length that NOT narrowing was deliberate, because no
fixture could grade the difference and a unilateral change would read as a port
bug in tier 2. That reasoning was sound and is now spent: #287 captured the
fixture, and both ports change in this commit, so tier 2 stays honest. The
docblock records that rather than quietly dropping it.

The `the_output_scale_multiplies_the_result_once` test asserted the old reading
and is replaced by `the_output_scale_and_the_product_are_both_narrowed`, which
keeps the original's discriminating scan and adds a second counter for points
that separate narrowing the product alone from also holding the constant at f32
- so the scan can see the half #269 omits. A new
`a_power_of_two_output_scale_is_blind_to_the_narrowing` asserts the immunity
rule directly. 137 Rust tests, up from 136.

`engine.wasm` rebuilt: 84,160 bytes, 4031d1d7. No POISONED_TESTS entry names the
renamed test, and no op was added, so none is owed.

Full gate green at VERIFY_RC=0, including the committed-wasm byte compare.


Claude-Session: https://claude.ai/code/session_01X2wz8eFazisYuENEkmBvvG

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: wormeyman

CLAUDE.md

@@ -1432,11 +1432,32 @@ shipped call sites.
 port.** All were behaviour changes to shipped fields that passed their own
 fixtures, so each got an issue instead. The port reproduces the TypeScript
 exactly in every case - a unilateral "fix" on the Rust side would read as a port
-bug in tier 2, which is the whole point of having tier 2. **Two have since
+bug in tier 2, which is the whole point of having tier 2. **All three have since
 landed as their own changes**, which is the intended path, not an exception:
 
-- **#269 - STILL OPEN.** `basisNoiseExpr` returns an un-narrowed f64 product
-  where the game narrows to f32, and none of its five callers narrow either.
+- **#269 - LANDED.** `basisNoiseExpr` returned an un-narrowed f64 product where
+  the game evaluates `f32(f32(output_scale) * basis)`, and none of its five
+  callers narrowed either. Settled against the game at 196 positions and five
+  output scales (the fixture is #287's): the shipped form scored
+  `[196, 28, 6, 96, 1]` and the game's form scores **196 of 196 at every scale**.
+  **Narrowing the product is necessary and NOT sufficient** - the `output_scale`
+  CONSTANT is held at f32 as well, the same shape as #273, and that is the half
+  the issue itself does not say.
+
+  Re-scored on every field that reads it, because a green gate proves nothing
+  here (see below): `mountain_plasma` **7 -> 11 of 38**, Vulcanus `elev` and
+  `elevation` **114 -> 116 of 434**, and `elevation_lakes` (13/17),
+  `elevation_nauvis` (3/17) and both `cliffiness` gates (1024/1024) unmoved.
+  Nothing regressed - unlike #273, which moved counts in both directions.
+
+  **A power-of-two `output_scale` is immune** and cannot grade any of this:
+  multiplying an f32 by one is a pure exponent shift. Which sites the fix can
+  reach is decided by the output scale alone - `cliff_fields` (0.51),
+  `nauvis_shared` (0.6), `elevation_lakes` (1.5), `vulcanus_elevation`
+  (250, 150) and the `plasma` magnitudes routed into it (125/625, 0.15/0.75)
+  are all exposed, while the eleven `plasma` sites the crack layer calls at
+  1, 0.5 and 0.25 are blind by construction and did not move.
+
 - **#270 - FIXED.** The wasm libm question above. Closed by deleting the
   un-narrowed `slider_rescale` and moving all five callers onto the
   per-operation form the oracle says the game uses.
@@ -1452,6 +1473,17 @@ landed as their own changes**, which is the intended path, not an exception:
 The shape to copy: find it while porting, reproduce it faithfully so tier 2 stays
 honest, open an issue, and fix it in a change graded on its own.
 
+**A green `pnpm run verify` cannot see a change of this class - measured, not
+assumed (#256).** When #269's fix landed, the full TypeScript suite passed with
+**zero failures** even though the model under seven call sites had changed,
+because the oracle specs that cover those callers assert combined abs/rel bounds
+rather than exact f32 matches. The bounds are wide enough to swallow the whole
+difference. The only spec that noticed was `test/basisOutputScale.spec.ts`,
+which freezes exact counts on purpose. So when you change an op that shipped
+fields read, **re-score those fields exactly before and after** - the gate going
+green is not evidence, and #162 is the standing record of a tolerance hiding a
+real bug for a year.
+
 **`f64::max` is NOT `Math.max`, and only a raw-bits fold can see the
 difference** (found 2026-08-19, #224). They differ two ways: on NaN, where
 `f64::max` returns the non-NaN operand and `Math.max` propagates - and on

crates/fmw-noise/src/eval/primitives.rs

@@ -35,22 +35,42 @@ pub struct BasisExprParams {
 /// there, and narrowing it here would evaluate a DIFFERENT point. This is the
 /// same reading `fixtures::score` records for the raw kernel.
 ///
-/// ## It returns f64, and the missing narrowing is DELIBERATE (#269)
+/// ## The output scale is narrowed twice, and both are needed (#269)
 ///
-/// The game's noise machine evaluates `output_scale * basis_noise(...)` as one
-/// f32 operation. The TypeScript does not narrow it - it returns the plain f64
-/// product - and neither do any of its five callers: `nauvis_shared` writes
-/// `0.65 + basisNoiseExpr(...)`, `elevation_lakes` writes
-/// `basisNoiseExpr(...) + sld/4 - 4`, both in f64.
+/// The game evaluates this as `f32(f32(output_scale) * basis)`. That is BOTH
+/// cases of the two-case rule at one call site, which is why neither half alone
+/// reaches the game:
 ///
-/// So this port returns f64 too. **Narrowing here would be a silent behaviour
-/// change to five shipped expression files**, every one of them currently
-/// passing its own oracle fixture, and this phase has no fixture that can grade
-/// the difference. The two-case rule in [`super`] says isolate the term and
-/// measure before fixing it; #269 tracks doing exactly that against those five
-/// fixtures. Until then the port carries the same approximation the TypeScript
-/// carries, on purpose, because tier 2 compares the two ports and a unilateral
-/// "fix" here would read as a port bug.
+/// - **The CONSTANT.** `output_scale` is a program literal the engine holds at
+///   f32. The f64 `0.6` is 0.59999999999999997780 and no amount of rounding the
+///   product recovers the difference.
+/// - **The PRODUCT.** `basis_noise` returns an f32 and the multiply is its own
+///   f32 operation, so its result is f32 before anything downstream reads it.
+///
+/// Graded against the game at 196 positions and five output scales in
+/// `test/basisOutputScale.spec.ts`. Exact equality, never a bound (#162):
+///
+/// ```text
+/// f32(f32(output_scale) * basis)   196/196 at all five scales   <- the game
+/// f32(output_scale * basis)        196, 110, 151, 196, 196      <- #269's proposal
+/// output_scale * basis             196,  28,   6,  96,   1      <- what shipped
+/// f32(output_scale) * basis        196,   0,   0,   0,   1
+/// ```
+///
+/// **A power-of-two `output_scale` is immune** and cannot grade this: multiplying
+/// an f32 by one is a pure exponent shift, so the product can never leave the
+/// f32 grid. That is why the older `oracle-basis` fixture, captured at
+/// `output_scale = 1`, could not answer the question and a new capture had to.
+///
+/// An earlier revision of this comment argued at length that NOT narrowing was
+/// deliberate, because no fixture could grade the difference and a unilateral
+/// change here would read as a port bug against the TypeScript. That reasoning
+/// was sound and it is now spent: #287 captured the discriminating fixture, the
+/// TypeScript changed in the same commit as this, and the two ports still agree.
+///
+/// The `input_scale` product is deliberately NOT narrowed. It decides which
+/// point gets sampled rather than what the product rounds to. Whether the game
+/// holds `input_scale` at f32 too is a separate, unmeasured question on #269.
 #[must_use]
 pub fn basis_noise_expr(
     x: f64,
@@ -63,7 +83,10 @@ pub fn basis_noise_expr(
         y * params.input_scale,
         tables,
     );
-    params.output_scale * f64::from(v)
+    // f32 * f32 in one operation IS `f32(f32(os) * basis)`: the exact product of
+    // two f32s fits in an f64 mantissa, so there is no double rounding to dodge
+    // and this matches `Math.fround(Math.fround(os) * basis)` bit for bit.
+    f64::from((params.output_scale as f32) * v)
 }
 
 #[cfg(test)]
@@ -111,49 +134,77 @@ mod tests {
         assert_ne!(got, wrong);
     }
 
-    /// `output_scale` multiplies the RESULT, in f64, with NO narrowing - see
-    /// the docblock and #269.
+    /// `output_scale` is narrowed to f32 and so is the product: the game
+    /// evaluates `f32(f32(output_scale) * basis)` (#269).
     ///
-    /// The second half is what makes this test say something: it picks an
-    /// output scale whose product is NOT f32-representable, so a port that
-    /// narrowed would return a different number. Without it the assertion would
-    /// hold for either reading.
+    /// The scans are what make this test say something. A hand-picked point
+    /// proves nothing here - at (3.25, -7.5) with a scale of 0.1 the f64 product
+    /// happens to land exactly on an f32, so it cannot tell the readings apart.
+    /// That was found by an assertion failing, not by reading the code, which is
+    /// why both halves scan and then assert they FOUND discriminating points.
     #[test]
-    fn the_output_scale_multiplies_the_result_once() {
+    fn the_output_scale_and_the_product_are_both_narrowed() {
         let tables = tables_from_seed(123_456, 123);
         let mut p = params();
+
+        // Half one: an f32-exact scale, so only the PRODUCT narrowing can show.
         p.output_scale = 7.5;
-        let raw = basis_noise((3.25) / 32.0, (-7.5) / 32.0, &tables);
+        let raw = basis_noise(3.25 / 32.0, -7.5 / 32.0, &tables);
         assert_eq!(
             basis_noise_expr(3.25, -7.5, &p, &tables),
-            7.5 * f64::from(raw)
+            f64::from(7.5_f32 * raw)
         );
 
-        // And the discriminating half. A single hand-picked point is not
-        // enough: at (3.25, -7.5) with a scale of 0.1 the f64 product happens
-        // to land exactly on an f32, so it cannot tell the two readings apart.
-        // That was found by the assertion below failing, not by reading the
-        // code, which is why this scans instead.
+        // Half two: a scale that is NOT f32-exact, so the CONSTANT narrowing
+        // shows too. `vs_unnarrowed` counts points that separate the shipped
+        // model from this one; `vs_product_only` counts points that separate
+        // narrowing the product ALONE from narrowing the constant as well -
+        // which is the half #269 itself does not say.
         p.output_scale = 1.0 / 3.0;
-        let mut discriminating = 0usize;
+        let mut vs_unnarrowed = 0usize;
+        let mut vs_product_only = 0usize;
         for k in 0..64 {
             let (x, y) = (f64::from(k) * 3.25 - 40.0, f64::from(k) * -1.75 + 11.0);
-            let want = p.output_scale
-                * f64::from(basis_noise(
-                    (x + p.offset_x) * p.input_scale,
-                    y * p.input_scale,
-                    &tables,
-                ));
+            let basis = basis_noise((x + p.offset_x) * p.input_scale, y * p.input_scale, &tables);
+            let want = f64::from((p.output_scale as f32) * basis);
             assert_eq!(basis_noise_expr(x, y, &p, &tables), want);
-            if want != f64::from(want as f32) {
-                discriminating += 1;
+
+            let unnarrowed = p.output_scale * f64::from(basis);
+            if want != unnarrowed {
+                vs_unnarrowed += 1;
+            }
+            if want != f64::from((p.output_scale * f64::from(basis)) as f32) {
+                vs_product_only += 1;
             }
         }
         assert!(
-            discriminating > 32,
-            "only {discriminating} of 64 points can tell the un-narrowed f64 \
-             product from its f32 narrowing, so the assertions above mostly \
-             hold for either reading"
+            vs_unnarrowed > 32,
+            "only {vs_unnarrowed} of 64 points separate this from the un-narrowed              f64 product, so the assertions above mostly hold for either reading"
         );
+        assert!(
+            vs_product_only > 0,
+            "no point separates narrowing the product alone from also holding              output_scale at f32, so this scan cannot see the second half of #269"
+        );
+    }
+
+    /// A power-of-two `output_scale` cannot grade any of this: multiplying an
+    /// f32 by one is a pure exponent shift, so every candidate model coincides.
+    /// This is why the older `oracle-basis` fixture, captured at
+    /// `output_scale = 1`, could not answer #269.
+    #[test]
+    fn a_power_of_two_output_scale_is_blind_to_the_narrowing() {
+        let tables = tables_from_seed(123_456, 123);
+        let mut p = params();
+        for os in [1.0, 0.5, 0.25, 2.0, 4.0, 64.0] {
+            p.output_scale = os;
+            for k in 0..64 {
+                let (x, y) = (f64::from(k) * 3.25 - 40.0, f64::from(k) * -1.75 + 11.0);
+                let basis =
+                    basis_noise((x + p.offset_x) * p.input_scale, y * p.input_scale, &tables);
+                // The un-narrowed product and the fully narrowed one are the
+                // same number here, so the adapter matches both at once.
+                assert_eq!(basis_noise_expr(x, y, &p, &tables), os * f64::from(basis));
+            }
+        }
     }
 }

crates/fmw-wasm/src/lib.rs

@@ -744,9 +744,10 @@ pub extern "C" fn checksum_eval_pipeline(
         offset_x,
     };
     let tables = basis_noise::tables_from_seed(seed0, seed1);
-    // f64, not f32: `basis_noise_expr` returns the un-narrowed f64 product
-    // that the TypeScript returns, and the TypeScript memos hold a `number`.
-    // See the note on `basis_noise_expr` and #269.
+    // f64, not f32: `basis_noise_expr` narrows the product to f32 (#269) but
+    // returns it widened, exactly as the TypeScript does, and the TypeScript
+    // memos hold a `number`. The memo element type tracks the memo, not the
+    // arithmetic. See the note on `basis_noise_expr`.
     let mut region = MemoRegion::<f64>::new();
     let mut slot = MemoXy::<f64>::new();
 

src/noise/eval/primitives.ts

@@ -1,4 +1,5 @@
 import { basisNoise, basisNoiseTablesFromSeed, type BasisNoiseTables } from "../basisNoise";
+import { f32 } from "./f32";
 
 export interface BasisExprParams {
   /** Map seed (basis seed word). */
@@ -19,6 +20,40 @@ export interface BasisExprParams {
  * adapter maps world `(x, y)` through `((x + offset_x) * input_scale, y *
  * input_scale)` and multiplies by `output_scale` - exactly the game's DSL. Pass
  * prebuilt `tables` to skip the per-seed derivation when sweeping a grid.
+ *
+ * ## The output scale is narrowed twice, and both are needed (#269)
+ *
+ * The game evaluates this as `f32(f32(output_scale) * basis)`. That is BOTH
+ * cases of the two-case rule in {@link f32} at one call site, which is why
+ * neither half alone reaches the game:
+ *
+ * - **The CONSTANT.** `output_scale` is a program literal the engine holds at
+ *   f32. Writing `0.6` in TypeScript is the f64 0.59999999999999997780, and no
+ *   amount of rounding the product recovers that.
+ * - **The PRODUCT.** `basis_noise` returns an f32 and the multiply is its own
+ *   f32 operation, so its result is f32 before anything downstream reads it.
+ *
+ * Graded against the game at 196 positions and five output scales in
+ * `test/basisOutputScale.spec.ts`. Exact f64 equality, never a bound - both
+ * sides produce f32 values, so a tolerance would pass for every candidate model
+ * at once and measure nothing (#162). The scores that settled it:
+ *
+ * ```text
+ * f32(f32(output_scale) * basis)   196/196 at all five scales   <- the game
+ * f32(output_scale * basis)        196, 110, 151, 196, 196      <- #269's proposal
+ * output_scale * basis             196,  28,   6,  96,   1      <- what shipped
+ * f32(output_scale) * basis        196,   0,   0,   0,   1
+ * ```
+ *
+ * **A power-of-two `output_scale` is immune** and cannot grade this: multiplying
+ * an f32 by one is a pure exponent shift, so it can never leave the f32 grid.
+ * That is why the older `oracle-basis` fixture, captured at `output_scale = 1`,
+ * could not answer the question and a new capture had to.
+ *
+ * The `input_scale` product is deliberately NOT narrowed here. It decides which
+ * point gets sampled rather than what the product rounds to, and narrowing it
+ * would evaluate a DIFFERENT point. Whether the game holds `input_scale` at f32
+ * too is a separate, unmeasured question tracked on #269.
  */
 export function basisNoiseExpr(
   x: number,
@@ -27,8 +62,8 @@ export function basisNoiseExpr(
   tables: BasisNoiseTables = basisNoiseTablesFromSeed(params.seed0, params.seed1),
 ): number {
   const offsetX = params.offsetX ?? 0;
-  return (
-    params.outputScale *
-    basisNoise((x + offsetX) * params.inputScale, y * params.inputScale, tables)
+  return f32(
+    f32(params.outputScale) *
+      basisNoise((x + offsetX) * params.inputScale, y * params.inputScale, tables),
   );
 }

src/noise/wasm/engine.wasm

@@ -86,16 +86,17 @@ describe("basis_noise output_scale narrowing (#269)", () => {
   });
 
   /**
-   * And the current port is the worst of the four wherever the question can be
-   * asked at all. These counts are what #269 is asking to change.
+   * **#269 is fixed, and this is the assertion that graded it.** Before the fix
+   * `basisNoiseExpr` returned the un-narrowed product and scored
+   * `[196, 28, 6, 96, 1]` - the worst of the four models wherever the question
+   * can be asked at all. It now IS `f32ScaleAndProduct`, so it reproduces the
+   * game at every position of every case.
    *
-   * **This assertion is expected to go GREEN-to-RED when #269 is fixed**, and
-   * that is deliberate: the fix turns `basisNoiseExpr` into
-   * `f32ScaleAndProduct`, and the whole point of a frozen count is that the
-   * change announces itself. When it does, replace these with `[196, 196, 196,
-   * 196, 196]` rather than loosening anything.
+   * The count was frozen rather than bounded precisely so the change would
+   * announce itself here, and it did. If it ever moves off a full house again,
+   * read it - do not loosen it.
    */
-  it("the shipped basisNoiseExpr scores this, today", () => {
+  it("the shipped basisNoiseExpr reproduces the game at every output scale", () => {
     const got = fixture.cases.map((c) => {
       let exact = 0;
       for (let i = 0; i < fixture.positions.length; i++) {
@@ -115,7 +116,7 @@ describe("basis_noise output_scale narrowing (#269)", () => {
       }
       return exact;
     });
-    expect(got).toEqual([196, 28, 6, 96, 1]);
+    expect(got).toEqual([N, N, N, N, N]);
   });
 
   /**