Implement element preserving `resize` in 1d about xtensor

[spectre-ns]

@tdegeus Yes I have a couple guys on our staff thinking it worked like std::vector is there a limitation to doing this on the underlying storage?

[spectre-ns]

@tdegeus The bottom level storage is just linear memory. Could it be implemented with a std::vector to propagate STL behaviour to some of the interface methods?

[tdegeus]

I think even that mostly the underlying IS std::vector so there are surely many cases where we could fix resize to propagate downstream properties. In addition, it would be nice to add push_back to xt::xtensor<T, 1>. Beyond that, were you thinking about more features?

[spectre-ns]

I think in ND we could implement a greedy concatenate using std::vector::insert to avoid the current performance issues.

[tdegeus]

From the implementation I think that the underlying resize is used:

xtensor/include/xtensor/xutils.hpp

Line 341 in 5f49f64

c.resize(size);

So I think that for xtensor and xarray resize is item preserving. Could you comment @JohanMabille ?

Edit I tried, indeed elements are not conserved. Yet, as indicated, at first glance I don't see where elements are modified.

[spectre-ns]

@tdegeus I just read the gitter channel and it sounds like it is deferred to the container implementation. How do you propose ensuring that the implementation be element preserving?

[tdegeus]

I have no idea yet ;)

[JohanMabille]

Actually the default container for xtensor and xarray is not std::vector, but uvector, which does not preserve its elements when resized.

Anyway, the resize with preserving should be independent from the dimension of the tensor, and should not make any assumption regarding the underlying container. One way to implement it would be to compute the "intersection" shape, and then recursively loop over to copy from the first vector to the other one, and eventually swap the vectors.

(I'll try to post some code later)

[spectre-ns]

@JohanMabille why is std::vector<T> not the underlying data structure? I've had a couple colleagues encounter issues with resizing containers expecting the same behaviour as std::vector<T>.