Accept owned arrays in `concatenate` and `stack`
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 45/100
Research direction
Start by reading the current concatenate and stack entry points and their signatures. Check how they accept views, how owned arrays would fit, and what happens for an empty slice. Done means the proposed API works for owned arrays and views without leaving the documented inference concern unresolved.
Written by the indexing model from the issue text.
Description
It would be convenient to be able to call concatenate or stack with a slice of owned arrays or array views, rather than just views currently.
So for concatenate, this:
let arrays = vec![a, b, c]; // more realistically, this would be returned by a function
let arrays = arrays.iter().map(|a| a.view()).collect::<Vec<_>>();
let res = ndarray::concatenate(Axis(2), &arrays);
would become:
let arrays = vec![a, b, c];
let res = ndarray::concatenate(Axis(2), &arrays);
This could be done by changing the signature of concatenate to the following, which would allow either views or owned arrays:
-pub fn concatenate<A, D>(axis: Axis, arrays: &[ArrayView<A, D>]) -> Result<Array<A, D>, ShapeError>
+pub fn concatenate<S, D, A>(axis: Axis, arrays: &[ArrayBase<S, D, A>]) -> Result<Array<A, D>, ShapeError>
where
+ S: Data<Elem = A>,
A: Clone,
D: RemoveAxis,
{
This is technically a breaking API change though, at least in the niche case of passing an empty slice as a parameter (which causes a type inference error). Before I open an unsolicited PR, would there be interest in this change?
- Dominant language
- Rust
- Stars
- 4.3k
- Forks
- 391
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-ndarray/ndarray
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rust-ndarray/ndarray#1612 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rust-ndarray/ndarray#1617 · 1 comment ·
-
bug good first issue
Difficulty 3/5 1-2 days Newbie friendliness 68/100
rust-ndarray/ndarray#1615 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
rust-ndarray/ndarray#1610 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
rust-ndarray/ndarray#1609 ·
All issues in rust-ndarray/ndarray
Similar issues
-
todo:perf
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
ACP agents get no MCP servers when the thread is created before the project's first worktree loads Openstate:needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
zed-industries/zed#64611 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
ontola/atomic-server#1625 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
objectionary/phie#154 ·