Tensor Interface: Computation & Physics

• Tensor Interface is an abstraction layer that maps tensor notations and diagrams to executable operations in computational and physical contexts.
• It removes manual index bookkeeping by encoding connectivity, labels, and storage constraints, leading to optimized contraction and factorization strategies.
• It supports multiple designs—from graphical interfaces to low-level APIs—enhancing rapid prototyping, portability, and error prevention.

A tensor interface is an abstraction layer that maps tensor notation, tensor-network diagrams, or tensor-storage descriptors to executable operations such as contraction, factorization, permutation, and assembly. In the literature, the term spans several related but non-identical meanings: graphical user interfaces for drawing tensor networks and generating code, programming interfaces that encode index semantics directly in tensor objects, low-level application binary interfaces for dense or sparse tensor kernels, application-oriented portability layers for tensor-network codes, and, in some areas of physics, a literal interface whose tensor structure carries physical information (Evenbly, 2019, Fishman et al., 2020, Brandejs et al., 12 Jan 2026, Yang et al., 2023).

1. Semantic range and design goals

Across software systems, tensor interfaces are designed to remove manual index bookkeeping, expose contraction structure at the level of diagrams or labels, and decouple application logic from particular tensor back ends. TensorTrace is described as an “interpreter” between schematic tensor-network diagrams and optimized executable code; ITensor models its interface on tensor diagram notation and rules out common programming errors; the sparse-tensor compiler work in taco develops an interface that is agnostic to tensor formats; TAPP is introduced to address the absence of a universal standard interface for tensor operations; and TCI is presented as an application-oriented, lightweight application programming interface for framework-independent tensor-network applications (Evenbly, 2019, Fishman et al., 2020, Chou et al., 2018, Brandejs et al., 12 Jan 2026, Sun et al., 30 Dec 2025).

The resulting design goals are recurrent. They include rapid prototyping, automatic contraction-order selection, correctness under nontrivial index permutations, portability across hardware and software stacks, and extensibility to symmetry, sparsity, and different decomposition families. This suggests that “tensor interface” is best understood not as a single API design, but as a family of mechanisms that shift tensor computation from manual axis management toward declarative descriptions of connectivity, labels, and storage constraints.

Category	Representative systems	Characteristic abstraction
Graphical construction	TensorTrace (Evenbly, 2019), GuiTeNet (Sahlmann et al., 2018)	users “draw” tensor networks or manipulate nodes and legs
Index- or label-centric programming	ITensor (Fishman et al., 2020), Cytnx (Wu et al., 2024)	contraction by matching Index objects or labels rather than positions
Format/layout abstraction	taco (Chou et al., 2018), xGETT (Hörnblad, 2024)	explicit level formats, strides, contracted modes, and output permutations
Standardized low-level ABI	TAPP (Brandejs et al., 12 Jan 2026)	backend-agnostic C interface with descriptors, plans, and execution
Application portability layer	TCI (Sun et al., 30 Dec 2025)	a well-defined type system and minimal set of core functions
Physical interface encoded by tensors	MERA/TFD (Matsueda et al., 2012), FM/AFM Néel tensor (Yang et al., 2023)	interface entropy or interfacial torque carried by tensor structure

2. Graphical and diagrammatic interfaces

TensorTrace is an integrated software system for the rapid design, optimization and code generation of tensor-network contractions. Its front end is a lightweight, cross-platform drawing canvas in which users place tensor nodes, attach blue-numbered anchors corresponding to index slots, and connect anchors with colored edges representing internal or open indices. Open indices carry green-numbered plaques that fix the index ordering on the final output tensor. The back end parses the drawing into a data structure, performs a heuristic-pruned brute-force search for a low-cost contraction sequence, and emits ready-to-run MATLAB, Python or Julia code invoking the standard ncon contractor (Evenbly, 2019).

A central feature of TensorTrace is the collapse of the usual three-step workflow of manual diagram labeling, hand optimization of index orderings, and coding of nested loops. For networks with $N \le 10$, practical global optimality is targeted; for larger networks, “quick,” “thorough” and “extensive” scope modes explore only the most promising partial sequences. The pairwise contraction cost is estimated by

$$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$

and, more precisely, if $A$ has indices $a \cup c$ and $B$ has $b \cup c$, contracting over $c$ costs

$\prod_{k \in a \cup b \cup c} D_k.$

The paper reports that small networks typically compile instantaneously, “sub-second on a 3 GHz CPU,” and that in MERA environments the optimizer can reduce total FLOPs by orders of magnitude, for example from $O(D^8)$ to $O(D^5)$ (Evenbly, 2019).

GuiTeNet occupies a similar graphical niche but with a different execution model. It runs directly in web browsers, represents tensors as circular nodes with attached legs, and uses small integer leg labels to indicate the ordering of tensor dimensions. Contractions are specified by snapping together leg tips, and the system instantly generates Python/NumPy source code for the hitherto sequence of user actions. Its elementary operations are contraction, general transposition, QR decomposition, and singular-value decomposition; internally, these actions form nodes in a directed acyclic graph, enabling parallel scheduling of independent elementary operations, merging consecutive contractions into a single einsum, transpose fusion, and caching of repeated subnetworks (Sahlmann et al., 2018).

