dst step is not handled and not checked.

Do you mean I should check whether dst steps are the same with src steps?

Yes, btw in case of ROI we could just overlap not from the beggining. @alalek do we have a method that checks if mats are non-overlapping?

Perhaps there is no such method.
We could do simple check overlap between .data / .dataend here (it is not fully accurate, e.g. for 1d cases)

I think we should just check if .datas are equal (if it's the start of the allocation, might be .datastart instead). It's not ideal for roi-to-roi in the same matrix without overlaps, but I'm not sure there is a platform-independent solution to check if memory regions overlap(without UB).

Ideally speaking, we should check ROI overlaps but who would do that intentionally? Such operations do not make sense. Or if we are talking about unintentionally mis-operation, it is what it is as long as it does not trigger crashing.

Generally I agree, but in this case it doesn't cost us anything to change ptr() to datastart.

I re-implemented with dst in-place flip and also ensuring both src and dst are continuous. In this case, I suppose we can skip checking whether steps are equal, can't we?

ROI handing of src/dst/src+dst should be added.

I don't quite understand what ROI handling is here. Examples?

Take a look on OCL_TEST_P(Transpose, Mat) test design (input data generation).

So if I understand correctly, case of non continuous input mat should be tested. Correct me if I am wrong.

Right. ROI means region of interest - it is a sub-matrix from larger matrix.

However, for ND case this may be not really useful. In 2D case we have flip().
Anyway, we still need to provide checks for that (contiguous data assumption) in the source code of implementation.

Anyway, we still need to provide checks for that (contiguous data assumption) in the source code of implementation.

I don't think the implementation assumes that data is contiguous.

Do we still need checks for ROI handling since in the latest impl src and dst are assumed to be continuous?

Isn't +1 redundant? In case of shape [A, 3, B]: (3+1)/2=2, but we need only 1 swap.

You are right. +1 is removed in the latest commit.

We don't need this special case, I think.

It serves like an early stop to improve efficiency, doesn't it?

To be honest, I don't know what we are winning here - one function frame that will do exactly this? I think copying is much slower than calling a function. @alalek can you elaborate?

I think copying is much slower than calling a function

function itself is heavier than simple copying.

There is no problem with that part. Refer to convertTo() implementation.

I believe we can lift that restriction.

I think so. I also lifted the restriction for dst since it will be covered by calling src.copyTo(dst) and be continuous in the end.