Add array collection type

[MarcelKoch]

This PR adds a type collection::array which is a std::vector like class that stores multiple arrays. These arrays are all subviews of a shared buffer.

I think technically this could be considered as a batch::array, but I'm not sure if we want to go that way. As a batch::array this would interleave the dependencies between the batched and non-batched stuff, and I'm not sure if that is a good idea.

Used in: #1543

[upsj]

Do you actually need these individual sub-ranges to be materialized as array views? Because otherwise this is just the typical row_ptr - col_idxs structure, and we might be better served with a fully functional std::span replacement and a range-of-ranges interface

[MarcelKoch]

At least for CPU kernels the arrays are quite handy. But you're right, something like std::span would be better suited.

[upsj]

I've had it in my mind to provide a nice abstraction over these segmented arrays (including range-for support) for a while already, if you want I can resurrect my prototype code

[MarcelKoch]

Sure, if it's not too much work, we could use that. I can also take that over if you want.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
6 New issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[MarcelKoch]

~~@upsj maybe this could be formulated using ranges and accessors. Accessing the segmented array could be thought of as [i][j], where i is the array index, and j the index within the array. But I don't know enough of ranges and accessor to judge if that would be appropriate.~~

I don't think that is a good abstraction, since the size per dimension isn't constant.

[MarcelKoch]

@upsj I don't think this will change with the segmented ranges at all. The ranges are only relevant on the backend side. The index_map has this type as constructor parameter, and accessors to it, so I would not put it into the detail namespace.

[pratikvn]

Maybe also update the PR name ?