Version conflict with ndarray 0.16.0

[Silzinc]

Hello. As it seems, using ndarray 0.16.0 (latest now) breaks some implementations in ndarray-linalg, such as ndarray_linalg::solve::Inverse (see picture below using rust-analyzer diagnostic). I don't know if it was planned to solve it already but I put it here. Thank you in advance for solving this !

Dependencies :

[dependencies]
nalgebra = "0.33.0"
ndarray = "0.16.0"
ndarray-linalg = "0.16.0"
num-traits = "0.2.19"
rand = "0.8.5"

[shigedangao]

@termoshtt it seems that you are the owner of the crate. Would it be possible to take a bit of time to bump the crate ? 😄

[akrutsinger]

For what it's worth, just ran into the same kind of incompatibility with my library. In my library, I'm also using ndarray-stats which requires ndarray v0.16. Below is simple example showing the method that can't be found for ArrayBase.

Code

use ndarray::array;
use ndarray_linalg::svd::SVD;

fn main() {
    let a = array![[4.20, 6.9], [6.9, -4.20],];
    let (u, s, vt) = a.svd(true, true).unwrap();
}

Visual Studio Code Error

cargo build error

error[E0599]: no method named `svd` found for struct `ArrayBase` in the current scope
   --> src/main.rs:6:24
    |
6   |     let (u, s, vt) = a.svd(true, true).unwrap();
    |                        ^^^
    |
help: there is a method `std` with a similar name, but with different arguments
   --> /home/austyn/.cargo/registry/src/index.crates.io-6f17d22bba15001f/ndarray-0.16.1/src/numeric/impl_numeric.rs:207:5
    |
207 | /     pub fn std(&self, ddof: A) -> A
208 | |     where A: Float + FromPrimitive
    | |__________________________________^

Cargo.toml

[package]
name = "svd"
version = "0.1.0"
edition = "2021"

[dependencies]
ndarray = "0.16"
ndarray-linalg = "0.16.0"

[RS-yifan]

mark the same problem

[danvonk]

Has anyone solved this problem yet?

[Silzinc]

For those really dying to use advanced linear algebra techniques in Rust, I can advise looking at faer. The maintainer does regular devstreams to develop the project, and its performances are really great when compared to usual linear algebra libraries (BLAS, LAPACK, etc...).

[akrutsinger]

I indirectly solved my problem by switching to nalgebra. Probably not the answer you're looking for. Honestly, for my use case ndarray was probably overkill anyway; nalgebra is much more fitting for me because I only ever need 1 or 2 dimensional arrays. When nalgebra doesn't implement some convenience function for the DMatrix type I'm using, it's really simple to implement my own function(s) for the DMatrix type to use in my library.

I did try forking ndarray-linalg and changing the versions to match (there are a few other forks that do this too), but when it came time to compile ndarray-linalg with my library, some of the underlying libraries ndarray-linalg relies on broke. I don't remember the specifics now and I didn't take much time fiddling around to get things to compile before switching to nalgebra and not yet looking back.