test: migrate math/base/special/bessely0 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 math/base/special/bessely0 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 computation and the y === expected special case in test/test.js and test/test.native.js with a single t.strictEqual( isAlmostSameValue( y, expected[ i ], N ), true, 'returns expected value' ); assertion.
• removes the now-unused @stdlib/math/base/special/abs require and adds @stdlib/assert/is-almost-same-value. The @stdlib/constants/float64/eps require is retained, as EPS is still used when generating negative inputs.

ULP bounds (test/test.js):

Fixture set	Previous tolerance	ULP bound	Next largest ULP difference in set
very_large_positive	680.0 * EPS * abs( expected )	1127	445
large_positive	2400.0 * EPS * abs( expected )	3716	232
medium_positive	850.0 * EPS * abs( expected )	1626	217
small_positive	1000.0 * EPS * abs( expected )	1510	532
smaller	4.5 * EPS * abs( expected )	7	6
tiny_positive	10.0 * EPS * abs( expected )	2	2
subnormal	5000.0 * EPS * abs( expected )	8678	73
huge_positive	4500.0 * EPS * abs( expected )	4053	945
positive_gamut	16.0 * EPS * abs( expected )	25	18

These are the measured minima. Starting from a high bound and tightening, each value above is the smallest integer for which the corresponding fixture set passes in full: decrementing every bound by one fails 2448 of 41653 assertions (exactly one point per set, except tiny_positive, where a bound of 1 fails 2440 points).

test/test.native.js uses the same bounds, with two exceptions. The two loops which previously carried a larger tolerance than their JavaScript counterparts (medium_positive: 885.0 * EPS vs. 850.0 * EPS; positive_gamut: 130.0 * EPS vs. 16.0 * EPS) retain their existing NOTE and keep the same proportional headroom over the measured minimum (1626 → 1693 and 25 → 203), since that headroom exists to absorb platform-dependent divergence between the JavaScript and C results (see the discussion referenced in the note). This mirrors the already-migrated math/base/special/besselj0, whose native tests likewise keep a slightly larger bound for the loops carrying that note.

Only the two test files are changed; no source, documentation, or package.json changes are included.

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?

The subnormal (8678), huge_positive (4053), and large_positive (3716) bounds are large in absolute terms, but each is strictly tighter than the relative tolerance it replaces, and in each of those sets a single fixture point dominates (the next largest difference is 73, 945, and 232 ULP, respectively). Happy to round these to more convenient values if reviewers prefer some headroom over the measured minimum.

Other

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

Verification performed locally:

• test/test.js — 41653 passing, 0 failing. Run twice at the final bounds with identical results, so the bounds are not sensitive to FMA/arch variation on this machine.
• Tightness check — lowering every bound by one yields 2448 failing assertions, confirming the reported minima.
• Native — the addon was not built in this environment, so test/test.native.js reports its assertions as skipped. To validate the native bounds, src/main.c was compiled standalone (gcc, at both -O3 and -O0) together with its resolved C dependencies and evaluated over the same fixture sets: the C results were bit-identical to the JavaScript results for all 40647 fixture points at both optimization levels, so the bounds above hold for the native implementation on this platform as well.
• Linting — eslint --config etc/eslint/.eslintrc.tests.js over both files is clean.

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 running as an unattended scheduled task. The test migration and the ULP bound search (start high, tighten to the minimum that still passes, then re-run to confirm determinism) were performed by the agent, following the idiom established in already-migrated packages in math/base/special.

---

@stdlib-js/reviewers

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
math/base/special/bessely0	$\\color{red}596/609$ $\\color{green}+97.87\\%$	$\\color{red}45/54$ $\\color{green}+83.33\\%$	$\\color{green}7/7$ $\\color{green}+100.00\\%$	$\\color{red}596/609$ $\\color{green}+97.87\\%$

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

[stdlib-bot]

Thank you for working on this pull request. However, we cannot accept your contribution as the issue this pull request seeks to resolve has already been addressed in a different pull request or commit.

Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions.