Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC]: Add C implementation for @stdlib/stats/base/dists/t/mean #3874

Closed
3 tasks done
Planeshifter opened this issue Dec 13, 2024 · 1 comment · Fixed by #3922
Closed
3 tasks done

[RFC]: Add C implementation for @stdlib/stats/base/dists/t/mean #3874

Planeshifter opened this issue Dec 13, 2024 · 1 comment · Fixed by #3922
Labels
Accepted RFC feature request which has been accepted. C Issue involves or relates to C. difficulty: 2 May require some initial design or R&D, but should be straightforward to resolve and/or implement. Feature Issue or pull request for adding a new feature. Good First Issue A good first issue for new contributors! priority: Normal Normal priority concern or feature request. RFC Request for comments. Feature requests and proposed changes. Statistics Issue or pull request related to statistical functionality.

Comments

@Planeshifter
Copy link
Member

Planeshifter commented Dec 13, 2024

Description

This RFC proposes adding a C implementation, including a Node.js native addon, C benchmarks, and C examples, for the @stdlib/stats/base/dists/t/mean package.

When adding support, the following tasks should be completed:

  1. A C source implementation should be added to a src folder within the package's directory.
  2. A native add-on interface should be added in order to call the C implementation from JavaScript.
  3. A JavaScript file should be added to the lib folder to allow benchmarking and unit testing the native implementation from JavaScript.
  4. A new test file should be created which includes unit tests testing against expected behavior.
  5. C benchmarks should be added which measure performance for the C source implementation.
  6. A file containing C examples should be added to demonstrate example usage.
  7. JavaScript benchmarks should be added which measure performance for the native add-on.
  8. Build and configuration files should be added to allow compiling and running the C source implementation using project make commands (as documented below).
  9. The README should be updated to include documentation for the added C API.

To provide a concrete example of what a PR adding the desired method should contain, see #3354, which is a PR adding a C implementation for the CDF of an arcsine distribution. This should provide an idea of what is expected.

Prerequisites

  1. Review JavaScript implementation in lib/main.js and its required modules to identify all stdlib functions used.
  2. Verify C implementations exist for each required function.

Related Issues

#3355

Questions

No.

Other

Once the implementation is ready including C examples and benchmarks, we should be able to run the following make commands.

Build native add-on

NODE_ADDONS_PATTERN="@stdlib/stats/base/dists/t/mean" make install-node-addons

Run C examples

make examples-c-files FILES="$(pwd)/lib/node_modules/@stdlib/stats/base/dists/t/mean/examples/c/example.c"

Run C benchmarks

make benchmark-c-files FILES="$(pwd)/lib/node_modules/@stdlib/stats/base/dists/t/mean/benchmark/c/benchmark.c"

Run JavaScript benchmarks

make benchmark-javascript-files FILES="$(pwd)/lib/node_modules/@stdlib/stats/base/dists/t/mean/benchmark/benchmark.native.js"

Run all tests

make TESTS_FILTER=".*/@stdlib/stats/base/dists/t/mean/.*" test

Notes

  • If you are interested in contributing a PR which addresses this RFC and are a first-time contributor or not yet familiar with our project conventions, please minimize the submission of LLM-generated code. Please consult our contributing guidelines and the associated development guide. Failure to respect project conventions will result in your PR being rejected without review. Thank you for understanding!

Checklist

  • I have read and understood the Code of Conduct.
  • Searched for existing issues and pull requests.
  • The issue name begins with RFC:.
@Planeshifter Planeshifter added Accepted RFC feature request which has been accepted. C Issue involves or relates to C. difficulty: 2 May require some initial design or R&D, but should be straightforward to resolve and/or implement. Feature Issue or pull request for adding a new feature. Good First Issue A good first issue for new contributors! priority: Normal Normal priority concern or feature request. RFC Request for comments. Feature requests and proposed changes. Statistics Issue or pull request related to statistical functionality. labels Dec 13, 2024
@stdlib-bot
Copy link
Contributor

🚨 Important: PLEASE READ 🚨

This issue has been labeled as a good first issue and is available for anyone to work on.

If this is your first time contributing to an open source project, some aspects of the development process may seem unusual, arcane, or some combination of both.

  1. You cannot "claim" issues. People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
  2. We have a very high bar for contributions. We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.

Before working on this issue and opening a pull request, please read the project's contributing guidelines. These guidelines and the associated development guide provide important information, including links to stdlib's Code of Conduct, license policy, and steps for setting up your local development environment.

To reiterate, we strongly encourage you to refer to our contributing guides before beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.

Setting up your local development environment is a critical first step, as doing so ensures that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. If you would prefer to avoid manual setup, we provide pre-configured development containers for use locally or in GitHub Codespaces.

We place a high value on consistency throughout the stdlib codebase. We encourage you to closely examine other packages in stdlib and attempt to emulate the practices and conventions found therein.

  • If you are attempting to contribute a new package, sometimes the best approach is to simply copy the contents of an existing package and then modify the minimum amount necessary to implement the feature (e.g., changing descriptions, parameter names, and implementation).
  • If you are contributing tests, find a package implementing a similar feature and emulate the tests of that package.
  • If you are updating documentation, examine several similar packages and emulate the content, style, and prose of those packages.

In short, the more effort you put in to ensure that your contribution looks and feels like stdlib—including variables names, bracket spacing, line breaks, etc—the more likely that your contribution will be reviewed and ultimately accepted. We encourage you to closely study the codebase before beginning work on this issue.

✨ Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions. ✨

Planeshifter added a commit that referenced this issue Dec 15, 2024
PR-URL: #3922
Closes: #3874

Co-authored-by: Philipp Burckhardt <pburckhardt@outlook.com>
Reviewed-by: Philipp Burckhardt <pburckhardt@outlook.com>
Signed-off-by: Philipp Burckhardt <pburckhardt@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted RFC feature request which has been accepted. C Issue involves or relates to C. difficulty: 2 May require some initial design or R&D, but should be straightforward to resolve and/or implement. Feature Issue or pull request for adding a new feature. Good First Issue A good first issue for new contributors! priority: Normal Normal priority concern or feature request. RFC Request for comments. Feature requests and proposed changes. Statistics Issue or pull request related to statistical functionality.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants