[harsh-thakkar7]

Resolves #16335.

Description

This pull request:

• ensures a primitive base is normalized to the real precision expected by the selected kernel (float32 for float32/complex64, float64 for float64/complex128);
• computes through float64/complex128 when a float64 base ndarray is paired with a single-precision output, then downcasts only the result, per the maintainer guidance in the issue;
• casts start and stop to that compute precision so non-integer exponents are not rounded before the higher-precision computation;
• adds public and private regression tests, including a test that fails on the original base dtype normalization.

Related Issues

• bug: blas/ext/logspace passes a float64 base to the float32 slogspace kernel #16335
• fix: ensure base has the precision expected by the selected kernel in blas/ext/logspace #16379 (closed draft exploring the alternative downcast-base approach)

Questions

No.

Other

Validation: test.main.js 595/595, test.assign.js 441/441, test.normalize_arguments.js 30/30, and test.js 3/3. ESLint reports 0 errors (two pre-existing max-lines warnings). The non-integer regression changes the result from 1105.12939453125 to 1105.1297607421875, matching double-precision evaluation downcast to float32.

Checklist

• Read, understood, and followed the contributing guidelines.

AI Assistance

• Yes

• No

• Code generation

• Test/benchmark generation

• Documentation (including examples)

• Research and understanding

Disclosure

This PR was prepared with Qoder AI assistance under the contributor's direction. All changed code and tests were reviewed and executed locally.

---

@stdlib-js/reviewers

[Shubham-Padkonde]

Hi Harsh, would independent tests for the temporary-buffer copy-back path be useful here? The new float64-base / float32-output tests use contiguous outputs; base.js now computes into tmp and then assigns back to out.

If you haven't already planned it, could you and a maintainer approve me taking a test-only follow-up for a non-contiguous output with a nonzero offset and a reversed output view? I'd check the computed values, returned object identity, and sentinel elements outside each view, with a non-integer exponent to exercise the higher-precision path. This would build on your implementation. I haven't run the package or these cases yet.

[harsh-thakkar7]

Hi @Shubham-Padkonde, sorry for the slow reply. Yes, independent tests for the copy-back path would be useful, and please go ahead with the test-only follow-up for a non-contiguous output with a nonzero offset and a reversed output view. Checking the computed values, returned object identity, and the sentinel elements outside each view all sound right, and the non-integer exponent for the higher-precision path is a good idea. Thanks for asking first!

[Shubham-Padkonde]

Thanks, Harsh. I’ll wait for the precision decision on #16335 before building on this PR. If the float64 temporary stays, would the maintainers like me to add the two output-view tests in a separate PR after this lands? That would keep your implementation and the test follow-up independently reviewable.