Matrices — Create and index matrices; understand dimensions

The concept of a matrix as a rectangular array of numbers has deep roots in mathematics, stretching back to ancient Chinese texts and later formalized in 19th-century linear algebra. When Ross Ihaka and Robert Gentleman designed R in the early 1990s at the University of Auckland, they inherited the matrix-centric philosophy of its predecessor, the S language, which John Chambers developed at Bell Labs. S was explicitly designed to make statistical computing feel like natural mathematical notation, and matrices were a first-class citizen from the start. R carried this philosophy forward, providing a native matrix type that maps directly onto the mathematical abstraction while remaining tightly integrated with the language's vectorized evaluation model.

Why should a computer science student care about a dedicated matrix type when R already has vectors and data frames? The answer lies in performance and semantic clarity. Matrices enforce type homogeneity—every element shares a single atomic type—which enables R's internal C and Fortran routines to operate on contiguous memory without type-checking overhead. Understanding how R creates, stores, and indexes matrices is the gateway to leveraging vectorized operations, writing efficient numerical code, and eventually interfacing with high-performance libraries like LAPACK and BLAS.

At its core, an R matrix is simply an atomic vector with a dim attribute attached. This means every matrix is backed by a flat, one-dimensional block of memory; the "rows" and "columns" you see are an illusion created by the dimension metadata. R stores matrix data in column-major order, meaning the first column's elements appear first in memory, then the second column's, and so on—identical to Fortran's convention and the opposite of C's row-major layout. Grasping these foundational ideas is essential before you write a single line of matrix code.

The diagram below illustrates how R stores a 3×3 matrix in column-major order. On the left you see the logical grid you interact with via [row, col] indexing. On the right, the same nine elements are laid out in their actual memory sequence, numbered 1 through 9. Notice how elements within the same column are contiguous—this is why column-wise operations (e.g., colSums()) are typically faster than row-wise ones.

The key observation from this diagram is that the linear index increases down each column before moving to the next column. When you access m[5] (using a single subscript), R returns the 5th element in the flat vector, which corresponds to m[2, 2]. The conversion formulas shown in the diagram use R's modular arithmetic operators: %% (modulo) and %/% (integer division). Internalizing column-major order will help you predict recycling behavior, optimize loops, and understand why certain operations are more efficient than others.

The matrix() Constructor

The matrix() function is the primary constructor. When you supply only data and nrow, R computes ncol as length(data) / nrow. If the length of the data vector does not evenly divide into the requested dimensions, R recycles the vector and emits a warning. This recycling behavior is consistent with R's general vector recycling semantics, but it is a frequent source of bugs in matrix code, so treat warnings as errors in production scripts.

Alternative Construction Methods

Beyond matrix(), you can create matrices by assigning a dim attribute directly: v <- 1:12; dim(v) <- c(3, 4) converts v in-place into a 3×4 matrix. You can also bind vectors together with cbind() (column bind) or rbind() (row bind), which are especially useful when constructing matrices from pre-existing data vectors. The choice of method affects readability and sometimes performance: dim<- modifies the object in-place (no copy), whereas matrix() always allocates a new object.

Querying Dimensions

R provides three distinct indexing paradigms for matrices, each suited to different use cases. Understanding when and why to use each paradigm is critical for writing idiomatic, efficient R code. The diagram below visualizes all three approaches applied to the same 4×3 matrix.

The drop Parameter

A subtle but important behavior is R's dimension dropping. When a subscript operation produces a result with a single row or single column, R automatically drops that dimension, returning a plain vector instead of a 1×n or n×1 matrix. This default, controlled by the drop parameter, can break code that assumes the result is always a matrix. To preserve matrix structure, use m[1, , drop = FALSE]. In production-grade code—especially inside functions where input dimensions may vary—always setting drop = FALSE is a defensive programming best practice.

Imagine you are building a simple grade-tracking system for a class of 4 students across 3 assignments. We will construct the matrix, label its dimensions, query its shape, extract subsets, and compute summary statistics—all using idiomatic R.

R offers multiple data structures for tabular data, and choosing the right one depends on your data's type constraints, dimensionality, and performance requirements. The table below compares matrices with vectors, data frames, arrays, and tibbles across the dimensions most relevant to a computer science student.

The basic matrix operations covered in this lesson serve as the foundation for a range of advanced topics in R and numerical computing more broadly. Understanding how R stores and indexes matrices is prerequisite knowledge for sparse matrix representations (via the Matrix package), multidimensional arrays, and integration with high-performance computing frameworks.

As you progress, you will also encounter matrix algebra operations—%*% for matrix multiplication, solve() for inversion, t() for transposition, and eigen() for eigendecomposition. All of these rely on the dimension semantics and storage layout you learned here. The payoff of mastering matrices now is that R's linear algebra interface becomes entirely predictable: you know exactly how elements are laid out, how indexing resolves, and why certain operations are fast.