"dimension" vs "extent", "axis" vs "dimension" - when should I use which term?

Question

I'm defining a small API involving both uni-dimensional and multi-dimensional data. In addition to representing the data itself, I also have function/methods/operators for creating a new multi-dimensional entity, or determining its, well, I'm already using one terms here, dimensions.

The thing is, I am having trouble deciding which terms to use in my API.

Suppose I have box of width 3, height 5, and depth 7.

Are the "dimensions" of this box "width", "height", and "depth"? In which case, 3, 5 and 7 are the "extents"?

Or, perhaps, the "dimensions" are 3, 5, and 7? In which case "width", "height", and "depth" are the axes? Or maybe 0, 1, 2 are the axes and "width", "height", "depth" are axis names?

I'm not a native English speaker, so I'm not sure whether one of the two options is more correct; or maybe these are just two different vernaculars, both valid; or perhaps I should consider some other nomenclature/combination of terms.

---

Notes:

• The code I'm writing is C++, if you believe that this could be a factor in the choice of terms.
• No, I can't use md-spans and spare myself the dilemma, this is C++11 code and there are other reasons. But do note that spans and md-spans use "extents," and C++ containers use the term "size" (and the size_t type is used a lot).

• Filip Milovanović: Consider what kinds of things your data is representing (what your domain is), and how this data is going to be used. Width/height/depth makes sense if what you are returning are the local orthogonal extents of an object (especially if the object is expected to be in some standard orientation - e.g. there's a front view, side view, top view). But in some other application, what you may want are the axis-aligned extents of an arbitrarily rotated object, in which case you could just return an axis-aligned bounding box (AABB), so w/h/d might be properties of the AABB, not of the object itself.
• einpoklum: @FilipMilovanović: The use case is not limited to width-height-depth, nor to a cartesian coordinate system.
• Filip Milovanović: Well then don't use those names. If nothing suggested here is suitable, it might be a good idea to look outside the developer community - sometimes the domain you're working with already has established terminology that you can adopt. This includes cases where it may not make sense to use English names as opposed to indices, each denoting an axis (i.e. you could just return a vector). In that vein, another question to ponder is how general you want to be here - e.g. do you want to impose these names on the user, or let them interpret the data. There are pros and cons to both.
• Caleth: Even if you are writing C++11 code, you are writing it in 2025, so the terminology of std::mdspan is accessible to your users.

Answer 1

In standard English, the 3 'dimensions' of space are most commonly referred to as 'width', 'height', and 'depth'. The values of those dimensions in your example are 3, 5, and 7 respectively. So if you wanted to represent the dimensions 'of' an object. If you wanted to represent that as e.g., in a JSON structure this would be standard and crystal clear:

"dimensions": {
 "width": 3,
 "height": 5,
 "depth": 7
}

'axis' refers to the names we give to the (typically) orthogonal directions in space and are usually a labelled x, y, and z where x is horizontal (left-right), y is vertical (up-down) and z is the distance away (far-near). The z-axis is probably the most confusing as it usually represented on a 2D monitor using (false/illusionary) perspective. For example, the z-order of elements determines which ones are 'on top' of the others and can obscure them.

The x, y, and z axes align with width, height, and depth. For example, 'width' is an object's length along the x-axis. The names x, y, and z are typically used to represent position. An object, therefore, will usually need both a set of dimensions as well as a position e.g.:

"position": {
 "x": 50,
 "y": 45,
 "z": 24
}

The term 'extent' is a potential synonym for 'length'. There are many such in English such as 'size', 'length', 'breadth', 'distance'. I would avoid using these other words in this software context because many have specific meanings in other domains. For example, 'breadth' has a particular meaning when talking about tree structures. The term 'extent', in my experience, is usually related to database storage.

After some thought, it occurs to me that you may be looking for a general term for talking about the dimensions of your data, 'shape' (as in pandas) might be the word you are looking for. The 'shape' in this context is 'a tuple representing the dimensionality' of the data.

• Greg Burghardt: To be honest, I've never ran into "extent" as a technical term, at least not to the extent of my experience. And yes, that was a pun, but it represents the more common way I've used the word "extent." I might be biased, though, being from the USA and working primarily in web applications.
• Greg Burghardt: And I would add that "dimension" is a more generalized term for "something you can measure." Things like width, height, depth, time, position -- these are all "dimensions" in the sense that they are measurements of something. And yet, within the context of 3D shapes and animation, "dimensions" can mean something specific; width, height, and depth.
• einpoklum: extent has been used for length/size of C++ referecence-type for continguous sequences of elements since C++20, and more so with the introduction of md-spans for multi-dimensional data in C++23.
• JimmyJames: @GregBurghardt These are examples of what I am referring to: Pages and extents Managing extents
• Christophe: As far as I know, extent is a very specific term used in the context of storage allocation for designating a set of contiguous blocks (e.g the link about pages and extents shared by Jimmy, or the older Oracle segment extents docs.oracle.com/cd/B19306_01/server.102/b14220/logical.htm but also for file systems en.m.wikipedia.org/wiki/Extent_(file_systems) or heap management algorithms synacktiv.com/publications/… ) - I don't think it can be used as a general substitute for "value", "measurement" or "size".

Answer 2

Unfortunately the answer given does not actually properly quantify the landscape of multidimensional datastructures in programming, nor in english. It's significantly more complicated than what they say.

When a normal person, with out mathematical background, is talking about "dimensions", they are talking about dimensions of space/reality. This is typically used when you talk about "how many dimensions something has", as in, does something have two dimensions? Three dimensions? one might say "space is three dimensional"

When you're talking about a multi-dimensional object, such as a vector in the linear algebra sense, you would use ND, as in a 3D vector, or a 2D vector (or vec3/vec3D/float3/float3D), where D stands for "dimension".

When you're talking about a tensor, a more generic mathematical object that encompasses vectors and matrices, for example, in machine learning and physics, and you're not talking about simply the number of elements, but the number of dimensions of the object itself, you're talking about modality, as in a vector is a rank 1 tensor, it has one mode, a matrix has rank 2, it has two modes. Alternatively, these are referred to in a mode sense (mode-1, mode-2, mode-3 etc...).

When you're talking about a generic programming object which may have multiple dimensions, the term is either shape, size, or extent.

• Shape is used in Python's Numpy and derivatives of it (such as xtensor in c++).

• Size has been used add-hoc and is the most confusing of these terms, it's used in Matlab, but I've seen it used in other random matrix libraries. It's especially not clear in C++, where the term is used normally for the total number of elements in a container.

• Extent is used in C++23's mdspan, and the Vulkan API, which has objects like VkExtent2D and VkExtent3D.

• Others like Eigen don't even officially have a word for the size of each dimension (since they only deal with matrices and vectors excluding unsupported versions)

One thing to note about extent is that it's often used in opposition to the idea of an "offset". You need a way to differentiate between these two types of objects, the size of each dimension (extent) and the offset within an extent (offset), where an extent can never be negative, but an offset can. This does a lot of things, like allow you to create a bounding box out of an offset and an extent and get semantic compile time argument checking with out having to resort to using named arguments, because you are using the same type for each parameter. Indeed, Vulkan contains a VkOffset2D and VkOffset3D because of this very important attribute, as seen in VkRect2D

// Provided by VK_VERSION_1_0
typedef struct VkRect2D {
 VkOffset2D offset;
 VkExtent2D extent;
} VkRect2D;

In contrast, while shape can physically fill the same niche as a name for a type that represents what Extent does (you can make a type called "shape" and a type called "offset"), linguistically it makes much less sense (shape is very generic). This isn't as much of a factor in a language like Python, but in a statically typed language, especially one with out named arguments, it becomes an important argument to use extent in place of shape in some scenarios.

Additionally note that the argument that "extent could refer to a 1 dimensional quantity" doesn't make sense linguistically (extent is often implicitly used to refer to all dimensions "extended" of a given subject, not just a single length dimension even outside of programming, the fact that sometimes a word could be used to mean a different thing at a different time is just a part of life and language, hence we have to rely on precedent as well to prime understanding, not just literal colloquial meaning of a thing) and doesn't make sense with regards to other words, such as offset which would face the same problem.

Extents also make it clear we aren't talking about the number of dimensions of an object but the extent of those dimensions, the length size of them, in a way that other terms except for shape, don't make clear.

So ultimately, shape or extent are the only terms with precedent for what you're doing. At least in describing the size of each dimension, I think both do an equally good job at making it clear what each means, for example:

"dimensions": {
 "width": 3,
 "height": 5,
 "depth": 7
} 

could also be written as

"dimensions": 3

for a completely different meaning, but you couldn't do the same with shape or extent and have it make sense, shape: 3 and extent: 3 would never mean "3 dimensions", while obviously the above could.

But do note that spans and md-spans use "extents", and C++ containers use the term "size" (and the size_t type is used a lot).

As mentioned earlier, Extent and Size are two totally different concepts in C++, the total number of elements in a container is not the same as the extent/shape of said container.