fastCbrt passes a double 1/3 where Math::powSafe takes a float exponent - 3.2% of inputs diverge

[wormeyman]

fastCbrt passes a JavaScript double 1/3 into fastPow:

export function fastPow(x: number, p: number): number {
  return fastPow2(f32(p * fastLog2(x)));   // p is a double here
}
export function fastCbrt(x: number): number {
  return fastPow(x, 1 / 3);                // 0.3333333333333333, not f32
}

The game's exponent is a float, so the multiply happens at single precision.

Read from the binary, not inferred

The symbol is __ZN4Math7powSafeEff = Math::powSafe(float, float) at 0x102955a88 in
the 2.1.12 arm64 binary - both parameters are float. The non-integral-exponent path
inlines fastapprox log2 (the same 0xbfbfbf75 / 0x3eb444f9 / 0xbfdce9a3 constants we
already carry) and then multiplies by the exponent at single precision:

102955ba8: fdiv  s2, s3, s2
102955bac: fadd  s0, s0, s2      ; s0 = fastlog2(x)
102955bb0: fmul  s0, s0, s1      ; <-- s1 is the exponent, SINGLE precision

f32(1/3) is 0.3333333432674408; the double is 0.3333333333333333. They are not equal,
so f32(double * log2) and f32(f32 * log2) can round to different f32 values.

Measured divergence

Current fastCbrt(x) vs fastPow(x, Math.fround(1/3)), 200,000 log-uniform samples over
x in [1e1, 1e8] (the band resource quantities live in):

6430 / 200000 = 3.215% of inputs differ.
Worst relative 2.867e-5, worst absolute 7.813e-3, at x ~= 2.023e7.

One rival explanation, tested and REFUTED

Math::powSafe also has an integral-exponent fast path (fcvtzs/scvtf round-trip at
0x102955ab0, then exponentiation by squaring) that skips fastapprox entirely. Our
fastPow has two other call sites that pass an integer octaves
(multioctaveNoise.ts:73, trees/treeField.ts:109), so the obvious worry is that the
multioctave RMS normalisation should be using exact squaring.

It should not. Swapping the norm to f32 exponentiation-by-squaring and re-measuring
against oracle-multioctave.seed123456.json (7 cases x 38 positions, persistences
0.45/0.5/0.65/0.7/0.9 - i.e. covering the non-power-of-two cases where the two differ most):

norm	worstNear	worstFar
fastPow (current)	2.630e-5	1.170e-4
exponentiation by squaring	5.332e-4	3.385e-4
gate	< 5e-5	< 2e-4

Squaring is 20x worse and fails both gates. So the noise machine's normalisation does
not route through Math::powSafe, and fastPow's current behaviour is correct at both
of its integer-exponent call sites. This issue is therefore only about the 1/3
exponent in fastCbrt.

What is still open

Whether the resource subsystem (spot_height / blob_amplitude / the spot-selection cone
radius - a different code path from the noise-expression evaluator) actually calls
Math::powSafe. The measurement above says the noise machine does not; it says nothing
about the resource autoplacer. Settle that before changing fastCbrt, because the fix is
only correct if powSafe is the function on that path.

The fix, if confirmed, is one character-class change: fastPow(x, f32(1 / 3)).

Related: the fastApprox per-op rounding change in #161, and #162 on why a
tolerance-based suite cannot see any of this.

[wormeyman]

Settled: yes, the resource expressions do route through Math::powSafe. The open question in the description is closed, and the fix is justified.

The cube roots are not C++ calls at all - they are ^ (1/3) written inside noise expression strings in core/prototypes/noise-functions.lua (2.1.12):

regular_spot_height_typical_at = "((random_spot_size_minimum + random_spot_size_maximum) / 2
    * regular_spot_quantity_base_at(distance)) ^ (1/3) / (pi/3 * regular_rq_factor ^ 2)"   -- :281
starting_blob_amplitude = "... / (pi/3 * starting_rq_factor ^ 2) * starting_area_spot_quantity ^ (1/3)"  -- :233

So the question is what the noise machine's ^ operator does. There are three pow paths, and all three take float:

op type	symbol	complexity
22	NoiseOperations::Functions::pow(float, float)	140
24	NoiseOperations::Functions::powPrecise(float, float)	1500
-	NoiseOperations::PowInt	-

Functions::pow at 0x10176d234 is one instruction:

10176d234: 1447a215    b    0x102955a88 <__ZN4Math7powSafeEff>

An unconditional tail-call into Math::powSafe(float, float). The exponent is therefore an f32 at the call boundary no matter how the parser folded 1/3, so the game computes f32(1/3) = 0.3333333432674408, not the double our fastCbrt passes.

Two corroborations, so this does not rest on the disassembly alone:

• voronoiNoise.ts already independently established the same constant. Its ONE_THIRD_F32 is commented "the exact multiplier the binary uses (0x3eaaaaab) for the cube root" - and 0x3eaaaaab is exactly f32(1/3). That was read from a different function (minkowski3) for a different reason and agrees.
• powPrecise is NOT the operator in play, which the empirical record already showed: it widens to double and calls Math::powPrecise(double, double) (0x10175d02c: fcvt d0, s0 / fcvt d1, s1 / bl), i.e. a genuine libm pow. If ^ compiled to that, an exact Math.cbrt would have matched the game - and test/regularPatches.spec.ts records that exact cbrt scored ~3 units of absolute error against fastapprox's ~0.7.

For contrast, PowInt is what regular_rq_factor ^ 2 on those same lines compiles to, which is why powSafe's integral fast path exists and why it is irrelevant here.

The fix is fastPow(x, f32(1 / 3)). It moves 3.215% of cube roots (worst rel 2.9e-5, abs 7.8e-3 at x~2e7), and every one of those feeds shipped resource output, so it interacts directly with #161 - the same "no downstream test can resolve 1e-5" problem applies.

Measured on the 2.1.12 binary (build 87038); note 2.1.13 shipped 2026-08-05 with no map-generation entries in its changelog.