12.18.1 Tensor Operation Type Compatibility

Tensor Operation Type Compatibility ensures valid algebraic interactions by aligning tensor types through precise index and dimension rules.

Tensor Operation Type Compatibility is the requirement that the variance type of a tensor — how many contravariant and covariant slots it has — match what a given tensor operation expects before that operation may be applied, together with the accounting rules describing how the variance type of the output is determined from the variance types of the inputs. It is the type-checking discipline underlying tensor algebra: an operation such as contraction, tensor product, pullback, or pushforward is only well-defined when its inputs carry the variance type that operation's formula presupposes, and violating this requirement produces expressions with no consistent mathematical meaning rather than merely an unexpected numerical answer.

Variance Type as the Basic Compatibility Criterion

Notation for Mixed Tensor Type

T_{q}^{p} (V)

A tensor of type (p,q) has p contravariant slots and q covariant slots, and this pair of numbers is the basic label used to check compatibility before applying any tensor operation. Two tensors, or a tensor and an operation, are type-compatible only when their declared (p,q) labels satisfy whatever relationship the intended operation requires.

Compatibility Requirement for the Tensor Product

T_{q_{1}}^{p_{1}} \otimes S_{q_{2}}^{p_{2}} \in T_{q_{1} + q_{2}}^{p_{1} + p_{2}}

The tensor product operation places no restriction on the variance types of its two inputs — any type (p₁,q₁) is compatible with any type (p₂,q₂) — but it does impose a definite rule for the resulting type, adding contravariant and covariant slot counts separately. Type compatibility for the tensor product is therefore trivially satisfied for any pair of inputs, while the output type is nonetheless fully determined.

Compatibility Requirements for Slot-Specific Operations

Contraction Requires One of Each Variance

contraction : T_{q}^{p} ​ ​ \to ​ ​ T_{q - 1}^{p - 1}

Contraction pairs one contravariant slot with one covariant slot and sums over a shared basis index. This operation is only defined when the tensor being contracted has at least one slot of each variance available to pair; a purely covariant or purely contravariant tensor, having no slot of the opposite variance, is type-incompatible with contraction and the operation simply does not apply to it.

Pullback Requires Purely Covariant Input

f^{*} : T_{k}^{0} (W) ​ ​ \to ​ ​ T_{k}^{0} (V)

The ordinary pullback operation is only type-compatible with tensors of type (0,k) — purely covariant tensors — since its defining formula pre-composes every argument slot with the source map f, a substitution meaningful only for slots that consume vectors as input. A tensor with a nonzero contravariant count p > 0 is type-incompatible with the ordinary pullback.

Pushforward Requires Purely Contravariant Input

f_{*} : T_{0}^{k} (V) ​ ​ \to ​ ​ T_{0}^{k} (W)

By the dual argument, the ordinary pushforward is type-compatible only with purely contravariant tensors of type (k,0), since it applies the source map directly to each factor, a substitution meaningful only for slots holding output vectors rather than argument positions.

Diagram of Type Compatibility Across Operations

Consequences of Type Incompatibility

Ill-Defined Formulas When Types Mismatch

Attempting to pull back a tensor with a nonzero contravariant count using the ordinary pullback formula produces an expression in which the source map is asked to act on a slot that does not accept vector arguments, yielding no valid mathematical expression at all rather than an incorrect but well-formed one. Type incompatibility of this kind is a categorical error, not a computational one.

Extended Operations Requiring Additional Structure

Some operations can be extended to accommodate otherwise-incompatible types, but only by introducing further assumptions: pulling back a mixed tensor's contravariant slots, or pushing forward a mixed tensor's covariant slots, requires f to be invertible so that f⁻¹ supplies the missing direction of transport for the otherwise-incompatible slots. Such extensions are separate constructions built on top of type compatibility rather than relaxations of the compatibility requirement itself.

Verifying Type Compatibility Before Combining Operations

Chaining Operations Requires Matching Output and Input Types

When several tensor operations are applied in sequence, the output type of each operation must be checked against the input type required by the next. For instance, contracting a type-(2,1) tensor down to type-(1,0) produces a purely contravariant tensor, which is then type-compatible with a subsequent pushforward but not with a subsequent ordinary pullback.

Bookkeeping Rank and Variance Jointly

Because several operations, such as contraction, change both the total rank and the specific counts of contravariant and covariant slots, verifying type compatibility along a chain of operations requires tracking the full pair (p,q) at each stage rather than only the total rank p+q, since two tensors of the same total rank but different variance splits are not interchangeable inputs for variance-sensitive operations such as contraction, pullback, or pushforward.