Update ndarray requirement from 0.16 to 0.17

[dependabot]

Updates the requirements on ndarray to permit the latest version.

Release notes

Sourced from ndarray's releases.

0.17.0

Version 0.17.0 (2025-10-14)

Version 0.17.0 introduces a new array reference type — the preferred way to write functions and extension traits in ndarray. This release is fully backwards-compatible but represents a major usability improvement. The first section of this changelog explains the change in detail.

It also includes numerous new methods, math functions, and internal improvements — all credited below.

A New Way to Write Functions

TL;DR

ndarray 0.17.0 adds new reference types for writing functions and traits that work seamlessly with owned arrays and views.

When writing functions that accept array arguments:

• Use &ArrayRef<A, D> to read elements from any array.
• Use &mut ArrayRef<A, D> to modify elements.
• Use &T where T: AsRef<LayoutRef<A, D>> to inspect shape/stride only.
• Use &mut T where T: AsMut<LayoutRef<A, D>> to modify shape/stride only.

All existing function signatures continue to work; these new types are fully opt-in.

Background

ndarray has multiple ways to write functions that take arrays (a problem captured well in issue #1059). For example:

fn sum(a: ArrayView1<f64>) -> f64;
fn sum(a: &ArrayView1<f64>) -> f64;
fn sum(a: &Array1<f64>) -> f64;

All of these work, but having several equivalent forms causes confusion. The most general solution, writing generically over storage types:

fn sum<S>(a: &ArrayBase<S, Ix1>) -> f64
where S: Data<Elem = f64>;

is powerful but verbose and often hard to read. Version 0.17.0 introduces a new, simpler pattern that expresses the same flexibility more clearly.

Solution

Three new reference types make it easier to write functions that accept any kind of array while clearly expressing what kind of access (data or layout) they need.

Reading / Writing Elements: ArrayRef<A, D>

ArrayRef is the Deref target of ArrayBase. It behaves like &[T] for Vec<T>, giving access to elements and layout. Mutability is expressed through the reference itself (& vs &mut), not through a trait bound or the type itself. It is used as follows:

fn sum(a: &ArrayRef1<f64>) -> f64;
fn cumsum_mut(a: &mut ArrayRef1<f64>);

(ArrayRef1 is available from the prelude.)

Reading / Writing Shape: LayoutRef<A, D>

LayoutRef lets functions view or modify shape/stride information without touching data. This replaces verbose signatures like:

fn alter_view<S>(a: &mut ArrayBase<S, Ix1>)
</tr></table> 

... (truncated)

Changelog

Sourced from ndarray's changelog.

Version 0.17.0 (2025-10-14)

Version 0.17.0 introduces a new array reference type — the preferred way to write functions and extension traits in ndarray.
This release is fully backwards-compatible but represents a major usability improvement.
The first section of this changelog explains the change in detail.

It also includes numerous new methods, math functions, and internal improvements — all credited below.

A New Way to Write Functions

TL;DR

ndarray 0.17.0 adds new reference types for writing functions and traits that work seamlessly with owned arrays and views.

When writing functions that accept array arguments:

• Use &ArrayRef<A, D> to read elements from any array.
• Use &mut ArrayRef<A, D> to modify elements.
• Use &T where T: AsRef<LayoutRef<A, D>> to inspect shape/stride only.
• Use &mut T where T: AsMut<LayoutRef<A, D>> to modify shape/stride only.

All existing function signatures continue to work; these new types are fully opt-in.

Background

ndarray has multiple ways to write functions that take arrays (a problem captured well in issue #1059). For example:

fn sum(a: ArrayView1<f64>) -> f64;
fn sum(a: &ArrayView1<f64>) -> f64;
fn sum(a: &Array1<f64>) -> f64;

All of these work, but having several equivalent forms causes confusion. The most general solution, writing generically over storage types:

fn sum<S>(a: &ArrayBase<S, Ix1>) -> f64
where S: Data<Elem = f64>;

is powerful but verbose and often hard to read. Version 0.17.0 introduces a new, simpler pattern that expresses the same flexibility more clearly.

Solution

Three new reference types make it easier to write functions that accept any kind of array while clearly expressing what kind of access (data or layout) they need.

Reading / Writing Elements: ArrayRef<A, D>

ArrayRef is the Deref target of ArrayBase. It behaves like &[T] for Vec<T>, giving access to elements and layout. Mutability is expressed through the reference itself (& vs &mut), not through a trait bound or the type itself. It is used as follows:

fn sum(a: &ArrayRef1<f64>) -> f64;
fn cumsum_mut(a: &mut ArrayRef1<f64>);
</tr></table> 

... (truncated)

Commits

• 6cd209b Release ndarray 0.17.0 (#1529)
• b4e7658 Update configurations for cargo-release (#1528)
• 8a39cad Add a changelog for Version 0.17.0 (#1527)
• 0d75035 Add nextest to our latest dependencies CI check (#1526)
• a44d71f Fills missing documentation and adds warn(missing_docs) (#1525)
• aa135d4 Document Array::zeros with how to control the return type (#1524)
• a141f37 Remove as many feature = "std" gates in tests as possible (#1522)
• 07bedad Moves scripts and CI/CD to nextest (#1514)
• 62a0ebb Fix docs and miri tests (#1523)
• 3ce0134 Updates to Edition 2021 (#1513)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)