Repository navigation
Conversation
Coverage Report
The above coverage report was generated for the changes in this PR. |
| <section class="notes"> | ||
|
|
||
| - Elements outside of the copied region are left unchanged. | ||
|
|
||
| </section> |
There was a problem hiding this comment.
| <section class="notes"> | |
| - Elements outside of the copied region are left unchanged. | |
| </section> | |
| <section class="notes"> | |
| ### Notes | |
| - Elements outside of the copied region are left unchanged. | |
| </section> |
Whenever <section class="notes"> in the C APIs section contains text, it must include a ### Notes heading right after opening the tag (see e.g. znancount/README.md and zany/README.md).
| stdlib_blas_ext_ztril( arrays ); | ||
| } | ||
| elapsed = tic() - t; | ||
| for ( j = 0; j < len; j++ ) { | ||
| parts.value = dataB[ j ]; | ||
| if ( isnan( parts.parts[ 0 ] ) || isnan( parts.parts[ 1 ] ) ) { | ||
| fprintf( stderr, "should not return NaN\n" ); | ||
| break; | ||
| } | ||
| } |
There was a problem hiding this comment.
This is not what is desired. You a) need to retain an assertion check within the hot loop and b) should be using functional accessors, such as complex/float64/real and complex/float64/imag.
|
Thanks for the feedback. I added the ### Notes heading and moved the |
|
while reviewing the implementation I made few changes following merged PRs convention
|
|
@yb175 , Left a few suggestions, PTAL; |
|
@yb175 In general, you need to pay much closer attention to how other packages are structured. Only the minimal essential changes should be present among separate similar packages. |
Thanks @kgryte for the feedback , from next time I would carefully observe the merged PRs from the similar packages before opening future PRs 😊 |
| * // returns true | ||
| */ | ||
| declare function ztril( arrays: [ complex128ndarray, complex128ndarray, typedndarray<number> ] ): complex128ndarray; | ||
| declare function ztril( arrays: [ complex128ndarray, complex128ndarray, int32ndarray ] ): complex128ndarray; |
There was a problem hiding this comment.
@kgryte Is it okay for k to be int32ndarray here as well ?
|
addressed all other review suggestions . leaving the |
| var bench = require( '@stdlib/bench' ); | ||
| var pow = require( '@stdlib/math/base/special/pow' ); | ||
| var format = require( '@stdlib/string/format' ); | ||
| var Complex128Matrix = require( '@stdlib/ndarray/matrix/complex128' ); | ||
| var uniform = require( '@stdlib/random/array/uniform' ); | ||
| var scalar2ndarray = require( '@stdlib/ndarray/from-scalar' ); | ||
| var isnan = require( '@stdlib/math/base/assert/is-nan' ); | ||
| var real = require( '@stdlib/complex/float64/real' ); | ||
| var tryRequire = require( '@stdlib/utils/try-require' ); |
There was a problem hiding this comment.
Keep the same order as benchmark.js.
| var bench = require( '@stdlib/bench' ); | |
| var pow = require( '@stdlib/math/base/special/pow' ); | |
| var format = require( '@stdlib/string/format' ); | |
| var Complex128Matrix = require( '@stdlib/ndarray/matrix/complex128' ); | |
| var uniform = require( '@stdlib/random/array/uniform' ); | |
| var scalar2ndarray = require( '@stdlib/ndarray/from-scalar' ); | |
| var isnan = require( '@stdlib/math/base/assert/is-nan' ); | |
| var real = require( '@stdlib/complex/float64/real' ); | |
| var tryRequire = require( '@stdlib/utils/try-require' ); | |
| var bench = require( '@stdlib/bench' ); | |
| var uniform = require( '@stdlib/random/array/uniform' ); | |
| var Complex128Matrix = require( '@stdlib/ndarray/matrix/complex128' ); | |
| var isnan = require( '@stdlib/math/base/assert/is-nan' ); | |
| var real = require( '@stdlib/complex/float64/real' ); | |
| var pow = require( '@stdlib/math/base/special/pow' ); | |
| var format = require( '@stdlib/string/format' ); | |
| var scalar2ndarray = require( '@stdlib/ndarray/from-scalar' ); | |
| var tryRequire = require( '@stdlib/utils/try-require' ); |
| var ztril = tryRequire( resolve( __dirname, './../lib/native.js' ) ); | ||
| var opts = { | ||
| 'skip': ( ztril instanceof Error ) | ||
| }; |
There was a problem hiding this comment.
| var ztril = tryRequire( resolve( __dirname, './../lib/native.js' ) ); | |
| var opts = { | |
| 'skip': ( ztril instanceof Error ) | |
| }; | |
| var ztril = tryRequire( resolve( __dirname, './../lib/native.js' ) ); | |
| var opts = { | |
| 'skip': ( ztril instanceof Error ) | |
| }; | |
| var options = { | |
| 'dtype': 'float64' | |
| }; |
| * Creates a benchmark function. | ||
| * | ||
| * @private | ||
| * @param {PositiveInteger} N - number of rows and columns |
There was a problem hiding this comment.
| * @param {PositiveInteger} N - number of rows and columns | |
| * @param {PositiveInteger} N - number of elements along each dimension |
| abuf = uniform( N*N*2, -100.0, 100.0, { | ||
| 'dtype': 'float64' | ||
| }); | ||
| bbuf = uniform( N*N*2, -100.0, 100.0, { | ||
| 'dtype': 'float64' | ||
| }); | ||
| A = new Complex128Matrix( abuf.buffer, 0, N, N ); | ||
| B = new Complex128Matrix( bbuf.buffer, 0, N, N ); |
There was a problem hiding this comment.
| abuf = uniform( N*N*2, -100.0, 100.0, { | |
| 'dtype': 'float64' | |
| }); | |
| bbuf = uniform( N*N*2, -100.0, 100.0, { | |
| 'dtype': 'float64' | |
| }); | |
| A = new Complex128Matrix( abuf.buffer, 0, N, N ); | |
| B = new Complex128Matrix( bbuf.buffer, 0, N, N ); | |
| abuf = uniform( N*N*2, -100.0, 100.0, options ); | |
| bbuf = uniform( N*N*2, -100.0, 100.0, options ); | |
| A = new Complex128Matrix( abuf.buffer, 0, N, N ); | |
| B = new Complex128Matrix( bbuf.buffer, 0, N, N ); | |
Related to #14819.
Description
This pull request:
blas/ext/base/ndarray/ztril, using the existing strided C routine.Related Issues
This pull request has the following related issues:
blas/ext/base/ndarraypackages #14819Questions
The native JS wrapper extracts k from the generic scalar ndarray and passes a float64 scalar ndarray to C, so the existing JS example works. For direct C callers, should stdlib_blas_ext_ztril require a 0-D float64 ndarray for k, or support other numeric dtypes? Since the C function returns void, how would you prefer it to handle an unsupported dtype or unreadable scalar?
Other
No.
Checklist
AI Assistance
If you answered "yes" above, how did you use AI assistance?
Disclosure
I used codex for tests generation and documentation writing , all the changes made by ai are reviewed carefully
@stdlib-js/reviewers