12.18 Tensor Operation Compatibility

Tensor Operation Compatibility is the umbrella body of requirements a tensor, or a pair of tensors, must satisfy before a given tensor algebra operation may be legitimately applied to it, encompassing agreement of variance type, agreement of the underlying base field or ring, agreement of the specific vector space an operation's auxiliary data (such as a source map) is defined relative to, and dimensional agreement wherever an operation pairs indices or slots across separate objects. It functions as the precondition layer sitting beneath every specific tensor operation — projection, inclusion, extension, pullback, pushforward, contraction, and the tensor product itself — collecting into one coherent framework the various compatibility checks each operation independently requires before its defining formula produces a meaningful result.

Categories of Compatibility Requirement

Variance Type Compatibility

Every tensor carries a variance type (p,q) recording its contravariant and covariant slot counts, and operations such as contraction, pullback, and pushforward each impose their own specific requirement on this type before they apply — contraction needs at least one slot of each variance, pullback needs purely covariant input, pushforward needs purely contravariant input. This category of compatibility is detailed fully in the study of tensor operation type compatibility specifically.

Base Field or Ring Compatibility

Two tensors, or a tensor and the auxiliary linear map an operation depends on, must be defined over the same base field or ring (or related by an explicit, specified homomorphism, as in scalar extension) before operations combining them make sense. A tensor over the real numbers and a tensor over a finite field, with no specified connecting homomorphism, admit no meaningful combined operation between them.

Ambient Space Compatibility

Operations that combine two separate tensors, such as the tensor product or a bilinear pairing, require the tensors to be defined on spaces that are either identical or explicitly related — for instance, one being a designated subspace of the other via an inclusion. Attempting to contract a tensor on V against a tensor on an unrelated space U, with no specified map connecting V and U, leaves the intended operation without a well-defined formula to apply.

Compatibility as a Precondition for Specific Operations

Contraction's Index-Pairing Requirement

Contracting a contravariant slot i against a covariant slot j requires both slots to range over bases indexed by the same set — ordinarily guaranteed by both slots belonging to tensor powers of the same space V and its dual — since the contraction sums over a shared index k. Compatibility here means the two paired slots must literally share an index range for the summation to be well-defined.

Pullback and Pushforward's Source Map Requirement

Both the pullback and the pushforward require a specific linear map f connecting the domain of the input tensor to the space the operation transports it toward; the tensor and the map must agree on which space plays the role of domain and which plays the role of codomain, matching the roles fixed by the tensor pullback source map and the tensor pushforward source map respectively.

Direct Sum Compatibility for Injection-Projection Pairs

The injection and projection maps associated with a direct sum are compatible with each other, and with the ambient direct sum, only when they are built from the same underlying decomposition V = V₁ ⊕ ... ⊕ Vₙ; mixing an injection built from one direct-sum decomposition with a projection built from an unrelated decomposition of the same space generally fails to satisfy the retraction and annihilation identities central to the injection-projection pair.

Diagram of Compatibility as a Gate Before Operation

Consequences of Verifying Compatibility First

Errors Are Caught Before Computation Begins

Checking compatibility as an explicit, separate step before applying a tensor operation converts a potential downstream numerical error, or worse, a meaningless computed value passed off as a real answer, into an immediate and localized failure at the point where the mismatch actually originates — an incompatible variance type, an unrelated base ring, or an unconnected ambient space.

Compatibility Enables Safe Composition of Operations

When several tensor operations are chained together, verifying that each operation's output satisfies the compatibility requirements of the next operation in the chain is what guarantees the overall composite expression is well-defined end to end, rather than merely well-defined at each individual step in isolation.

Relationship to the Individual Operations' Own Requirements

A Unifying Perspective, Not a Replacement

Tensor operation compatibility does not replace the specific requirements documented separately for each operation — the embedding map role for inclusions, the linear map role for projections, the type compatibility for contraction, pullback, and pushforward — but instead names the common pattern these separate requirements all instantiate, allowing them to be recognized, taught, and checked using one unified vocabulary rather than as unrelated, operation-specific rules.

A Starting Point for Diagnosing Ill-Defined Expressions

When an attempted tensor computation fails to produce a sensible result, checking compatibility — variance type, base ring, ambient space, and any operation-specific index-pairing requirement — in that order is a systematic way to locate which precondition was violated, before assuming the failure reflects an error in the underlying mathematics of the operation itself.