Add segmented array type

[MarcelKoch]

This PR adds a class to store a segmented array. A flat ginkgo array is partitioned into multiple segments by an additional index offset array. The segment i starts within the flat buffer at index offsets[i], and ends (exclusively) at index offsets[i + 1]. The class only provides access to the flat buffer and the offsets.

Used in: #1543

PR Stack:

• [x] #1545
• [ ] #1543
• [ ] #1579
• [ ] #1544
• [ ] #1588
• [ ] #1589

---

Old Description

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.

[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.

[sonarcloud[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 ?