feat: add C implementation for blas/ext/base/ndarray/dtril

[ujjwalv01]

Resolves a part of #14819

Description

What is the purpose of this pull request?

This pull request:

• adds a native C implementation for copying the lower triangular part of a double-precision floating-point matrix to another matrix (dtril).
• updates the test suite (test.js, test.main.js, test.native.js) and benchmarks to cover and utilize the new native C addon.

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• #[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.".

I consulted an AI assistant to help structure and generate the test files (test.main.js, test.native.js) and benchmark files required to test the native C addon. The core logic and implementation were authored manually by myself.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/ext/base/ndarray/dtril	$\\color{green}227/227$ $\\color{green}+100.00\\%$	$\\color{green}7/7$ $\\color{green}+100.00\\%$	$\\color{green}2/2$ $\\color{green}+100.00\\%$	$\\color{green}227/227$ $\\color{green}+100.00\\%$

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

[kgryte]

@ujjwalv01 Is this a duplicate of #14471?

[ujjwalv01]

Oops, yes it is! Completely missed that one. Closing this PR in favor of #14471. Thanks!

[Arjan-P]

Hi @ujjwalv01, I was curious on your take on this package so I went ahead and took a look at the PR. I noticed you opted to pass k as a scalar in favour of keeping dtype as generic. While we can’t say what the correct approach is until @kgryte has a look at #14471, I think the conversation there can be of help for future reference. Hope it’s of some use.

[ujjwalv01]

@Arjan-P , Thanks for taking a look and for the pointer to #14471 , It’s definitely helpful to see the discussion there.
My main reasoning for extracting k to a scalar in JS was to easily handle generic dtypes without complicating the C addon. If k is a generic 0D ndarray, its underlying buffer is a standard JS array. By using ndarraylike2scalar in JS, we can extract the primitive value regardless of the dtype, pass it as a simple int64 to the C addon, and then just wrap it back into a native INT64 ndarray on the C side to satisfy the core C API.
It felt like a clean way to keep the JS interface flexible (supporting generic arrays) while keeping the N-API bindings simple. But I'll definitely keep an eye on how it gets resolved in #14471 so I can align with whatever approach preferred for the project. Thanks again;

[kgryte]

In this case, it is not clear that dtril is much different than how we handled the correction ndarray in stats/base/ndarray/dvariancetk, etc. There, we passed down a zero-dimensional ndarray rather than extracting the scalar and then passing down directly. See

stdlib/lib/node_modules/@stdlib/stats/base/ndarray/dvariancetk/lib/native.js

Line 59 in f89afd6

var correction = arrays[ 1 ];

Whatever path we choose, we should be consistent. Given that the C API expects an array of ndarrays, it is not clear that we should be unwrapping in JS and then passing down. Instead, from JS, we should be passing the zero-dimensional ndarray.

[ujjwalv01]

Thanks for explaining that, @kgryte . I originally extracted it because k was a generic array, but seeing the approach in #14471 clears it up nicely. Thanks for the feedback;