PermutedDimsArray, and layout for dense 1st index #12
Conversation
Codecov Report
@@ Coverage Diff @@
## master #12 +/- ##
==========================================
+ Coverage 61.14% 61.34% +0.20%
==========================================
Files 8 8
Lines 700 727 +27
==========================================
+ Hits 428 446 +18
- Misses 272 281 +9
Continue to review full report at Codecov.
|
src/memorylayout.jl
Outdated
| """ | ||
| FirstMajor | ||
|
|
||
| const FirstUnion = Union{FirstMajor, AbstractColumnMajor} |
There was a problem hiding this comment.
I don't think this needs to be in ArrayLayouts.jl: I tend to avoid union types due to compile time type inference issues (though something this simple won't be impacted to that) and its only used in one place.
If there's a strong reason to keep it, it needs a more descriptive name.
There was a problem hiding this comment.
OK, I removed this for now.
The argument for it is that you would almost never want to dispatch on UnitStride{1} and exclude ColumnMajor, it just happens that there's no abstract type which fills this role.
There was a problem hiding this comment.
Hmm, I'm tempted to remove IncreasingStrides and define
const ColumnMajor = UnitStride{1}though perhaps some more thought is needed...
There was a problem hiding this comment.
Do you mean ColumnMajor = Union{DenseColumnMajor, UnitStride{1}} as a replacement for AbstractColumnMajor?
One could also re-organise the type tree so that these two share a supertype. Does anything care about increasing strides, as opposed to just DenseColumnMajor or UnitStride{1}?
However I also need UnitStride{2}, and clearly the tree can't depend on D.
|
Looks good! If you address the minor comments and get the code coverage tests passing I'll merge. |
Closes #10
Not entirely sure whether
SecondMajorwill be needed in the end. (Nor what named things should have.)