[RFC]: add support for low-level singular value decomposition via LAPACK

[prajjwalbajpai]

Full name

Prajjwal Bajpai

University status

Yes

University name

Indian Institute of Technology (BHU), Varanasi

University program

Mechanical Engineering

Expected graduation

2027

Short biography

I am a third year B.Tech. student at the Indian Institute of Technology (BHU), Varanasi doing Mechanical Engineering. I enjoyed working with computers from an early age and was good at mathematics, which led me to software development. I have experience with Python, C, C++, HTML/CSS, TypeScript, JavaScript and its various frameworks like React, Express.js and more.

I completed courses like MA-101(Real Analysis), MA-102 (Linear Algebra & Calculus), MA-201 (Numerical Techniques) and MA-202 (Probability and Statistics) during my college years which give me a strong mathematical foundation. In the course CSE-530 (Information Security) I learned about PRNGs, RSA encryption, and digital signatures. I have explored Machine Learning and Deep Learning in depth from basic algorithms like linear regression, to advanced models like transformers, with an emphasis on the mathematical foundations as well as implementation.

I enjoy developing a deep understanding of the systems I work with rather than simply memorizing concepts. Recently, I have been exploring low-level programming to better understand how software operates closer to the hardware.

Timezone

Indian Standard Time (UTC +5:30)

Contact details

email:prajjwal8166@gmail.com github:prajjwalbajpai

Platform

Linux

Editor

I use Visual Studio Code. It has a large, active community and a rich extension marketplace, plus excellent built-in support for debugging, Git, and remote development. I’m also highly familiar with it as I wrote my first “Hello World!” in VSCode six years ago.

Programming experience

I have primarily worked with Python, JavaScript, and C++, and have experience building and experimenting with multiple machine learning and deep learning models. I’ve also participated in several competitions. My strongest learning has come from hands on projects that I built or contributed to.

• Exam Helper: A tool which can help students prepare for their exams by providing notes and previous year questions. This tool is based on the RAG-LLM framework and building it was a great experience for me to learn agentic AI and tools like LangGraph.

• Hackathon Scraper: A platform that aggregates details of all the tech hackathons that are live and upcoming so that users never miss a hackathon. Built by me and my peers at my college’s programming club, this project taught me web scraping, scheduling, and basic deployment.

• Vehicle Dashboard: A dashboard for tracking mileage and fuel spending for older vehicles. Implemented a simple UI and data pipeline to log trips and costs.

JavaScript experience

I have a couple of years of practical JavaScript experience primarily in web development. I’ve built full-stack projects (React frontends + Express/Node backends), and implemented pipelines for LLM based tools.

My favorite feature of JavaScript is its vast ecosystem, npm, Node, and browser tooling. This makes JavaScript well suited for rapid prototyping and scalable application development.

I am not a fan of JavaScript’s single Number type based on IEEE-754 double-precision floating point. While this simplifies the language, it can introduce issues such as precision loss and special values like NaN or ±0. In contrast, languages like C/C++ provide more explicit control over numeric types (e.g., float, double, long double) and memory layout. To address this limitation, stdlib uses typed ndarray with an explicit dtype and supporting helpers. This allows users to choose the underlying data type, while the arrays are backed by JavaScript TypedArray buffers. As a result, values are stored with a well-defined representation rather than relying on JavaScript’s generic Number type.

Node.js experience

I have practical experience using Node.js primarily for web development (Express backends, REST APIs, npm-based tooling, and full-stack projects). I’m comfortable with asynchronous patterns (callbacks, Promises, async/await), request/response middleware, working with Buffer/streams, and debugging Node apps.

More recently, contributing to stdlib-js deepened my understanding of Node’s runtime and performance characteristics. I initially used Node.js mainly for web development, but implementing LAPACK routines gave me a much stronger grasp of Node’s lower-level capabilities.

C/Fortran experience

I had an introductory programming course (CSO101) in my first semester where I learned C fundamentals, pointers, memory management, and basic data structures. My main practical experience comes from contributing to stdlib-js, particularly while working on refactoring code to use dynamic memory allocation and implementing several BLAS routines in C. It gave me strong confidence in my ability to work on numeric, systems-level code.

I have also studied the basics of Fortran during my LAPACK work, which helps when reading and porting Fortran routines and testing my implementation against the Fortran one.

Interest in stdlib

I’m interested in contributing to stdlib because it brings numerical and scientific tools to JavaScript, which matches my interests in low-level numeric code. Working on stdlib lets me tackle systems-level problems (memory/strides/performance) while producing libraries other developers can actually use.

My favorite feature is the ndarray API. Its explicit support for strides, offsets, and multiple storage orders (row-/column-major) makes it possible to express Fortran style memory layouts in JavaScript and C.

I also value the project’s beginner-friendly culture and active maintainers, who provide constructive feedback and patiently answer questions (including basic ones). This makes stdlib a great place to contribute and learn.

Version control

Yes

Contributions to stdlib

I first learned about stdlib in 2025 and started contributing soon after. I also made a proposal for GSoC with stdlib last year. Since December last year, I have been contributing more regularly and have opened 112 pull requests so far, working across different parts of the codebase including BLAS routines, LAPACK related work, tests, and refactoring tasks.

While working on the refactoring to use dynamic memory allocation issue, I experimented with writing a Bash script to automate the process of creating a PR. However, since this issue was identified as a beginner-friendly task and not urgent, I did not run the script blindly across the entire repository. Instead, I applied it cautiously to a small subset of BLAS routines and manually verified the results before submitting changes.

I have worked on the following things:

• Refactor and add protocol support to packages in stats/base/*.
• Improve doctests for complex number instances. (Issue#8641)
• Refactor benchmarks to use string interpolation. (Issue#8647)
• Replace static memory allocation of large arrays in C benchmarks with dynamic memory allocation. (Issue#8643)
• JavaScript implementation of various LAPACK routines.
• C implementation of BLAS routines. (Issue#2039)

Through these contributions, I have become familiar with the repository structure, coding standards, review process, and the numerical computing patterns used throughout the project. I have also helped guide fellow contributors interested in LAPACK by sharing my understanding of the routines and the implementation process.

My commits to stdlib
My merged PRs
My open PRs

stdlib showcase

For the stdlib showcase, I have implemented a neural network using stdlib.

Link to showcase repository

This project demonstrates how the stdlib ecosystem can be used to build a small machine learning pipeline in Node.js, being a JavaScript native alternative to NumPy for web development workflows. The project implements a simple feedforward neural network and trains it on the "UCI Red Wine Quality" dataset. This project leverages several stdlib modules for numerical computing and data processing. In particular, it uses stdlib/blas/base/ddot for matrix-vector multiplications, stdlib/random/base/normal for He-initialization of network weights, stdlib/stats/base/mean and stdlib/stats/base/variance for standardization, and stdlib/math/base/special functions such as exp and ln for implementing softmax and cross-entropy loss. The implementation uses Float64Array typed arrays throughout to ensure compatibility with BLAS routines.

The project also includes a small benchmark comparing the time taken per forward pass using stdlib routines against a vanilla JavaScript implementation using Math functions and standard JavaScript arrays. My showcase demonstrates how stdlib modules can be combined to build higher level numerical and machine learning functionality in JavaScript, while being faster than the vanilla implementation.

Goals

For this project, I propose a two phase plan to do the JavaScript implementation of the following routines under Singular Value Decomposition (SVD): Standard SVD driver, A = UΣV^H :

1. dgesvd (DGESVD computes the singular value decomposition (SVD) for GE matrices).
2. dgesvdq (DGESVDQ computes the singular value decomposition (SVD) with a QR-Preconditioned QR SVD Method for GE matrices ).

I have chosen the SVD branch as many of its dependent routines are already complete, and it is important for many machine learning algorithms (for eg. Principal Component Analysis (PCA)) and thus, this project provides the core numerical primitive required to build higher level statistical and machine learning utilities in JavaScript in the future.

The Phase-1 of the project would deal with the completion of dgesvd and all of its dependencies. The Phase-2 would deal with the completion of dgesvdq and all of its dependencies (apart from the dgesvd dependencies as they would have already been completed). I will allot 75% of the project length to Phase-1 (through Week-10), and the remaining time would be for Phase-2.

The current status of the dependencies of dgesvd. (Routines marked in green are merged or have open PRs, routines marked in red are not required (at least for the JavaScript implementation), white routines are those I will work on.)

The status of the dependencies of dgesvdq after the completion of dgesvd:

The BLAS dependencies for the routines along with the status of their JS implementation:

• daxpy (Complete)
• dcopy (Complete)
• dgemm (Complete)
• dgemv (Complete)
• dger (Complete)
• dnrm2 (Complete)
• drot (Complete)
• dscal (Complete)
• dtrmm (Open PR #7366)
• lsame (Not needed as we have @stdlib/string/lowercase)
• idamax (Complete)

This implies that I have 26 routines in Phase-1 and 7 routines in Phase-2.

The main target of the project is Phase-1 but Phase-2 is just an add-on for the extra time that is there, I would call this project a success if all the work of Phase-1 is complete that is the bare minimum I am planning. Phase-2 is not the main target but if everything goes right we can have two branches of SVD complete in LAPACK. I have discussed this in more detail in the schedule part of the proposal.

The JavaScript implementation of each routine consists of the following files according to the conventions at stdlib:

routine/
├── benchmark/
│   ├── benchmark.js
│   └── benchmark.ndarray.js
├── docs/
│   └── types/
│       ├── index.d.ts
│       ├── test.ts
│       └── repl.txt
├── examples/
│   └── index.js
├── lib/
│   ├── base.js
│   ├── routine.js
│   ├── index.js
│   ├── main.js
│   └── ndarray.js
├── test/
│   ├── test.routine.js
│   ├── test.js
│   └── test.ndarray.js
├── package.json
└── README.md

This list deals with the core implementation, tests, benchmarks, examples and all the documentation required for each routine. Apart from this, some routines might need helper or utility functions which would be implemented on demand. While porting the Fortran code into stdlib, there are two key changes, first, Fortran uses 1-based indexing, whereas JavaScript uses 0-based indexing. Second, Fortran only has column-major storage of matrices, whereas stdlib supports both row-major and column-major storage of matrices. This is a major improvement over the standard Fortran implementation which helps with wider usage of LAPACK routines.

For the most optimised implementation of operations on row-major and column-major the technique of loop interchange is frequently used on multi-dimensional arrays. This takes advantage of the fact that when we access elements from an array, the CPU will retrieve an entire block of data from memory to cache due to tiling (or blocking), which partitions computations into smaller chunks that fit into cache, improving cache reuse and overall memory access efficiency. Thus, accessing elements in the order of their storage would help in fetching elements from cache which is faster than accessing elements from the main memory (I have given an example below). This optimization is often combined with other compiler and algorithmic techniques such as loop unrolling, which reduces loop overhead and increases a program's speed by reducing or eliminating instructions that control the loop.

An example of implementing an LAPACK subroutine in JavaScript following the standards used by stdlib. I have taken the example of the dgetc2 routine which computes the LU factorization with complete pivoting of the general n-by-n matrix.

In the Fortran code, the subroutine is called as follows:

program dgetc2_ex
  implicit none

  integer :: n, lda, info

  double precision :: a(3,3)
  integer :: ipiv(3), jpiv(3)

  n = 3
  lda = n

  a = reshape( (/ 1.0d0, 2.0d0, 3.0d0, 4.0d0, 5.0d0, 6.0d0, 7.0d0, 8.0d0, 10.0d0 /), &
               shape(a) )

  call dgetc2( n, a, lda, ipiv, jpiv, info )

end program dgetc2_minimal

This subroutine has the following parameters:

1. N: The order of the matrix A. [in]
2. A: A double precision array, dimension (LDA, N). [in,out]
3. LDA: The leading dimension of the array A. [in]
4. IPIV: The pivot indices for rows. [out]
5. JPIV: The pivot indices for columns. [out]
6. INFO: The status of execution. [out]

Now, using this routine in stdlib would look like this:

var Float64Array = require( '@stdlib/array/float64' );
var Int32Array = require( '@stdlib/array/int32' );

var A = new Float64Array( [ 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 10.0 ] );
var IPIV = new Int32Array( 3 );
var JPIV = new Int32Array( 3 );

dgetc2( 'column-major', 3, A, 3, IPIV, JPIV );
// A => <Float64Array>[ 10, 0.7, 0.8, 3, ~-1.1, ~0.36, 6, ~-0.2, ~0.27 ]
// JPIV => <Int32Array>[ 3, 3, 3 ]
// IPIV => <Int32Array>[ 3, 3, 3 ]

The dgetc2 function in stdlib has the following parameters:

dgetc2( order, N, A, LDA, IPIV, JPIV )

Here, order describes the storage method of the matrix in array A i.e. row-major or column-major. Also, stdlib has an ndarray API for each routine/function which takes the following parameters:

dgetc2.ndarray( N, A, strideA1, strideA2, offsetA, IPIV, strideIPIV, offsetIPIV, JPIV, strideJPIV, offsetJPIV ) 

Note that we can set the strides and offsets of all arrays, which gives the user better control over the storage method of the matrices in arrays.

For this particular subroutine, the loop interchange is implemented as follows:

        // Find max element in matrix A
		xmax = 0.0;

		ix1 = offsetA + ( i*( strideA1 + strideA2 ) ); // Index of `A( i, i )`

		if ( isRowMajor( [ strideA1, strideA2 ] ) ) {
			dx0 = strideA2;
			dx1 = strideA1 - ( N*strideA2 ) + ( i*dx0 );
			for ( i1 = i; i1 < N; i1++ ) {
				for ( i0 = i; i0 < N; i0++ ) {
					if ( abs( A[ ix1 ] ) >= xmax ) {
						xmax = abs( A[ ix1 ] );
						ipv = i1;
						jpv = i0;
					}
					ix1 += dx0;
				}
				ix1 += dx1;
			}
		} else { // column-major
			dx0 = strideA1;
			dx1 = strideA2 - ( N*strideA1 ) + ( i*dx0 );
			for ( i1 = i; i1 < N; i1++ ) {
				for ( i0 = i; i0 < N; i0++ ) {
					if ( abs( A[ ix1 ] ) >= xmax ) {
						xmax = abs( A[ ix1 ] );
						ipv = i0;
						jpv = i1;
					}
					ix1 += dx0;
				}
				ix1 += dx1;
			}
		}		

For reference, here is the Fortran implementation of the same code block:

* Find max element in matrix A
xmax = zero
DO 20 jp = i, n
   DO 10 ip = i, n
      IF( abs( a( ip, jp ) ).GE.xmax ) THEN
         xmax = abs( a( ip, jp ) )
         ipv = ip
         jpv = jp
      END IF
   10 CONTINUE
20 CONTINUE

Note how the stdlib implementation exchanges the inner and outer loop depending upon whether the matrix A is stored column-major or row-major. Also, since stdlib has support for varied strides and offsets, we are pre-computing the index of the element to be accessed, which is more efficient than calculating the index every time.

Apart from what I have planned, there would be numerous issues and bugs that cannot be predicted beforehand. It is a good idea to take fixing them into account as a part of the goals of this project.

Why this project?

While learning various Machine Learning algorithms, we are not taught how the mathematical equations and methods are implemented in code. LAPACK bridges this gap between classroom mathematics and practical implementation. It helps me understand how to implement various mathematical operations and that too in such a way that is optimised and fast.

Beyond Machine Learning, LAPACK (or, linear algebra) is used in countless software applications be it Finite Element Analysis (used in Mechanical Engineering) or Parallel Computing for Graphics Processing. This gives me a great opportunity to learn and tackle problems at the grassroots level of software and would definitely help me in my future as a software developer. This project would also strengthen the linear algebra capabilities of stdlib-js, as many mathematical functions and operations rely on linear algebra, making LAPACK an important foundation for the future growth of the library.

Qualifications

I have completed the Linear Algebra course during my engineering, which gives me a strong background in linear algebra. I have a strong interest in algorithms and data structures and hands on experience from competitive programming and algorithmic problem solving. Which taught me to decompose complex problems, and implement correct, efficient code skills that directly transfer to LAPACK development.

I have also worked on various LAPACK routines. I began with simple routines and then picked up harder routines where I learnt how to handle row-major and column-major storage of multi-dimensional arrays and loop interchange for optimised implementation. I studied the basics of Fortran and reading and implementing multiple routines has helped me getting acclimatized to LAPACK routines in Fortran.

I have worked on the following routines:

1. dlartgp
2. dlamrg
3. dgetc2
4. dla-gbrpvgrw

While understanding the LAPACK routine structure and dependencies, I developed the tool LAPACK-deps which generates all the dependencies of an LAPACK routine along with the dependency graph which is provided as a .dot file.

The main challenge I faced, was to build the dependency graph. The dependency graph on the netlib site is not always correct and it includes BLAS routines as well. To tackle this, I parsed each file and checked for any valid LAPACK routine name followed by ‘(‘ which would indicate that a routine is being called and is its dependency. This solution fixed the issue of encountering cycles while doing the topological sort of routines to get a valid working order. All the graphs and orders are stored in the same GitHub repository.

I also tried to organise a list of all LAPACK routines into a Google Sheet:
LAPACK-routines

Since it’s impractical to create a tracking issue for every LAPACK routine, this sheet would help maintainers and contributors track the status of each routine.

Prior art

The algorithms implemented in this project originate from LAPACK (Linear Algebra PACKage), the standard numerical linear algebra library used in scientific computing. LAPACK itself builds on the BLAS (Basic Linear Algebra Subprograms) interface and provides higher level routines built on top of the BLAS kernels. Many scientific programming organisations rely on LAPACK through language bindings rather than reimplementing the algorithms. For example, Python’s SciPy exposes LAPACK routines via its scipy.linalg module, Julia does it through LinearAlgebra.LAPACK module.

Unlike ecosystems such as Julia, SciPy, and MATLAB, which typically expose LAPACK through wrappers over compiled Fortran libraries, stdlib implements routines in modular JavaScript/C packages, enabling portable numerical computing, smaller dependency footprints, and seamless integration with the JavaScript ecosystem. This design is analogous to Go’s Gonum. which exposes a subset of LAPACK routines in Go through a well defined API, providing a native Go implementation along with optional bindings to optimized C/Fortran LAPACK.

First research paper of LAPACK

Scipy documentation for LAPACK

Matlab documentation for LAPACK

Julia documentation for LAPACK

Gonum LAPACK documentation

For this project, I will use the Netlib LAPACK documentation as the authoritative Fortran reference for latest implementation of each routine and follow recent implementation patterns used by the community. The LAPACKE C Interface to LAPACK is also a useful reference point providing a C wrapper around the original Fortran routines while supporting both column-major (Fortran-style) and row-major (C-style) memory layouts.

Lots of LAPACK routines are already implemented in stdlib, the RFC issue #2464(stdlib-js/stdlib#2464) tracks the status of routines under the Linear Solve branch. Apart from this, a great source of inspiration would be the GSoC 2025 project Add LAPACK bindings and implementations for linear algebra by Aayush Khanna to get the latest implementation method and procedures. My project can be treated as a continuation of this project from last year, but my focus would be on routines related to SVD only.

Commitment

I have my summer break from 9th May 2026 to 21st July 2026 and have no other commitments during this period. I can work full-time, dedicating 30-35 hours per week, which aligns well with the project’s estimated workload of 350 hours over 12 weeks.

For the weeks beyond 21st July, I will make the necessary arrangements to continue contributing. During the initial weeks of the semester, my course load will be relatively light, which will allow me to continue allocating time to the project. I am also comfortable working on weekends to keep the project on schedule and meet deadlines.

Schedule

As I previously discussed, I will be implementing a two-phase plan for this project. That means 26 routines for Phase-1 and 7 routines for Phase-2. I have created a spreadsheet of the order in which I will be doing the work. This order ensures that no two adjacent working packages depend on each other, so maintainers can review earlier PRs while I work on other routines and there are no blockages.

LAPACK routines order

I have also rated each routine on the basis of my prediction of the time required to implement them. Routines which have 2-D matrix operations take longer as we need to implement both row-major and column-major storage and they require more reviews due to loop-interchange operations. The final routine for each phase, that is, dgesvd and dgesvdq are very long and might even take upto a week to be completed.

Assuming a 12 week schedule,

Phase-1

• Community Bonding Period: From 11th May to 24th May, I will be working on the following routines -

1. dlasq6 (computes one dqd transform in ping-pong form)
2. dlasq5 (computes one dqds transform in ping-pong form)
3. dlasq4 (computes an approximation to the smallest eigenvalue using values of d from the previous transform)
4. dlasq3 (checks for deflation, computes a shift and calls dqds)

During this period, my main focus would be on getting in the flow of things, connecting with mentors and building the setup for fastest workflow so that I don’t need to worry about my setup later on.

• Week 1: I plan to work on the following routines –

1. dlabrd (reduces the first nb rows and columns of a general matrix to a bidiagonal form)
2. dgebd2 (reduces a general matrix to bidiagonal form using an unblocked algorithm)
3. dlasrt (sorts numbers in increasing or decreasing order)

• Week 2: I plan to work on the following routines –

1. dgeqr2 (computes the QR factorization of a general rectangular matrix using an unblocked algorithm)
2. dgelq2 (computes the LQ factorization of a general rectangular matrix using an unblocked algorithm)

• Week 3: I plan to work on the following routines –

1. dorgl2 (generates an m by n real matrix Q with orthonormal rows)
2. dorml2 (multiplies a general matrix by the orthogonal matrix from a LQ factorization determined by sgelqf (unblocked algorithm))

• Week 4: I plan to work on the following routines –

1. dlarft (forms the triangular factor T of a block reflector H = I – V * T * (V**H))
2. dgebrd (reduces a general real M-by-N matrix A to upper or lower bidiagonal form B by an orthogonal transformation: (Q**T) * A * P = B)
3. dlasq2 (computes all the eigenvalues of the symmetric positive definite tridiagonal matrix associated with the qd Array Z to high relative accuracy)

• Week 5: I plan to work on the following routines –

1. dgeqrf (computes a QR factorization of a real M-by-N matrix A)
2. dorgqr (generates an M-by-N real matrix Q with orthonormal columns, which is defined as the first N columns of a product of K elementary reflectors of order M)

• Week 6: (midterm) I will submit my project report to the mentors in parallel to working on the following routines –

1. dorglq (generates an M-by-N real matrix Q with orthonormal rows, which is defined as the first M rows of a product of K elementary reflectors of order N)
2. dgelqf (computes an LQ factorization of a real M-by-N matrix)

• Week 7: I plan to work on the following routines –

1. dormlq
2. dormqr
3. dlasq1 (computes the singular values of a real square bidiagonal matrix)

• Week 8: I plan to work on the following routines –

1. dlasr (applies a sequence of plane rotations to a general rectangular matrix)
2. dorgbr

• Week 9: I plan to work on the following routines –

1. dormbr
2. dbdsqr

• Week 10: I plan to work on the following routines –

1. dbdsqr
2. dgesvd

The dbdsqr routine is very lengthy for implementation so I might not be able to complete it within Week 9. Also dgesvd itself is very long and is very likely to be continued into Phase-2.

Phase-2

• Week 11: I plan to work on the following routines –

1. dlaqp2 (computes a QR factorization with column pivoting of the matrix block)
2. dlaqps (computes a step of QR factorization with column pivoting of a real m-by-n matrix A by using BLAS level 3)
3. dgeqp3 (computes a QR factorization with column pivoting of a matrix A: AP = QR using Level 3 BLAS)

• Week 12: I plan to work on the following routines –

1. drscl (multiplies a vector by the reciprocal of a real scalar)
2. dpocon (estimates the reciprocal of the condition number (in the 1-norm) of a real symmetric positive definite matrix using the Cholesky factorization)
3. dlapmt (performs a forward or backward permutation of the columns of a matrix)

• Final Week: I plan to complete all the pending work and try to get all the previous routines merged and write all the needed documentation. If time permits I would like to work on dgesvdq which is the final routine for Phase-2.

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

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

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.

[kgryte]

@prajjwalbajpai Thanks for this detailed proposal. A few comments:

1. For your dgetc2 example of loop interchange, avoid checking for isRowMajor within the innermost loop. If it is not possible to have a single nested loop for both row- and column-major, then it is best to simply split into separate loops with the conditional moved to the outside.
2. The LAPACK dep graphs look good. It would also be good to identify which BLAS routines are prerequisites so that we can prioritize getting those over the finish so you are not blocked.

Overall, this is a solid proposal.

[prajjwalbajpai]

@kgryte, thanks for the comments! I have addressed both the things you pointed out. If you get some time, please just take a quick glance at them.

[kgryte]

One additional note: I would rename your proposal to

Add support for low-level singular value decomposition via LAPACK