composition(A, B) returns a layout that violates R(i) == A(B(i)) when divisibility fails — expected, or a missing check?

[arpiku]

My mental model (corrections welcome):

• A CuTe layout is a function from a (hierarchical) integer domain to integers (Edit: The co-domain can be formed by any valid "integer-semimodule");
  the algebra is developed in Paper 1 and
  Paper 2.
• I read composition(f, g) as f ∘ g, so the contract should be
  composition(f, g)(i) == f(g(i)) for all i ∈ [0, size(g)) — provided
  the admissibility (stride/shape divisibility) preconditions hold.

What I see:

auto f = make_layout(make_shape(_4{}, _4{}), make_stride(_3{}, _5{})); // (4,4):(3,5)
auto g = make_layout(Int<20>{}, _3{});                                 // 20:3

auto fog = composition(f, g);  // (_2,_10):(_9,_5) --> Is this OK? Should it have failed, or this is expected? 
auto gof = composition(g, f);  // (_4,_4):(_9,_15) --> I understand this one. 

for (int i = 0; i < size(fog); ++i)
    std::cout << "fog(" << i << ")=" << fog(i)
              << "  f(g(" << i << "))=" << f(g(i)) << "\n";
for (int i = 0; i < size(gof); ++i)
    std::cout << "gof(" << i << ")=" << gof(i)
              << "  g(f(" << i << "))=" << g(f(i)) << "\n";

Output (trimmed):

fog(0)=0   f(g(0))=0
fog(1)=9   f(g(1))=9
fog(2)=5   f(g(2))=11      <-- diverges here
fog(3)=14  f(g(3))=13
...
gof(0)=0   g(f(0))=0
gof(15)=72 g(f(15))=72     <-- matches throughout

The confusion:

• gof = composition(g, f) = (4,4):(9,15) satisfies gof(i) == g(f(i)) for all i. As expected.
• fog = composition(f, g) = (2,10):(9,5) does not: it diverges from
  f(g(i)) at i = 2. So the returned layout isn't f ∘ g.
• I'd expect f ∘ g to be inadmissible: composing f with g's mode
  20:3 strides through f by 3, but f's leading shape is 4 and 3 ∤ 4.

Questions:

1. Given divisibility fails, is (2,10):(9,5) just "garbage out" from a violated
   precondition (i.e. my responsibility to check), or should composition have
   rejected it?
2. The docs say these conditions are "statically checked when possible." With
   fully static operands (_4, Int<20>, _3), I'd have hoped for a
   static_assert here — is this a case that can't be caught, or a gap?
3. Is there a recommended predicate to test admissibility before composing, so I
   can guard my own call sites?

The issues 2133, and 2411, are also exploring the opposite of this doubt, where valid composition raise assertion errors.

Environment:

• CUTLASS commit e406c186…, tag v4.5
• CUDA 12.8 (nvidia/cuda:12.8.0-devel-ubuntu24.04), gcc 14, RTX 5070 (sm_120)
• nvcc -std=c++17 --expt-relaxed-constexpr --extended-lambda -arch=sm_120 -I.../cutlass/include
• Experimenting (Rough) Repo: https://github.com/arpiku/cute_tut

[ccecka]

composition(g,f) fails the "mutually segregated images" precondition, which is needed to ensure that concatenation distributes over composition:

g o (f1, f2) = (g o f1, g o f2)

This is documented in the paper, but unfortunately is not checked in CuTe C++.

[arpiku]

Ok, thank you for the insight.