[aryan7071]

Resolves a part of #14034

Description

What is the purpose of this pull request?

This pull request:

• feat: add C implementation for stats/base/ndarray/sztest

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• [RFC] : add C implementations for @stdlib/stats/base/ndarray packages (tracking issue) #14034

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
stats/base/ndarray/sztest	$\\color{green}267/267$ $\\color{green}+100.00\\%$	$\\color{green}7/7$ $\\color{green}+100.00\\%$	$\\color{green}2/2$ $\\color{green}+100.00\\%$	$\\color{green}267/267$ $\\color{green}+100.00\\%$

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

[0PrashantYadav0]

Tracking issue #14034 marks the ztest family as blocked on custom-dtype support (the note was added after this PR was opened), and this PR works around that with y.get().toDataView(), as stats/strided/sztest does, so a maintainer needs to confirm the approach. The AI disclosure in the description is still {{TODO: add disclosure if applicable}}.

[0PrashantYadav0]

When the output ndarray has a non-zero offset, the native path writes to the wrong struct. With buf = new ResultsArray( 3 ) and out = new ndarray( Float32Results, buf, [], [ 0 ], 1, 'row-major' ), main.js fills buf.get( 1 ) but native.js fills buf.get( 2 ). With offset 2, it writes past the end of the buffer.

The cause is upstream. At napi/argv-dataview/src/main.c:69, the code adds byte_offset to a pointer that napi_get_dataview_info has already offset. stats/strided/sztest native has the same bug with buf.get( 1 ). Should this wait for that fix, and then add an output-offset case to test/test.native.js?

[0PrashantYadav0]

Suggested change

	static double rand_double( void ) {
	return (double)rand() / ( (double)RAND_MAX + 1.0 );
	static float rand_float( void ) {
	int r = rand();
	return (float)r / ( (float)RAND_MAX + 1.0f );

Also update line 133 to data[ i ] = ( rand_float()*10.0f ) - 5.0f;. Same as #15170 (comment).