docs: fix headings

[Planeshifter]

Follow-up fixes for commits merged to develop between 2026-09-22 12:31:02 -0700 and 2026-09-23 04:54:18 -0700.

No related issue.

Description

What is the purpose of this pull request?

This pull request:

• fc9905c8: fix doubled Equal suffix in lib/node_modules/@stdlib/blas/ext/base/ndarray/gfill-greater-than-equal/README.md — H1 (L21) and usage signature (L39) read gfillGreaterThanEqualEqual; corrected to gfillGreaterThanEqual to match lib/main.js and the rest of the docs.
• ec5d60d6, cf2b5045, and f158b2ff each added new members to blas/ext/base/ndarray's runtime namespace via setReadOnly in lib/index.js without updating lib/node_modules/@stdlib/blas/ext/base/ndarray/docs/types/index.d.ts; runtime had 231 members, declarations only 223, so dvander, gfillGreaterThanEqual, gleftPadCircular, gleftPadEdge, grightPadCircular, grightPadEdge, gvander, and gwhere all fail TS2339 for TS consumers despite existing at runtime. Added the missing imports and <name>: typeof <name>; interface members (with JSDoc/@example adapted from each package's own .d.ts) at their alphabetical positions; counts now match at 231/231.

Commits are grouped one per package directory: blas/ext/base/ndarray/gfill-greater-than-equal (docs:) and blas/ext/base/ndarray (fix:).

Related Issues

Does this pull request have any related issues?

None.

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.

Review scope. 37 first-parent commits, 196 files, 4e396e96^..f158b2ff. Themes: eight new blas/ext/base/ndarray packages (gvander, dvander, gwhere, gfill-greater-than-equal, g{left,right}-pad-{edge,circular}) plus their namespace registrations; a float16 dtype rollout across array/base/assert/* and ndarray/base/{full,full-by,nans,nans-like}; nine ULP-assertion test migrations; a new C backend for stats/base/ndarray/dnanmeanpw; and lint/tooling work (ESLint flat-config for Markdown code blocks, new _tools/repl-txt/rules/no-redeclare).

Validation. Checked for stdlib style-guide compliance (each new package diffed structurally against an established sibling — blas/ext/base/ndarray/gfill-equal for the ndarray wrappers, stats/base/ndarray/{dmeanpw,dnanmeanors} for the C addon) and scanned for bugs across the full window diff. Verified independently before committing: the namespace member counts (223 declared vs. 231 registered, the eight missing being exactly those added in this window), and the modified declaration file parsing clean under tsc --noEmit with no new error classes relative to its develop baseline.

Deliberately excluded. Anything requiring interpretation: subjective suggestions, style preferences not mandated by docs/style-guides, and issues whose fix would reach outside the window's diff. Three candidates were dropped on that basis — 8a518c59 migrated only ellipj/test/test.main.js to ULP assertions, leaving test.sncndn.js, test.assign.js, and test.native.js on the old abs/EPS pattern; none of those three files is in the window's diff, and completing the migration would require deriving new ULP bounds, so it belongs in its own PR. Also dropped: gfill( len, 1.0, xbuf, 3 ) in gfill-greater-than-equal/benchmark/benchmark.js, which indexes past the len-element xbuf and grows the generic array to 3*len-2. The measured work is still len elements because end = len clips the range, so results are unaffected, and the pre-existing non-ndarray blas/ext/base/gfill-greater-than-equal benchmark uses the same pattern — changing only the new package would split the family. Flagging it here rather than fixing it unilaterally.

The deliberate numeric reorderings in fed47c5a (stats/base/dists/hypergeometric/mean, stats/base/dists/chi/skewness), the recalibrated ULP bounds, and the new Array(W) → zeros(W) change in stats/incr/mvmr were all reviewed and left alone.

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 written primarily by Claude Code, as part of an automated review of the last 24 hours of commits to develop. Reviewer agents surfaced the candidate issues; each finding was then re-verified against the tree before any edit, and the two findings that survived filtering are the ones applied here. Opened as a draft for maintainer audit.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01F5HbkjKMwKyrN7mThirjgQ

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/ext/base/ndarray/gfill-greater-than-equal	$\\color{green}167/167$ $\\color{green}+0.00\\%$	$\\color{green}5/5$ $\\color{green}+0.00\\%$	$\\color{green}1/1$ $\\color{green}+0.00\\%$	$\\color{green}167/167$ $\\color{green}+0.00\\%$

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

[Planeshifter]

Run affected benchmarks is red on 383b9917 (job). Not this PR's failure, and not fixable from here.

It is a job timeout, not a benchmark failure:

##[error]The action 'Run affected benchmarks' has timed out after 60 minutes.

Every benchmark that reported before the cap passed. The ones executing when it died are blas/ext/base/gsort2ins, which this PR does not touch — the diff here is two lines in one README.

Same check, same timeout, on develop itself: run 35145 on 66f69b6a (#15512). That commit corrects i % M to j % M in the data generation of 110 blas/ext/base sort benchmarks. The correction is right, and the consequence is that *_rev_sorted_few_uniques now produces actual reverse-sorted, few-uniques input — worst case for insertion sort — so gsort2ins/gsortins/ssortins and friends got dramatically slower and the suite no longer fits in the 60-minute job cap. This branch inherited 66f69b6a through the Merge branch 'develop' commit, which is also what widened the affected-directory set far beyond the changed README.

No fix exists on develop to port: 66f69b6a is the most recent commit touching those benchmark files, with no revert or follow-up.

Not re-running the job. The failure is a deterministic wall-clock cap, not flake, and it has already reproduced on the base branch — a second hour of runner time would tell us nothing.

The real fix belongs in its own PR against develop: cap len/iterations for the worst-case sort benchmarks, or split run_affected_benchmarks so a large affected set fans out instead of running serially under one 60-minute budget. Happy to open that if you want it.

---

Generated by Claude Code

[kgryte]

Not clear why so many benchmarks ran for this PR. But, as the CI failure is not due to changes in this PR, I'll go ahead and merge.

[Planeshifter]

Not clear why so many benchmarks ran for this PR.

The run was triggered by push, not pull_request, so the affected-directory step took its else branch:

if [ -n "${{ github.event.pull_request.number }}" ]; then
  ancestor_commit=$(git merge-base base.sha head.sha)
  files=$(git diff --diff-filter=AM --name-only $ancestor_commit head.sha)
else
  files=$(git diff --diff-filter=AM --name-only ${{ github.event.before }} ${{ github.event.after }})
fi

On a push there is no pull_request.number, so it diffed before..after — 3cb9a2c3..383b9917, the range the merge commit pushed. That is every develop commit from the last two days:

$ git diff --diff-filter=AM --name-only 3cb9a2c3 383b9917 | wc -l
321          # 146 unique directories, 33 of them benchmark dirs, 19 blas/ext/base sort packages

Which is how 66f69b6a's 110 sort-benchmark files ended up in scope.

The pull_request path would have computed merge-base(develop, head)..head:

$ git diff --diff-filter=AM --name-only 63f3434d 383b9917
lib/node_modules/@stdlib/blas/ext/base/ndarray/gfill-greater-than-equal/README.md

Zero benchmark directories — the workflow's paths: lib/**/benchmark/** filter would have skipped it outright.

So this is general: any Merge branch 'develop' push into a topic branch makes the affected set the whole merged range rather than the PR's own diff. Worth fixing independently of the 60-minute cap — the push branch could use merge-base(origin/develop, HEAD)..HEAD instead of before..after.

---

Generated by Claude Code