Skip to content

test: migrate blas/base/scnrm2 to ULP-based assertions - #16261

Draft
kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-blas-base-scnrm2
Draft

kgryte wants to merge 1 commit into
developfrom
kgryte/ulp-blas-base-scnrm2

Conversation

@kgryte

@kgryte kgryte commented Oct 20, 2026

Copy link
Copy Markdown
Member

Resolves a part of #11352.

Description

What is the purpose of this pull request?

This pull request:

  • migrates the tests for blas/base/scnrm2 (test.scnrm2.js, test.ndarray.js, test.scnrm2.native.js, test.ndarray.native.js) from the relative-tolerance isApprox helper

    delta = abs( actual[ i ] - expected[ i ] );
    tol = rtol * EPS * abs( expected[ i ] );
    t.ok( delta <= tol, 'within tolerance. ...' );

    to ULP-based assertions

    t.strictEqual( isAlmostSameValuef( actual, expected, 1 ), true, 'returns expected value' );
  • adds the @stdlib/number/float32/base/assert/is-almost-same-value require (the single-precision variant, as scnrm2 returns a single-precision result; this mirrors the already-migrated lapack/base/crot and lapack/base/spttrf) and drops the now unused @stdlib/constants/float64/eps and @stdlib/math/base/special/abs requires.

  • removes the isApprox helper entirely, rather than re-parameterizing it from rtol to ulp. Every call site in this package passed scalars, not collections, so expected.length was undefined, the for loop never executed, and no comparison was ever actually performed. The assertions are therefore replaced with direct scalar isAlmostSameValuef calls, following the approach taken for the sibling package in test: migrate blas/base/dnrm2 to ULP-based assertions #16244.

  • corrects one expected value that the dead loop had masked: in the "view offsets" / "offset" test, expected = 14.1 is replaced with expected = 14.106736183166504. The vector under test is (3+4i, 5+6i, 7+8i), whose L2-norm is sqrt(199) = 14.106736...; the single-precision result is 14.106736183166504. The previous value was 7063 ULP away and would never have passed a real comparison.

Final ULP constants (measured minimum per assertion, by bisection):

test/test.scnrm2.js (5 assertions):

test case ULP
L2-norm, N=4, stride=1 (0.8) 1
L2-norm, N=3, stride=1 (0.7) 1
stride=2 (0.8) 1
stride=-2 (0.8) 1
view offsets (14.106736183166504) 0

test/test.ndarray.js (10 assertions):

test case ULP
L2-norm, N=4, stride=1 (0.8) 1
L2-norm, N=3, stride=1 (0.7) 1
5e+15 elements (14142135623730952) 1
1e-20 elements (2.82843e-20) 9
1e20/1e10 elements (2e+20) 1
1e-20/1e10 elements (20000000000) 0
1e-19/1.08420217e-19 elements (2.52012e-19) 13
stride=2 (0.8) 1
stride=-2, offset=6 (0.8) 1
offset=1 (14.106736183166504) 0

Notes on the bounds:

  • 0 is only used where the values are bit-identical; isAlmostSameValuef short-circuits to isSameValue when maxULP === 0, so every inexact comparison requires at least 1.
  • The two larger bounds (9 and 13) are a property of the fixtures, not of the implementation: those expected values are the pre-existing six-significant-digit reference values from the "Checked on Wolfram Alpha" comments (2.82843e-20 vs. the computed 2.8284271361165843e-20, and 2.52012e-19 vs. 2.520116630043669e-19). They were left as-is to avoid changing fixtures unnecessarily. Verified tight: the assertions fail at 8 and 12 respectively and pass at 9 and 13.
  • Every other bound was likewise verified tight by bisection (each fails at one less).

Only the four test files are modified; no implementation, documentation, benchmark, or package.json files are touched.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

Questions

Any questions for reviewers of this pull request?

Yes, one:

  • Is correcting expected = 14.1 to 14.106736183166504 acceptable in this PR? It is strictly necessary for the migration (the old value is 7063 ULP from the true single-precision norm, so no sensible ULP bound accepts it), but it does change a fixture value, which the tracking issue otherwise asks contributors to avoid. The alternative would be to leave the value at 14.1 and use a 7063 ULP bound, which would defeat the purpose of the migration. Happy to split this into a separate commit or PR if preferred.

Other

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

  • Verification: make test TESTS_FILTER=".*/blas/base/scnrm2/.*" passes (9/9, 14/14, 5/5; the two .native.js suites are skipped). The suite was run twice at the final ULP values with identical results, confirming determinism (no FMA/architecture variance; the fixtures are fixed, non-random data). make eslint-tests TESTS_FILTER=".*/blas/base/scnrm2/.*" is clean.
  • The native addon is not built in this environment, so test.scnrm2.native.js and test.ndarray.native.js could not be executed and their ULP values are unverified. Following the convention in test: migrate blas/base/dnrm2 to ULP-based assertions #16244, they use 1 at every call site (i.e., the JavaScript minimum, floored at 1), which allows for the JS-vs-C return value differences described in the FAQ. Please confirm these in CI.
  • The commit was made with --no-verify because the pre-commit EditorConfig linter could not download its binary in this environment (HTTP 403 when fetching editorconfig-checker). EditorConfig compliance was instead verified manually: LF line endings, tab indentation, no trailing whitespace, and a final newline in all four files.

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 PR was written primarily by Claude Code, which surveyed the repository for the remaining relative-tolerance tests, mirrored the idiom used by already-migrated packages, and determined the minimum passing ULP bound for each assertion by bisection.


@stdlib-js/reviewers

https://claude.ai/code/session_01GhRCNQymp1bwMrNiwom4xq


Generated by Claude Code

Ref: #11352

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GhRCNQymp1bwMrNiwom4xq
@stdlib-bot stdlib-bot added BLAS Issue or pull request related to Basic Linear Algebra Subprograms (BLAS). Good First PR A pull request resolving a Good First Issue. labels Oct 20, 2026
@stdlib-bot

Copy link
Copy Markdown
Contributor

Coverage Report

Package Statements Branches Functions Lines
blas/base/scnrm2 $\\color{green}453/453$
$\\color{green}+100.00\\%$
$\\color{green}37/37$
$\\color{green}+100.00\\%$
$\\color{green}4/4$
$\\color{green}+100.00\\%$
$\\color{green}453/453$
$\\color{green}+100.00\\%$

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

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

BLAS Issue or pull request related to Basic Linear Algebra Subprograms (BLAS). Good First PR A pull request resolving a Good First Issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants