feat: add blas/base/zdotu

[gururaj1512]

---

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 status: passed
• 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 a part of #2039.

Description

What is the purpose of this pull request?

This pull request:

• Adds javascript implementation for blas/base/zdotu

Related Issues

Does this pull request have any related issues?

This pull request:

• Resolves a part of [RFC]: Add BLAS bindings and implementations for linear algebra (tracking issue) #2039.

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.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
blas/base/zdotu	$\color{green}235/235$ $\color{green}+100.00\%$	$\color{green}12/12$ $\color{green}+100.00\%$	$\color{green}2/2$ $\color{green}+100.00\%$	$\color{green}235/235$ $\color{green}+100.00\%$

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

[ShabiShett07]

/stdlib merge

[kgryte]

/stdlib merge

[kgryte]

This isn't a valid check. You need to check, e.g., the real component.

[kgryte]

Here, you can check the imaginary component (e.g., isnan( imag( d ) )).

[kgryte]

Same comments.

[kgryte]

Suggested change

	Scalar constant.
	Dot product.

[kgryte]

Suggested change

	buffer, the offset parameters support indexing based on a starting index.
	buffer, offset parameters support indexing based on starting indices.

[kgryte]

Suggested change

	Second input array.
	Dot product.

[kgryte]

Would you mind updating all the descriptions to use consistent language? s/Calculates/Computes/ here and everywhere else.

[kgryte]

Suggested change

	// The function returns Complex128...
	// The function returns a complex number...

[kgryte]

Suggested change

	// Attached to main export is an `ndarray` method which returns a Complex128...
	// Attached to main export is an `ndarray` method which returns a complex number...

[kgryte]

This isn't correct. We should not be using the accessors. We should reinterpret the complex input arrays as Float64Arrays of interleaved real and imaginary components. And then we should use muladd.strided. For reference, see

stdlib/lib/node_modules/@stdlib/blas/base/zaxpy/lib/ndarray.js

Line 79 in 0283804

muladd( re, im, viewX[ ix ], viewX[ ix+1 ], viewY[ iy ], viewY[ iy+1 ], viewY, 1, iy ); // eslint-disable-line max-len

.

[kgryte]

Instead of muladd.assign, you want to use muladd.strided: https://github.com/stdlib-js/stdlib/tree/02838049b98a8ae3c595714e397364aace06f7b9/lib/node_modules/%40stdlib/complex/float64/base/mul-add#muladdstrided-alpha-sa-oa-x-sx-ox-y-sy-oy-out-so-oo-

This allows you to have the output real and imaginary components stored in a Float64Array. To return a complex number, you then do new Complex128( out[ 0 ], out[ 1 ] ).

[kgryte]

The reason we shouldn't be using accessors and constantly materializing Complex128 instances is that all of this is happening in a hot loop. Instead, prefer to operate on the individual components directly.

[kgryte]

Suggested change

	t.strictEqual(isSameComplex128( dot, new Complex128( 3, 70 ) ), true, 'returns expected value' );
	t.strictEqual(isSameComplex128( dot, new Complex128( 3.0, 70.0 ) ), true, 'returns expected value' );

To indicate that the input values are double, we should add decimals here and everywhere else in these test files when creating Complex128 instances.

[kgryte]

These annotations are not correct. The 0 and 1 comments should be reversed, as the strided for y is -1 at L236.

[kgryte]

Same comments.

[kgryte]

Suggested change

	tape( 'if provided an `N` parameter less than or equal to `0`, the function returns `0 + 0i`', function test( t ) {
	tape( 'if provided an `N` parameter less than or equal to `0`, the function returns `0`', function test( t ) {

Consistency with other test file.

[kgryte]

Same comment regarding the comments.

[kgryte]

This PR needs a bit of clean-up still.

@ShabiShett07 Also, in addition to the main export and the ndarray method, we should add an assign method with the following signature:

zdotu.assign( N, x, strideX, offsetX, y, strideY, offsetY, out, offsetOut );

In this case, the real and imaginary components of the complex number output will be written to out which should be a Complex128Array at the index offsetOut.

The ndarray method can then wrap the assign API and you can use a preallocated Complex128Array workspace array which you then pass as input to assign. When returning from ndarray, you then do workspace.get( 0 ), which will materialize a new Complex128 value.

Similarly, the main export can also wrap the assign API.

Why are we doing this? Because in zgemm, you will want to use the assign API of zdotu, not the ndarray API. The assign API will allow you to avoid materializing complex number instances in hot loops.