test: migrate stats/base/dists/lognormal/mode 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/dists/lognormal/mode from computed relative-tolerance comparisons (delta = abs( y - expected[ i ] ) / tol = N * EPS * abs( expected[ i ] ), asserted via t.ok( delta <= tol, ... )) to ULP-difference assertions using @stdlib/assert/is-almost-same-value.
• applies the migration to the two tolerance-based assertion sites in the package: one each in test/test.js and test/test.native.js. Both iterate over the same test/fixtures/julia/data.json fixture (110 points, some null/skipped).
• collapses the if ( y === expected[i] ) { ... } else { ... } branch at each site into a single ULP assertion via a named ULP constant, and standardizes the assertion message to 'returns expected value'.
• removes the now-unused @stdlib/math/base/special/abs and @stdlib/constants/float64/eps requires and the delta and tol variable declarations.

The remaining assertions in these files are exact comparisons (NaN propagation for NaN and non-positive sigma, and function type), which are correct as-is and are left unchanged.

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

ULP bounds

File	Implementation	Previous tolerance	ULP bound
test/test.js	JavaScript, main export	1.0 * EPS * abs( expected )	0
test/test.native.js	C	18.0 * EPS * abs( expected )	0

0 is the minimum integer bound N such that isAlmostSameValue( y, expected[ i ], N ) holds at every non-null element of the fixture. It was determined by computing mode( mu[i], sigma[i] ) for all fixture points outside the test harness (via both lib/main.js and, after building the native add-on with node-gyp rebuild, lib/native.js) and comparing directly against expected[i] using @stdlib/number/float64/base/ulp-difference: the maximum observed ULP difference across the full fixture set was 0 for both implementations, so a 0-ULP (exact) bound is both sufficient and necessary — no looser bound would be tighter.

node test/test.js and node test/test.native.js were each run twice at the final bound with identical results on both runs (110/110 and 111/111 assertions passing, respectively), ruling out flakiness on this platform. npx eslint is clean for both changed files.

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 resulting diff mirrors the already-merged migrations for sibling distribution "mean"/"mode" packages with the same test structure, e.g. stats/base/dists/f/mean (#15233) and stats/base/dists/hypergeometric/mean (#15235).

Two environment notes, neither of which affected verification:

• make install-node-modules initially failed with ETARGET for es-object-atoms@^1.1.2. The local npm packument cache was stale and served a filtered view of the registry; after npm cache clean --force, the install and make init completed and the full toolchain was available for this PR.
• 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. The commit was made with SKIP_LINT_EDITORCONFIG=1 (a flag the hook itself exposes for this purpose), and the changed files were instead checked manually against .editorconfig: tabs for indentation, no trailing whitespace, and a final newline.

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, studied previously migrated packages in the same family to match the established idiom, performed the migration, built the native add-on to verify both implementations empirically, and determined the minimum passing ULP bound over the full fixture set.

---

@stdlib-js/reviewers

🤖 Generated with Claude Code

https://claude.ai/code/session_01KaEmx8PGodkbJvH7CcTJpR

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
stats/base/dists/lognormal/mode	$\\color{green}176/176$ $\\color{green}+0.00\\%$	$\\color{green}9/9$ $\\color{green}+0.00\\%$	$\\color{green}2/2$ $\\color{green}+0.00\\%$	$\\color{green}176/176$ $\\color{green}+0.00\\%$

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