Principle:LaurentMazare Tch rs Tensor Shape Abstraction

Knowledge Sources	LaurentMazare_Tch_rs
Domains	Software Engineering, Type Systems, API Design
Last Updated	2026-02-08 00:00 GMT

Overview

Shape abstraction through polymorphic interfaces allows flexible dimension specification by accepting arrays, tuples, scalars, and slices as shape descriptors through a unified trait.

Description

Tensor shape abstraction addresses the ergonomic challenge of specifying tensor dimensions across a wide variety of use cases. Creating a tensor requires specifying its shape -- the sizes of each dimension. However, different contexts naturally express shapes in different forms:

A scalar (single integer) for 1D tensors: shape = 10 means a vector of length 10
A pair or tuple for 2D tensors: shape = (3, 4) means a 3-by-4 matrix
A fixed-size array when the number of dimensions is known at compile time: [2, 3, 4]
A slice or dynamic vector when dimensions are computed at runtime

Rather than requiring users to convert all shapes to a single canonical form, a well-designed tensor library defines a shape trait (or interface) that is implemented for all of these types. Any function accepting a shape parameter is generic over this trait, allowing callers to pass whichever form is most natural.

The shape trait converts any input form into a canonical representation -- typically a slice of dimension sizes $[d_{1}, d_{2}, \dots, d_{n}]$ . This canonical form is what the underlying tensor creation and manipulation functions consume.

This pattern demonstrates the broader principle of polymorphic API design: defining a trait that multiple types implement, then writing functions that are generic over that trait. This maximizes flexibility for callers while maintaining a single implementation path internally.

Usage

Apply shape abstraction when:

Designing tensor creation APIs that should be convenient for common cases
Users may specify shapes as scalars, tuples, arrays, or slices depending on context
Compile-time known shapes and runtime-computed shapes should both be supported
API ergonomics are a priority and boilerplate conversions should be minimized

Theoretical Basis

Shape as a Polymorphic Type

Define a shape trait $𝒮$ with a single required method:

Failed to parse (syntax error): {\displaystyle \text{as\_dimensions}: \mathcal{S} \rightarrow [d_1, d_2, \ldots, d_n]}

where each $d_{i} \in ℕ^{+}$ is a positive integer dimension size.

Implementations

The following types implement the shape trait:

Scalar integer $d$ maps to $[d]$ (1D shape)
Pair $(d_{1}, d_{2})$ maps to $[d_{1}, d_{2}]$ (2D shape)
Triple $(d_{1}, d_{2}, d_{3})$ maps to $[d_{1}, d_{2}, d_{3}]$ (3D shape)
Fixed array $[d_{1}, \dots, d_{n}]$ maps directly (n-D shape)
Slice/vector already in canonical form

Tensor Construction

A generic tensor constructor accepts any shape type:

function zeros<S: Shape>(shape: S) -> Tensor
function ones<S: Shape>(shape: S) -> Tensor
function randn<S: Shape>(shape: S) -> Tensor

The monomorphization of these generic functions produces specialized versions for each concrete shape type, ensuring zero overhead from the abstraction.

Empty and Scalar Shapes

Special cases in the shape system:

An empty shape $[]$ represents a scalar tensor (0-dimensional, 1 element)
The total number of elements is $\prod_{i = 1}^{n} d_{i}$ , with the convention that the empty product equals 1

Related Pages

Implementation:LaurentMazare_Tch_rs_Tensor_Mod

Page Connections

Double-click a node to navigate. Hold to expand connections.

Principle

Implementation

Heuristic

Environment