feat: add math/base/special/kernel-log1p

[gunjjoshi]

Description

What is the purpose of this pull request?

This pull request:

• adds math/base/special/kernel-log1p.

Related Issues

Does this pull request have any related issues?

None.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

---

@stdlib-js/reviewers

[gunjjoshi]

Code coverage report:

For the code coverage report, we are not able to get inside the branch when x = 0.0. This is because, when x = 0.0, in the parent kernelLog function, that means f = 0.0, which means the execution will go into L90 of main.js, rather than reaching below for the polyeval functions.

[kgryte]

Not being able to reach inside the polynomial functions is fine. We could write tests specifically for the polyval modules, but that seems like overkill for now.

[kgryte]

@gunjjoshi Okay. I've updated this PR. Note that I've done so based on msun v12.2.0. We should go ahead and update log2 and log10 accordingly based on 12.2.0, as well. Given that msun renamed this kernel function from log to log1p, we should follow suit.

It's still misleadingly misnamed IMO, and, in contrast to things like kernel-sin, this package is more of a helper function which only makes sense based on the implementations of log2 and log10. It's unlikely to be more generally useful. Nevertheless, I'm still fine with adding, as it reduces code duplication for log2 and log10.

As mentioned in my comment above, hard to test this function against reference implementations as doesn't really make sense on its own. So, I've effectively introduced smoke tests to ensure no accidental changes leading to regressions.

At this point, I think this is ready, but you should give it another look through to ensure that I haven't missed anything. If all looks good to you, I'll go ahead and merge. And once merged, if you want to take on refactoring log2 and log10, that would be great!

[gunjjoshi]

@gunjjoshi Okay. I've updated this PR. Note that I've done so based on msun v12.2.0. We should go ahead and update log2 and log10 accordingly based on 12.2.0, as well. Given that msun renamed this kernel function from log to log1p, we should follow suit.

It's still misleadingly misnamed IMO, and, in contrast to things like kernel-sin, this package is more of a helper function which only makes sense based on the implementations of log2 and log10. It's unlikely to be more generally useful. Nevertheless, I'm still fine with adding, as it reduces code duplication for log2 and log10.

As mentioned in my comment above, hard to test this function against reference implementations as doesn't really make sense on its own. So, I've effectively introduced smoke tests to ensure no accidental changes leading to regressions.

At this point, I think this is ready, but you should give it another look through to ensure that I haven't missed anything. If all looks good to you, I'll go ahead and merge. And once merged, if you want to take on refactoring log2 and log10, that would be great!

Thanks for looking into this @kgryte. I tried to go through all the changes thoroughly, everything seems fine.
Once this gets merged, I will be refactoring log2 and log10. We can then just import kernel-log1p into both of these packages and directly use them, rather than having the older implementations in them as we have now.

[kgryte]

@gunjjoshi Thanks for reviewing. I'll merge once CI finishes.