Taken together, these systems show that a graphical tensor interface is not merely a visualization layer. It can serve as a formal front end for contraction optimization, code generation, and algebraic normalization of user actions.

3. Index objects, labels, and tensor-diagram semantics

ITensor provides a programmatic tensor interface modeled explicitly on tensor diagram notation. Every tensor index is an Index object carrying a dimension, a 64-bit unique id, optional tags, a prime level, and, for quantum-number indices, quantum-number subspaces and an arrow direction. Two Index objects compare equal only if they have the same id, same tags, and same prime level. In this model, contraction is written with the * operator: connected legs in a Penrose-style diagram correspond to shared Index objects in code, and ITensor performs outer products, full inner products, or partial contractions through the same operator (Fishman et al., 2020).

This interface is designed to hide ordering and storage layout while exposing only the connectivity structure. Priming distinguishes otherwise similar indices, and functions such as hasind, hasinds, and commonind support assertions. High-level factorizations such as qr and svd are specified by selecting row versus column index sets, after which the implementation matricizes, factors, and reshapes back. The same interface is used for dense tensors, quantum-number conserving block-sparse tensors, and GPU-backed storage through the broader ITensor/NDTensors ecosystem (Fishman et al., 2020).

Cytnx develops a related but label-driven design. Its UniTensor carries Bond objects, string labels, an optional name, a dtype, a device, and a rowrank that specifies how a tensor is viewed as a matrix. Labels allow contractions by label rather than by position, and the library emphasizes an almost identical interface and syntax for both C++ and Python. For symmetric tensors, only charge-conserving blocks are stored; the charge-conservation rule is written as

$$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$0

The Network object stores a blueprint of a tensor network from a file or string and can launch contractions after an automatic order search based on a dynamic-programming search for minimal flop count (Wu et al., 2024).

A common misconception is that these interfaces merely wrap dense array libraries. The design emphasis in both ITensor and Cytnx is narrower and more structural: matching indices or labels determines the algebra, so the programmer writes connectivity rather than axis permutations. This is why both systems present the interface itself as a mechanism for error prevention, especially in the presence of nontrivial contraction patterns (Fishman et al., 2020, Wu et al., 2024).

4. Format abstraction, strides, and standard tensor kernels

At a lower level, tensor interfaces formalize memory layout and iteration semantics. The taco work on sparse tensor algebra compilers views an $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$1-dimensional sparse tensor as an $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$2-level coordinate hierarchy. Each level format provides a storage mechanism for child coordinates and an abstract interface for iteration, random access, and, in write contexts, insert or append. The six reference level formats are Dense, Compressed, Singleton, Range, Offset, and Hashed. The interface exposes functions such as coord_bounds, coord_access, pos_bounds, pos_access, locate, insert_*, and append_*, together with level properties full, ordered, unique, branchless, and compact (Chou et al., 2018).

The significance of this design is that higher-order formats such as CSR, CSF, COO, DIA, ELL, and HASH are treated as compositions of per-dimension level implementations, rather than as monolithic special cases. The code generator manipulates tensors only through the abstract level API and chooses between co-iteration and locate-driven loops by querying properties. The paper reports that the generated code is competitive with hand-optimized implementations and that, if input data is provided in COO format, direct computation of a single matrix-vector multiplication in COO can be up to $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$3 faster than first converting to CSR (Chou et al., 2018).

The proposed BLAS-like interface xGETT is an even more explicit formulation of the same idea for binary tensor contraction. Its C signature $a \cup c$3 separates rank and extents, strides, data pointers, contracted mode lists, and an output permutation. In contrast to classical BLAS, it allows arbitrary rank, explicit listing of each contracted mode, non-unit and negative strides, subtensor views, and explicit permutation of output modes. The thesis concludes that this interface is sufficient as a BLAS-like interface for binary tensor contractions and possible to use in a BLAS-like standardization for tensor operations (Hörnblad, 2024).

TAPP generalizes this standardization effort into a backend-agnostic C API built around opaque handles, tensor descriptors, contraction plans, executors, and execution status. Its simplest contraction update is written as

$$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$4

with the contracted, free, and Hadamard index sets inferred from label strings. The reference implementation prioritizes simplicity and correctness and is used as an oracle for optimized back ends. The paper reports successful integrations with TBLIS, cuTENSOR, and the DIRAC quantum chemistry package, with TBLIS via TAPP matching native TBLIS to within a few percent and cuTENSOR via TAPP achieving within $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$5 of direct cuTENSOR performance (Brandejs et al., 12 Jan 2026).

The Toulouse workshop report documents a complementary social dimension of tensor-interface standardization. It describes TAPP as a small, C-ABI, backend-agnostic API for tensor creation, user-supplied storage with arbitrary strides and layouts, linear combinations, Einstein-style tensor contraction, and transpose. It also records that the low-level API was found “very clear and on the right track,” that some participants initially viewed TAPP itself as a tensor library rather than an interface layer, and that the community requested explicit transpose functionality, more examples, and language bindings (Brandejs et al., 5 Feb 2026).

