[RFC]: Implement strided implementations of statistical hypothesis tests

[Lokeshranjan8]

Full name

Lokesh Ranjan

University status

Yes

University name

Indian Institute of Technology (Banaras Hindu University), Varanasi

University program

Major in Pharmaceutical Engineering & Technology

Expected graduation

2027

Short biography

I am a pre-final year student at IIT Varanasi, majoring in Pharmaceutical Engineering. Although my studies mainly involve drugs and medicinal plant–related topics, I developed an interest in programming because of my peer group. Because of them, I started exploring competitive programming and later moved into web development. From there, I never looked back. I keep learning, improving my skills, and trying new things, moving from one programming language to another. I am also interested in system scalability and enjoy learning how systems can be optimized for better performance. Reading technical blogs and exploring such topics is something I genuinely enjoy spending my time on

Currently, I am working on a personal project using Go (because of its concurrency and goroutine features). I am also a little interested in Agentic AI, so I have been learning more about LangGraph and LangChain. I have experience with JavaScript, TypeScript, React, C/C++, Python and Go. I also organize hackathons and conduct workshops on various programming languages as a member of the programming club at my college.

Timezone

Indian Standard Time (UTC +5:30)

Contact details

email:lokesh8ranjan@gmail.com, github:Lokeshranjan8

Platform

Linux

Editor

I use VS Code for its rich extensions, built-in Git support, debugging tools, and code customization.

Programming experience

I have worked on various projects using different technologies. Here are a few of them:

• Contest-Tracker: An application that displays upcoming contests from various platforms and analyzes user submissions to generate graphs highlighting strengths, key topics, and rating levels, showing where the user currently stands.
• Repo-doc-agent: An agentic AI project where you simply provide a GitHub repository, and it generates a README for the entire codebase using LangGraph.
• Worked as a Backend developer intern at Sherlock Studio.

JavaScript experience

I started learning JavaScript through YouTube after completing HTML and CSS as part of the typical roadmap. Initially, I started it just for the sake of completing the coursework, but at that time nothing really made sense to me. Gradually, after building some personal projects using those concepts, things started making sense. Because of JavaScript, I was later able to grasp React, Node.js, and Express much better.

In JavaScript, I particularly like asynchronous programming. Thanks to it, we do not need to write long callback functions.
I do not like dynamic typing in JavaScript, because small type errors can lead to unexpected issues.

Node.js experience

I started learning Node.js to implement backend features and understand server-side development. I really enjoyed working with it while building my first full-stack application, which simply fetched data from competitive programming platforms. Through this project, I learned about REST APIs, Express.js, API handling, and querying and structuring data efficiently. Overall, I have a good experience with Node.js. It was a very enjoyable experience and helped me gain a clearer understanding of backend development.

C/Fortran experience

I learned C as part of my coursework in college, which focused on C programming and data structures. I further gained practical experience with C through my work at stdlib, where I contributed C implementations for mathematical and statistical functions in stats/base/dists.

I do not have much experience with Fortran and have not contributed to it yet, but I am definitely willing to learn and understand how it works.

Interest in stdlib

stdlib-js always holds a special place for me because it was my first open-source contribution, I still remember that one year ago I submitted my first open-source PR for @stdlib/stats/base/dists/arcsine/quantile contributing to the C implementation. I feel more connected to it because of its strong focus on mathematics. I love math,and seeing even complex equations implemented in C and JavaScript is very interesting to me. It provides a practical way to understand mathematical concepts better while combining my interest in programming. Since stdlib is used in research purpose work, scientific computing, and performance-critical work, and has much more potential ahead, it really excites me to be part of this growing community and contribute to it.

I would like to thank the maintainers of this project for making my contribution journey smooth, from reviewing my code to clearing my doubts. I will definitely try to carry forward the same welcoming attitude toward new contributors.

Version control

Yes

Contributions to stdlib

Merged Work

I have contributed multiple pull requests that have been successfully merged . This includes:

• Adding structured package data support for math/base/special #8017 , #7986 etc.
• Adding C implementations for existing statistical distributions like #4637, #4374 etc.
• Refactoring existing code to follow current coding conventions like #10373 , #10335, #10317 etc.
• Performing cleanup and fixes where necessary like #9799 ,#9798 , etc.

Open Work
Some of my open PRs are still under review, mostly focused on mathematical and distribution functions. OPEN PRs

Issues Created
I have also raised issues related to updating older packages to use newer dependencies and improve consistency. Issues

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

stdlib showcase

showcase

Goals

The goal of this project is to implement the missing lower-level strided array implementations of statistical hypothesis tests.

