test: migrate stats/base/dists/bradford/mean to ULP-based assertions

[kgryte]

Resolves a part of #11352.

Description

What is the purpose of this pull request?

This pull request:

• migrates the tests for stats/base/dists/bradford/mean from relative tolerance testing to ULP difference testing, per [RFC]: Migrate math/base/special packages from relative tolerance testing to ULP difference testing (tracking issue) #11352.
• replaces the delta/tol comparisons in test/test.js and test/test.native.js with t.strictEqual( isAlmostSameValue( y, expected[ i ], 9 ), true, 'returns expected value' ), adding the @stdlib/assert/is-almost-same-value require and removing the now unused @stdlib/math/base/special/abs and @stdlib/constants/float64/eps requires.

Final ULP constant: 9, for both fixture loops (test.js and test.native.js).

The bound was tightened by starting high (64) and lowering it to the minimum integer which still passes over the full fixture set. The Python fixture set contains 1000 cases, and the measured maximum ULP difference against the reference values was 9 for both the JavaScript and the C implementation:

implementation	cases	measured max ULP diff	ULP bound used
test.js (JS)	1000	9	9
test.native.js (C)	1000	9	9

The two implementations agree exactly: the per-case ULP distribution is identical for both, namely

ULP diff	0	1	2	3	4	5	6	7	8	9
cases	938	17	22	12	5	1	2	1	1	1

9 is the tightest passing bound: a bound of 8 fails one assertion in each file, and 7 fails two. The worst case is c = 0.2585585585585586, where the returned value is 0.4808529480326162 against a reference value of 0.4808529480326157.

The previous relative tolerance was 4.7 * EPS * abs( expected[ i ] ), which is a comparable accuracy budget (4.7 * EPS relative error corresponds to roughly 9 ULP near the lower end of a binade).

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.

• Only the two test files are changed; no source, fixture, or documentation changes.
• The idiom mirrors the already-migrated sibling package stats/base/dists/bradford/median, including the placement of the @stdlib/assert/is-almost-same-value require.
• test/test.js and test/test.native.js each pass 1006/1006 assertions at the final ULP bound. The suite was run twice at that bound with identical results, to rule out arch/FMA nondeterminism.
• The native add-on was built locally (node-gyp rebuild) so that test/test.native.js actually executed rather than being skipped, which is what confirms the 9 bound for the C implementation.
• make install-node-modules could not complete in the development environment used here: the registry mirror reachable from this environment serves es-object-atoms only up to 1.1.1, while a transitive dependency requires ^1.1.2, so npm reports ETARGET. tape and the lint tooling were therefore provided out of tree, and the tests were run directly against the package. This is an environment limitation only; no dependency or lockfile in the repository was modified.
• Linting: the changed files were checked with ESLint 8.57 using the repository's own etc/eslint/.eslintrc.tests.js rule set (282 rules), with the in-repo stdlib plugin's rules omitted because that plugin's remark-lint-* dependency chain could not be installed in this environment. The result is 0 errors and 0 warnings. The rule set used was verified to be live by a negative control (an injected unused variable was correctly reported). Reviewers may wish to confirm the full make lint and the native tests on CI.

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

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

This PR was authored by Claude Code, which selected the package, mirrored the idiom used by the already-migrated sibling package stats/base/dists/bradford/median, measured the minimum passing ULP bound over the full fixture set for both the JavaScript and the C implementation, and verified the tests and linting locally.

---

@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_016N9p5gjiRoDs5L3nHixpuB

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
stats/base/dists/bradford/mean	$\\color{green}180/180$ $\\color{green}+100.00\\%$	$\\color{green}8/8$ $\\color{green}+100.00\\%$	$\\color{green}2/2$ $\\color{green}+100.00\\%$	$\\color{green}180/180$ $\\color{green}+100.00\\%$

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