chore: clean-up

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request propagates the operation-ordering fix from ef08b9f5 (align JS floating-point evaluation order with each package's C implementation) to two sibling distributions.

For @stdlib/stats/base/dists/hypergeometric/mean, n * ( K / N ) becomes ( n * K ) / N, matching src/main.c. n*K is exact below 2^53, so the C form is a single correctly-rounded division while the old form rounds twice; the two forms disagree by 1 ULP on 24% of the integer domain, and the package's own test files already asserted 1 ULP for JS versus 0 ULP for native — in-repo evidence the divergence was known. Post-fix, the implementation reproduces the package's Julia fixture bit-for-bit, versus 20/100 mismatched cases before.

For @stdlib/stats/base/dists/chi/skewness, sigma = sqrt( variance( k ) ); sigma2 = sigma * sigma; becomes sigma2 = variance( k ); sigma = sqrt( sigma2 );, matching src/main.c. The old form round-tripped variance through sqrt and a squaring to recover a value already held exactly, and since chi variance tends to 0.5 as k grows, the 1.0 - ( 2.0*sigma2 ) cancellation amplifies that perturbation: max error over 100k samples of k drops from 838 ULP to 3 ULP with the corrected ordering.

Documented example values are unchanged in both packages.

A follow-up commit tightens the JS ULP bound in hypergeometric/mean from 1 to 0, matching the bound test/test.native.js already asserts. The 1 ULP slack existed only to accommodate the old operation order; with the implementations aligned the JS build reproduces the fixture exactly. Verified as a real guard rather than a cosmetic change: at 0 ULP the previous arrangement fails 20 of 100 fixture cases and the current one passes all 100. The bound is deterministic across platforms, since the computation is an integer product and a single IEEE-754 division with no transcendental functions involved.

The chi/skewness tolerance is deliberately left alone. Its fixture margin is unchanged by this PR (21.0% → 21.1% of a 1e-11 relative budget) because the residual error there is dominated by the gamma ratio in chi/mean, not by the arrangement corrected here; tightening it would clamp down on an error source this PR does not touch.

Source commit: ef08b9f5a6f457b574aa57b11b52d07bb70f0d79

Target packages:

• @stdlib/stats/base/dists/hypergeometric/mean
• @stdlib/stats/base/dists/chi/skewness

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

Three sibling packages matched the same search signature and were deliberately excluded; flagging them in case you want them handled separately:

• lognormal/pdf and triangular/logpdf — lib/main.js and lib/factory.js are currently bit-identical in both packages, and factory.js structurally cannot adopt the C arrangement, since A/denom are hoisted precisely because sigma/the range are fixed while x is not. Aligning main.js alone would trade a holding invariant for a sub-ULP gain, and on triangular/logpdf it burns the medium_range fixture margin from 61% to 89% of a 60-EPS budget.
• truncated-normal/pdf — the C is the side that is wrong here. Its s2x2 = 2.0*abs2(sigma) formulation underflows below sigma ≈ 1.5e-154 and abs2(x-mu) overflows above |x-mu| ≈ 1.3e154, so mirroring it into JS returns NaN where the current code returns correct finite values. Worth a separate issue against src/main.c.

Other

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

Also noted while searching, not addressed here: lib/factory.js in lognormal/pdf, triangular/logpdf and truncated-normal/pdf each use a hoisted arrangement that matches neither lib/main.js nor src/main.c. Separately, the lognormal/pdf fixture tolerances (800/1489/305 ULP) are far looser than the measured maximum error of 4 ULP.

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 as part of an automated routine that reviews fixes merged to develop and propagates them to sibling packages with the same defect. Candidate sites were found by comparing each package's lib/main.js against its own src/main.c across all 474 stats/base/dists packages that ship both, then validated by independent agents that measured the divergence empirically and compared both arrangements against exact-rational and arbitrary-precision references. Three of the five candidate sites were rejected on those measurements and are described above. The numbers quoted in this description were reproduced against the packages' own fixtures before committing.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01YRk2WJxnRNdX8txWkmyLtb

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
stats/base/dists/chi/skewness	$\\color{green}172/172$ $\\color{green}+0.00\\%$	$\\color{green}8/8$ $\\color{green}+0.00\\%$	$\\color{green}2/2$ $\\color{green}+0.00\\%$	$\\color{green}172/172$ $\\color{green}+0.00\\%$
stats/base/dists/hypergeometric/mean	$\\color{green}194/194$ $\\color{green}+0.00\\%$	$\\color{green}13/13$ $\\color{green}+0.00\\%$	$\\color{green}2/2$ $\\color{green}+0.00\\%$	$\\color{green}194/194$ $\\color{green}+0.00\\%$

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

[kgryte]

In principle, this computation has a greater risk of overflow, including just to the realm beyond safe integers. However, practically speaking, that is not a common use case, so I am fine having this match the C implementation.

[Planeshifter]

Confirmed, and worth pinning down the boundary: the product overflows once n*K exceeds sqrt(MAX_VALUE) ≈ 1.34e154, so mean( 1e160, 1e160, 1e160 ) now returns Infinity where the previous arrangement returned 1e160.

The asymmetry is JS-only. src/main.c takes int32_t, so the C cannot reach that regime at all, whereas the JS guard is isNonNegativeInteger, which accepts 1e300. So this is a case where matching the C narrows the JS domain rather than just reordering within it.

Leaving as-is per your call. Noting the threshold here so it's on the record if anyone later hits it.

---

Generated by Claude Code

[kgryte]

@anandkaranubc Would you be interested in following up on the truncated-normal question discussed in the OP above?