Skip to content

Releases: rust-ndarray/ndarray

ndarray-rand 0.16.0

04 Nov 00:46
ndarray-rand-0.16.0
0e1d04b

Choose a tag to compare

This release of ndarray-rand adds compatibility for the new ArrayRef type in ndarray 0.17. It adds the the new RandomRefExt trait, providing sample_axis and sample_axis_using methods on ArrayRef.

This release also bumps the requirements for rand to 0.9.0 and for rand_distr to 0.5.0.

0.17.1

02 Nov 22:20
0.17.1
66dc0e1

Choose a tag to compare

Version 0.17.1 provides a patch to fix the originally-unsound implementation of the new array reference types.

The reference types are now all unsized. Practically speaking, this has one major implication: writing functions and traits that accept RawRef and LayoutRef will now need a + ?Sized bound to work ergonomically with ArrayRef. For example, the release notes for 0.17.0 said

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>)
where S: Data<Elem = f64>;

Use AsRef / AsMut for best compatibility:

fn alter_shape<T>(a: &mut T)
where T: AsMut<LayoutRef<f64>>;

However, these functions now need an additional bound to allow for callers to pass in &ArrayRef types:

fn alter_shape<T>(a: &mut T)
where T: AsMut<LayoutRef<f64>> + ?Sized; // Added bound here

A huge thank you to Sarah Quiñones (@sarah-quinones) for catching the original unsound bug and helping to fix it. She does truly excellent work with faer-rs; check it out!

0.17.0 [YANKED]

14 Oct 22:02
6cd209b

Choose a tag to compare

Version 0.17.0 (2025-10-14) [YANKED]

Note: 0.17.0 was yanked due to a bug in the reference type implementation that could cause use-after-free. That bug was fixed in 0.17.1. All the changes listed here are once again available in 0.17.1, with a small caveat for the reference types. See the release notes for 0.17.1 for details.

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>)
where S: Data<Elem = f64>;

Use AsRef / AsMut for best compatibility:

fn alter_shape<T>(a: &mut T)
where T: AsMut<LayoutRef<f64>>;

(Accepting a LayoutRef directly can cause unnecessary copies; see #1440.)

Reading / Writing Unsafe Elements: RawRef<A, D>

RawRef augments RawArrayView and RawArrayViewMut for power users needing unsafe element access (e.g. uninitialized buffers). Like LayoutRef, it is best used via AsRef / AsMut.

Added

Changed

  • remove_index can now be called on views, in addition to owned arrays by @akern40

Removed

  • Removed the serde-1, test, and docs feature flags; by @akern40 #1479
    • Use approx,serde,rayon instead of docs.
    • Use serde instead of serde-1

Fixed

  • last_mut() now guarantees that the underlying data is uniquely held by @bluss #1429
  • ArrayView is now covariant over lifetime by @akern40 #1480, so that the following code now compiles
fn fn_cov<'a>(x: ArrayView1<'static, f64>) -> ArrayView1<'a, f64> {
    x
}

Documentation

  • Filled missing documentation and adds warn(missing_docs) by @akern40
  • Fixed a typo in the documentation of select by @Drazhar
  • Fixed a typo in the documentation of into_raw_vec_and_offset by @benliepert
  • Documented Array::zeros with how to control the return type by @akern40

Other

0.16.1

14 Aug 17:39

Choose a tag to compare

Version 0.16.1 (2024-08-14)

  • Refactor and simplify BLAS gemm call further by @bluss #1421
  • Fix infinite recursion and off-by-one error in triu/tril by @akern40 #1418
  • Fix using BLAS for all compatible cases of memory layout by @bluss #1419
  • Use PR check instead of Merge Queue, and check rustdoc by @bluss #1420
  • Make iterators covariant in element type by @bluss #1417

0.16.0

03 Aug 18:05
84fe611

Choose a tag to compare

Version 0.16.0 (2024-08-03)

Featured Changes

  • Better shape: Deprecate reshape, into_shape by @bluss #1310

    .into_shape() is now deprecated.
    Use .into_shape_with_order() or .to_shape() instead, which don't have into_shape's drawbacks.

New Features and Improvements

Tests, CI and Maintainer tasks

Read more