GSoC 2024 ‐ Gunj Joshi

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:

• FreeBSD
• Cephes
• Boost and a few others.

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 ) )

• Replacing certain functions used in reference implementations with their stdlib equivalents. For instance, replacing scalbn in FreeBSD implementation for rempio2 by ldexp, which is the appropriate stdlib equivalent.
  

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, I also made updates in existing packages to make sure they are up to the mark.

Project recap

TODO: add a summary of what you did

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".

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).