[RFC]: add LAPACK bindings and implementations for linear algebra

[DhruvArvindSingh]

Full name

Dhruv Arvind Singh

University status

Yes

University name

Indian Institute of Information Technology, Nagpur (IIIT Nagpur)

University program

Bachelor of Technology in Computer Science and Engineering

Expected graduation

May 2027

Short biography

I'm a third-year CSE student at IIIT Nagpur. I got into programming in high school through Android development (Kotlin), and over time I’ve moved more towards systems programming, backend work, and numerical computing.

For the past some time, I’ve been actively contributing to stdlib. So far I’ve made 70+ merged PRs, working across JavaScript, C, and Fortran. Most of my work has been around BLAS routines, refactoring older C++ code to C, and writing native bindings using N-API. Working on stdlib has really helped me understand how numerical libraries are structured and how different layers (JS, C, Fortran) fit together.

Outside of stdlib, I was part of the C4GT Developer Mentorship Program, where I worked as a blockchain developer on a government open-source project. That was my first experience working on a large, real-world OSS codebase with multiple contributors.

I also interned as an SDE intern at Twigg (fintech), where I worked on backend systems and got exposure to production environments.

Right now, I’m mainly interested in systems + numerical computing, especially making JavaScript more usable for performance-heavy workloads.

Timezone

Indian Standard Time (IST, UTC+5:30)

Contact details

dhruvsinghxd@gmail.com

Platform

Linux

Editor

VS Code

Programming experience

I was introduced to programming in high school through Kotlin for Android development, which helped me understand object-oriented programming and app architecture.

In college, I built a strong foundation in C and C++ through coursework and competitive programming. I’ve implemented data structures and algorithms from scratch and worked on projects like a custom string library in C and a terminal-based Library Management System in C++.

I later moved into full-stack development using JavaScript, working with React, Next.js, Node.js, and databases like MySQL and PostgreSQL. I’ve built projects like a multiplayer Ludo platform with real-time communication using WebSockets.

More recently, I’ve been focusing on systems and infrastructure. I built Deployer, a static site deployment platform using Go, Docker, and k3s, and I maintain a small homelab setup running services like Nextcloud and MinIO.

JavaScript experience

I’ve worked across the JavaScript ecosystem:

• Frontend: React, Next.js
• Backend: Node.js, Express, Fastify
• Databases: PostgreSQL, MySQL, MongoDB
• Real-time: WebSockets, Socket.io

Through stdlib, I’ve worked with:

• TypedArrays and ArrayBuffer
• module systems (CJS/ESM)
• native bindings using N-API

Node.js experience

• Built REST APIs with Express
• Worked with file systems, streams, and CLI tools
• Developed npm packages
• Integrated native C code using N-API

C/Fortran experience

C:

• Built a custom string library
• Implemented data structures and algorithms
• Worked on stdlib native addons

Fortran:

• Implemented BLAS routines in Fortran
• Familiar with LAPACK-style structure
• Worked on interoperability with C

Interest in stdlib

I started contributing to stdlib around December 2024, and it’s been one of the most useful learning experiences for me so far.

What I like about stdlib is the overall vision, building a proper standard library for JavaScript that goes beyond typical web use cases. A lot of packages here deal with things like numerical computing, statistics, and low-level utilities, which you usually don’t associate with JavaScript.

While contributing, I got a chance to work across different parts of the codebase, from JavaScript implementations to C and even some Fortran. That helped me understand how stdlib is structured and how different layers interact, especially when performance matters.

I’ve also become familiar with the contribution workflow, writing tests, benchmarks, handling reviews, and iterating on feedback which I initially struggled with, Over time, I’ve gotten more comfortable picking up issues and working through them independently.

Overall, contributing to stdlib feels very different from most open-source projects I’ve worked on, mainly because of the focus on correctness, consistency, and long-term maintainability. That’s something I really want to continue working on during GSoC.

Version control

Yes

Contributions to stdlib

BLAS (Level 1 - Coverage Nearly Complete)

Most of my recent work this year has been around BLAS Level 1 base packages.

I’ve been working towards completing BLAS Level 1 coverage by filling in missing and partially implemented routines. This involved building on top of older partial PRs from other contributors and extending them into full implementations across JavaScript, C, and Fortran. Once my current open PRs are merged, all BLAS Level 1 base packages will have implementations across all three layers.

