feat!: add writable parameter to ndarray/base/remove-singleton-dimensions

[headlessNode]

---

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: na
• 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 stdlib-js/metr-issue-tracker#151.

Description

What is the purpose of this pull request?

This pull request:

• add writable parameter to ndarray/base/remove-singleton-dimensions

Related Issues

Does this pull request have any related issues?

This pull request has the following related issues:

• Resolves [BUG]: add writable parameter to ndarray/base/remove-singleton-dimensions metr-issue-tracker#151

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.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

{{TODO: add disclosure if applicable}}

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
ndarray/base/remove-singleton-dimensions	$\color{green}136/136$ $\color{green}+0.00%$	$\color{green}6/6$ $\color{green}+0.00%$	$\color{green}1/1$ $\color{green}+0.00%$	$\color{green}136/136$ $\color{green}+0.00%$

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

[kgryte]

This parameter is somewhat in conflict with the note at L74. Namely, if we return a provided ndarray unchanged, then the writable parameter is ignored.

[kgryte]

We have a couple of choices. 1) Always return a new view of the input ndarray. 2) Update the docs here to indicate that the writable parameter will be ignored if the input ndarray doesn't have any singleton dimensions. 3) Pursue (1) plus add the package maybe-remove-singleton-dimensions where this new package does what this package does now, which is returns an input ndarray unchanged iff an input ndarray has no singleton dimensions.

The original rationale for sometimes returning the original input ndarray is for performance, as ndarray view creation is expensive. Having a maybe-* prefix makes this behavior explicit similar to maybe-broadcast-array, etc.

That seem reasonable to you, @headlessNode?

[headlessNode]

@kgryte So, we add a maybe- prefix to this package and add the remove-singleton-dimensions package which always return a new view?

[kgryte]

@headlessNode That doesn't quite make sense. It means copy the current package to maybe-* and then modify the existing package to always return a view.

[kgryte]

Also means that we'll need a follow-up PR to migrate all current downstream usage to use the maybe-* package.

[headlessNode]

@kgryte I've modified the current package to always return a new view. I think adding the maybe-* package and updating downstream usage should be separate PR?

[kgryte]

Correct. Adding and updating should actually be two separate PRs (in addition to the current PR).

[kgryte]

Left initial comments.

[kgryte]

Left initial comments.

[kgryte]

For METR, initial review

review_time: 15 mins