feat: add unary function database in math/special/data

[gunjjoshi]

---

type: pre_commit_static_analysis_report
description: Results of running static analysis checks when committing changes. report:

• task: lint_filenames status: passed
• task: lint_editorconfig status: passed
• task: lint_markdown status: na
• task: lint_package_json status: na
• task: lint_repl_help status: na
• task: lint_javascript_src status: na
• task: lint_javascript_cli status: na
• task: lint_javascript_examples status: na
• task: lint_javascript_tests status: na
• task: lint_javascript_benchmarks status: na
• task: lint_python status: na
• task: lint_r status: na
• task: lint_c_src status: na
• task: lint_c_examples status: na
• task: lint_c_benchmarks status: na
• task: lint_c_tests_fixtures status: na
• task: lint_shell status: na
• task: lint_typescript_declarations status: na
• task: lint_typescript_tests status: na
• task: lint_license_headers status: passed ---

Resolves None.

Description

What is the purpose of this pull request?

This pull request:

• adds the unary function database in math/special/data, as per https://github.com/stdlib-js/stdlib/pull/7773/files#r2337722847.

Related Issues

Does this pull request have any related issues?

This pull request:

• resolves 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

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
math/special	$\color{green}51/51$ $\color{green}+100.00\%$	$\color{green}1/1$ $\color{green}+100.00\%$	$\color{green}0/0$ $\color{green}+100.00\%$	$\color{green}51/51$ $\color{green}+100.00\%$

The above coverage report was generated for the changes in this PR.

[kgryte]

In thinking about this, if we don't have dedicated kernels for particular dtypes (except for "generic"), we shouldn't include them in the list of scalar kernels.

In the generation script, I believe we try to find the nearest "compatible" scalar kernel based on type promotion, correct? In which case, for int16 and int8 here, we'd infer that labs should be used.

[kgryte]

Thanks for putting together an initial draft, @gunjjoshi. Left some initial comments for clean-up.

[gunjjoshi]

Thanks for having a look, @kgryte. I have updated the PR. Now,

• We have only specialized scalar kernels mentioned, i.e., the dtype is listed only if it has a dedicated scalar kernel.
• The output field inside policies now includes generic too, for all functions that contain generic in input dtypes.

[kgryte]

LGTM after some minor clean-up. Let's go ahead and get this in, and we can make changes in follow-up PRs/commits.