PRs and feature requests: avoid shallow contributions; what do we include?

[jonaspleyer]

This issue discusses which contributions and feature requests should be considered worth adding to ndarray and which changes should be avoided.

Note that this discussion evolves around adding new functionality and does not apply to changes such as "fixed typo", "bump version of dependency XYZ", bugfixes etc.

Background

I have recently opened a PR #1482 to add a new function which produces a view with swapped axes. This addition replaces two lines by one for users but will harm discoverability if more methods like this should be added in the future.
In order to avoid such PRs and feature requests in the future, we should discuss possible guidelines as to what is considered a "shallow" addition and should be omitted.

Ideas for Guidelines

Replaced Lines of Code

My own PR replaces

let mut aview = array.view();
aview.swap_axes(a, b);

with

let aview = array.swap_axes_view(a, b);

which is a very minor change. In my opinion, most changes which reduce N<=3 -> 1 line without adding any new functionality should be flagged as "probably too shallow".

Impact

Even if the number of lines replaced is small, the impact could be very large for frequent uses.

What do you think?

[nilgoyette]

I agree with what you wrote, notably with "guideline" and "probably" because it's kinda impossible to provide a precise rule for this.

Moreover, I would add "It must help the average user of ndarray". Some features should go in ndarray-stats. Some PR (like this one, imo) should go in another project (sometimes there's no other project). In brief, some features should be offered in the ndarray ecosystem, but not directly by ndarray.

[akern40]

I'd agree with both of you. I also think there's a difference between ndarray and packages like NumPy or PyTorch, one that creates a tension that I've been wondering about. In the Python frameworks, speed comes from implementations in C(++); so if you want a new function to be fast, it has to be implemented in the framework. Rust and ndarray are a different beast, though: given some core functionality (e.g., ::map), you can write a lot of functions yourself. So should ndarray be in the business of providing functions like floor and abs? We already provide some of these; should we provide them all?

My answer right now is that there's a lot of foundational work (shape/stride refactoring and a lazy API) that take precedence. But down the line, I am partial to the idea of an ndarray-core which provides limited functionality, then something like ndarray-numpy to provide the full sweet of Python Array API-compliant methods (although there are questions there, too, like when to break from the Python API in favor a more "Rusty" approach).

[nilgoyette]

I am partial to the idea of an ndarray-core

Interesting. This would solve the current discussion. I might move the debate to: "It this or that function core?", but I believe it's an easier debate. I certainly think it's a good idea! As you wrote though, Rust is a different beast than Python. When coding ndarray-ndimage, I had to accept not offering some parameters because they just don't fit in Rust. I mean, they could be added, but in a "class builder" style, not in a function style.