This included:

• adding missing C / Fortran implementations
• completing JS implementations
• adding complete end-to-end implementations
• ensuring consistency across layers
• adding tests and benchmarks for all the implementation

Some of my open PR's of blas Level 1:

• #11026 (open) - @stdlib/blas/base/cdotc
• #11025 (open) - @stdlib/blas/base/zdotu
• #11024 (open) - @stdlib/blas/base/cdotu
• #10976 (open) - @stdlib/blas/base/izamax
• #10942 (open) - @stdlib/blas/base/icamax
• #10920 (open) - @stdlib/blas/base/dzasum
• #9724 (open) - @stdlib/blas/base/drotmg
• #9711 (open) - @stdlib/blas/base/srotmg
• #9628 (open) - @stdlib/blas/base/zrotg
• #9592 (open) - @stdlib/blas/base/drotg
• #9537 (open) - @stdlib/blas/base/srotg

... and more

---

Statistics packages and C implementation

Refactored 15+ packages from C++ to C to simplify native bindings and improve consistency.

Added C implementation to multiple packages

---

Native bindings

• worked with N-API
• added utilities like argv-bool
• handled JS ↔ C integration

---

Distribution functions

Implemented C versions for:

• logistic
• laplace
• weibull

---

Summary

• 70+ merged PRs (link)

• worked across JS, C, and Fortran
• contributions in BLAS, stats, bindings, distributions

stdlib showcase

Through my contributions, I’ve explored stdlib’s layered architecture:

• JavaScript layer
• C native bindings
• Fortran implementations
• build + testing setup

Working across these layers helped me understand how performance-critical numerical code is structured and exposed to JavaScript users.

To demonstrate that understanding from a user perspective, I built a 3D interactive showcase using stdlib in a Next.js frontend:

Strange Attractors Playground

An interactive 3D particle simulation of chaotic systems (Lorenz, Rössler, Thomas attractors) powered by stdlib. 15,000 particles flow through the attractor's vector field in real time, with colour mapped to velocity magnitude.

stdlib packages used:

• @stdlib/math-base-special-sin - Thomas attractor derivatives (sin(y) - bx, etc.)
• @stdlib/blas-base-dnrm2 - BLAS L1 Euclidean norm, called every frame per particle to map velocity → colour
• @stdlib/random-base-normal - seeded Gaussian PRNG for initial particle scatter
• @stdlib/math-base-special-cos, @stdlib/math-base-special-exp - available for extension

The project intentionally avoids Math.* in favour of stdlib equivalents to show the difference in API surface and numerical rigour. The hot loop (Euler integration + dnrm2 per particle per frame) is a real-world stress test of stdlib's BLAS bindings from the browser.

The project is live at stdlib.solanalance.com, deployed in my homelab

Goals

Overall Goal

Deliver complete JS, C, and Fortran implementations for 35 LAPACK routines in @stdlib/lapack/base starting by adding C and Fortran layers to the existing JS-only auxiliary packages, then implementing the critical missing routines that form three complete solver chains: LU factorization (dgetf2 → dgetrf2 → dgetrf → dgesv), Cholesky factorization (dpotf2 → dpotrf2 → dpotrf → dposv), triangular operations (dlauu2 → dtrti2 → dtrtri, dtrtrs), and tridiagonal solvers (dgtts2, dptts2, dpttrs, dgttrs) turning stdlib into a production-ready LAPACK implementation for JavaScript.

---

Primary Goals

0. Unblock Fortran builds and harden existing JS-only packages

Before any LAPACK Fortran implementation can compile cleanly, @stdlib/blas/base/lsame must be merged as a complete stdlib package. lsame performs case-insensitive character comparison and is called by virtually every LAPACK routine that accepts character parameters (UPLO, TRANS, SIDE, DIAG). Verified by reading the actual Fortran source from Netlib, the following 13 routines in the main 35 scope contain a CALL LSAME or function reference: dlaset, dlacpy, dlamch, dgetrs, dpotf2, dpotrf, dpotrs, dposv, dlauu2, dtrti2, dtrtri, dtrtrs, dppequ. Without lsame as a proper stdlib package, the build system's manifest dependency resolver cannot link any of these Fortran addons. (The stretch-goal routines dlarf1f, dpptrf, dpptrs, dlasyf, dsyconv, dsyswapr also call LSAME, bringing the total to 19 routines across main scope and stretch goals so lsame unblocks the full future roadmap as well.)

