Athan

@aman-095 Are you planning on adding the C/Fortran implementation to this PR or in a follow-up PR?

@aman-095 Looks like in your refactoring commit, you removed the C/Fortran implementation. Was this intentional?

@itskdhere I'm not opposed the addition of various constants; however, my guess is that we'd need to resolve package organization before actually adding any of the specified constants. E.g., they...

Also, can you articulate why you want these particular constants? Typically, we've only added constants as we've needed them. This RFC proposes adding them for their own sake and is...

I wonder if it would make sense instead to follow the dictionary API found in SciPy instead, as done for CODATA.

> any particular reason why we are not using scripts/evalPoly.js here? No. This was likely an oversight during the initial implementation. I did a quick check and it looks like...

@USERSATOSHI I'd consult other packages in `math/base/special` which have a scripts directory and contain a script for `evalpoly`. That script is more or less the same for every relevant package...

@USERSATOSHI I think it is better to skip the script refactoring and just leave as is. We can always revisit in the future if, and when, we need to update...

@gunjjoshi You should now have permissions to take over this PR and directly edit/commit. LMK if not.

As touched on in the OP it would be similar to [`@stdlib/utils/omit`](https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/utils/omit), so a list of nested key paths and maybe something like [`@stdlib/utils/deep-pluck`](https://github.com/stdlib-js/stdlib/blob/develop/lib/node_modules/%40stdlib/utils/deep-pluck/lib/main.js), which supports an options object. I...