Open correaa opened 2 years ago
Nice to see you again @BobSteagall , the library I mentioned is now in Github (moved from Gitlab) and in preparation for a Boost review.
https://github.com/correaa/boost-multi
It also has "adaptors" to call BLAS/LAPACK (also cuBLAS, cuSolver), FFTW (cuFFT) (1D and multidimensional) but this is separate from the traits discussion above.
Hi @BobSteagall and @hatcat ,
I have been testing your reference implementation to use my https://gitlab.com/correaa/boost-multi as a storage engine.
MULTI is a general purpose container of dynamic arrays for arbitrary dimension, focuses only on dense strided memory layouts. One of the principles of the library is that dimensionality of anything wuth dimension D can be seen also as something of dimension D - 1 of elements of higher dimension; therefore allowing generic programming in multiple dimensions. It also is agnostic to linear algebra applications.
So, in some aspect is more general than the LA proposal engines (arbitrary dimensionality) and is some aspects it is less ambitious (no linear algebra, no fancy or sparse storage strategies). The good thing is that I believe the storage and view engine concept should also be independent of the LA operations, so the intersection of the two projects is the case of D = 2 (and perhaps D = 1).
With this in mind, I added this simple test to verify the constraints and already I find some incompatibilities out of the box (I am using the branch
r7z
)I get out the box these 3 initial errors which I think can help both improve my library and also the LA proposal, see my comments interleaved:
ok, my arrays have
M2D::reference
andM2D::element_type
typedefs but you expect a different meaning from them. We have a common meaning forelement_type
which is the type of the elements, e.g. scalar. However in my library,reference
is an object of lower dimension, not necessarily a scalar.The logic behind this is that I want to view
A
as a 1D container of arrays of dimension 1D from the point of view of access and iteration.For example
My suggestion is that
reference
is renamed toelement_ref
orelement_reference
in the proposal, which I can also add to my library (I already useelement_ref
,element_cref
,element_ptr
andelement_const_ptr
.(My logic also applies to
value_type
,multi::array<double, 2>::value_type
is preciselymulti::array<double, 1>
, just to give another example. This is consistent becausemulti::array<double, 2>::reference
is convertible tomulti::array<double, 2>::value_type
)As far as I see, the engine concept doesn't need to support subviews of views of lower dimension, that is fine, but a clear meaning of "reference" would be helpful.
Same argument for
const_reference
, I suggest to rename it toelement_const_reference
orelement_cref
.Due to constraints and tradeoffs that occur in multiple dimensions (in general) I do not support space reservation. Therefore the concept of
capacity
, separated fromsizes
or the number of elements is non-existent. Of course I could add a trivialcapacity
function but that will send the message that my library supports space reservation.More importantly, how does it concern to a LA library if the storage engine supports
capacity
or space reservation in general? I understand that resizing may be supported to perform inplace changes in the extensions of the matrices but I think in that case, "resizing" alone is the required operation.Incidentally, in my library I call it
.reextent({nx, ny, ... })
, I don't use the word.resize
because I don't provide amortized operations likestd::vector
does and I don't want to give the impression I do. The only virtue ofreextent
is doing element preservation.Ok, that is what I have for now. Let me know if you want to talk about this points, I am available in Slack too.
To illustrate the reference/element problem I have the following code test:
also available here: https://gitlab.com/correaa/boost-multi/-/blob/master/test/concepts.cpp