chore: clean-up

[Planeshifter]

Follow-up fixes for commits merged to develop between af036154 (2026-09-23 22:53 PDT) and ca4d8510 (2026-09-24 02:26 PDT).

Description

What is the purpose of this pull request?

This pull request:

• In 68b4b33, test.native.js swapped the native tolerance for isAlmostSameValue( y, expected[ i ], 0 ) and dropped the FMA comment; the kernel's variance computation contracts to FMA by default, so 0 ULP fails on any native build. Restored 64000 ULPs (tight bound over the actual fixtures, which range 32001.2–63932.7 ULPs under the old formula) and restored the FMA note, matching the still-unmigrated skewness sibling.
• In number/int64/ctor/README.md, the static-method-of anchor landed after the Int64.of() heading rather than before it (ed84323), so the Notes section link resolves past the target; moved the anchor above the heading, matching static-method-from and the parallel number/uint64/ctor/README.md fix (93dfa49).
• number/uint64/ctor/README.md: lines 196/198 still use escaped bracket notation (\[0, 2^64-1]) for the interval, inconsistent with the code-span form (`[0, 2^64-1]`) used one line above in the same hunk added in 93dfa49, and with the rest of the namespace after ed84323/e131d88e normalized int64/ctor and uint64/base/*; converted both to code spans.

Grouped by package, one commit each:

Package	Commit	Origin
stats/base/dists/triangular/stdev	fix: restore FMA tolerance ...	68b4b33
number/int64/ctor	docs: fix anchor placement ...	ed84323
number/uint64/ctor	docs: update markup ...	93dfa49

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

The triangular/stdev native tolerance is the one judgment call. 64000 is the tight upper bound of the previous 32000.0 * EPS * abs( expected ) formula measured over the package's own Julia fixtures (range 32001.2–63932.7 ULPs), chosen so no case that passed before can now fail. Happy to substitute an empirically measured value if someone can run the native build.

Other

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

Validation. Reviewed all 22 commits merged to develop in the window (59 files, +1623/−523) along two axes: stdlib style-guide compliance (docs/style-guides, each changed package compared against an established reference package of similar complexity) and a bug/logic scan. Four independent reviews were run and their findings cross-checked; only findings that survived re-verification against the diff are included here.

Checked and found clean: the ULP-assertion migration across all 14 stats/* test files (assertion counts identical old-vs-new in every file; no isnan check weakened, no loop bound changed, no unused abs/EPS requires left behind); the int64/uint64 ctor range widening (isBetween( value, -TWO_63, TWO_63, 'closed', 'open' ) admits exactly the documented range, and the new number2words delegation was differentially tested against the old inline word-splitting and against BigInt.asUintN ground truth over boundary cases and randomized inputs with zero mismatches); the new number/int64/base/number2words package against its uint64 sibling; and the blas/ext/base/ndarray namespace declarations against the actual exports.

Deliberately excluded: anything requiring interpretation, subjective style preferences not codified in the style guide, and anything that could not be validated without changes outside the window's diff. Two candidate findings were dropped as false positives after verification — a suspected mishandling of negative bigint values passed to uint64/base/bigint2words, and suspected dead TWO_32/UINT32_MAX requires in int64/ctor/lib/main.js; both are correct as written.

Not run: this environment has no installed dependencies, so the test suite and linters could not be executed. Changes were verified by re-reading each modified file against the proposed fix, by node --check, and by computing the tolerance bounds directly against the committed fixtures. CI is the authority here.

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 PR was authored by Claude Code running as an automated daily review of commits merged to develop. It enumerated the commit window, ran the review passes, applied the fixes, and wrote this description. The findings were cross-checked across independent review passes and re-verified against the diff before inclusion, but the changes have not been reviewed by a human yet — hence draft. Please audit before promoting.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01EoFMqk2435zfsa2ngHZa5a

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
number/int64/ctor	$\\color{red}594/676$ $\\color{green}+0.00\\%$	$\\color{red}48/52$ $\\color{green}+0.00\\%$	$\\color{red}9/11$ $\\color{green}+0.00\\%$	$\\color{red}594/676$ $\\color{green}+0.00\\%$
number/uint64/ctor	$\\color{red}581/641$ $\\color{green}+0.00\\%$	$\\color{red}48/51$ $\\color{green}+0.00\\%$	$\\color{red}9/11$ $\\color{green}+0.00\\%$	$\\color{red}581/641$ $\\color{green}+0.00\\%$
stats/base/dists/triangular/stdev	$\\color{green}198/198$ $\\color{green}+0.00\\%$	$\\color{green}5/5$ $\\color{green}+0.00\\%$	$\\color{green}2/2$ $\\color{green}+0.00\\%$	$\\color{green}198/198$ $\\color{green}+0.00\\%$

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

[kgryte]

@Planeshifter Left an initial comment. I am a bit confused as to why CI passes but yet the native add-on was flagged.

[Planeshifter]

Our messages crossed — I answered on the inline thread a few minutes before your review landed: #15498 (comment)

Short version: CI passes because run_affected_tests runs on ubuntu-latest, and FMA is not in the baseline x86-64 ISA, so GCC emits no FMA instruction no matter what -ffp-contract says. The add-on is built and the test body does execute — I was wrong to assume it was being skipped — it just computes the fixtures bit-exactly there. Measured on this package's own fixtures: 0 ULP error at -O3, 32692 ULP with -mfma or -march=native, back to 0 with -ffp-contract=off.

So "CI green" and "the assertion is wrong" aren't in conflict: the tolerance is inert on x86-64 and only bites where FMADD is baseline, i.e. aarch64 — make test on Apple Silicon. That's also why the original 32000.0 * EPS looks arbitrary from an x86 vantage point; at the worst fixture it worked out to 33715 ULP against a measured 32692, so whoever wrote it measured it on an FMA target.

No strong opinion on the constant. Options as I see them, in order of my preference:

1. Keep 64000 — faithful upper bound of the old formula, protects arm64, costs nothing on CI.
2. Tighten to ~33000 — matches measured x86+FMA error, thinner margin for other toolchains.
3. Drop the commit — tests stay bit-exact everywhere CI can see, arm64 handled separately.

Your call; happy to push whichever. And since it's adjacent: #15505 did the same thing to triangular/skewness last night, same comment deleted, so whatever we decide here probably wants applying there too.

---

Generated by Claude Code