Skip to content

GSoC 2024 ‐ Gunj Joshi

Jump to bottom
Gunj Joshi edited this page Aug 22, 2024 · 21 revisions

About me

Hello 👋. I am Gunj Joshi, from Banswara, Rajasthan, India. I am a pre-final year undergraduate at Indian Institute of Information Technology, Kottayam, Kerala, India. It has been an year since I started my open-source journey, and believe me, it has been a great ride! Apart from stdlib, my interests include mathematics (which might be evident from my GSoC project) and sports.

Project overview

The goals of my project included adding C implementations for various base special mathematical functions. Along with that, I also worked on adding single-precision variants for pre-existing functions. To achieve this, I followed certain reference implementations, some of which include:

The approach for developing a certain C implementation from the reference implementation to its stdlib equivalent included quite a few things, out of which some are as follows:

  • Using a relevant napi function, in order to match the function signature.

    For instance, binomcoef, has the following signature:
double stdlib_base_binomcoef( const int64_t n, const int64_t k ) {

It takes in two 64-bit integers, and gives a number of type double as output. In order to achieve this, I worked on adding LL_D in math/base/napi/binary, which was as follows:

napi_value stdlib_math_base_napi_ll_d( napi_env env, napi_callback_info info, double (*fcn)( double, int64_t, int64_t ) )

and a few more tweaks to follow the conventions used in stdlib.

In order to develop single-precision implementations, certain conventions and methods were followed, some of which include:

  • Choosing an appropriate reference implementation.
  • Modifying tests to suit single-precision calculations, along with changing the range of the test fixtures.
    For example, In math/base/special/ln, for testing subnormal inputs, we use the range as:
x = range( 1.0e-309, stop = 1.0e-312, length = 500 );

But, in math/base/special/lnf, we use a smaller range, as it is only for single-precision values.

x = range( 1.0e-39, stop = 1.40129846e-45, length = 500 );
  • Modifying the algorithm to align with single-precision arithmetic, whether it is casting expressions to float32 after each arithmetic operation in JavaScript using float64ToFloat32, or using a suffix f for every decimal number in C.
    For example,

Double-precision in JavaScript:

var a = 2.5;
var b = 1.5e3;

var c = a + b;

Single-precision in JavaScript:

var float64ToFloat32 = require( '@stdlib/number/float64/base/to-float32' );

var a = 2.5;
var b = 1.5e3;

var c = float64ToFloat32( float64ToFloat32( a ) + float64ToFloat32( b ) );

Double-precision in C:

double a = 2.5;
double b = 1.5e3;

double c = a + b;

Single-precision in C:

float a = 2.5f;
float b = 1.5e3f;

float c = a + b;

Along with these, some updates were also made in existing packages to make sure they are up to the mark.

Project recap

I started out with adding the C implementations for various base special mathematical functions. I generated a topological sort using:

node ./lib/node_modules/@stdlib/_tools/pkgs/toposort/bin/cli $PWD/lib/node_modules/@stdlib/math/base

to identify all the dependencies, with the help of which I made this dependency diagram. With the help of this diagram, I was able to work on those packages first, which could unlock several others. For instance, most of the trigonometric functions were dependent on rempio2, and thus it was among the first ones to be focused upon. After I completed most of the C implementations, I moved towards adding single-precision variants for the packages whose double-precision variants we already had.

In order to develop the C implementations or to add single-precision packages, I followed the steps which were explained in the previous section.

Completed work

TODO: include a list of links to all relevant PRs along with a short description for each. For small bug fix PRs, you can group them together and describe them as, e.g., "various maintenance work".

Everything that I did till now can be categorized in four major categories:

Let us have an overview for each one of them:

Adding C implementations for various base special mathematical functions:

Adding single-precision variants of pre-existing functions:

Adding new packages:

Various other maintenance work:

Current state

TODO: add a summary of the current state of the project.

What remains

TODO: add a summary of what remains left to do. If there is a tracking issue, include a link to that issue.

Challenges and lessons learned

TODO: add a summary of any unexpected challenges that you faced, along with any lessons learned during the course of your project.

Conclusion

TODO: add a report summary and include any acknowledgments (e.g., shout outs to contributors/maintainers who helped out along the way, etc).

Clone this wiki locally