You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have questions about stdlib? Need help fixing a bug, figuring out what to do next, or just looking for feedback? Join our weekly office hours to connect with project maintainers, stay updated on the latest project news, and chat with other community members. This is a great opportunity to ask questions, share ideas, and engage directly with the stdlib team.
General advise for GSoC participants on the use of AI in contributions.
Why I advise against the use of AI to generate package tests. Instead: write manually (including copy-paste from similar packages + modify) and use test coverage reports to identify test coverage gaps.
For math/base/special/* single-precision implementations, we should not be adding single-precision packages which are missing requisite single-precision dependencies (e.g., floor2f requires log2f and, for tests, exp2f).
I have opened an issue #10365 related to the GSoC idea 7 mentioned in the ideas.md file. Which is discussing about the developing of a project test runner
Could you please review it and confirm whether my issue aligns correctly with the proposed idea and whether this approach is feasible?
I wanted to ask about the priorities for the “Add BLAS bindings and implementations for linear algebra” project.
Is the current focus of the organization on:
completing Level 2 BLAS routines,
implementing Level 3 routines in JavaScript, or
adding C implementations / WebAssembly bindings?
I read in previous discussions that the frontend implementation for Level 2 and Level 3 routines is currently blocked. Could you clarify what the main blocker is?
Also, if someone wants to contribute to C implementations or WebAssembly bindings for Level 2/3 routines, what would be a good reference or starting point?
For my GSoC proposal in idea#28 LAPACK, I have decided to go ahead with the SVD branch dgesvd. I have some doubts regarding the ilaenv routine and its dependencies:
From what I understand, ilaenv decides which parameters to use depending upon the system/environment. Do we need to implement it for JavaScript, or is there a better way? Also, if we do implement it, which of its dependencies would be required? I think lsame(can use functions in string) and ieeeck(JS guarantees IEEE-754 floating point behavior) might not be necessary.
Also, as a small follow-up from last week, whenever you get time, I’d really appreciate feedback on my dgetc2 LAPACK PR. I understand you are quite busy, but even one merged PR in LAPACK would really help strengthen my GSoC proposal.
C Doctest Annotation Design Question ( GSOC Idea )
I’m planning a C doctest framework modeled after our JS doctest system, and I need guidance on type/annotation design.
In JS doctests, we support rich runtime/type annotations like:
<Function>, <DoublyLinkedList>, <DataType>
<ndarray>, <Buffer>, <ArrayBuffer>
<Complex64>[ ... ], <Float64Array>[ ... ]
// throws <RangeError>
unions like // returns <number> || null
object-shape / wildcard forms like { 'a': true, ... }
In C, most APIs are:
scalar-return: double, int, bool
status-return: int, LAPACK_INT
in-place output via pointers: double *out, uint8_t *out
We also don’t have JS-style runtime instance identity for many of the above types.
What is the recommended C doctest strategy for return annotations? Other than basic c datatypes like float double etc support of what return datatype annotations should be there and some pointers on how to acheive that.
I'm planning to create number/uint64 package for 64 bit integer arithmetic and I need some feedback about some design decisions.
I'm representing an uint64 value as an array in the form of [high, low] 32-bit halves.
The package will have all the equivalent functions from number/uint32 as shown below
I also propose some more functions in addition to these like div, mod, shiftl, shiftr, and, or, xor, toString, toBigInt etc. The rationale here is that, since an uint64 value is represented in a composite structure (high-low halves), all the operations become composite as well.
I would like to clarify some questions regarding implementing ml algorithms:
Namespace for the user facing API?
ml/cluster/(d|s)kmeans/ctor
ml/cluster/kmeans/float64/ctor
common API for both f64 and f32 with a fn arg 'dtype' (ml/cluster/kmeans/ctor)
Should we follow the same namespace convention followed in sklearn?
For example, they keep both LogisticReg (classification) and LinearReg (regression) inside a namespace called linear_models.
Do we keep linear_models, or classification and regression?
Can I use ndarray ctor as a reference for implementing ctor for all the ml algorithms? Also should I have both high-level and low-level ctor?
Packages like kernel-betainc have lots of js files in lib, if we implement their C API should these have separate logical include header files or just one would suffice?
stdlib check-files and auto-lintfix and few workflows show failure instead of saying no changes to perform, is this expected?
Needed a bit of help on understanding BLAS C implementations, for example: why is there two c files like caxpy_cblas and caxpy?
Are all functions planned to be mapped, or will there be some kind of a prioritization or filtering step?
Can I discuss implementation details for specific functions starting from now? If so, who or where do I start the discussion?
Can I start implementing base functions from now or do I need to discuss the approach first? Even though most of them is straightforward.
If a function is so close to the array API, only difference is in the name and some optional arguments, do we create a total different base and user-facing API for it? Or create a user-facing API only which mimics the current version but adds the required modifications? Or modify the existing altogether?
For functions where scalars or arrays is expected, do we create 1 base version which deals with ndarrays only and broadcast scalars in the user-facing API or create a different base version which deals with scalars, for better memory and performance? I noticed that in assign for example, something similar to scalar-assign was commented as a TODO.
Will there be any parallel concerns regarding this idea going forward with other GSoC ideas regarding extending or creating new array types?
Just a final follow up note, regarding the where package that I was working on, I'll be finalizing the tests and benchmarks once I reach good point regarding Array API mapping and implementation details for each function, so it may wait for a while before asking for a review.
I would like some extra clarity on the linear algebra idea for GSoC.
Is a numpy and scipy like API the envisioned goal where the functions provided do "smart" things like input validation, automagically pick dot vs matrix-vector vs matrix-matrix product even though the function is matmul.
After analyzing the dependencies and numpy implementation, I believe a subset of the linear algebra APIs (JS and C) can be implemented in 12 weeks (dot, matmul, norm, qr, lu, det, inv, solve, cholesky). However, my question is whether I should go forward with this proposal or rather focus instead on purely implementing BLAS or LAPACK functions.
Activity
kgryte commentedon Mar 10, 2026
A few points from me:
math/base/special/*single-precision implementations, we should not be adding single-precision packages which are missing requisite single-precision dependencies (e.g.,floor2frequireslog2fand, for tests,exp2f).anoofmhd commentedon Mar 10, 2026
Hi @kgryte ,
I have opened an issue #10365 related to the GSoC idea 7 mentioned in the ideas.md file. Which is discussing about the developing of a project test runner
Could you please review it and confirm whether my issue aligns correctly with the proposed idea and whether this approach is feasible?
Thank you!
DivitJain26 commentedon Mar 10, 2026
Hello @kgryte
I wanted to ask about the priorities for the “Add BLAS bindings and implementations for linear algebra” project.
Is the current focus of the organization on:
I read in previous discussions that the frontend implementation for Level 2 and Level 3 routines is currently blocked. Could you clarify what the main blocker is?
Also, if someone wants to contribute to C implementations or WebAssembly bindings for Level 2/3 routines, what would be a good reference or starting point?
Thanks!
shubham220420 commentedon Mar 10, 2026
Just a check on :
These should be close to merging, thanks :)
prajjwalbajpai commentedon Mar 10, 2026
For my GSoC proposal in idea#28 LAPACK, I have decided to go ahead with the SVD branch
dgesvd. I have some doubts regarding theilaenvroutine and its dependencies:From what I understand,
ilaenvdecides which parameters to use depending upon the system/environment. Do we need to implement it for JavaScript, or is there a better way? Also, if we do implement it, which of its dependencies would be required? I thinklsame(can use functions instring) andieeeck(JS guarantees IEEE-754 floating point behavior) might not be necessary.Also, as a small follow-up from last week, whenever you get time, I’d really appreciate feedback on my
dgetc2LAPACK PR. I understand you are quite busy, but even one merged PR in LAPACK would really help strengthen my GSoC proposal.navyansh007 commentedon Mar 10, 2026
Please review on these PRs
These should be close to merging. Thanks!
officiallyanee commentedon Mar 10, 2026
Hi, if we can conclude the discussion on this issue about sincosf returning values outside [-1,1], it would be incredibly helpful.
Thanks!
nirmaljb commentedon Mar 10, 2026
Hi, I have encountered some CI/CD bugs, could you please look into them?
Om-A-osc commentedon Mar 10, 2026
C Doctest Annotation Design Question ( GSOC Idea )
I’m planning a C doctest framework modeled after our JS doctest system, and I need guidance on type/annotation design.
In JS doctests, we support rich runtime/type annotations like:
<Function>,<DoublyLinkedList>,<DataType><ndarray>,<Buffer>,<ArrayBuffer><Complex64>[ ... ],<Float64Array>[ ... ]// throws <RangeError>// returns <number> || null{ 'a': true, ... }In C, most APIs are:
double,int,boolint,LAPACK_INTdouble *out,uint8_t *outWe also don’t have JS-style runtime instance identity for many of the above types.
What is the recommended C doctest strategy for return annotations? Other than basic c datatypes like float double etc support of what return datatype annotations should be there and some pointers on how to acheive that.
impawstarlight commentedon Mar 10, 2026
I'm planning to create
number/uint64package for 64 bit integer arithmetic and I need some feedback about some design decisions.uint64value as an array in the form of [high, low] 32-bit halves.number/uint32as shown belowdiv,mod,shiftl,shiftr,and,or,xor,toString,toBigIntetc. The rationale here is that, since anuint64value is represented in a composite structure (high-low halves), all the operations become composite as well.I already have a working prototype of 64-bit addition and multiplication in my PR for PCG32
nakul-krishnakumar commentedon Mar 10, 2026
I would like to clarify some questions regarding implementing ml algorithms:
ml/cluster/(d|s)kmeans/ctorml/cluster/kmeans/float64/ctorml/cluster/kmeans/ctor)Should we follow the same namespace convention followed in sklearn?
For example, they keep both LogisticReg (classification) and LinearReg (regression) inside a namespace called
linear_models.Do we keep
linear_models, orclassificationandregression?Can I use ndarray ctor as a reference for implementing ctor for all the ml algorithms? Also should I have both high-level and low-level ctor?
Feedback on implementation sheet
Witty-31-06 commentedon Mar 10, 2026
LoayAhmed304 commentedon Mar 10, 2026
I would like to discuss some concerns regarding Array API compliance with ndarray GSoC idea:
basefunctions from now or do I need to discuss the approach first? Even though most of them is straightforward.assignfor example, something similar toscalar-assignwas commented as a TODO.Just a final follow up note, regarding the
wherepackage that I was working on, I'll be finalizing the tests and benchmarks once I reach good point regarding Array API mapping and implementation details for each function, so it may wait for a while before asking for a review.Thank you!
batpigandme commentedon Mar 10, 2026
Hey @nirmaljb,
The second one:
is a known issue. We need to update the version of R being used, since it's too old for the lintr package.
udaykakade25 commentedon Mar 10, 2026
Here's my timeline in mind: Notion Link
Need early review if we have some free time in the end :)
nirmaljb commentedon Mar 10, 2026
I would want some clarity.
In main.c and main.js, what should I do with that chunk of code?
https://github.com/stdlib-js/stdlib/pull/10805/changes#diff-da8e6992128d18423f7944aaffae87a33aaee8e8256419fd3efe5311b13d9b86
manit2004 commentedon Mar 10, 2026
can you please review this timeline once? sheets
dhruvan2006 commentedon Mar 10, 2026
I would like some extra clarity on the linear algebra idea for GSoC.
Is a
numpyandscipylike API the envisioned goal where the functions provided do "smart" things like input validation, automagically pick dot vs matrix-vector vs matrix-matrix product even though the function ismatmul.After analyzing the dependencies and numpy implementation, I believe a subset of the linear algebra APIs (JS and C) can be implemented in 12 weeks (dot, matmul, norm, qr, lu, det, inv, solve, cholesky). However, my question is whether I should go forward with this proposal or rather focus instead on purely implementing BLAS or LAPACK functions.
kgryte commentedon Mar 10, 2026
Thanks everyone!