[RFC]: add `ndarray` interface variants for missing modules in `@stdlib/blas/ext/base`

[0PrashantYadav0]

Description

This RFC proposes to add ndarray interface variants for the following modules present in @stdlib/blas/ext/base which do not yet have a corresponding implementation in @stdlib/blas/ext/base/ndarray.

Each module listed below needs an ndarray-style interface accepting offset and stride arguments, following the conventions of existing modules such as @stdlib/blas/ext/base/ndarray/daxpb.

c prefix (Complex float32)

• capx
• cfill
• cindex-of-column
• cindex-of-row
• clast-index-of-row
• creplicate
• cwapx
• cwax
• cwhere
• cwxsy

d prefix (float64)

• dapx
• dapxsum
• dapxsumkbn
• dapxsumkbn2
• dapxsumors
• dapxsumpw
• dasumpw
• dcartesian-power
• dcartesian-product
• dcartesian-square
• dcuany
• dcuevery
• dcusome
• dediff
• dfill
• dfill-less-than
• dindex-of-column
• dindex-of-row
• dlast-index-of-row
• dminheap-sift-down
• dminheapify
• dmskrev
• dnanasum
• dnanasumors
• dnancount
• dnancusumkbn
• dnannsum
• dnannsumkbn
• dnannsumkbn2
• dnannsumors
• dnannsumpw
• dnone
• dones
• dreplicate
• drev
• drrss
• drss
• drssbl
• drsskbn
• dsapxsum
• dsapxsumpw
• dsnannsumors
• dsnansum
• dsnansumors
• dsnansumpw
• dsome
• dsort2hp
• dsort2ins
• dsort2sh
• dssum
• dssumors
• dssumpw
• dvander
• dwapx
• dwax
• dwhere
• dwxdy
• dwxmy
• dwxpy
• dwxsy
• dzeros

g prefix (generic)

• gapx
• gapxsum
• gapxsumkbn
• gapxsumkbn2
• gapxsumors
• gapxsumpw
• gasumpw
• gcartesian-power
• gcartesian-product
• gcartesian-square
• gconjoin
• gcuany
• gcuevery
• gcusome
• gediff
• gevery
• gfill
• gfill-by
• gfill-less-than
• gfirst-index-not-equal
• gindex-of-column
• gindex-of-falsy-row
• gindex-of-row
• gindex-of-same-value
• gindex-of-truthy-row
• glast-index-of-row
• gminheap-sift-down
• gminheapify
• gmskrev
• gnancount
• gnannsumkbn
• gnannsumpw
• gnone
• greplicate
• grev
• gsome
• gsort2hp
• gsort2ins
• gsort2sh
• gsorthp-by
• gsortins
• gsortsh
• gvander
• gwapx
• gwax
• gwaxpb
• gwhere
• gwxdy
• gwxmy
• gwxpy
• gwxsy

s prefix (float32)

• sapx
• sapxsum
• sapxsumkbn
• sapxsumkbn2
• sapxsumors
• sapxsumpw
• sasumpw
• scartesian-power
• scartesian-product
• scartesian-square
• scuany
• scuevery
• scusome
• scusumpw
• sdsapxsum
• sdsapxsumpw
• sdsnansum
• sdsnansumpw
• sdssum
• sdssumpw
• sediff
• sfill
• sindex-of-column
• sindex-of-row
• slast-index-of-row
• sminheap-sift-down
• smskrev
• snancount
• snone
• sones
• sreplicate
• srev
• ssome
• ssort2hp
• ssort2ins
• ssort2sh
• ssortins
• ssortsh
• svander
• swapx
• swax
• swhere
• swxdy
• swxmy
• swxpy
• swxsy
• szeros

z prefix (complex128)

• zany
• zapx
• zcartesian-product
• zcartesian-square
• zfill
• zindex-of-column
• zindex-of-row
• zlast-index-of-falsy
• zlast-index-of-row
• znancount
• zreplicate
• zwapx
• zwax
• zwhere
• zwxmy
• zwxsy

Related Issues

No.

Questions

No.

Other

No.

Checklist

• I have read and understood the Code of Conduct.
• Searched for existing issues and pull requests.
• The issue name begins with RFC:.

[ujjwalv01]

Hi @0PrashantYadav0,

I wanted to confirm one thing;

Looking at the existing @stdlib/blas/ext/base/ndarray/daxpb as the reference, it appears these new packages should be pure JS wrappers that simply call the existing strided version's .ndarray method , with no native C addon required; Should all new packages in this issue follow the same pattern?

[0PrashantYadav0]

Yes, exactly. All new packages in this issue will follow that same pattern, acting mostly as JS wrappers around the existing strided version's .ndarray method. You can reference @stdlib/blas/ext/base/ndarray/dsum as a good example of this setup.

Regarding the native C addons: while they are not strictly required for the initial PR, they are highly preferred. We do eventually want the C implementations alongside the JS wrappers, but starting with just the JS wrapper for now is perfectly fine.

Maybe we need another tracking issues for C implementation of these packages in the future.