feat: add blas/base/ndarray/drot

[MeKaustubh07]

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown_pkg_readmes status: passed
• task: lint_markdown_docs status: na
• task: lint_markdown status: na
• task: lint_package_json status: passed
• task: lint_repl_help status: passed
• task: lint_javascript_src status: passed
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: passed
• task: lint_javascript_tests status: passed
• task: lint_javascript_benchmarks status: passed
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: na
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: na
• task: lint_typescript_declarations status: passed
• task: lint_typescript_tests status: passed
• task: lint_license_headers status: passed ---

Resolves #{{TODO: add issue number}}.

Description

What is the purpose of this pull request?

This pull request:

• feat: add blas/base/ndarray/drot

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• #{{TODO: add related issue number}}

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.

No.

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.".

{{TODO: add disclosure if applicable}}

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/base/ndarray/drot	$\color{green}137/137$ $\color{green}+0.00\%$	$\color{green}3/3$ $\color{green}+0.00\%$	$\color{green}1/1$ $\color{green}+0.00\%$	$\color{green}137/137$ $\color{green}+0.00\%$

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

[MeKaustubh07]

@kgryte
In drot/test/test.js, the expected arrays currently use exact float64 values (e.g., 4.3999999999999995 instead of 4.4) as the isSameFloat64Array performs bit-level equality checks.
Since values such as 0.8 and 0.6 are not exactly representable in IEEE 754, the rotation arithmetic produces results that differ slightly from the corresponding decimal literals due to floating-point rounding.
How would you prefer we handle this? Should we continue using the exact computed float64 values in the expected arrays, or would it be better to use approximate comparisons for these test cases?

[kgryte]

@MeKaustubh07 Use isAlmostSameFloat64Array. Don't compare exact values. That is brittle and just a future source of breakages when results are inexact.

[MeKaustubh07]

@batpigandme The discussion came up while I was working on the #12456
I initially used exact array comparisons isSameFloat*Array in the tests, but some expected values differed by a few ULPs due to floating-point rounding from the rotation coefficients (c = 0.8, s = 0.6). For example, while mathematically 0.8 * 1.0 + 0.6 * 6.0 = 4.4, the actual floating-point result may be stored as 4.3999999999999995 due to IEEE-754 rounding.
The problem is that your expected value in the test is usually written as 4.4, while the computed result is 4.3999999999999995.

For example,

actual   = 4.3999999999999995
expected = 4.4

isSameFloat64Array( actual, expected ) // false

The BLAS implementation is still correct—the difference comes from IEEE-754 rounding during operations involving values like 0.8 and 0.6, which are not exactly representable in binary.
isAlmostSameFloat*Array resolves this by allowing a small ULP tolerance:

isAlmostSameFloat64Array( actual, expected , 2)

Instead of asking “Are these values bit-for-bit identical?”, it asks “Are these values within a small number of representable floating-point values of each other?”

Since the difference between 4.4 and 4.3999999999999995 is only 1 ULP, the comparison passes, making the test robust against harmless rounding differences while still catching genuine numerical errors.

@kgryte suggested switching to isAlmostSameFloat*Array, which made the tests much more robust. It was a good reminder that BLAS rotation routines naturally involve inexact arithmetic, so exact bit-level comparisons can be brittle even when the implementation is correct.