test: migrate stats/base/snanstdev to ULP-based assertions

[Planeshifter]

Resolves a part of #11352.

Description

What is the purpose of this pull request?

This pull request:

• migrates the tests for stats/base/snanstdev from a computed relative-tolerance comparison (delta = abs( v - expected ) / tol = 1.0 * EPS * abs( expected ), asserted via t.strictEqual( delta <= tol, ... )) to a ULP-difference assertion using @stdlib/number/float32/base/assert/is-almost-same-value.
• applies the migration to the two tolerance-based assertion sites (population standard deviation, float32 precision) present identically across all four test files: test/test.snanstdev.js, test/test.snanstdev.native.js, test/test.ndarray.js, and test/test.ndarray.native.js.
• removes the now-unused @stdlib/math/base/special/abs and @stdlib/constants/float32/eps requires from each file, along with the delta and tol variable declarations, replacing them with a single named ULP constant declared at the top of the affected test body.
• the sibling "sample standard deviation" test block in each file already used exact t.strictEqual comparisons against bit-identical float64ToFloat32( sqrt( ... ) ) results and was left unchanged.

Only test files are changed; no implementation, fixture, or documentation changes are included.

ULP bounds

Assertion	Previous tolerance	ULP bound
population standard deviation of a strided array, ignoring NaN (2 fixtures, all 4 test files)	1.0 * EPS * abs( expected ) (float32 EPS)	1

This is the minimum integer bound N such that isAlmostSameValue( v, expected, N ) holds at both fixture values in every one of the four test files. At N = 1 each file's full suite passes (36/36 for the non-native variants; the native variants skip, as no native addon is built in this environment). At N = 0, 2 of the 36 assertions fail in both the non-native test.snanstdev.js and test.ndarray.js files, so no tighter bound exists.

Each non-native test file (test.snanstdev.js, test.ndarray.js) was run twice at the final bound via npx tape with identical results (36/36 passing, no failures), ruling out FMA/architecture-dependent flakiness on this platform. npx eslint on all four changed files is clean.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: Migrate math/base/special packages from relative tolerance testing to ULP difference testing (tracking issue) #11352

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

The migration mirrors the idiom used in already-merged conversions for other float32 strided packages, notably blas/base/srotm and blas/base/drotm, which use @stdlib/number/float32/base/assert/is-almost-same-value (aliased isAlmostSameValuef) rather than the float64 @stdlib/assert/is-almost-same-value, since the compared values (v and expected) are float32-precision quantities produced via float64ToFloat32.

Two environment notes, neither of which affected verification:

• make install-node-modules initially failed with ETARGET for es-object-atoms@^1.1.2: that version was published to the npm registry and then unpublished, but several transitive dependents (array-includes, string.prototype.trim, string.prototype.trimend, etc.) still declare it as their required range. Installed with a temporary root-level overrides pin to es-object-atoms@1.1.1 for this one-time setup; the overrides field itself was never part of, and is not included in, this PR's diff.
• The pre-commit hook's lint-editorconfig-files step could not run, because it downloads the editorconfig-checker binary from a GitHub release that this environment cannot reach (network access is scoped to the stdlib-js/stdlib repository only). The changed files were instead checked manually against .editorconfig: LF line endings, tab indentation, no trailing whitespace, and a final newline in all four files.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

This PR was written primarily by Claude Code, running as an unattended scheduled task. It selected the package by searching the repository for the old tolerance idiom and cross-checking against open/merged ULP-migration PRs to avoid collisions, studied previously migrated float32 packages to match the established idiom, performed the migration across all four test files, and determined the minimum passing ULP bound empirically at the assertion site.

---

@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01NK6DcZzirTjPVrQb1Rh72c

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
stats/base/snanstdev	$\\color{green}361/361$ $\\color{green}+0.00\\%$	$\\color{green}14/14$ $\\color{green}+0.00\\%$	$\\color{green}4/4$ $\\color{green}+0.00\\%$	$\\color{green}361/361$ $\\color{green}+0.00\\%$

The above coverage report was generated for the changes in this PR.

[Planeshifter]

⚠️ Issue Reference Review

An automated check found potentially unrelated issue/PR references in this PR:

Reference	Assessment	Reasoning
#11352	suspicious	Issue #11352 is an RFC explicitly scoped to migrating math/base/special packages from relative-tolerance to ULP-based testing ("Migrate math/base/special packages..."; its own steps say to search for a package "in math/base/special"). This PR migrates tests for stats/base/snanstdev, which is outside the issue's stated scope.

Why this matters: GitHub automatically closes issues referenced with
closing keywords (Resolves, Closes, Fixes) when the PR is merged. Incorrect
references can accidentally close unrelated issues.

What to do:

• If the reference is correct, no action needed. This check may produce
  false positives.
• If the reference is incorrect, please update your PR description.

This assessment was generated by an AI model and is informational only.

---

Generated by Claude Code