[RFC]: implement base special mathematical functions in JavaScript and C

[anandkaranubc]

Full name

Karan Anand

University status

Yes

University name

University of British Columbia

University program

Combined Major in Computer Science & Math

Expected graduation

April, 2026

Short biography

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 an Undergraduate 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.

Timezone

Pacific Daylight Time

Contact details

email: [email protected], github:anandkaranubc

Platform

Mac

Editor

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.

Programming experience

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.

JavaScript experience

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.

Node.js experience

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.

C/Fortran experience

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!

Interest in stdlib

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.

Version control

Yes

Contributions to stdlib

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 (Merged PRs). 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. Open PRs

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

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

stdlib showcase

Link

Goals

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 the above implementations depend on.

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.

Why this project?

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!

Qualifications

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.

Prior art

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 complex-number arithmetic, which provide useful guidelines for accuracy and implementation.

Commitment

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.

Schedule

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)

Development Period:

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!

Related issues

Of course, they are everywhere:

GSoC Issue #34
Issue #649
Issue #365

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.
• I have read and understood the stdlib showcase 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.

[anandkaranubc]

CC: @kgryte @Planeshifter @gunjjoshi

[Planeshifter]

Thanks @anandkaranubc for your proposal!

A few questions:

• You mention that in Week C3, you plan on tackling kernel-betainc and potentially betainc, but later state that your plan doesn't include C implementations for these functions. Could you please clarify?
• Having C implementations for functions including betaincinv would be beneficial insofar as it would unlock C implementations for all the statistical distribution function in stdlib. If you were to prioritize these functions, which parts of your single-precision implementation phases would you deprioritize or reschedule to accommodate this work?
• You mention implementing C versions of variadic functions like maxabn and maxn. Can you elaborate on how you are planning to go about this?

[kgryte]

You mention implementing C versions of variadic functions like maxabn and maxn.

I would add that these variadic functions should not have C implementations at all. Less of a need in C.

[anandkaranubc]

Thanks @Planeshifter for the review and feedback!

• You mention that in Week C3, you plan on tackling kernel-betainc and potentially betainc, but later state that your plan doesn't include C implementations for these functions. Could you please clarify?

Sorry for the confusion. Ideally, I would like to complete both kernel-betainc and betainc. However, if things don’t go as planned due to the complexity and R&D involved on my part, I’ll continue working on them alongside the other tasks scheduled for the following weeks. I’ll prioritize the main objectives first and keep betainc and friends as a side task. This might slow progress down a bit, but I hope to make good headway or at least "incrementally" complete a large portion by the end.

• Having C implementations for functions including betaincinv would be beneficial insofar as it would unlock C implementations for all the statistical distribution function in stdlib. If you were to prioritize these functions, which parts of your single-precision implementation phases would you deprioritize or reschedule to accommodate this work?

I completely agree and had a similar concern. If it's about implementing betaincinv and kernel-betaincinv, I think Phase 5 will have to be pushed back slightly, i.e. expf and friends...

That said, right now I’m trying to slowly pick off all the low-hanging fruits so I can gain more leverage on the tougher ones.

cc: @kgryte

[gunjjoshi]

Thanks for writing this proposal, @anandkaranubc! Some comments:

• You can add links to your open PRs under the Open Work section, rather than having them separately.

• Similarly, you can add links to created issues under Issues Created section.

• A small nitpick:

  Add missing constants and NAPI macros that will be dependent on the above implementations.

  I think it would be vice-versa, i.e., those implementations will be dependent on constants and NAPI macros, not the other way round.

• Verify existing double-precision implementations against upstream references and fix any bugs (e.g., ln, log1p, etc.).

  Anything specific about ln, log1p? Do they have bugs or need to be updated?

[anandkaranubc]

Thanks for the review and feedback, @gunjjoshi!

• You can add links to your open PRs under the Open Work section, rather than having them separately.
• Similarly, you can add links to created issues under Issues Created section.

I have inlined them now.

I think it would be vice-versa, i.e., those implementations will be dependent on constants and NAPI macros, not the other way round.

Oops! Thanks, I’ve fixed the wording now.

Anything specific about ln, log1p? Do they have bugs or need to be updated?

Context: While implementing functions for the Bradford distribution, I noticed some significant differences between the results of our ln and log1p implementations near unity, compared to SciPy’s. Based on a discussion in the last OH, it seems SciPy uses Cephes for log1p, and they don't appear to have a dedicated ln implementation. Instead, they refer to np.log (which is a bit surprising).

So, I believe the main goal here isn't necessarily to fix something, but rather to do a spot check to confirm whether there have been any changes in the latest upstream implementations.

Reference discussion
SciPy's reference implementation

[anandkaranubc]

Final submission PDF: Proposal_GSOC_KaranAnand.pdf

[anandkaranubc]

Please provide a brief summary of your proposal. It should encompass the problem you are solving, how you plan to solve it, and a clear set of deliverables. If your proposal is accepted, this text will become your public project description on the program site.

This project aims to implement and enhance base special mathematical functions in JavaScript and C for stdlib. The goal is to complete missing C implementations for existing double-precision packages, develop new single-precision versions, and ensure consistency, accuracy, and IEEE 754 compliance. Deliverables include multiple function implementations, added constants, improved test coverage, and documentation updates. These enhancements will make math functions in stdlib faster, more robust, and more accessible for developers across platforms.

This is the proposal summary I intend to write, for the official GSOC proposal. Open to feedback if it needs improvement.

cc: @kgryte @Planeshifter @gunjjoshi

[kgryte]

That works for me.

[gunjjoshi]

Seems great. Best of luck, @anandkaranubc!