Add p5.strands support for randomGaussian()

[harshiltewari2004]

Resolves #8775

Changes

Adds randomGaussian() support for p5.strands, following @davepagurek's guidance in #8775. The implementation is a JS-side wrapper over the existing random() strands function, applying a Box-Muller transform to two uniform samples to produce a normal-distributed sample.

• New augmentFn entry in src/strands/strands_api.js next to the existing random() registration.
• Falls through to the original p5 randomGaussian() when called outside a strands shader context.
• Inside a strands context: builds Box-Muller via two this.random() calls + chained node math.

Implementation note

Uses this.x() rather than fn.x() per @davepagurek's note in the issue thread.

Testing

No unit tests included — there's no existing test/unit/strands/ directory and no clear precedent for unit-testing strands functions (which produce IR nodes rather than directly-testable values). Happy to add tests in whichever direction the maintainers prefer.

Local npm test shows the same 4 flaky visual regression test failures (test/unit/visual/cases/typography.js) that I observed on dev-2.0 before my changes — unrelated to this PR.

PR Checklist

• npm run lint passes
• [Inline reference] is included / updated
• [Unit tests] are included / updated

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@515d2e2/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@515d2e2

Commit hash: dabfd6d

Previous deployments

055554d

• https://raw.esm.sh/pr/p5@03ae18a/lib/p5.min.js
• https://pkg.pr.new/p5@03ae18a

---

This is an automated message.

[perminder-17]

Hi, thanks for the work @harshiltewari2004 , just one concern I have: are you defining randomGaussian inside the random function intentionally? Do you think it should be outside, otherwise randomGaussian won't exist until the user calls random() at least once, and it'll get redefined on every random() call.

Also, can you ad tests for this implementation?

[harshiltewari2004]

Good catch, thanks @perminder-17 — fixed in the latest commit. The randomGaussian augmentation is now a sibling of random, not nested inside it.

[harshiltewari2004]

Happy to add tests @perminder-17 — I noticed there's no test/unit/strands/ directory yet, so I held off. Should I establish that pattern here, or is there an existing test approach for strands I missed?

[perminder-17]

off

You can go with the visual tests, that would make more sense. Thanks for the update :)

[harshiltewari2004]

Thanks @perminder-17! Here's the plan — would appreciate a thumbs-up before I write the tests.

Location: inside the existing visualSuite('p5.strands', ...) in both test/unit/visual/cases/webgl.js and test/unit/visual/cases/webgpu.js. Mirrors the random() colors a basic shader pattern (webgl L1119 / webgpu L329). No new file or suite.

Tests (two per file, four total):

1. randomGaussian() colors a basic shader — direct analogue of the existing random() shader-coloring test. randomSeed(12), then randomGaussian(0.5, 0.1) per pixel mapped to a grayscale color channel. Mean of 0.5 + small sd keeps ~99.7% of samples in [0.2, 0.8] (3σ), so out-of-range tails are rare enough not to dominate the snapshot — no clamping needed.

2. randomGaussian() in a fragment loop averages to the mean — analogue of the existing random() in a fragment loop averages to gray test (webgpu L346). randomSeed(7), sum 20 samples of randomGaussian(0.5, 0.2) per pixel, divide by 20. Averaging shrinks the spread by a factor of √20, so the canvas should appear nearly-uniform gray near 0.5. A single-sample test can't catch a wrong distribution mean; this one can.

WebGPU versions will be async with await createCanvas / await screenshot(); WebGL versions sync — per existing convention.

Reference screenshots will be generated on first run, sanity-checked (test 1: Gaussian noise around mid-gray; test 2: near-uniform gray), then committed alongside the test code.

Does this look reasonable? Happy to adjust means/sd/sample counts, or add a third test for a different property.

[perminder-17]

• randomGaussian() colors a basic shader — direct analogue of the existing random() shader-coloring test. randomSeed(12), then randomGaussian(0.5, 0.1) per pixel mapped to a grayscale color channel. Mean of 0.5 + small sd keeps ~99.7% of samples in [0.2, 0.8] (3σ), so out-of-range tails are rare enough not to dominate the snapshot — no clamping needed.

• randomGaussian() in a fragment loop averages to the mean — analogue of the existing random() in a fragment loop averages to gray test (webgpu L346). randomSeed(7), sum 20 samples of randomGaussian(0.5, 0.2) per pixel, divide by 20. Averaging shrinks the spread by a factor of √20, so the canvas should appear nearly-uniform gray near 0.5. A single-sample test can't catch a wrong distribution mean; this one can.

Yeah, everything sounds good to me. You can go with adding that. Thanks

[harshiltewari2004]

Tests added per discussion — randomGaussian() colors a basic shader and randomGaussian() in a fragment loop averages to the mean, in both webgl and webgpu visual suites. Following the existing patterns from the random() tests in the same files.
One thing worth flagging: writing the averaging test surfaced a bug in the implementation. randomGaussian(0.5, 0.2) was producing samples from N(0.5, 1.0) — the stdDev argument wasn't being applied. Traced it to unnecessary p5.strandsNode() wrapping around the scalar in the final scale-and-shift line. Removed the wrapping (mirroring how -2 and 2*PI are passed raw to .mult() elsewhere in the same expression), and Test 2 now shows the expected variance-reduced output.
Small caveat on Test 2's snapshot: there are a few scattered outlier pixels that don't appear in the analogous random() in a fragment loop averages to gray reference. The math suggests they aren't simple Box-Muller tail behavior (a single extreme sample averaged with 19 normal ones can't push the result outside [0,1] at this stdDev). Could indicate non-independence in strands' random() at certain seeds, but I haven't traced it conclusively. The snapshot is deterministic and stable across runs, so the test catches regressions either way — flagging it here for visibility in case it points at something worth a follow-up.