A small breakdown:

• Implement the missing lower-level strided array functionality in both JavaScript and C within /stats/strided/, including support for double precision and generic types.
• Implement utilities for resolving the alternative hypothesis, along with a result object for each statistical test in /stats/base/.
• Implement missing C implementations for certain distribution and mathematical special functions that currently exist only in JavaScript and are required as dependencies for the statistical tests.

There are 16 statistical hypothesis tests, of which 2 tests (ztest and ztest2) already have lower-level strided array APIs. The remaining tests will be implemented in a similar manner as ztest and ztest2, while adhering to stdlib code conventions. Will also use SciPy.hypothesis as an additional reference during implementation. Each Hypothesis Test will look like this (eg for ztest):

stats/
└── strided/
    ├── dztest/       
    ├── sztest/ - (if time permits)         
    └── ztest/           

I looked into what associated packages would be needed alongside the strided implementations. These include enums for defining alternative hypothesis (two-sided, less, greater ) and resolver utilities for converting between string and numeric enum representations similar to how other packages ( stats/base/ztest ) in stdlib handle this internally. Some tests such as levene-test,kruskal-test,fligner-test, chi2gof,bartlett-test,anova1 and chi2test do not have alternative hypothesis. For these, only result objects need to be implemented.

Why this project?

From my coursework, I am already familiar with some statistical distributions such as the z-distribution, Student’s t-distribution and p-distribution. Because of this familiarity, I felt comfortable choosing this project. Apart from that, this is a high-priority project and involves several challenging mathematical functions. Working on these implementations will challenge me and help me understand the underlying statistical computations more deeply.

Contributing to this project would also allow me to apply my knowledge of mathematics and programming together. It would be a matter of great pride for me to contribute to such an important part of this ecosystem.

Qualifications

I have been a consistent contributor to the project over the past few months and have worked on several meaningful contributions. Through this period, I have improved my logical thinking, problem-solving ability, debugging skills and gained experience in identifying edge cases. Working on the repository has helped me become familiar with the coding style and structure used in @stdlib. Additionally, I have developed familiarity and a better understanding of several statistical distribution functions used in the project.

Prior art

The implementation of the lower-level strided APIs will draw from the existing higher-level hypothesis test modules in @stdlib/stats along with Scipy and Julia . The design of alternative hypothesis resolvers and result objects will be guided by the core logic of the respective test implementations. For C implementations of distribution function stats/base/dists and special functions (the beta function), I will refer to SciPy, the Julia library and Wikipedia. Additionally, work by Karan Anand in @stdlib/math/base/special will also serve as a useful reference.

Commitment

I do not have any other commitments during my summer break, which runs from May 9 to July 21. During this period, I will be able to work full-time on the project and can dedicate around 40–45 hours per week.I am also comfortable putting in additional hours if needed to meet the weekly goals or project milestones. After July 21, when my college semester begins, I will try my very best to stay on schedule and complete the project within the expected timeline, as the initial days of college are not very hectic.

Schedule

I will use these two documents to track my progress and plan the work. These will help me monitor what has been completed and ensure that dependencies are handled early so that other implementations are not blocked. They will also serve as a roadmap throughout the project.

1. Statistical Test.pdf– This pdf keeps track of all the routines that need to be implemented.

This is not the full dependency tree but only the components lacking C implementations are shown

2. Math_base_special.pdf - This PDF contains certain math-based special functions and distribution functions whose implementations are currently blocked due to missing prerequisites (C API) and therefore need to be addressed first.

Assuming a 12 week schedule,

• Community Bonding Period:

During this community bonding period, I will mainly focus on clearing the majority of the blockers, including the associated packages for each test, as well as special functions and distribution functions, so that it becomes easier to implement statistical hypothesis tests afterward. As these functions can be complex and difficult, I will continuously seek regular feedback from maintainers to gain clarity on my approach, ensure I am moving in the right direction, and identify anything I might be missing. This will be very helpful for my upcoming weeks. There are also some open PRs, and I will try to move them to completion, as listed in the sheet, including lognormalcdf, erlangcdf, signrankcdf, kernel-betainc, gammaincinv , betainc and binomialcdf.

-Week 1: Work on completing and reviewing the open PRs from my side, along with implementing the associated packages for kruskal (only their result objects need to be implemented, which should not be too difficult).

-Week 2: Work on adding C implementations for betacdf ,tcdf, negative-binomial-pmf and fcdf.

-Week 3: Work on adding the C implementation for kernel-betaincinv. Along with this, implement the associated packages for levene and fligner tests.

Development Period:

