Idea brainstorm

[kgryte]

The purpose of this issue is to provide a single place for documenting potential GSoC project ideas. The ideas may be ill-defined or even wishful thinking, but they may serve as inspiration for more concrete GSoC project proposals given some R&D and careful consideration.

[kgryte]

Two potential ideas are:

• linear programming APIs
• APIs for solving ODEs and PDEs

[kgryte]

• stdlib-jStat integration
• stdlib-math.js integration
• stdlib-scijs integration

[kgryte]

• Excel add-on (conceptually similar to GSheets add-on
  • Issue: [Idea]: develop an Excel add-on which exposes stdlib functionality #35

[kgryte]

• C implementations for special mathematical functions
  • Issue: [Idea]: develop C implementations for base special mathematical functions #34

[kgryte]

@Planeshifter Do you have any ML/AI ideas? Possibly related to tooling or developer experience?

[kgryte]

• incremental machine learning algorithms (@stdlib/ml/incr)
  • Issue: [Idea]: implement incremental (online) machine learning algorithms #37

[kgryte]

• Writing matrix format parsers and loaders (e.g., Matrix Market, NumPy npy format, etc)

[kgryte]

• Implementing ndarray APIs to achieve Data APIs specification compliance.

[kgryte]

• Promise APIs

[kgryte]

• explicit BLAS implementations and native add-ons
  • Issue: [Idea]: add BLAS bindings and implementations for linear algebra #36
• refactor add-on compilation to support a single shared library

[kgryte]

• add DLPack support to stdlib (see https://data-apis.org/array-api/latest/design_topics/data_interchange.html#data-interchange)

[kgryte]

• Apache Arrow support (main concern is future maintenance burden associated with keeping updated with latest Arrow version)

[Planeshifter]

• N-D labeled arrays (inspired by Python's Xarray)

[kgryte]

• slash bot for running commands on PRs

UPDATE: this has been done.

[kgryte]

• code coverage app

[Planeshifter]

• AI-powered code linting tool that scans the code base for code blocks violating the project conventions

[Planeshifter]

• stdlib-bot GitHub application that can be triggered via PR and issue comments and perform a variety of tasks (can subsume existing functionality such as scaffolding and reviewing PRs for required files)

UPDATE: We now have slash commands for this purpose.

[kgryte]

• ndarray API parity with built-in JS arrays (e.g., forEach, map, reverse, etc)
  • Issue: [Idea]: achieve ndarray API parity with built-in JavaScript arrays #33

[kgryte]

• support the collection of browser benchmark results (e.g., from standalone package repos and API docs)

[kgryte]

• nodeschool workshopper for the REPL

[Planeshifter]

• REPL browser terminal for using stdlib on the web

[kgryte]

• SIMD support in ndarray kernels

[kgryte]

• additional data structures (e.g., B-trees, binary search trees, etc)

[kgryte]

• Float16Array support
  • Issue: [Idea]: add support for Float16Array #94

[kgryte]

• Int64Array support (this would be useful for int64-based array indexing, etc)
• Uint64Array support (this is less a priority, but would be good to have for Int32/Uint32 parity)

Ideally, we'd add Int64 class/object support along with associated utilities.

[Planeshifter]

VSCode extension for data analysis with stdlib. Can take inspiration from Positron by Posit (formerly RStudio).

[kgryte]

• WGSL (WebGPU) implementations of special math functions

Idea would be to create shared libraries for special math functions. For each special math function, we'd author a *.wgsl file containing function source code. For dependencies, we'd use #include syntax and then have tooling which automatically injected the source code of dependencies into a single output file. We'd need to deduplicate injected dependencies. We'd effectively need to do the work of a C preprocessor. We could probably leverage manifest.json files for this. And rely on leveraging a global namespace, similar to what we do with C implementations in order to avoid symbol name conflicts.

[kgryte]

• Extend our doctesting framework to C examples
  • Issue: [Idea]: extend stdlib's doctesting approach to C examples #96

[kgryte]

• As part of Markdown linting, compile and run C examples, similar to how we run JavaScript examples in READMEs.

[kgryte]

• ESLint 9 migration so that we could lint JSON and YAML, etc.
  • Issue: [Idea]: ESLint 9 Migration for JSON and YAML Linting #90

[kgryte]

Some of @Planeshifter's ideas:

• LLM-based automated code fixes (initially scoped to commit comments directed to stdlib-bot)
• Implementing stdlib meta data security model
• refactor stdlib publishing pipeline (observability, testing, checkpointing, etc)
  • Issue: [Idea]: improve stdlib publishing pipeline #92
• refactor stdlib website generation pipeline (migrate to ESM loading for modern web browsers, support versioning in API docs, CI to run nightly)

[kgryte]

@Planeshifter I was looking at TF.js models, and one of the models is for toxicity detection. What about creating tooling for detecting "toxic" comments on GitHub issues and PRs and sending them as candidates to stdlib moderators (via e-mail or some other means) to review?

Also, what about an LLM or other deep learning model which runs on PRs which checks for malicious comments?

[kgryte]

• LAPACK routines
  • Issue: [Idea]: add LAPACK bindings and implementations for linear algebra #95

[kgryte]

• Improving TypeScript type specificity across the project
  • There are a number (perhaps many) declarations across the project in where our type specificity could be improved, particularly when mapping input dtypes to output dtypes. There are likely a number of occurrences where we lose specificity, thus decreasing type safety.

[kgryte]

• A just-in-time compiler for generating ndarray kernels in WebAssembly.
  • Would allow lazy kernel generation.
  • If you have an interface backed by a lazy kernel, the first time an ndarray is passed through, we'd generate the kernel just-in-time according to the input ndarray dtype and dimensionality.
  • Output the kernel in some format which could be compiled to the WebAssembly binary format.
  • Once compiled, instantiate the WebAssembly module.
  • Call into the module and return the result.
  • Cache the module instance so that it can be reused for future calls.

[kgryte]

• Porting ARPACK: https://github.com/opencollab/arpack-ng/tree/master
  • Fortran Lang discussion: https://fortran-lang.discourse.group/t/modernizing-arpack/3886/12