[RFC]:

[anandkaranubc]

Thanks for taking the time to complete this application!

A few general notes:

Before working on your proposal, be sure to read through instructions first!

We will not tolerate plagiarism of any kind. Please write your proposal in your own words. If we find that you have plagiarized application content, we will reject your application without review.

To be considered, a GSoC application must have a written proposal submitted to https://summerofcode.withgoogle.com/. The purpose of creating this issue is to allow stdlib mentors to provide feedback and answer any questions you have regarding your prospective project proposal. Note, however, that we will not write your proposal for you. You, and you alone, are responsible for writing, and the timely submission of, your project proposal.

Please use a succinct name to describe your proposal. This issue should use the following issue naming convention:

[RFC]: the succinct name describing your proposal
For example,

[RFC]: improve tiling algorithms for element-wise ndarray iteration
[RFC]: build a developer dashboard for tracking repository build status
In your proposal, you should include the following information, as described below.

---

Short biography
*
Please provide a brief overview of your background, including any education/professional qualifications (e.g., university degrees, certificates, etc), technical competencies (e.g., C/C++, JavaScript, CI/CD), and general interests (e.g., high-performance numerical computing, machine learning, frontend development).

---

Editor
*
What is your preferred code editor (e.g., VSCode, Sublime Text, Vim, Emacs, etc) and why?

---

Programming experience
*
What is your experience programming? Tell us about something that you've created!

---

JavaScript experience
*
What is your experience with JavaScript? What is your favorite feature of JavaScript? What is your least favorite feature of JavaScript?

---

Node.js experience
*
What is your experience with Node.js?

---

C/Fortran experience
*
What is your experience with C and/or Fortran?

---

Interest in stdlib
*
What interests you about stdlib? Do you have a favorite feature or example? If so, tell us more!

---

