|Re: [eigen] [Review] Pull request 66, Huge Tensor module improvements|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
For that (simple) case it would just be
Tensor<float, 3> T(Array3i(1,2,3));
Thats with integers instead of ptrdiff, but so was your C++11
example. And it is currently limited to 4 dimensions.
I do agree that the C++11 syntax is nicer, and I would definitely
not object supporting std::array if it is available -- my question
was basically, if there is a need to partially re-implement
std::array if it does not give additional features compared to
We should allow any type exposing the right interface. For instance
the SparseMatrix::reserve() function accept any "integer array"
exposing a size() and operartor(int). This way one can use
std::vector, Eigen::ArrayXi, Eigen::ArrayXi::Constant, or some
customized objecst computing the sizes procedurally.
For public APIs I completely agree, but in the current code, we also
need a data type for the storage (m_dimensions in TensorStorage) and
internal argument passing, i.e. writePacket(coeffs, value).
If we use Eigen::Array for that, then we have the problem that if we
want to merge MultiDimArray and Array later, we have to be really
careful about not causing an infinite recursion.
OTOH, since we have to special-case single-coefficient accessors anyway
and fixed-size arrays don't store their dimensions in their storage,
this might still work.
I'll think about it some more for a while...