Add shuffle_axis_inplace and shuffle_axis_inplace_using

[LukeMathWalker]

Other two simple functions that I think might useful when working with arrays.

Should we add also sampling_axis and sampling_axis_using as convenient shims for

let a = self.clone();
a.shuffle_axis_inplace(axis);
a

?

[bluss]

We are modifying through read-only/shared array views and this is invalid, unless we have interior mutability (i.e using Cell, Mutex or similar).

And we'd like to avoid iter().zip() for ndarray, because it is much slower than it needs to be, we have Zip.

[bluss]

I'm working on making ArrayView<Cell<T>, D> a reality, a conversion we can use sometimes, - it allows us to have.. more fun like this. :)

[LukeMathWalker]

We are modifying through read-only/shared array views and this is invalid, unless we have interior mutability (i.e using Cell, Mutex or similar).

On the other hand the method is taking a mutable reference to self, hence we are guaranteed to be the only ones operating on the array - we are opting out of the compiler safety guarantees because we know that two slices are not overlapping and that we have a unique handle on the data, hence the references are valid and to the outside world the operation should be safe.
Or am I interpreting this incorrectly?

[bluss]

Modifying through an ArrayView (without the Cell exception) is invalid full stop, because we treat it as we would treat a &[T] or &T. (We could go into details and exceptions at another time, maybe there's some argument for a more lenient view?)

[bluss]

x is a &T but we are modifying through it. That's not permitted.

Exceptions would come in to place if you somehow got a raw pointer out of an array view, maybe you'd then be able to make an argument. But since we go through explicit shared references here, we are at invalid full stop.

[LukeMathWalker]

Given the S: DataMut trait bound on the method, aren't we dealing with an ArrayViewMut, which is equivalent to a &mut [T]?
Just trying to truly understand, I am not trying to argue 😅

[bluss]

Sure, no problem. The types matter and there are shared refs used on the path to the swap. If we read the rust reference document this is UB, we can't just cast from &T and mutate.

[bluss]

Most pressing is to fix the shuffle/swap code, so that it respects borrowing/mutability rules.

Remember “unsafe code isn’t for violating Rust’s invariants, it’s for maintaining them manually”

[bluss]

Shuffle the array's xyz along axis.

We need a name for it, not sure if it should be slices. For the .lanes(axis) method we call them lanes - but those are perpendicular to axis in that case.

[bluss]

I'd be tempted to call them planes. We shuffle among the items in an AxisIter, right? Each such item is n - 1 dimensional in an ndarray.

That said it's good to have 2D explanations - how to shuffle rows and columns.

[LukeMathWalker]

An alternative name could be projections, which has the plus of not carrying an intuitive dimensionality along with it (I think 2D when I read planes).

[bluss]

This is a good starting point (not actually -- too technical and talks about a model that is not canon)
In Rust, a shared reference is more than a pointer.

http://smallcultfollowing.com/babysteps/blog/2017/02/01/unsafe-code-and-shared-references/

[bluss]

ArrayView<Cell<..>> would actually be useful here - and is not so far off - because Cell::<T>::swap is an allowed method for all T (unlike .get() which is restricted to T: Copy). But there are other tools that should make it possible to write the equivalent code with ArrayViewMut, too.

Not sure about how to solve this. Another way would be to make one permutation as a vector of len_of(axis) and then apply that permutation identically to every lane in lanes_mut(axis). But that hinges on applying permutations quickly, and I don't know about that.

[bluss]

How to make an ArrayView<Cell<T>

See lines 14-15

ndarray/tests/raw_views.rs

Lines 14 to 15 in 6b38810

	let raw_cell_view = a.raw_view_mut().cast::<Cell<f32>>();
	let cell_view = unsafe { raw_cell_view.deref_into_view() };

and mind the lifetime of the conversion. Note we go through RawArrayViewMut<T, D> into ArrayView<Cell<T>, D>.

The conversion in std that looks like this is: &mut T -> &Cell<T> https://doc.rust-lang.org/nightly/std/cell/struct.Cell.html#method.from_mut

[LukeMathWalker]

Wouldn't #717 be enough to get this method written in safe Rust?
Both slices would be mutable, hence I could get mutable reference to their elements and swap them using std::mem::swap.

[bluss]

Maybe, and split at or axis iter mut could also make it possible.

With slicing I think we'd struggle too much to construct the slice argument, not sure?

[LukeMathWalker]

I tried to get it done with slicing and I am indeed struggling to construct the slice argument 😅