feat: add lapack/base/zlacpy

[rreusser]

Towards #2464

Description

What is the purpose of this pull request?

This pull request adds JS implementation for lapack/base/zlacpy.

Related Issues

Does this pull request have any related issues?

N/A

Questions

• When printed, Complex128Array shows up as <Complex128Array>, unlike Float64Array which is printed as <Float64Array>[ 1.0, 2.0, 3.0, 4.0 ]. This makes the 40-or-so instances of repl text output in docs, readmes, code etc. mostly useless. Is there a better solution for this? I left them all just blank since that's technically correct for what's printed.
• What is the correct syntax for importing Complex128Array into the typescript annotations?
• TypeScript complains that Complex128Array should be a dependency of this module. Should it?
• Is there a better way to generate random data than this? new Complex128Array( uniform( 2*N, -10, 10, { 'dtype': 'generic' }));
• I commit and push with --no-verify. This is not ideal. Maybe there's a better pattern? I mostly did this because of line length limits. It's hard to fit nontrivial arrays of complex numbers onto one line, and I wasn't quite sure the rules for breaking them onto multiple lines and getting around line length linters.

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
lapack/base/zlacpy	$\color{green}1017/1017$ $\color{green}+100.00\%$	$\color{green}40/40$ $\color{green}+100.00\%$	$\color{green}6/6$ $\color{green}+100.00\%$	$\color{green}1017/1017$ $\color{green}+100.00\%$

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

[kgryte]

/stdlib update-copyright-years

[kgryte]

This makes the 40-or-so instances of repl text output in docs, readmes, code etc. mostly useless. Is there a better solution for this? I left them all just blank since that's technically correct for what's printed.

Atm, in the REPL, we rely on utils.inspect from Node.js to perform printing of object values, and we have yet to write our own custom implementation. Hence, the divergence between Float64Array and Complex128Array. Relevant TODO:

stdlib/lib/node_modules/@stdlib/repl/lib/drain.js

Line 131 in abf124e

// TODO: pretty printing (can defer to `util.inspect` for now, but will invariably want more control over this later, possibly including default configuration, etc, either at startup, during runtime, or according to an external configuration file)

For doctesting, this has been a longstanding feature request. See https://github.com/stdlib-js/todo/issues/2081.

What is the correct syntax for importing Complex128Array into the typescript annotations?

See other packages. E.g.,

stdlib/lib/node_modules/@stdlib/blas/base/zcopy/docs/types/index.d.ts

Line 23 in abf124e

import { Complex128Array } from '@stdlib/types/array';

Is there a better way to generate random data than this? new Complex128Array( uniform( 2*N, -10, 10, { 'dtype': 'generic' }));

We don't have a dedicated PRNG for complex typed array data. So, yes, what you propose or similar.

var xbuf = uniform( 2*N, -10.0, 10.0, {
	'dtype': 'float64'
});
var x = new Complex128Array( xbuf.buffer ); // or just new Complex128Array( xbuf )

I mostly did this because of line length limits. It's hard to fit nontrivial arrays of complex numbers onto one line, and I wasn't quite sure the rules for breaking them onto multiple lines and getting around line length linters.

Yes, agreed. In this case, in JS, you can disable the rule at the top-level in JS: /* eslint-disable max-len */. Although, in JS, max-len is a warning, not an error. For repl.txt, the situation is different. We do need to respect line length limits there, as terminals are more likely to be width constrained and have clunkier automatic soft-wrapping. Hence, you may need to get creative, or use things like @stdlib/array/linspace to generate a Float64Array and then wrap with a Complex128Array, etc.

[kgryte]

This now LGTM. Thanks for working on this, @rreusser!