5. Machine-learning workflows and application portability

Tensor interfaces in machine learning emphasize differentiability, repeated execution, and integration with existing training stacks. TensorKrowch builds on three core abstractions: Node, Edge, and TensorNetwork. An Edge represents one index of a Node, and compatible edges are connected with the ^ operator. Operations such as contraction, splitting, stacking, unbinding, and einsum are implemented through cached Operation objects, so only tensor data moves during training. The method net.trace(input_example) pre-allocates intermediate nodes and precomputes permutations and reshapes for repeated contractions, while net.reset() clears cached resultant nodes. The paper reports $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$6–$$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$7 speedups on common MPS layers and relies on PyTorch autograd and CUDA for differentiation and GPU execution (Monturiol et al., 2023).

tntorch presents a different interface strategy: one polymorphic Tensor class supports CP, Tucker, Tensor Train, and arbitrary blends under a unified interface. Construction, decomposition, truncation, contraction, outer products, batching, and GPU migration are presented through a syntax intended to resemble ordinary PyTorch usage. Internally, cores and factors remain torch.Tensor objects, so autograd, batched linear algebra, and device placement are inherited from PyTorch. The benchmark summary states that tntorch on GPU is fastest in four representative operations—elementwise sum, elementwise product, TT-SVD, and cross-approximation—and that even CPU performance is comparable or faster than the ttpy baseline (Usvyatsov et al., 2022).

TCI moves the portability problem up one level, from individual kernels to complete tensor-network applications. It defines a type system centered on an abstract tensor type TenT and associated tensor_traits, together with a context handle and a minimal set of core functions for allocation, element access, reshape, transpose, concatenate, stack, contraction, SVD, QR, eigensolvers, and conversion between contexts. The key portability claim is that application code can be retargeted by changing only the alias using ten = ... and linking against a different back end. In the reported experiments, the GPU implementation of iTEBD on the 1D TFIM achieves over a tenfold speedup for bond dimension $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$8, and a 2dTN-BP application on Fugaku with 156 nodes is approximately $$\mathrm{FLOPs}(A \times B)=\prod_{j \in A \cup B} D_j,$$9 faster than on 4 nodes. A direct comparison against a hand-written implementation using the native GraceQ/tensor API shows virtually identical performance on CPU and indistinguishable behavior for $A$0 on Fugaku with 156 nodes (Sun et al., 30 Dec 2025).

These systems indicate that, in the machine-learning and application-portability setting, a tensor interface is not only a notation layer. It is also a control point for caching graph topology, preserving differentiability, and separating high-level algorithm design from the tensor runtime actually executing the contractions.

6. Physical meanings of tensor interfaces

Outside software engineering, the phrase “tensor interface” can denote an actual interface encoded by tensor structure. In the thermofield-dynamics construction of finite-temperature tensor networks, the original Hilbert space and its tilde copy are represented by a product of two copies of a tensor network, and their interface becomes an event horizon. For a maximally entangled interface of bond dimension $A$1, the entropy is

$A$2

In the finite-temperature MERA picture, truncation at a layer $A$3 produces a horizon at $A$4, and the horizon entropy matches the volume-law contribution to the finite-temperature CFT entanglement entropy (Matsueda et al., 2012).

In holographic interface and defect CFTs, the problem is different but again structural. The theory of minimal updates states that, starting from an optimized MERA for a parent CFT, only disentanglers and isometries inside the causal cone of the defect need to be updated in the defect CFT. The updated region encodes the boundary operator expansion coefficients, while the un-updated region reproduces the parent CFT’s OPE data. The paper also emphasizes a limitation: minimal updates are valid for genuine defect, interface, and boundary CFTs, but not for arbitrary two-dimensional theories with only $A$5 invariance. To handle the latter, it proposes “rayed MERA,” in which tensors are identical only along a given ray related by dilation, and different rays carry different tensors labeled by the invariant

$A$6

Even when many tensors are identical, their contributions to entanglement weights can differ according to the ray label $A$7 (Czech et al., 2016).

In spintronics, the “tensor interface” concept appears at the ferromagnet/antiferromagnet boundary. The Néel tensor is defined as the covariance matrix

$A$8

with $A$9 real, symmetric, positive semi-definite, and in practice of rank two. At an FM/AFM interface, the scalar coupling

$a \cup c$0

produces an effective field $a \cup c$1 and a torque

$a \cup c$2

The reported device experiments show that trained Néel tensors can retain a specific orientation and enable zero-field spin-orbit-torque switching in heavy-metal/ferromagnet/AFM trilayers, with XMLD measurements confirming the trained tensor orientation (Yang et al., 2023).

A plausible implication is that the phrase “tensor interface” has two enduring technical meanings. In computation, it denotes the formal boundary between tensor mathematics and executable code. In physics, it can denote a literal interface—between networks, defects, or materials—whose entropy, symmetry breaking, or torque is encoded by tensorial structure.