Design for the subtensor_engine and current work

[kannavkm]

This is a comparatively detailed description of my proposal with the results of the experiments that Cem and I talked about for the subtensor_engine. Firstly, I'll outline the generic proposal that I propose for the future. Hence, as the design is to be prepared for extending and the second part, I'll outline the work I have done.

Design

Span

basic_span<class derived_type>
The base span class from which all the span classes derive, as discussed, if different types of span classes have to be defined then.

Span Classes

strided_span<class size_type = size_t> : basic_span<self_type> this would take care of contiguous span i.e. step = 1 and strided span step > 1 with special placeholder for end of range.

Currently, I have been using the span types present, but rather than two different types for strided/non-strided spans, I believe that one would suffice.

non_strided_span<class size_type = size_t> : basic_span<self_type> this would be to take care of non strided span such as index.

Tensor Engine Type

The next question Cem discussed and I was to try out the various template parameters for the subtensor_engine specifically and what requirements to put on the template parameter.

• subtensor_engine<engine_type, spans...>
• subtensor_engine<tensor_type, spans....>
• subtensor_engine<engine_type>
• subtensor_engine<tensor_type>

Specifically, we would like to cover all the requirements of tensor_core since that is what will be using the subtensor_engine as its template parameter. So, we must provide a const/non-const iterator, reference, and pointer types. Therefore we require the above types from the template parameter. The const nature of these types would be dependent on the const nature of the parent tensor. So to get that nature, we would require the parent tensor type to be the template parameter. Therefore our final template declaration looks like follows.

template<class tensor_type, class ... spans>

Note: I'd like to discuss the inclusion of the span parameter pack in another post, along with the iterator design.

But in my earlier implementation, I only kept the engine type as the template parameter and had a read-write tag to specify the const non-const nature as mentioned in the wiki. In my earlier design, I coded a helper function subtensor to create the entity of type tensor_core<subtensor_engine<engine_type, read_write_tag, class .. spans> the read-write tag would be determined via this helper function based on the parent tensor. My notion of doing it like this was to cover the case of creating a const view of a non-const tensor and then keeping the engine_type as less was better. So I wanted to have a better discussion regarding this.

Any thoughts/comments are extremely welcome.

[kannavkm]

To clarify, in the last paragraph, I don't think that a helper function is beneficial in any way, just that I had written one to iterate faster.