Skip to content

Office Hours (2026-03-10) #88

Closed
Closed

Description

@kgryte

🌟 Join Us for Weekly Office Hours! 🌟

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.

Everyone is welcome—drop in and say hello!

Time

UTC Tue 10-Mar-2026 16:30 (04:30 PM):

Timezone Date/Time
US / Pacific Tue 10-Mar-2026 09:30 (09:30 AM)
US / Mountain Tue 10-Mar-2026 10:30 (10:30 AM)
US / Central Tue 10-Mar-2026 11:30 (11:30 AM)
US / Eastern Tue 10-Mar-2026 12:30 (12:30 PM)
EU / Western Tue 10-Mar-2026 16:30 (04:30 PM)
EU / Central Tue 10-Mar-2026 17:30 (05:30 PM)
EU / Eastern Tue 10-Mar-2026 18:30 (06:30 PM)
Moscow Tue 10-Mar-2026 19:30 (07:30 PM)
Chennai Tue 10-Mar-2026 22:00 (10:00 PM)
Hangzhou Wed 11-Mar-2026 00:30 (12:30 AM)
Tokyo Wed 11-Mar-2026 01:30 (01:30 AM)
Sydney Wed 11-Mar-2026 03:30 (03:30 AM)

or in your local time:

Links

Joining the meeting

Agenda

  • Have specific things to discuss? Please comment in the issue thread below to add specific items to the agenda.

Activity

  1. added
    Office HoursIssue announcing office hours and soliciting associated agenda items.
    on Mar 3, 2026
  2. kgryte commented on Mar 10, 2026

    @kgryte
    MemberAuthor

    A few points from me:

    1. General advise for GSoC participants on the use of AI in contributions.
    2. 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.
    3. 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).
  3. anoofmhd commented on Mar 10, 2026

    @anoofmhd

    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!

  4. DivitJain26 commented on Mar 10, 2026

    @DivitJain26
    Member

    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:

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

    Thanks!

  5. shubham220420 commented on Mar 10, 2026

    @shubham220420

    Just a check on :

    1. 9739
    2. 9857
    3. 9636
    4. 10067

    These should be close to merging, thanks :)

  6. prajjwalbajpai commented on Mar 10, 2026

    @prajjwalbajpai
    Member

    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:

    Image

    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.

  7. navyansh007 commented on Mar 10, 2026

    @navyansh007

    Please review on these PRs

    These should be close to merging. Thanks!

  8. officiallyanee commented on Mar 10, 2026

    @officiallyanee
    Member

    Hi, if we can conclude the discussion on this issue about sincosf returning values outside [-1,1], it would be incredibly helpful.
    Thanks!

  9. nirmaljb commented on Mar 10, 2026

    @nirmaljb
  10. Om-A-osc commented on Mar 10, 2026

    @Om-A-osc

    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.

  11. impawstarlight commented on Mar 10, 2026

    @impawstarlight
    Member

    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
    Image
    • 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.
    • Any gotchas I should keep in mind?

    I already have a working prototype of 64-bit addition and multiplication in my PR for PCG32

  12. nakul-krishnakumar commented on Mar 10, 2026

    @nakul-krishnakumar
    Member

    I would like to clarify some questions regarding implementing ml algorithms:

    1. 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)
    1. 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?

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

  13. Witty-31-06 commented on Mar 10, 2026

    @Witty-31-06
    • 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?
  14. LoayAhmed304 commented on Mar 10, 2026

    @LoayAhmed304

    I would like to discuss some concerns regarding Array API compliance with ndarray GSoC idea:

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

    Thank you!

  15. batpigandme commented on Mar 10, 2026

    @batpigandme
    Member

    Hey @nirmaljb,

    The second one:

    1. gammaf: stdlib-js/stdlib/actions/runs/22865163230/job/66329844383?pr=10805

    is a known issue. We need to update the version of R being used, since it's too old for the lintr package.

  16. udaykakade25 commented on Mar 10, 2026

    @udaykakade25

    Here's my timeline in mind: Notion Link
    Need early review if we have some free time in the end :)

    Image
  17. nirmaljb commented on Mar 10, 2026

    @nirmaljb

    I would want some clarity.
    In main.c and main.js, what should I do with that chunk of code?

    1. Remove it completely
    2. Keep it commented.

    https://github.com/stdlib-js/stdlib/pull/10805/changes#diff-da8e6992128d18423f7944aaffae87a33aaee8e8256419fd3efe5311b13d9b86

  18. manit2004 commented on Mar 10, 2026

    @manit2004

    can you please review this timeline once? sheets

  19. dhruvan2006 commented on Mar 10, 2026

    @dhruvan2006

    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.

  20. kgryte commented on Mar 10, 2026

    @kgryte
    MemberAuthor

    Thanks everyone!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Office HoursIssue announcing office hours and soliciting associated agenda items.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions