Skip to content

GSoC 2025 ‐ Muhammad Haris

Jump to bottom
Athan edited this page Aug 29, 2025 · 4 revisions

About me

Hi, I'm Muhammad Haris from Islamabad, Pakistan. I hold a Bachelors degree in Mechanical Engineering from Air University, Islamabad. My open-source journey began in February 2024 when I first learned about the Google Summer of Code (GSoC) program. Although my initial application wasn't successful, I remained engaged and continued contributing. That persistence paid off—this year, when I was selected to work on the same project I had applied for the year before. It’s really been a rewarding experience in terms of growth and learning.

Project overview

JavaScript’s built-in arrays are not designed for efficient operations on large, multi-dimensional datasets. stdlib addresses this gap by providing the ndarray API, a general-purpose interface for creating and manipulating multi-dimensional arrays.

This project built on those foundations by extending the ndarray API to achieve API parity with JavaScript’s Array.prototype. The goal was to make ndarrays feel as natural and intuitive to use as native arrays without compromising performance. This involved implementing high-level parity functions in ndarray/* or blas/ext/*, along with the necessary lower-level utilities in ndarray/base/* or blas/ext/base/*, respectively.

Over the course of the project, I implemented a wide range of functions such as concat, find, some, fill, indexOf, findIndex, with and more.

Project recap

The general implementation process was as following:

  1. Determine whether any lower-level utilities were required to support the top-level parity function.
  2. If needed, implement the required lower-level functions within the ndarray/base/* or blas/ext/base/* namespaces.
  3. With the necessary low-level machinery in place, implement the user-facing API in the ndarray/base/* or blas/ext/* namespace.

The functions implemented can be grouped into the following categories:

  • Functions implemented in ndarray/* namespace: For most of these functions specialized kernels were implemented at the base-level in ndarray/base/* for dimensions up to 10d and a generalized nd kernel for higher-dimensional cases. Along with tests and benchmarks for each dimension which significantly increased the implementation time for these functions. In cases where a base-level implementation already existed (or was not needed), only the top-level function was implemented.

     ndarray/
  ├── map
  │    └── User-facing wrapper around the base implementation
  └── base/
       └── map
            └── Base implementation with specialized kernels

  • Functions implemented in blas/ext/* namespace: For these functions, 1D strided functions were implemented in the blas/ext/base/* and relevant ndarray wrappers in blas/ext/base/ndarray/*. These implementations were relatively less time-consuming since they didn't involve implementing specialized kernels for various dimensions.

    blas/ext/
 └── index-of
      └── Top-level wrapper (calls into ndarray wrappers)
           └── base/ndarray/
                ├── sindex-of   (ndarray wrapper over base/sindex-of)
                ├── dindex-of   (ndarray wrapper over base/dindex-of)
                └── gindex-of   (ndarray wrapper over base/gindex-of)
                     ├── base/sindex-of   (single-precision 1D strided function)
                     ├── base/dindex-of   (double-precision 1D strided function)
                     └── base/gindex-of   (generic 1D strided function)

Completed work

Following is the list of PRs I worked on over the 12-week period. These include the implementation of new functions, supporting utility functions and various maintenance related PRs:

Current state

At this stage, a few top-level implementations are still pending, including blas/ext/sorthp, ndarray/any-by, ndarray/any, ndarray/find, ndarray/every-by, and ndarray/some. In addition, during the final week of the project I began work on ndarray/flatten, ndarray/flat-map, ndarray/pop, and ndarray/shift, which are currently in progress.

What remains

A few functions still remain to be implemented, as outlined in the tracking issue, including those mentioned above. With the exception of ndarray/reduce, the remaining functions won't require implementing specialized kernels, which should significantly reduce the time needed to complete them. That said, some functions, such as ndarray/splice, will require additional R&D to determine how they should operate on ndarrays, which may increase the time to completion.

Challenges and lessons learned

One of the main challenges was the sheer effort required in implementing implementing functions which require specialized kernels. Each kernel brought with it a heavy workload — documentation, testing, and benchmarking across up to 10 dimensions — which significantly increased the time required for each function. This demanded not only the technical ability but also persistence and patience.

Another challenge was thinking about overall design: it was not always obvious where each piece of the overall machinery should fit and how it would contribute to the bigger picture of the stdlib ecosystem. Because user-level functions often required building multiple layers of lower-level machinery, I gained a stronger appreciation for how much effort and foresight goes into API design.

Conclusion

This has truly been a great journey. I am very grateful for the opportunity to contribute and grow through this experience.

I want to thank @kgryte and @Planeshifter for creating such a welcoming community and for their support and guidance whenever I needed it. In particular, @kgryte has been an incredible source of both technical help and motivation, and I truly appreciate the time and effort he dedicated to mentoring me.

I would also like to congratulate @aayush0325, @anandkaranubc, @ShabiShett07, and @gururaj1512 on successfully completing their GSoC projects, and I wish them all the best in their future endeavors.

Clone this wiki locally