[yb175]

Related to #14819.

Description

What is the purpose of this pull request?

This pull request:

• Adds a native C implementation for blas/ext/base/ndarray/slogspace using the
  existing strided C routine.
• Uses the native addon when available and retains the JavaScript fallback.
• Adds C API documentation, a C example, benchmarks, and native tests.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC]: add C implementations for blas/ext/base/ndarray packages #14819

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

The AI is used for generating the documentation , all the changes are carefully reviewed before push

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/ext/base/ndarray/slogspace	$\\color{red}248/252$ $\\color{red}-1.59\\%$	$\\color{red}7/8$ $\\color{red}-12.50\\%$	$\\color{green}2/2$ $\\color{green}+0.00\\%$	$\\color{red}248/252$ $\\color{red}-1.59\\%$

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

[yb175]

The native wrapper now converts non-float32 base scalars to float32, matching the existing slogspace powf behavior. Added regression tests for float64 bases.

[ujjwalv01]

No dtype conversion here. Like k in ztril, the scalar ndarrays should already be float32 (as in the docs), and the boolean buffer can go through reinterpret-boolean.

Suggested change

	var endpoint = arrays[ 4 ];
	var base = arrays[ 1 ];
	var strt = arrays[ 2 ];
	var buf = getData( endpoint );
	var stp = arrays[ 3 ];
	var x = arrays[ 0 ];
	if ( getDType( base ) !== 'float32' ) {
	base = scalar2ndarray( ndarraylike2scalar( base ), {
	'dtype': 'float32'
	});
	}
	addon( getData( x ), serialize( x ), getData( base ), serialize( base ), getData( strt ), serialize( strt ), getData( stp ), serialize( stp ), new Uint8Array( buf.buffer, buf.byteOffset, buf.length ), serialize( endpoint ) ); // eslint-disable-line max-len
	var endpoint = arrays[ 4 ];
	var base = arrays[ 1 ];
	var strt = arrays[ 2 ];
	var stp = arrays[ 3 ];
	var x = arrays[ 0 ];
	addon( getData( x ), serialize( x ), getData( base ), serialize( base ), getData( strt ), serialize( strt ), getData( stp ), serialize( stp ), reinterpret( getData( endpoint ), 0 ), serialize( endpoint ) ); // eslint-disable-line max-len

[yb175]

I’m concerned removing the conversion will bring back the failure in this CI run(https://github.com/stdlib-js/stdlib/actions/runs/39103254507/job/117603674460#step:9:220): logspace passes a float64 base with float32 output, and native slogspace returned [1, 0, 0] instead of [1, 10, 100]. Where would you prefer that conversion to happen?

[ujjwalv01]

Good catch, and thanks for the link. The root cause is in blas/ext/logspace: it intentionally keeps base in its own dtype (a number primitive becomes a float64 0-d ndarray, to avoid casting the base to complex for complex outputs), while start/stop are cast to the output dtype, and the dispatcher doesn't cast additional ndarray arguments. So with a float32 output the kernel receives a float64 base, and stdlib_ndarray_get_float32 in main.c misreads it. That's why only base was wrong.

The JS main.js is dtype-agnostic (ndarraylike2scalar), but the C getters are not, so the real question is which layer should guarantee the kernel's float32 contract. Converting in native.js works, but no merged native.js does this, and a generic endpoint (also allowed by blas/ext/logspace) would still crash the add-on. @kgryte, would you prefer blas/ext/logspace to cast a real base to the output dtype (for real outputs), or should the kernels handle mixed scalar dtypes? Until then the current conversion is fine with me.

[ujjwalv01]

Left a few suggestions;

[yb175]

Updated boolean buffer handling to use reinterpret-boolean and synced the tests with develop. Waiting for @kgryte’s guidance on dtype conversion.