Skip to content

bench: fix data generation - #15535

Merged
kgryte merged 1 commit into
developfrom
philipp/fix-propagation-2026-09-25
Sep 26, 2026
Merged

kgryte merged 1 commit into
developfrom
philipp/fix-propagation-2026-09-25

Conversation

@Planeshifter

Copy link
Copy Markdown
Member

Description

What is the purpose of this pull request?

Propagating fixes merged to develop between 2026-09-24 16:49 PDT and 2026-09-25 04:01 PDT to sibling packages.

This pull request:

  • Reverse-sorted benchmark data seeded from the iteration count instead of the array length. 66f69b6a corrected iter - j - randu() to len - j - randu(), but only where the expression is written in indexed form (tmp[ j ] = ...), the spelling used by the typed-array dsort*/ssort* packages. The generic-array packages build their input via tmp.push( ... ) and were left unchanged, even though that commit touched the same packages for the unrelated i % M correction in their few_uniques benchmarks. Source: 66f69b6a. Target packages:

    • blas/ext/base/gsort2hp
    • blas/ext/base/gsort2ins
    • blas/ext/base/gsort2sh
    • blas/ext/base/gsorthp
    • blas/ext/base/gsorthp-by
    • blas/ext/base/gsortins
    • blas/ext/base/gsortsh

    Two files per package (benchmark.rev_sorted_random.js and benchmark.rev_sorted_random.ndarray.js), 14 files, one line each.

    Because iter is derived from the array length per size tier (floor( pow( iter, 3/4 ) ) or floor( sqrt( iter ) )), the offset shrinks as len grows, so the larger tiers generated predominantly negative values over a range unrelated to len. The sequence remained strictly decreasing, so measured timings are unaffected; what changes is that the generated values now fall in the intended (0, len] range and match the already-corrected typed-array siblings, making cross-package comparisons meaningful.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

The source commit's exclusion of these files looks unintentional, but the gsort* packages were in its diff, so flagging in case the omission was deliberate.

Other

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

Validation. Pattern search covered all benchmark/**/*.js under lib/node_modules/@stdlib/; the 14 sites here are the only remaining occurrences of an iter-derived data-generation expression inside an element loop anywhere in the tree. Every site was reviewed by two independent validation agents that read each file in full, then by an adaptation pass confirming the change is confined to a single line per file, then by a style pass checking spacing, tab indentation, and that iter remains used in each file (it does — as the outer loop bound and in main() — so no unused-variable lint failure). node --check passes on all 14 files; eslint could not be run locally because package dependencies are not installed in this environment, so CI is the first lint signal.

Deliberately excluded. Six further fix patterns were extracted from the same commit window and searched, and all yielded zero live sites — the originating commits were already complete:

  • 8da0d154 — docs/types/test.ts importing its own package by @stdlib/... path rather than ./index: 0 remaining.
  • 8da0d154 — extensionless relative require: 22 textual matches, all false positives (every target resolves to a directory, where omitting the extension is correct).
  • e0453d77 — README heading not matching the exported name: 0 remaining.
  • e737e900 — anchor placed after its heading, and escaped-bracket interval notation: 0 remaining each.
  • 27b070dd — ## C APIs section missing its <section class="c"> wrapper: 0 remaining.

Also excluded: the test: ULP-assertion migrations merged in this window, since choosing a per-package tolerance requires judgment rather than a mechanical transformation; and several one-off cleanups with no generalizable search signature. Nothing here required cross-package changes, new tests, or adaptation beyond a single file.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

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 as part of an automated routine that reviews fixes merged to develop and propagates them to sibling packages carrying the same defect. The candidate sites were found by pattern search and each was independently reviewed before inclusion, as described under "Other" above.


@stdlib-js/reviewers


Generated by Claude Code

Propagates fix from 66f69b6 ("bench: fix data generation in
`blas/ext/base` sort benchmarks") to the generic-array sort packages,
whose reverse-sorted benchmark data was seeded from the iteration
count rather than the array length.

The source commit corrected `iter - j - randu()` to `len - j - randu()`
wherever the expression was written in indexed form
(`tmp[ j ] = ...`), which is the spelling used by the typed-array
`dsort*` and `ssort*` packages. The generic-array `gsort*` packages
build their input via `tmp.push( ... )` and were therefore left
unchanged, even though the source commit touched those same packages
for the unrelated `i % M` correction in their `few_uniques`
benchmarks.

Because `iter` is derived from the array length per size tier
(`floor( pow( iter, 3/4 ) )` or `floor( sqrt( iter ) )`), the offset
shrinks as `len` grows, so the larger tiers generated predominantly
negative values spanning a range unrelated to `len`. The sequence
remained strictly decreasing, so measured timings are unaffected;
what changes is that the generated values now match the intended
`(0, len]` range and the already-corrected typed-array siblings,
making cross-package comparisons meaningful.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0166DfWubFLrTN9qRtaKbATZ
@stdlib-bot stdlib-bot added the BLAS Issue or pull request related to Basic Linear Algebra Subprograms (BLAS). label Sep 25, 2026
@stdlib-bot

Copy link
Copy Markdown
Contributor

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/gsort2ins $\\color{green}527/527$
$\\color{green}+100.00\\%$
$\\color{green}62/62$
$\\color{green}+100.00\\%$
$\\color{green}3/3$
$\\color{green}+100.00\\%$
$\\color{green}527/527$
$\\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\\%$
blas/ext/base/gsorthp $\\color{green}430/430$
$\\color{green}+100.00\\%$
$\\color{green}51/51$
$\\color{green}+100.00\\%$
$\\color{green}3/3$
$\\color{green}+100.00\\%$
$\\color{green}430/430$
$\\color{green}+100.00\\%$
blas/ext/base/gsorthp-by $\\color{green}473/473$
$\\color{green}+100.00\\%$
$\\color{green}37/37$
$\\color{green}+100.00\\%$
$\\color{green}3/3$
$\\color{green}+100.00\\%$
$\\color{green}473/473$
$\\color{green}+100.00\\%$
blas/ext/base/gsortins $\\color{green}419/419$
$\\color{green}+100.00\\%$
$\\color{green}61/61$
$\\color{green}+100.00\\%$
$\\color{green}3/3$
$\\color{green}+100.00\\%$
$\\color{green}419/419$
$\\color{green}+100.00\\%$
blas/ext/base/gsortsh $\\color{green}348/348$
$\\color{green}+100.00\\%$
$\\color{green}36/36$
$\\color{green}+100.00\\%$
$\\color{green}3/3$
$\\color{green}+100.00\\%$
$\\color{green}348/348$
$\\color{green}+100.00\\%$

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

@kgryte kgryte added the Benchmarks Pull requests adding or improving benchmarks for measuring performance. label Sep 26, 2026
@kgryte
kgryte marked this pull request as ready for review September 26, 2026 02:07
@kgryte
kgryte requested a review from a team September 26, 2026 02:07
@stdlib-bot stdlib-bot added the Needs Review A pull request which needs code review. label Sep 26, 2026
@kgryte kgryte changed the title bench: fix data generation in blas/ext/base generic sort benchmarks bench: fix data generation Sep 26, 2026
@kgryte
kgryte merged commit 947861b into develop Sep 26, 2026
68 checks passed
@kgryte
kgryte deleted the philipp/fix-propagation-2026-09-25 branch September 26, 2026 02:09
@stdlib-bot stdlib-bot removed the Needs Review A pull request which needs code review. label Sep 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Benchmarks Pull requests adding or improving benchmarks for measuring performance. BLAS Issue or pull request related to Basic Linear Algebra Subprograms (BLAS).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants