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

[performant23]

Full name

</>

University status

</>

University name

</>

University program

</>

Expected graduation

</>

Short biography

</>

Timezone

</>

Contact details

</>

Platform

</>

Editor

</>

Programming experience

</>

JavaScript experience

</>

Node.js experience

</>

C/Fortran experience

</>

Interest in stdlib

</>

Version control

</>

Contributions to stdlib

</>

Goals

</>

Why this project?

</>

Qualifications

</>

Prior art

</>

Commitment

</>

Schedule

</>

Related issues

</>

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.
• 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.

[performant23]

</>

[performant23]

</>

[kgryte]

@performant23 Thank you for sharing a draft of your proposal; pushing forward the BLAS work is certainly high priority. A few comments:

1. A general comment regarding our use of Fortran/C/JavaScript for implementing BLAS interfaces. We retain Fortran implementations in order to have a high fidelity port of netlib. We use Freeform Fortran 95 to improve commenting and take advantage of improved language features. We reimplement in C, as gfortran is not commonly available on Windows platforms and compiling from C to WebAssembly is more straightforward. We reimplement in JavaScript in order to support native browser usage and as a fallback in case native add-on bindings are not compiled in Node.js.
2. You currently prioritize single-precision before double-precision. I'd revise that. Real-valued double-precision should take priority, followed by real-valued single-precision, then complex-valued double-precision, and then finally complex-valued single-precision. The rationale here is that real-valued double-precision will be the primary end-user dtype, so getting these finished should be higher priority.
3. Another thing that we provide are "generic" BLAS interfaces (e.g., gasum). These are necessary for supporting arrays having data types other than d, s, c, z. We cannot pass an Int32Array down to C, when the C routine expects double-precision. Hence, we provide JavaScript-only interfaces for handling arrays of any type, including accessor arrays. These packages are, however, straightforward, as usually a copy-paste of the double-precision JavaScript implementation.
4. One pre-requisite is implementing xerbla. This is necessary for handling error conditions in Level 2 and 3 routines.