[p5.js 2.0 Bug Report]: noise(null) is treated as noise(0) while noise(undefined) errors, and this behaviour is undocumented and inconsistent.

[shuklaaryan367-byte]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.1.2

Web browser and version

Google Chrome Version 143.0.7499.170

Operating system

Windows 11

Steps to reproduce this

Steps:

1. Run the sketch below
2. Compare the outputs of noise(null) and noise(0)
3. Observe that they are identical, while noise(undefined) throws an FES warning

Snippet:

function setup() {
  noCanvas();

  console.log("null:", noise(null));
  console.log("0:", noise(0));
  console.log("undefined:", noise(undefined));
}

Explanation:

noise(null) returns the same value as noise(0), while noise(undefined) produces a NaN and a Friendly Error message. Both null and undefined represent missing values in JavaScript, but they are handled differently here. This behaviour is not documented and can lead to silent bugs when null is passed unintentionally.

I'm happy to take on this task, if this is approved

[sidhansu10]

noise(null) gets coerced to noise(0), while noise(undefined) becomes NaN and triggers FES. This inconsistency isn’t documented and can cause silent bugs. It would be helpful to align these behaviors or document them clearly. I’m happy to contribute a fix once the expected behavior is confirmed.

[davepagurek]

Hi @shuklaaryan367-byte, it sounds like this is probably not unique to noise and would need an update to the zod type checking in FES for numeric parameters. Thanks for volunteering, I'll assign this to you since you expressed interest first.

[shuklaaryan367-byte]

Hi @davepagurek I did a bit more digging around this and wanted to share some observations before moving forward with a PR.

While the original issue was noticed with noise(null), this behaviour doesn’t seem to be unique to noise() itself and appears to be more generally related to how numeric parameters are validated by FES / Zod.

I tested a few other numeric functions with null and found inconsistent behaviour:

function setup() {
  noCanvas();

  console.log('sin(null):', sin(null));           // 0 (no FES warning)
  console.log('noise(null):', noise(null));       // same as noise(0), no warning

  console.log('lerp(0, 10, null):', lerp(0, 10, null));
  // 🌸 Expected number at the third parameter in lerp()

  console.log('dist(null, 0, 0, 0):', dist(null, 0, 0, 0));
  // 🌸 Expected number at the first parameter in dist()
}

So it looks like:

• sin(null) and noise(null) silently coerce null to 0 with no FES message
• lerp() and dist() do trigger FES warnings for null

This made me think the root cause is likely in the parameter validation layer rather than any individual function. In param_validator.js, Number parameters currently map to z.number(), which doesn’t explicitly guard against null before JS coercion happens.

Before making changes, I wanted to check:

• Should null be consistently treated as an invalid numeric argument across the API (i.e. always produce a friendly warning)?
• Or is the current behaviour intentional for lower-level math functions like sin()?

Once I understand the intended policy here, I’m happy to either:

• make a focused fix for noise() only, or
• work on a more general FES/Zod-level solution if that’s preferred.