`eval` flavors

[SylvainCorlay]

Numpy has the functions numpy.ascontiguousarray and numpy.asfortranarray.

Currently, in xtensor-blas, we have a view_eval which is passing through things that have a raw data interface, but should really behave like numpy.ascontiguousarray or numpy.asfortranarray.

I guess that we could have a

template<layout_type L=xt::layout_type::any, class E>
return_type contiguous(E&&)

which would basically

1. if L = layout_type::any (the default with unspecified ):
   • pass-through anything that has a static contiguous layout already
   • behave like contiguous<XTENSOR_DEFAULT_LAYOUT> otherwise.
2. if L = layout_type::row_major:
   • for objects that have a raw data interface a. pass them through if they have a runtime layout of row_major (they are already row-major-contiguous) b. return a container otherwise
   • return a container otherwise
3. if L = layout_type::column_major:
   • for objects that have a raw data interface a. pass them through if they have a runtime layout of column_major (they are already column-major-contiguous) b. return a container otherwise
   • return a container otherwise

The difficulty is with unifying the return type of a and b in both cases.

One way to do this is to make it return a [xarray/xtensor]_adaptor on a new buffer adaptor type, which would be the same type for owning and non-owning cases, where the owning would be a runtime attribute set in the constructor.

[SylvainCorlay]

Moving this upstream in xtensor would allow xtensor-blas to make use of it instead of the view_eval.

[SylvainCorlay]

Another thought

• This could be called contiguous instead of eval.
• the current eval is not only meant for this but to flatten the expression tree so that there is no more closure. While this would not do it in case of a view.
• also for the latter use case, an expression like linspace does not depend on closure can can safely be returned from a function without an eval.