Contributions to stdlib
*
Please provide a brief summary of your contributions to stdlib thus far, including any unmerged work. This should be a list of pull requests and an indication as to whether each pull request is merged, closed, or still open. If you made significant contributions outside of your pull requests (e.g., reviewing someone else's pull request), you may list that as well.

---

stdlib showcase
*
Please provide a brief summary of how you've used stdlib and explored its functionality. This should be a list of one or more repositories in which you've created demos, tutorials, how-to guides, and/or showcases using stdlib. Please do not include forks of the main stdlib repository or forks of other someone else's demos in an attempt to pass them off as your own. Any showcases should be your own original work.

---

Project Description

Tell us about your proposal!

When detailing the project schedule, you are advised to note where along the way you could formulate a pull request. Ideally, pull requests should be points where you can have self-contained, well-documented, and tested pieces of functionality. Breaking the project into smaller sub-tasks which can be completed as part of one or more pull requests helps to keep branch merges and code reviews reasonable. A large code dump at the end of the program will likely be hard to review and merge before the project deadline.

Please do not copy verbatim text from the list of project ideas or from other people's discussions about your project. Always write your proposal in your own words.

If you include any significant text or code from another source in your application, you must properly cite the included material. All papers or references that you use or plan to use must be cited. Place all citations in a "References" section at the bottom of each appliable application section. Copying text without citation is plagarism and will result in your application being rejected.

For an example of a well-written and clearly articulated GSoC proposal, see Aaron Meurer's 2009 SymPy GSoC proposal.

Goals
*
What do you hope to achieve? This should be your project abstract and include a detailed description of the proposed work.

---

Why this project?
*
What excites you about the proposed project and why?

---

Qualifications
*
What qualifications do you have to execute on your proposal? How are you suited to work on this project? For example, if you are interested in implementing statistical hypothesis tests, what courses have you taken or books have you read on statistics?

---

Prior art
*
How have other people achieved the aims of this project? Has the project been implemented before (e.g., in another programming language or library)? Are there are papers or blog posts about it? (hint: this is likely!)

---

Commitment
*
How much time do you plan to invest in the project before, during, and after the Google Summer of Code program? E.g., for part-time contributors, we expect ~15 hr/week during GSoC based on a 12 week schedule, but we request that you be explicit in your commitment. If you have other commitments, such as if you plan on taking any vacations or time away, have other jobs, or will be busy with exams during the program, let us know about it here.

---

Schedule
*
Please provide a weekly schedule of how your time will be spent on the subtasks of the project throughout the GSoC program and the expected deliverables. While this is only preliminary and can be adjusted later, if need be, providing such a schedule will help us monitor your progress throughout the program. During your project, understand that you will issue weekly progress reports against the proposed schedule. If you aim to perform any prepwork prior to week 1 (e.g., during the community bonding period), be sure to include that in your answer below. The template below assumes a 12 week schedule. If you are doing an alternate schedule, you can adjust the template accordingly.

Assuming a 12 week schedule,

• Community Bonding Period:

• Week 1:

• Week 2:

• Week 3:

• Week 4:

• Week 5:

• Week 6: (midterm)

• Week 7:

• Week 8:

• Week 9:

• Week 10:

• Week 11:

• Week 12:

• Final Week:

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
Does this proposal have any related issues (e.g., a proposal idea issue or upstream issues in the main stdlib project or website repositories)? If so, please link to those issues below.

---

[anandkaranubc]

IEEE compliance
No stats dist
retrain brain to floating point

adding new implementations on hold

scaffolding

math/base/special/fast

there are already open prs

[anandkaranubc]

Short biography

Please provide a brief overview of your background, including any education/professional qualifications (e.g., university degrees, certificates, etc), technical competencies (e.g., C/C++, JavaScript, CI/CD), and general interests (e.g., high-performance numerical computing, machine learning, frontend development).

I'm a third-year undergraduate student at the University of British Columbia (UBC) Vancouver, pursuing a combined major in Computer Science and Math. I’ve always been fascinated by the intersection of math and computing, particularly in numerical computing, machine learning and high-performance software. Academically, I’ve maintained strong performance and have been recognized on the Dean’s Honour List.

Currently, I work as a Teaching Assistant for Differential Calculus, Data Structures and Algorithms (in C++), and Introduction to Data Science (in R), helping students with everything from integrals to debugging pointers. I’m also an Undergraduate Research Assistant, comparing model performance in Julia and JAX to see which one wins the speed race.

Previously, I’ve interned at Seaspan and UBC Emerging Media Lab, working on 3D visualizations and AR/VR. I love hackathons, both as a participant and as a mentor/judge, and have had the chance to work on some exciting projects along the way.

I have experience with JavaScript, Typescript, Julia, R, C/C++ and Python, and I’ve used React for web development and JAX for numerical computing and machine learning. In short, I enjoy building cool things, solving tricky problems, and occasionally breaking my own code just to fix it again.

[anandkaranubc]

I prefer VS Code because it's lightweight, fast, and has great support for multiple languages. The built-in Git integration, debugging tools, extensions support and customization options make it my go-to editor.

[anandkaranubc]

I have experience in programming and have worked on various projects using different technologies. Here are a few:

• LeetBoard: A 3D technical interview platform for hardware engineers with a 3D editor, difficulty levels, and performance playback.
• AWS DeepRacer Challenge: Developed and trained a reinforcement learning model for autonomous racing in AWS DeepRacer Student League
• Krypto: A Web 3.0 app built with React and Solidity that enables secure Ethereum transactions and wallet management with low fees.
• A3C for Kung Fu: Built an AI agent that achieved an 85% win rate in Atari’s Kung Fu game using deep reinforcement learning.

These projects helped me learn about web development, AI/ML, and blockchain technology.

[anandkaranubc]

I have worked with JavaScript on several projects, including web apps using React, Three.js, and Node.js. I enjoy how flexible and dynamic JavaScript is. It makes building interactive web applications fun!

My favourite feature? Asynchronous programming (async/await) because it makes handling API calls and background tasks smooth. (Bye-bye to callback hell!)

My least favourite? Type coercion. While it's a powerful feature that allows for flexible and dynamic code, it sometimes tries too hard to interpret intent, leading to unexpected behaviour.

That said, the good definitely outweighs the bad.

[anandkaranubc]

Node.js experience
*
What is your experience with Node.js?

I have experience using Node.js to build backend services and APIs with Express.js, handling authentication and database connections. In one project, I built a backend system to fetch and process geolocation location data from a web service, managing large datasets efficiently. I have also worked on designing REST API endpoints for querying and filtering data.

[anandkaranubc]

I have experience with C, thanks to a CS course I took, working on memory management, data structures, and system programming. I’ve implemented a simulated cache system with optimized replacement policies and worked on Y86 assembly for pipeline optimization.

I don’t have experience with Fortran, but if needed, I’m ready to learn!

[anandkaranubc]

Interest in stdlib
*
What interests you about stdlib? Do you have a favorite feature or example? If so, tell us more!

What interests me about stdlib is its commitment to building a fast and comprehensive standard library for numerical and scientific computing on the web, which has been clearly reflected in office hours and the Gitter channel. I've always wondered, while looking at different mathematical equations and algorithms, how they are actually implemented. stdlib provided me with the stage where I could see and experience that firsthand, and on top of it, even contribute to it by learning the same level of attention to detail. I really enjoy the textbook-to-practical experience it offers.

One feature I find particularly exciting is its extensive collection of mathematical and statistical functions, along with its vast support for Pseudo-Random Number Generators (PRNGs). It's great to have access to well-designed utilities all in one place.

On a personal level, stdlib holds a special place for me as my first ever open-source contribution. The journey, coupled with the support I received, made the experience deeply meaningful and continues to inspire me to contribute more in the future.

[anandkaranubc]

Contributions to stdlib
*
Please provide a brief summary of your contributions to stdlib thus far, including any unmerged work. This should be a list of pull requests and an indication as to whether each pull request is merged, closed, or still open. If you made significant contributions outside of your pull requests (e.g., reviewing someone else's pull request), you may list that as well.

Merged Work
I have contributed multiple pull requests that have been successfully merged. My main work has been in the math/base/special and stats/base/dists namespaces. This includes:

• Adding C and JS implementations for special math functions like #5140, #5348, etc.
• Adding C implementations for existing statistical distributions like #4585, #4589, etc.
• Introducing support for Bradford distribution in stats/base/dists like #5280, #5326, etc.
• Implementing NAPI macros like #5545, #4855, etc.
• Improving test coverage like #5693, #5638, etc.
• Refactoring existing code to follow current coding conventions like #5787, #5988, etc.
• Performing cleanup and fixes where necessary like #5807, #5810, etc.

Open Work
I currently have open pull requests that are under review, mostly focused on mathematical functions, distributions, and overall improvements to stdlib.

Issues Created
I have also raised issues related to improvements, missing features, and potential fixes.

Code Reviews
I have helped in code reviews, largely revolving around refactoring random value generation in stats/base/dists and math/base/special.

Contributions:

• Merged PRs
• Open PRs
• Created Issues

[anandkaranubc]

stdlib showcase
*
Please provide a brief summary of how you've used stdlib and explored its functionality. This should be a list of one or more repositories in which you've created demos, tutorials, how-to guides, and/or showcases using stdlib. Please do not include forks of the main stdlib repository or forks of other someone else's demos in an attempt to pass them off as your own. Any showcases should be your own original work.

This is still a work in progress...

[anandkaranubc]

Project Description

Tell us about your proposal!

When detailing the project schedule, you are advised to note where along the way you could formulate a pull request. Ideally, pull requests should be points where you can have self-contained, well-documented, and tested pieces of functionality. Breaking the project into smaller sub-tasks which can be completed as part of one or more pull requests helps to keep branch merges and code reviews reasonable. A large code dump at the end of the program will likely be hard to review and merge before the project deadline.

Please do not copy verbatim text from the list of project ideas or from other people's discussions about your project. Always write your proposal in your own words.

If you include any significant text or code from another source in your application, you must properly cite the included material. All papers or references that you use or plan to use must be cited. Place all citations in a "References" section at the bottom of each appliable application section. Copying text without citation is plagarism and will result in your application being rejected.

For an example of a well-written and clearly articulated GSoC proposal, see Aaron Meurer's 2009 SymPy GSoC proposal.

Goals
*
What do you hope to achieve? This should be your project abstract and include a detailed description of the proposed work.

---

The goal of this project is to complete as much work as possible in the following areas, focusing on math/base/special.

Main Goals:

• Implement the remaining C implementations for existing double-precision packages, as mentioned in issue #649.
• Develop a wide range of single-precision packages (including both C and JS implementations) as listed in issue #649.
• Add missing constants and NAPI macros that will be dependent on the above implementations.

Supporting Goals:

• Add missing addons to some double-precision complex number functions like cabs2f, cabsf, etc.
• Implement C versions of variadic functions like maxabn, maxn, etc., if needed.
• Verify existing double-precision implementations against upstream references and fix any bugs (e.g., ln, log1p, etc.).
• Add tests for IEEE 754 compliance as mentioned in issue #365.
• Improve test coverage for existing implementations in math/base/special as much as possible.
• Contribute to documentation and blog posts (finally!).
• Refactor random value generation and test messages in math/base/special and stats/base/dists (if time permits).

The main and supporting goals can be worked on independently and in parallel, with the main goals taking priority.

By the end of the program, if there are any unfinished tasks, I will ensure they are properly documented as new issues for future contributors or for me to continue working on outside of GSoC.

[anandkaranubc]

Why this project?
*
What excites you about the proposed project and why?

I've always been curious about how mathematical functions and algorithms are actually implemented under the hood. stdlib gave me the perfect opportunity to not just see it but also contribute to it. When I implemented the Gaussian hypergeometric function (hyp2f1), it was an eye-opening experience, seeing a function go from a textbook definition to a real, working implementation felt incredibly rewarding. (I promise this is the last time I’m bringing up hyp2f1… maybe)

What excites me most about this project is the chance to bridge the gap between theory and practice. stdlib provides a structured way to write efficient, well-tested numerical computing tools, and I love how it balances performance with clarity. The idea of working on JS/C implementations, precision improvements, and IEEE compliance excites me because it's about making math more accurate, reliable, and accessible for developers.

Also, there’s something really satisfying about writing code that makes scientific computing smoother for everyone. It’s like leaving behind a well-optimized trail for others to follow, and I would be proud to be a tiny part of that!

[anandkaranubc]

Qualifications
*
What qualifications do you have to execute on your proposal? How are you suited to work on this project? For example, if you are interested in implementing statistical hypothesis tests, what courses have you taken or books have you read on statistics?

I have worked on math/base/special in stdlib, gaining experience in implementing and improving mathematical functions. I have taken courses in numerical computing, algorithms, software construction, and hardware systems, giving me a strong academic background and the ability to handle complex problems in this project. As a teaching/research assistant, I have improved my debugging, documentation, and problem-solving skills, making me well-prepared to contribute to stdlib.

[anandkaranubc]

Prior art
*
How have other people achieved the aims of this project? Has the project been implemented before (e.g., in another programming language or library)? Are there are papers or blog posts about it? (hint: this is likely!)

This area has been widely explored, not just in stdlib's math/base/special, which is being tracked in issue #649, but also in other well-known libraries like Cephes, FreeBSD, Go, Boost, Julia, FDlibm, SLATEC, and SciPy. For single-precision implementations, we can also take inspiration from stdlib's existing double-precision versions in math/base/special.

There are also important standards like IEEE 754 for floating-point arithmetic and C99 for mathematical functions, which provide useful guidelines for accuracy and implementation.

[anandkaranubc]

Commitment
*
How much time do you plan to invest in the project before, during, and after the Google Summer of Code program? E.g., for part-time contributors, we expect ~15 hr/week during GSoC based on a 12 week schedule, but we request that you be explicit in your commitment. If you have other commitments, such as if you plan on taking any vacations or time away, have other jobs, or will be busy with exams during the program, let us know about it here.

---

I am all in for this project as a full-time, large project (350-hour commitment) and don’t mind going beyond that if needed. I will dedicate ~30-40 hours per week to the project, focusing on steady progress, well-structured/sized pull requests, and thorough testing.

I am also holding a summer research position, but I have successfully managed multiple responsibilities in the past, including academics, teaching/research assistant roles, and open-source contributions. This experience ensures that my GSoC commitment will not be impacted. I am confident in my ability to effectively balance both, keeping my work for stdlib at an equal priority with my research.

Before GSoC officially begins, I will focus on refining my proposal, improving my showcase, and putting out some first standalone implementations that align with the project goals. After GSoC, I plan to stay involved, addressing any remaining work and contributing further.

[anandkaranubc]

Schedule
*
Please provide a weekly schedule of how your time will be spent on the subtasks of the project throughout the GSoC program and the expected deliverables. While this is only preliminary and can be adjusted later, if need be, providing such a schedule will help us monitor your progress throughout the program. During your project, understand that you will issue weekly progress reports against the proposed schedule. If you aim to perform any prepwork prior to week 1 (e.g., during the community bonding period), be sure to include that in your answer below. The template below assumes a 12 week schedule. If you are doing an alternate schedule, you can adjust the template accordingly.

Implementation Blueprint

To guide the implementation process, I will reference and follow the structured progression outlined in two key documents:

1. stdlib-dp-wrapup.pdf – detailing the remaining work for double precision implementations.
2. stdlib-sp-ladder.pdf – outlining the step-by-step plan for adding single precision JS/C implementations.

These documents will be used throughout the project (and potentially beyond) to ensure a clear and efficient development roadmap.

Note: The single-precision document has been created to reflect the prerequisites required only for the implementations. There may be a few instances (though I do not expect many) where some packages involve functions for benchmarks, tests, etc., that are further down the dependency chain. In such cases, we can either use the respective double-precision package and cast the values using float64ToFloat32 (and adding a FIX comment) or add a TODO comment (and leave that part blank). In either case, we will visit them again. Open to feedback on this.

Additional Notes

1. For double precision functions, the focus will be on adding missing C implementations to existing JS implementations. To ensure consistency and correctness, I will follow the same upstream implementations that were used in the JS versions.

2. For single precision functions, the plan is to mostly refer to the same upstream library that was used for its respective double precision counterpart. If a direct upstream implementation is not available, I will scout implementations from well-established libraries, including:

   • Cephes
   • FreeBSD
   • Go
   • Boost
   • Julia
   • FDlibm
   • SLATEC
   • SciPy

Thanks to Gunj's GSoC Issue #41 for providing key insights and references.

Schedule

Assuming a 12 week schedule,

Community Bonding Period (Weeks C1-C3):

Referenced from stdlib-dp-wrapup.pdf

Weeks C1:
This period will be dedicated to connecting with mentors and fellow participants to better understand the overall goals and expectations for GSOC. These discussions will also serve as an eye-opener for me, helping to identify areas of the codebase that I am less familiar with and expanding my knowledge.

Since I have some familiarity with the math/base/special module, I will start implementing after consulting with my mentors, to ensure I am heading in the right direction. I will begin with low-hanging fruits by adding the missing addons for complex number packages:

• cabs2f
• cabsf
• cceilf
• cflipsignf
• cidentityf

As mentioned in the document too, there are already open PRs addressing this. I will try to review those and assess their
status. If not, they can be implemented from the beginning.

Additionally, I will implement the missing C implementations for the following functions:

• bessely1
• ellipj
• heaviside
• heavisidef
• minmax

Week C2:
I will focus on implementing the C versions of:

• gammainc
• gammaincinv

Week C3:
The focus will be on:

• kernel-betainc
• betainc (potentially)

[anandkaranubc]

Referenced from stdlib-sp-ladder.pdf

Week 1,2: Completion of Phase 0

Week 3: Completion of Phase 1

Week 4, 5: Nearing the complete wrap-up of Phase 2

Week 6: (midterm) Completion of Phase 2, with time to gather feedback on my development process, contributions, and areas for improvement.

Week 7, 8: Completion of Phase 3

Week 9, 10: Completion of Phase 4

Week 11, 12: Nearing the complete wrap-up of Phase 5 (potentially)

Final Week: Submission of the project, along with the creation of an issue/tracking issue to document any remaining tasks. Lastly, gathering feedback and guidance to reflect on the development process and plan for future improvements.

That's my 4 months in 8 lines...

Notes:

1. Regarding the remaining portions of the Supporting Goals mentioned above, since they are largely independent, I will try to implement them alongside the main plan as much as possible.
2. The above plan doesn't consider anything from Phases 6 and 7, but I will try to address them if we wrap up the earlier phases ahead of schedule. Sorry, I am still battling between being realistic and wildly optimistic. Open to feedback on this too!
3. The above plan also doesn't include adding C implementations for kernel-betainc, betainc, kernel-betaincinv, and betaincinv. If these need to be prioritized, it will likely require adjustments to the timeline and a reallocation of focus, probably pushing Phase 5 to a later stage.
4. I haven’t considered the open PRs right now for some ready-to-merge implementations that could speed up the progress.
5. Adding new implementations is on hold for now based on the current priorities and progress.

And I ended up not combining my previous idea of introducing new statistical distributions with this gigantic beast.

Thank you for taking the time to read my proposal!

[anandkaranubc]

Related issues
Does this proposal have any related issues (e.g., a proposal idea issue or upstream issues in the main stdlib project or website repositories)? If so, please link to those issues below.

Of course, they are everywhere:

GSoC Issue #34
Issue #649
Issue #365