Views, copies and memory layout

Slice a Python list and you get a new list. Slice an array and, most of the time, you get a view: a second array object pointing at the same buffer. Nothing was copied. Both names refer to one block of memory.

The dividing line is not arbitrary. Basic slicing can always be described as "start here, then step this far each time", and that description is all an array is, so NumPy hands you a new description of the same bytes:

a[1:3]        view      evenly spaced
a[:, 0]       view      evenly spaced
a.T           view      just a different description
a.reshape(6)  view      usually

Fancy indexing and boolean masks pick elements that are not evenly spaced. There is no start-and-step that describes them, so NumPy has no choice but to gather them into a new buffer:

a[[0, 2]]     copy      arbitrary positions
a[a > 2]      copy      arbitrary positions
a.copy()      copy      you asked
a + 1         copy      a new array of results

Both come back as an array and print the same way. Nothing in the output tells you which one you are holding.

Reading through a view is harmless. Writing through one changes the original, because there is only one original:

a = np.array([[1, 2, 3],
              [4, 5, 6]])

row = a[0]      # a view
row[:] = 0

a   ->   [[0, 0, 0],
          [4, 5, 6]]      a changed

Now index the same row a different way:

row = a[[0]]    # fancy indexing, so a copy
row[:] = 0

a   ->   [[1, 2, 3],
          [4, 5, 6]]      a did not change

Two lines that look the same, and opposite consequences. This is the bug the lesson exists for, and it is nasty in both directions: sometimes you change data you did not mean to, and sometimes you carefully write a fix that lands in a temporary array and is thrown away.

Note the [:]. row[:] = 0 writes into the buffer, but row = 0 just rebinds the name and touches nothing. The subscript is what makes it a write.

Memory is one-dimensional. An array that is not needs a rule for turning a position like (1, 2) into an offset into a flat buffer, and that rule is the strides: how many bytes to step to move one place along each axis.

a.shape   == (2, 3)     int64, so 8 bytes each
a.strides == (24, 8)

move one along axis 1  ->  8 bytes    the next number
move one along axis 0  ->  24 bytes   past a whole row of three

For a normal array the strides fall straight out of the shape. The last axis steps by one element; each axis to the left steps by the whole block underneath it:

shape (2, 3, 4), float32 (4 bytes)

axis 2  ->  4        one number
axis 1  ->  16       a run of 4
axis 0  ->  48       a block of 3 x 4

strides == (48, 16, 4)

So an array is a buffer, a shape, a dtype and a strides tuple. Everything else in this lesson is what happens when you change one of those four and leave the buffer alone.

NumPy lays arrays out in row-major order, also called C order: the last axis varies fastest. Walking the buffer from start to finish, you read across the first row, then across the second.

[[1, 2, 3],
 [4, 5, 6]]

in memory:  1 2 3 4 5 6

That single fact explains what flattening gives you. a.reshape(-1) does not rearrange anything -- it reads the buffer in order:

a.reshape(-1)      ->  [1, 2, 3, 4, 5, 6]
a.T.reshape(-1)    ->  [1, 4, 2, 5, 3, 6]

The second one has to be different. The transpose is a view with swapped strides, so reading it in row-major order walks the original buffer in jumps, and the elements come out interleaved.

It also explains a performance rule you will meet again: summing along the last axis reads adjacent bytes, and summing along the first jumps a row at a time. Same arithmetic, and on a large array, very different speed.

Transposing sounds expensive. It is free, and the strides say why: reverse the shape, reverse the strides, hand back a new description of the same bytes.

a.shape   == (2, 3)      a.strides   == (24, 8)
a.T.shape == (3, 2)      a.T.strides == (8, 24)

Read that second line as instructions. To move one along the transpose's first axis, step 8 bytes -- which in the original buffer is one place to the right. The transpose walks the same memory in the other order, and no element was ever copied.

What you get back is non-contiguous: its elements are no longer in buffer order. That costs nothing to hold and something to use, because a non-contiguous array is slower to read and cannot always be reshaped without a copy.

Every operation so far has tried to return a view, and returned a copy only when a view was impossible. That is the rule, and contiguity is what decides possible.

An array is C-contiguous when its elements sit in the buffer in exactly the order its shape implies. A fresh array is. A transpose of one is not.

a  = np.arange(6).reshape(2, 3)
a.reshape(3, 2)      view      still in order
a.T.reshape(3, 2)    copy      no strides can describe it

The second one is the trap. It looks like the first, it succeeds without a warning, and on a large array it has silently allocated and filled a second copy of everything.

Which leaves the practical advice this lesson is for:

• If you are about to write into something, know whether it is a view.
• If you need independence, say .copy() and mean it.
• If a line is unexpectedly slow, ask whether it had to copy.