stdlib-js
feat: add `stats/mannwhitneyu`
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: passed
- task: lint_package_json status: passed
- task: lint_repl_help status: passed
- task: lint_javascript_src status: passed
- task: lint_javascript_cli status: na
- task: lint_javascript_examples status: passed
- task: lint_javascript_tests status: passed
- task: lint_javascript_benchmarks status: passed
- 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: passed
- task: lint_typescript_tests status: passed
- task: lint_license_headers status: passed Resolves None.
Description
This pull request:
feat : add stats/mannwhitneyu
Related Issues
This pull request has the following related issues:
- https://github.com/stdlib-js/stdlib/issues/293
Questions
No.
Other
No.
Checklist
- [x] Read, understood, and followed the contributing guidelines.
AI Assistance
- [x] Yes
- [ ] No
How was AI assistance used?
- [ ] Code generation
- [ ] Test/benchmark generation
- [ ] Documentation
- [x] Research and understanding
Disclosure
AI assistance was used for research only.
@stdlib-js/reviewers
Coverage Report
| Package | Statements | Branches | Functions | Lines |
|---|---|---|---|---|
| stats/mannwhitneyu | $\color{green}433/433$ $\color{green}+100.00%$ |
$\color{red}71/72$ $\color{green}+98.61%$ |
$\color{green}4/4$ $\color{green}+100.00%$ |
$\color{green}433/433$ $\color{green}+100.00%$ |
The above coverage report was generated for the changes in this PR.
Hey @stdlib-js/reviewers,
The CI failure looks unrelated to this PR. The R workflow stops before evaluating my changes due to a deprecated lintr rule:
Error: Linter extraction_operator_linter was deprecated in lintr version 3.2.0.
Could you provide guidance on how you’d like this handled in the R workflow?
Also, should I update the copyright year for this type of packages ?
@DivyanshuVortex Thanks for this PR. However, this is an instance where some up-front discussion could have been useful. While your implementation largely mirrors what can be found in ttest and other packages, we're planning on moving away from that implementation pattern in order to support multi-dimensional arrays (i.e., ndarrays). This isn't yet reflected in the top-level stats API stats/ztest, but if you examine stats/strided/ztest, this should give you an idea of where we are heading. In other words, to first implement stats/mannwhitneyu, we'd first need to implement lower-level strided array APIs (e.g., stats/strided/dmannwhitneyu, stats/strided/smannwhitneyu, stats/strided/mannwhitneyu and all associated helper utilities. Once all those are in place, we could then move on to the top-level API.
@kgryte , Thanks for the clarification. I’d like to work on this and understand the lower-layer implementation in more depth, so I want to make sure I have the complete picture before proceeding.
From what I understand, the required components before adding the top-level stats/mannwhitneyu API are:
• @stdlib/stats/strided/dmannwhitneyu
• @stdlib/stats/strided/smannwhitneyu
• @stdlib/stats/strided/mannwhitneyu
• @stdlib/stats/base/ndarray/mannwhitneyu (dtype dispatcher)
Can you confirm whether this list is complete, or if there are additional strided/ndarray packages needed for Mann–Whitney U?
If this is a larger effort than expected, please let me know whether you recommend taking this on, or if it would be better for me to focus on a different package for now.
@DivyanshuVortex I suggest studying the stats/strided/*ztest and stats/strided/*ztest2 packages. One thing you'll find is https://github.com/stdlib-js/stdlib/tree/develop/lib/node_modules/%40stdlib/stats/base/ztest which provides a collection of helper packages which are used across the ztest strided packages. We'd probably need to do something similar for Mann-Whitney, but tailored to the expected results object, alternatives, etc, of the Mann-Whitney test.
One other addendum is that, rather than mannwhitneyu, we'd probably name mann-whitney-u for readability (e.g., dmann-whitney-u, smann-whitney-u, etc, with alias dmannWhitneyU, smannWhitneyU, mannWhitneyU, etc).
Hey @kgryte , I’d like to implement this end-to-end starting from the low-level helpers and progressing upward in small, reviewable PRs. I will begin with the alternative hypothesis utilities (alternatives, alternative-str2enum, alternative-resolve-enum, alternative-resolve-str) and move sequentially toward the result factories and strided computation [ same like the architecture used in ztest/ztest2 ] . Building from the bottom ensures correctness, maintainability, and consistency with Stdlib’s internal architecture.
Requesting approval to proceed with this bottom-up implementation plan.