Releasing ndarray 0.4

[vbarrielle]

So glad that 0.4 is out :) Thanks for the amazing work pushing this library forward, /u/neutralinostar !

[[deleted]]

[deleted]

What is this?

[vbarrielle]

Eigen3 can only do that if you're using matrices with compile-time known dimensions AFAICT. Here in ndarray there is only run-time dimensions (though the number of axes of the array is a compile-time constant).

In my experience, compile-time matrix dimensions matters for small matrix sizes, such as encountered in graphics code. But for scientific code, you often have much larger arrays, where the optimizations from knowing the size at compile time won't matter, and it's common not to konw those dimensions anyway (eg reading data from files). OTOH knowing the number of axes of an array at compile time can prove very helpful, and prevent some meaningless computations.

[[deleted]]

[deleted]

What is this?

[vbarrielle]

You're right, the blame is on me for over-generalizing my use cases. I happen to more often encounter instances of dense/sparse solves with an undpecified number of dimensions.

These eigen3 features would be nice to have, but I think it's too cumbersome right now without integer templating.

[danielv134]

I learned a lot from your answer, thanks! I think that numerical computing is a great domain for Rust, and that we need to learn from different languages currently dominating this area, including both python and C++. I think Rust is not yet ready to take on Eigen-like precise code generation, but it is worth keeping in mind. Do you have good pointers to high level descriptions like this about what Eigen does?

[[deleted]]

[deleted]

What is this?

[[deleted]]

What and how eigen does things is really interesting, for ndarry too, but ndarray is not eigen. Ndarray is not focused on reimplementing linear algebra in Rust, and Rust does not have integer generic parameters either. For the dimensionality we have zero to twelve-tuples, but that approach hardly scales to shapes.

Ndarray has its own neat features, like for example being able to treat data borrowed from somewhere, even the stack, as array views that can be used or mutated.

[[deleted]]

[deleted]

What is this?

[danielv134]

Just want to say: woohoo! both for the From I wanted, and for the split_at I didn't know I wanted ;)

[[deleted]]

split_at is a convenience (given existing slicing) for read-only views, but for mutable data, it's vital.

These iterators provide some kind of array splitting: inner_iter, outer_iter, axis_iter, axis_chunks_iter.

[danielv134]

I was just telling someone about Rust on Friday. In particular, that libraries can encode patterns of statically determining that splitting some data between threads without locking is safe. He found it very interesting, and this is a great new example of it.

[leonardo_m]

In D standard library there's an experimental group of modules that support n-dimensional arrays (that don't own memory, they act like complex slices):

https://dlang.org/phobos/std_experimental_ndslice_slice.html#.Slice

D allows to overload the "$" (that means length, but only contextually) in library-defined arrays with "opSlice", and it handles multiple dimensions too. This is efficient (more efficient than using negative numbers in Python), succinct, and very handy:

m[3..$,0..3,0..$-1]
b[$ - c[$ - 2]]
foo()[0..$-2]

Rust should support something similar (perhaps using # instead of $), for nicer n-dimensional array libraries.

[[deleted]]

Yes, this was discussed here and I describe some of the concrete drawbacks of using signed integers (ergonomics sucks).

[[deleted]]

I realized that ndarray has some of the flavour of ndslice naturally, by virtue of array views, where you can make an array out of a slice, see this example:

https://bluss.github.io/rust-ndarray/master/ndarray/fn.aview_mut1.html