docs: fix descriptions

[Planeshifter]

Description

What is the purpose of this pull request?

This pull request:

• Removes the phrase "double-precision floating-point " from the JSDoc first-line descriptions of blas/ext/base/gsort2hp and blas/ext/base/gsort2sh, which describe generic routines. The change is comment-only.

The two packages each carried the qualifier in all four of lib/index.js, lib/main.js, lib/ndarray.js, and lib/accessors.js, while their own package.json description, README.md, docs/repl.txt, and docs/types/index.d.ts already read "two strided arrays". The namespace-level docs/types/index.d.ts and README.md also already read "two strided arrays", so this change makes the namespace internally consistent rather than introducing a new wording.

Namespace summary

Derived from a structural and semantic scan of the whole namespace:

Members analyzed	417 (blas/ext/base direct children with a package.json, excluding the ndarray and wasm sub-namespace containers)
Features analyzed	19
Features with a clear majority (≥75%)	15
Features excluded for no clear majority	4

Features excluded for want of a clear majority: implementation-file test naming (test/test.<pkg>.js 52.5% vs test/test.main.js 30.5%), lib/index.js export shape (30.5% vs 69.5%), the package.json __stdlib__ value ({} 47.5% vs {"wasm": false} 41.0%), and the browser/gypfile keys together with the binding.gyp/manifest.json/src//lib/native.js/examples/c group (65.9–69.3%). The last of these tracks whether a package ships a C addon and is legitimately absent for pure-JS packages.

blas/ext/base/gsort2hp

In blas/ext/base/gsort2hp, the JSDoc first-line description in lib/index.js, lib/main.js, lib/ndarray.js, and lib/accessors.js called the routine's inputs "two double-precision floating-point strided arrays"; this is now "two strided arrays". gsort2hp is a generic routine that resolves inputs via arraylike2object and dispatches to an accessor-array code path, accepting NumericArray | Collection<number> | AccessorArrayLike<number> per its docs/types/index.d.ts declaration, not Float64Array as the removed phrase implied; the qualifier was copied from the double-precision sibling dsort2hp and predates this package's accessor-array refactor. package.json, README.md, and docs/repl.txt already read "two strided arrays", matching the terminology used by 415/417 (99.5%) of blas/ext/base members, and gsort2ins served as the conforming generic template for this fix.

blas/ext/base/gsort2sh

Removed the "double-precision floating-point" qualifier from the JSDoc first-line description in lib/index.js, lib/main.js, lib/ndarray.js, and lib/accessors.js for blas/ext/base/gsort2sh, leaving "two strided arrays". gsort2sh is a generic Shellsort routine that resolves inputs via arraylike2object and dispatches to an accessor-array code path, accepting any array-like per its NumericArray | Collection<number> | AccessorArrayLike<number> type declaration, not Float64Array; the qualifier was copied from dsort2sh and predates the accessor-array refactor, and the package's package.json, README.md, docs/repl.txt, and docs/types/index.d.ts already said "two strided arrays". The dsort2sh cross-reference in this package's README.md "See Also" section correctly retains the qualifier and was left unchanged. Terminology was already consistent in 415/417 (99.5%) of blas/ext/base members, with gsort2ins serving as the conforming generic template for this fix.

Related Issues

Does this pull request have any related issues?

No.

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.

Validation

Checked:

• Structural extraction over all 417 members: file tree, package.json key set, scripts/stdlib/manifest.json key sets, README ##/### heading set and order, and test/, benchmark/, examples/ file naming.
• Semantic extraction over all 417 members: public signature, error construction, validation prologue, JSDoc shape, and require()-derived dependency sets.
• Three-agent review of each candidate correction: semantic review of whether a deviation reflects a genuine difference in what the package does, cross-reference of whether tests, examples, or repo tooling depend on the deviating state, and structural review of whether the majority pattern is the pattern that should actually be applied.
• Completeness of this fix: of every g* package in the namespace, only gsort2hp and gsort2sh name a precision in their lib/*.js JSDoc, so the 8 corrected lines are the full set.
• All 8 modified files pass node --check, and both routines were exercised on plain JS arrays to confirm the documented generic contract.

Deliberately excluded:

• Intentional deviations. The 22 comparison-sort packages lack a generic benchmark/benchmark.js (present in 94.7% of members) because they benchmark per input distribution instead — ssorthp/benchmark/ holds 40 files across 10 distributions. That is broader coverage, not a gap, and the make benchmark glob already discovers those files.
• Outliers whose tests rely on the deviation. gdiff is the one pure-JS package using the native-addon lib layout (99.2% conform), but gdiff/test/test.gdiff.js and gdiff/benchmark/benchmark.js both require ./../lib/gdiff.js, so conforming would force test and benchmark edits.
• Features without a clear majority, listed under Namespace summary above.
• Corrections that are not mechanical. dsort2hp is the only package with src/addon.cpp rather than src/addon.c (99.65% conform), but it is the last hand-rolled C++ N-API addon in the namespace and conforming means porting it onto the STDLIB_NAPI_ARGV_* macro template, not renaming a file.
• Anything changing observable behavior. Eight legacy sorting packages export C symbols as c_<name> instead of API_SUFFIX(stdlib_strided_<name>) (97.2% conform); renaming them would change the published C API.

Noted for maintainers, not addressed here

• package.json __stdlib__ is absent in 48 members and present in 88.5%, but the value splits 198 {} / 171 {"wasm": false} with no majority, and the key is present in only 39.5% of @stdlib package.json files repo-wide. The existing values are also unreliable: of the 10 leaf packages with a sibling under blas/ext/base/wasm/, nine are marked {} and sapxsumkbn is marked {"wasm": false}, so wasm: false does not track whether a WASM build exists. Nothing reads the key for its own presence — every consumer tests a sub-key — so inserting it would be inert. What __stdlib__.wasm is meant to encode is a maintainer decision.
• README ## Examples blocks and examples/index.js are byte-identical in 375/417 (89.9%) after normalizing indentation and require paths; the 42 divergences are substantive content differences rather than mechanical ones.

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 pull request was authored by Claude Code. It is the output of an automated cross-package consistency audit of the blas/ext/base namespace: structural and semantic features were extracted from all 417 members, the majority pattern per feature was computed at a 75% threshold, and deviating packages were flagged. Each candidate correction was then reviewed by three independent agents, and the audit's other candidates were dropped as intentional deviations or as changes that were not mechanical. The surviving change here is comment-only and was verified by hand against the affected packages' package.json, README.md, docs/repl.txt, and TypeScript declarations before committing.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01PC6sSdkTMxrMmxPCHP2oZk

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/ext/base/gsort2hp	$\\color{green}498/498$ $\\color{green}+100.00\\%$	$\\color{green}52/52$ $\\color{green}+100.00\\%$	$\\color{green}3/3$ $\\color{green}+100.00\\%$	$\\color{green}498/498$ $\\color{green}+100.00\\%$
blas/ext/base/gsort2sh	$\\color{green}408/408$ $\\color{green}+100.00\\%$	$\\color{green}37/37$ $\\color{green}+100.00\\%$	$\\color{green}3/3$ $\\color{green}+100.00\\%$	$\\color{green}408/408$ $\\color{green}+100.00\\%$

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