There is an open PR (#2274) that adds only a bare lsame.f file with no package structure. Delivering @stdlib/blas/base/lsame as a complete stdlib package (Fortran source, C wrapper, manifest.json, binding.gyp, package.json, tests, benchmarks) is the first concrete task scoped to the community bonding period so the Fortran path is fully unblocked before Week 1 begins.

Once lsame is merged, Phase 1 immediately adds C and Fortran layers to the existing JS-only auxiliary LAPACK packages. The specific Fortran dependency structure, verified from Netlib source, is:

• Truly standalone (no external Fortran calls): dlaswp, iladlc, iladlr, dgttrf, dpttrf
• Needs only lsame: dlaset, dlacpy
• Needs lsame + dlamc3 (internal): dlamch
• Needs dlamch + disnan: dlapy2, dlapy3
• Needs dlamch + dladiv1/2 (internal): dladiv
• Needs LA_CONSTANTS + LA_XISNAN modules: dlassq (uses Fortran module interface)

Note: dge-trans (stdlib-specific, no Netlib counterpart) and dlarf1f (difficulty 4, needs LSAME + full BLAS L2 set) are kept as stretch goals outside the main 35.

1. Implement and deliver missing prerequisite utilities: ilaenv, disnan, dgetrf2, dpotrf2

Verified against Netlib source, four routines are called by higher-level packages in this project's scope but do not yet exist in @stdlib/lapack/base:

• ilaenv: environment query returning block sizes (NB). Called by dpotrf, dtrtri, dpttrs, and dgttrs. For the JS implementation, returns a hardcoded block size (NB=64) which is correct blocking is optional, not a correctness concern. For C and Fortran, wraps LAPACK's ilaenv or provides a standalone implementation.
• disnan: IEEE NaN check (x /= x in Fortran). Called by dlapy2 and dpotf2. Trivially implemented in all three layers (JS: Number.isNaN, C: isnan(), Fortran: IEEE intrinsic).
• dgetrf2: recursive variant of LU factorization. Called by dgetrf. Implements the unblocked recursive algorithm using dgemm + dtrsm + dgetf2 on sub-blocks.
• dpotrf2: recursive variant of Cholesky factorization. Called by dpotrf. Implements the unblocked recursive algorithm using dsyrk + dgemm + dtrsm on sub-blocks.

These four packages will be delivered before their dependents are started.

2. Implement the LU factorization chain: dgetf2 → dgetrf2 → dgetrf → dgetrs → dgesv

This is the single most impactful chain in all of LAPACK. dgesv solves general linear systems Ax = B and is the routine that downstream linear algebra users will call most. The chain, with exact Netlib-verified dependencies:

• dgetf2: unblocked LU with partial pivoting calls IDAMAX (BLAS L1, finds pivot), DLAMCH (LAPACK aux, provides safe minimum for singularity guard), DSWAP (BLAS L1), DSCAL (BLAS L1), DGER (BLAS L2)
• dgetrf2: recursive blocked LU calls dgetf2, dgemm (BLAS L3), dtrsm (BLAS L3)
• dgetrf: driver for blocked LU calls dgetrf2, dlaswp, dtrsm, dgemm
• dgetrs: solve using LU factors calls LSAME, dlaswp, dtrsm
• dgesv: complete driver calls dgetrf, dgetrs

Each routine is delivered JS → C → Fortran, with C using cblas function calls for all BLAS operations.

3. Implement the Cholesky factorization chain: dpotf2 → dpotrf2 → dpotrf → dpotrs → dposv

For symmetric positive definite systems, Cholesky is numerically superior to LU. The chain, with exact Netlib-verified dependencies:

• dpotf2: unblocked Cholesky calls LSAME, DDOT (BLAS L1), DISNAN, DGEMV (BLAS L2), DSCAL (BLAS L1)
  • Note: dpotf2 calls DGEMV (not DSYR as one might assume from the algorithm description)
• dpotrf2: recursive Cholesky calls dpotf2, dsyrk (BLAS L3), dgemm (BLAS L3), dtrsm (BLAS L3)
• dpotrf: blocked Cholesky driver calls LSAME, ILAENV, dpotrf2, dsyrk, dgemm, dtrsm
• dpotrs: solve using Cholesky factors calls LSAME, DTRSM (BLAS L3)
• dposv: complete driver calls LSAME, dpotrf, dpotrs

4. Implement tridiagonal solvers: dgtts2, dptts2, dpttrs, dgttrs

The factorization packages dgttrf and dpttrf already exist as JS-only. This goal completes the solve half. Exact Netlib-verified dependencies:

• dgtts2: solves using general tridiagonal LU factors no external calls (pure scalar arithmetic); easiest Fortran implementation in the project
• dptts2: solves positive definite tridiagonal calls DSCAL (BLAS L1 only)
• dpttrs: driver calls ILAENV, dptts2
• dgttrs: driver calls ILAENV, dgtts2

5. Implement triangular inversion and solve: dlauu2 → dtrti2 → dtrtri → dtrtrs

dependencies:

• dlauu2: unblocked U·Uᵀ product calls LSAME, DDOT (BLAS L1), DGEMV (BLAS L2), DSCAL (BLAS L1)
• dtrti2: unblocked triangular inverse calls LSAME, DTRMV (BLAS L2), DSCAL (BLAS L1)
• dtrtri: blocked triangular inverse calls LSAME, ILAENV, dtrti2, DTRMM (BLAS L3), DTRSM (BLAS L3)
• dtrtrs: triangular solve calls LSAME, DTRSM (BLAS L3)

6. Register all new packages in the @stdlib/lapack/base namespace and ensure full test + benchmark coverage

Every new package must be wired into the namespace index, have unit tests covering column-major and row-major layouts, non-unit leading dimensions, INFO error paths (singularity detection, wrong UPLO/TRANS argument), zero-size matrices, and include benchmarks comparing the JavaScript path against the native C path.

Why this project?

LAPACK is the standard computational library underpinning virtually all serious numerical software NumPy, SciPy, Julia's LinearAlgebra, MATLAB, R, and others all call LAPACK under the hood. When a Python script calls np.linalg.solve, it's calling dgesv. When it calls np.linalg.cholesky, it's calling dpotrf. Without LAPACK, there is no practical foundation for dense linear algebra.

Stdlib has made good progress on BLAS, which gives us vector and matrix-vector operations. But LAPACK is the next layer it's what turns those primitives into solvers, factorizations, and eigenvalue routines. Right now, @stdlib/lapack/base has 14 packages, all JavaScript-only. That means no native performance, no Fortran reference implementations, and no support for the higher-level routines that applications actually need (dgesv, dpotrf, dtrtri).

This project is the natural continuation of the BLAS work. Now that BLAS Level 1 is nearly complete and Level 2/3 is in progress, LAPACK becomes the next critical layer. The dependency chain flows directly: BLAS provides the building blocks, and LAPACK assembles them into solvers that real users need.

I'm also in a good position to do this work. I've spent months getting familiar with stdlib's package structure the manifest/binding setup, how C/Fortran implementations are exposed through N-API, how test fixtures are generated. I also spent time digging into the actual Netlib Fortran source for this proposal, which confirmed several non-obvious dependencies (e.g., dpotf2 calls DGEMV not DSYR; dgetrf routes through dgetrf2 not dgetf2 directly) that directly inform the implementation order. That level of pre-work means I won't be discovering the dependency tree during the coding period.

Qualifications

• 70+ merged PRs in stdlib
• experience across JS, C, Fortran
• familiarity with N-API and native bindings
• selected for C4GT mentorship program (blockchain, govt OSS)
• SDE intern at Twigg (fintech)
• consistent contributor with experience in reviews and iteration

Prior art

The groundwork for LAPACK in stdlib has been started. The @stdlib/lapack/base namespace already has 14 d* packages (plus their s*, c*, z* counterparts where applicable), all with working JavaScript implementations. These were largely contributed by early contributors like Pranavchiku and Aman.

However, unlike the equivalent BLAS packages, none of the current LAPACK packages have C or Fortran source. This is partly because LAPACK routines depend on BLAS L2/L3 C implementations that themselves have been in progress. With C implementations of dtrsm, dgemm, dger, dsyrk now landing (via open PRs in the BLAS track), the LAPACK C layer is now unblockable.

The RFC tracking issue #2464 provides a comprehensive inventory of what LAPACK routines are needed. A LAPACK JS PR (#2483 for dlaswp) was the first step showing the package structure is already established. Several auxiliary routines (dlamch, dladiv, dlapy2, dlapy3) have also been implemented in JavaScript.

The lsame gap and its impact on LAPACK Fortran:

Just as lsame blocks all Level 2 and Level 3 BLAS Fortran builds, it blocks the majority of LAPACK Fortran builds too. Reading the actual Fortran source from Netlib, 13 of the 35 main-scope routines call LSAME directly (plus 6 stretch-goal routines, 19 total). The build system walks manifest.json dependency trees at link time without a proper @stdlib/blas/base/lsame package, every one of those addons fails to link. This is the first concrete deliverable of the community bonding period.

Verified dependency map (from Netlib Fortran source):

Existing Packages - Complete Dependency Audit

Package	JS	C	F	Fortran deps (non-intrinsic, non-XERBLA)	Needs lsame?
dlaswp	✅	⬜	⬜	-	No
iladlc	✅	⬜	⬜	-	No
iladlr	✅	⬜	⬜	-	No
dge-trans	✅	⬜	⬜	- (stdlib-specific, no LAPACK counterpart)	No
dgttrf	✅	⬜	⬜	- (XERBLA only)	No
dpttrf	✅	⬜	⬜	- (XERBLA only)	No
dlaset	✅	⬜	⬜	LSAME	Yes
dlacpy	✅	⬜	⬜	LSAME	Yes
dlamch	✅	⬜	⬜	LSAME, DLAMC3 (internal subprogram)	Yes
dlapy2	✅	⬜	⬜	DLAMCH, DISNAN	No (transitive via dlamch)
dlapy3	✅	⬜	⬜	DLAMCH	No (transitive via dlamch)
dladiv	✅	⬜	⬜	DLAMCH, DLADIV1/DLADIV2 (internal)	No (transitive via dlamch)
dlassq	✅	⬜	⬜	LA_CONSTANTS module, LA_XISNAN module	No
dlarf1f	✅	⬜	⬜	LSAME, ILADLC, ILADLR, DSCAL, DGEMV, DAXPY, DGER	Yes

New Prerequisite Utilities - Not Yet in @stdlib/lapack/base

Package	JS	C	F	Dependencies	Notes
ilaenv	➕	➕	➕	(pure query, no BLAS/LAPACK deps)	Block size query; JS implementation hardcodes NB=64
disnan	➕	➕	➕	-	NaN check; JS: Number.isNaN, C: isnan(), Fortran: IEEE intrinsic
dgetrf2	➕	➕	➕	dgetf2, DGEMM, DTRSM	Recursive LU; prereq for dgetrf
dpotrf2	➕	➕	➕	dpotf2, DSYRK, DGEMM, DTRSM	Recursive Cholesky; prereq for dpotrf

Missing Routines - LU Factorization Chain

Package	JS	C	F	Exact dependencies (from Netlib source)	Needs lsame?
dgetf2	➕	➕	➕	IDAMAX, DLAMCH, DSWAP, DSCAL, DGER	No
dgetrf2	➕	➕	➕	dgetf2, DGEMM, DTRSM	No
dgetrf	➕	➕	➕	dgetrf2, dlaswp, DTRSM, DGEMM	No
dgetrs	➕	➕	➕	LSAME, dlaswp, DTRSM	Yes
dgesv	➕	➕	➕	dgetrf, dgetrs	No (transitive via dgetrs)

Missing Routines - Cholesky Factorization Chain

Package	JS	C	F	Exact dependencies (from Netlib source)	Needs lsame?
dpotf2	➕	➕	➕	LSAME, DDOT, DISNAN, DGEMV, DSCAL	Yes
dpotrf2	➕	➕	➕	dpotf2, DSYRK, DGEMM, DTRSM	No
dpotrf	➕	➕	➕	LSAME, ILAENV, dpotrf2, DSYRK, DGEMM, DTRSM	Yes
dpotrs	➕	➕	➕	LSAME, DTRSM	Yes
dposv	➕	➕	➕	LSAME, dpotrf, dpotrs	Yes

Missing Routines - Triangular Inverse and Solve

Package	JS	C	F	Exact dependencies (from Netlib source)	Needs lsame?
dlauu2	➕	➕	➕	LSAME, DDOT, DGEMV, DSCAL	Yes
dtrti2	➕	➕	➕	LSAME, DTRMV, DSCAL	Yes
dtrtri	➕	➕	➕	LSAME, ILAENV, dtrti2, DTRMM, DTRSM	Yes
dtrtrs	➕	➕	➕	LSAME, DTRSM	Yes

Missing Routines - Tridiagonal Solvers

Package	JS	C	F	Exact dependencies (from Netlib source)	Needs lsame?
dgtts2	➕	➕	➕	- (pure scalar arithmetic, no external calls)	No
dptts2	➕	➕	➕	DSCAL (BLAS L1 only)	No
dpttrs	➕	➕	➕	ILAENV, dptts2	No
dgttrs	➕	➕	➕	ILAENV, dgtts2	No

Missing Routines - Tier 3 (Scaling Auxiliaries, in main 35)

Package	JS	C	F	Exact dependencies (from Netlib source)	Needs lsame?
dpoequ	➕	➕	➕	- (XERBLA only)	No
dppequ	➕	➕	➕	LSAME	Yes

Stretch Goals (outside main 35 scope)

Package	Description	Exact dependencies	Notes
dptcon	Tridiagonal condition estimate	IDAMAX	Move here - lower priority
dlarf1f C+F	Householder reflection	LSAME, ILADLC, ILADLR, DSCAL, DGEMV, DAXPY, DGER	JS exists; difficulty 4
dge-trans C+F	Matrix transpose	- (stdlib-specific)	Not standard LAPACK
dpptrf	Packed Cholesky	LSAME, DDOT, DTPSV, DSCAL, DSPR	Needs BLAS L2 (DTPSV, DSPR) PRs first
dpptrs	Packed Cholesky solve	LSAME, DTPSV	Depends on dpptrf
dlasyf	Partial sym factorization	LSAME, IDAMAX, DCOPY, DGEMV, DSWAP, DSCAL, DGEMMTR	DGEMMTR is non-standard BLAS extension
dsyconv	Sym storage conversion	LSAME	Low impact
dsyswapr	Sym row/col swap	LSAME, DSWAP	Low impact

Legend: ✅ Done · ⬜ Missing · 🔄 PR Open · ➕ To Be Added
BLAS calls in UPPERCASE (DGEMM, DTRSM); LAPACK calls in lowercase (dgetf2, dlaswp)

---

Strategy and Planning

The core challenge in LAPACK is that routines form dependency chains a high-level driver like dgesv is only as solid as the chain beneath it. Having verified each dependency from Netlib source (not from algorithm descriptions), the exact chains are:

lsame (CB prereq)
 └── enables Fortran for: dlaset, dlacpy, dlamch, dgetrs, dpotf2, dpotrf,
     dpotrs, dposv, dlauu2, dtrti2, dtrtri, dtrtrs, dlarf1f, dppequ, dpptrf ...

disnan ─── dpotf2
dlamch ─── dgetf2 ──────────── dgetrf2 ─── dgetrf ─── dgetrs ─── dgesv
dlaswp ┘                                └── dgetrf ┘
iladlc/r ─ dlarf1f
ilaenv ──── dpotrf, dtrtri, dpttrs, dgttrs

dpotf2 ─── dpotrf2 ─── dpotrf ─── dpotrs ─── dposv
dlauu2 ──────────────── dtrtri
dtrti2 ┘
dgttrf ─── dgtts2 ─── dgttrs
dpttrf ─── dptts2 ─── dpttrs

My strategy is:

1. Implement complete chains bottom-up not individual routines in isolation
2. For the JS layer: validate each implementation against LAPACK reference output before moving to C
3. For the C layer: use cblas function calls for all BLAS sub-operations
4. For the Fortran layer: use free-form Fortran 95, following reference LAPACK style exactly
5. C implementations of routines that call only scalar BLAS (L1) can be done independently of BLAS L3 C progress only dgetrf2, dpotrf2, and the DTRSM/DGEMM callers need the BLAS L3 C implementations that are currently in PRs

---

Prioritization

Routines are prioritized by (a) real-world usage frequency, (b) their unblocking value delivering a package that enables five others is worth more than one that enables zero, and (c) difficulty relative to the value delivered. All dependencies are from verified Netlib source.

Difficulty scale: 1 = trivial · 2 = simple · 3 = moderate · 4 = complex · 5 = expert

---

Tier 1 - Critical

Community bonding: lsame, ilaenv, disnan

Priority	Package	Description	Difficulty	Notes
CB-1	lsame (in @stdlib/blas/base)	Case-insensitive char compare	1	Hard prereq for 13 main-scope + 6 stretch = 19 total Fortran addons
CB-2	ilaenv	Block size query	2	Prereq for dpotrf, dtrtri, dpttrs, dgttrs
CB-3	disnan	IEEE NaN check	1	Prereq for dlapy2, dpotf2

Truly standalone auxiliary packages (no Fortran deps)

Priority	Package	Description	Difficulty	Notes
1	dlaswp	Row interchange	2	Prereq for dgetf2, dgetrf; no Fortran deps
2	iladlc	Last non-zero column index	1	Prereq for dlarf1f
3	iladlr	Last non-zero row index	1	Prereq for dlarf1f
4	dgttrf	General tridiagonal LU (C+F)	3	JS exists; XERBLA only
5	dpttrf	Pos-def tridiagonal LU (C+F)	3	JS exists; XERBLA only
6	dlaset	Initialize matrix	1	Needs lsame for Fortran
7	dlacpy	Copy matrix	1	Needs lsame for Fortran
8	dlamch	Machine constants	2	Needs lsame; prereq for dlapy2, dlapy3, dladiv, dgetf2
9	dlapy2	sqrt(x²+y²)	1	Needs dlamch + disnan
10	dlapy3	sqrt(x²+y²+z²)	1	Needs dlamch
11	dladiv	Safe complex division	2	Needs dlamch; dladiv1/2 are internal subprograms
12	dlassq	Scaled sum of squares	2	Needs LA_CONSTANTS/LA_XISNAN Fortran modules

LU factorization chain

Priority	Package	Level	Description	Difficulty	Exact deps
13	dgetf2	aux	Unblocked LU + partial pivoting	3	IDAMAX, DLAMCH, DSWAP, DSCAL, DGER
14	dgetrf2	aux	Recursive LU	4	dgetf2, DGEMM, DTRSM
15	dgetrf	factor	Blocked LU driver	4	dgetrf2, dlaswp, DTRSM, DGEMM
16	dgetrs	solver	Solve with LU factors	3	LSAME, dlaswp, DTRSM
17	dgesv	driver	General linear system	2	dgetrf, dgetrs

---

Tier 2 - High

Tridiagonal solvers (easiest full chain no BLAS L3 deps)

Priority	Package	Description	Difficulty	Exact deps
18	dgtts2	Solve general tridiagonal	2	none (pure scalar)
19	dgttrs	General tridiagonal driver	2	ILAENV, dgtts2
20	dptts2	Solve pos-def tridiagonal	2	DSCAL (BLAS L1)
21	dpttrs	Pos-def tridiagonal driver	1	ILAENV, dptts2

Cholesky factorization chain

Priority	Package	Level	Description	Difficulty	Exact deps
22	dpotf2	aux	Unblocked Cholesky	3	LSAME, DDOT, DISNAN, DGEMV, DSCAL
23	dpotrf2	aux	Recursive Cholesky	4	dpotf2, DSYRK, DGEMM, DTRSM
24	dpotrf	factor	Blocked Cholesky	4	LSAME, ILAENV, dpotrf2, DSYRK, DGEMM, DTRSM
25	dpotrs	solver	Solve with Cholesky factors	2	LSAME, DTRSM
26	dposv	driver	SPD linear system	2	LSAME, dpotrf, dpotrs

---

Tier 3 - Medium

Triangular inversion and solve

Priority	Package	Description	Difficulty	Exact deps
27	dlauu2	Unblocked U·Uᵀ product	3	LSAME, DDOT, DGEMV, DSCAL
28	dtrti2	Unblocked triangular inverse	3	LSAME, DTRMV, DSCAL
29	dtrtri	Blocked triangular inverse	4	LSAME, ILAENV, dtrti2, DTRMM, DTRSM
30	dtrtrs	Triangular solve	2	LSAME, DTRSM

Scaling auxiliaries

Priority	Package	Description	Difficulty	Exact deps
31	dpoequ	SPD row/col equilibration	2	(XERBLA only)
32	dppequ	Packed SPD scaling	2	LSAME

---

Summary by Tier

Tier	Routines	Avg Difficulty	End-to-End Deliverable
CB	3 (lsame, ilaenv, disnan)	1.3	Unblocks all Fortran addons
1	17	2.7	C+F for all auxiliaries; complete LU chain (dgesv)
2	9	2.8	Complete tridiagonal + Cholesky chains (dposv)
3	6	2.8	Triangular inversion (dtrtri) + scaling auxiliaries
Stretch	8	3.5	dlarf1f, packed Cholesky, sym routines (time permitting)

Main scope: 35 routines across JS, C, and Fortran
Stretch: 8 additional routines if ahead of schedule

Commitment

My summer break begins around mid-May, which aligns well with the GSoC coding period. During this time, I’ll be able to work full-time (~40 hours/week) without any other major commitments.

Once the semester resumes towards the end of July, I expect to continue contributing around 25–30 hours/week alongside coursework.

Since I’ve already been actively contributing to stdlib for the past few months, I’m comfortable with the workflow and plan to stay consistent throughout the program. I’ll also be regularly communicating progress, sharing updates, and incorporating feedback from mentors.

Overall, I don’t anticipate any conflicting commitments during the GSoC period.

Schedule

Assuming a 12 week schedule,

During the community bonding period, I'll align with mentors, refine scope, clean up open PRs, and deliver the three hard prerequisites: lsame (as a complete stdlib package in @stdlib/blas/base this unblocks Fortran for 19 LAPACK routines), ilaenv, and disnan. I'll also set up a local LAPACK reference test harness using Netlib output, so correctness validation is ready from Week 1.

Week	Focus	Packages	Implementation
CB	Prereqs + setup	lsame (full stdlib pkg), ilaenv, disnan; reference test harness	Prereqs
W1	Aux hardening (1/2)	dlaswp C+F, iladlc C+F, iladlr C+F, dlaset C+F, dlacpy C+F	Add C + Fortran
W2	Aux hardening (2/2)	dlamch C+F, dlapy2 C+F, dlapy3 C+F, dladiv C+F, dlassq C+F, dgttrf C+F, dpttrf C+F	Add C + Fortran
W3	Tridiagonal solvers	dgtts2, dgttrs, dptts2, dpttrs	JS → C → F
W4	LU chain (1/2)	dgetf2, dgetrf2	JS → C → F
W5	LU chain (2/2)	dgetrf, dgetrs, dgesv	JS → C → F
W6	Midterm Evaluation	All Tier 1 complete	Buffer + Fortran polish
W7	Cholesky chain (1/2)	dpotf2, dpotrf2	JS → C → F
W8	Cholesky chain (2/2)	dpotrf, dpotrs, dposv	JS → C → F
W9	Triangular ops (1/2)	dlauu2, dtrti2, dtrtrs	JS → C → F
W10	Triangular ops (2/2)	dtrtri	JS → C → F
W11	Scaling + stretch start	dpoequ, dppequ; begin dlarf1f C+F if on track	JS → C → F
W12	Final + buffer	Namespace wiring, polish, stretch (dptcon, dlarf1f)	Wrap up

Notes:

• The community bonding period is a 3 week period built into GSoC to help you get to know the project community and participate in project discussion. This is an opportunity for you to setup your local development environment, learn how the project's source control works, refine your project plan, read any necessary documentation, and otherwise prepare to execute on your project project proposal.
• Usually, even week 1 deliverables include some code.
• By week 6, you need enough done at this point for your mentor to evaluate your progress and pass you. Usually, you want to be a bit more than halfway done.
• By week 11, you may want to "code freeze" and focus on completing any tests and/or documentation.
• During the final week, you'll be submitting your project.

Related issues

stdlib-js/stdlib#2464

#95

Checklist

• I have read and understood the Code of Conduct.
• I have read and understood the application materials found in this repository.
• I understand that plagiarism will not be tolerated, and I have authored this application in my own words.
• I have read and understood the patch requirement which is necessary for my application to be considered for acceptance.
• I have read and understood the stdlib showcase requirement which is necessary for my application to be considered for acceptance.
• The issue name begins with [RFC]: and succinctly describes your proposal.
• I understand that, in order to apply to be a GSoC contributor, I must submit my final application to https://summerofcode.withgoogle.com/ before the submission deadline.