• Week 1: Work on implementing associated packages for chi2gof, chi2test, vartest, wilcoxon, anova1 and pcorrtest.

• Week 2: Work on implementing associated packages for bartlett, kstest, ttest and binomialtest.

• Week 3: Work on adding C implementations for betaprime-cdf, f-quantile, t-quantile, and betaincinv. I will prioritize betaincinv, as this will unlock implementation for beta-quantile, which is further needed for the binomial test.

• Week 4: Work on implementing generic pure JavaScript versions for pcorrtest, ttest, ttest2, binomialtest, wilcoxon, kruskal, and kstest.

• Week 5: Work on implementing generic pure JavaScript versions for anova1, chi2test, vartest, fligner, bartlett, and chi2gof.

• Week 6 (midterm): Submit my work to the mentor for review, and parallelly work on the JS implementation for dttest, dttest2, and danova1 and implement the C version of beta_quantile.

• Week 7: Work on the JS implementation of dbartlett, dbinomialtest, dchi2test and dvartest.

• Week 8: Work on the JS implementation of dfligner, dkruskal, dwilcoxon and dpcorrtest.

• Week 9: Work on the JS implementation of dchi2gof, dkstest and dlevene.

• Week 10: Work on the C implementation of dttest, dttest2, danova1, dkruskal and dvartest.

• Week 11: Work on the C implementation of dfligner, dwilcoxon, dpcorrtest, dchi2test and dbartlett.

• Week 12: Work on the C implementation of dlevene, dkstest, dchi2gof and dbinomialtest.

• Final Week: I will submit my project and ensure that all documentation and testing are completed from my side. If anything is left, I will open an issue to track it.

• Stretch Goals: If the core scope and prioritized deliverables are completed ahead of schedule, I will start implementing JS version of single-precision types for each statistical hypothesis test.

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

#179

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.

[kgryte]

@Lokeshranjan8 Thank you for opening this draft proposal. A few comments:

1. Thanks for also including the various special function dependencies in your timeline. I might suggest bumping those up to the community bonding period. The sooner those are all out of the way, the smoother your remaining weeks will be, as those PRs will like be quite involved to review.
2. The strided implementations having various additional associated packages (e.g., results objects, enums, etc). It would be good to account for those in your roadmap and as a design principle. It is not as simple, unfortunately, as writing a single package. And each strided API comes in three flavors: double-precision, single-precision, and "generic". If you start planning that out, you realize that there will be a lot of packages to implement, review, fixup, and merge. You should keep that in mind and plan accordingly. May be worth doing a bit more of a technical deep dive on ztest.
3. For your showcase, I believe you can likely use even more stdlib functionality (e.g., the computation of the mean, stdev, normal CDF, normalPDF, etc in Stats.js). May be worth exploring how far you can take stdlib.

[Lokeshranjan8]

@kgryte Thanks for the feedback.

1. Regarding the special function and other high priority dependencies , I’ll move those to the community bonding period and prioritize getting them implemented early, along with the some associated packages (such as enums and result objects).
2. I have revised the timeline to include all dependencies that need to be implemented beforehand, such as alternative hypothesis resolvers and result objects. I understand that these can vary in complexity depending on whether a test requires only a result object or also an alternative hypothesis resolver. During the project period, I plan to implement both generic and double-precision versions for each statistical test.
3. I agree there is still room for improvement, I will implement more stdlib functionality where possible.

[Lokeshranjan8]

Hi @kgryte , I updated the stdlib showcase. It now uses strided/mean, strided/stdev, normal-cdf, normal-pdf, ztest, ttest2, and pcorrtest. I also updated the proposal to include the missing pieces.

[Lokeshranjan8]

Just a small question regarding my planned work for the community bonding period. My current thinking is to include only some core math base special functions and distribution functions first, and then gradually bring in the remaining special functions in later stages as their dependencies get fulfilled.
Another thought ( probably not a good one ) : should I include both the blocked and unblocked functions during the community bonding period, open draft PRs for the blocked ones, and then come back to complete the testing and finalize them once their dependencies are fulfilled?

[Lokeshranjan8]

This is my finalized proposal summary can I go ahead with it?

This project aims to implement lower-level strided array APIs for the statistical hypothesis tests. Each implementation will provide both a strided API and an ndarray API to ensure compatibility with stdlib ndarrays, enabling users to operate on one-dimensional strided arrays using Type specialized hypothesis test implementations. Deliverables include strided and ndarray implementations for each hypothesis test, alternative hypothesis resolvers, result objects and C implementations for the prerequisite special functions and distribution functions, along with complete test coverage and documentation for each package.

[kgryte]

The summary looks reasonable.