TensorFlow in 8 Slides

This is the orientation post for TensorFlow, and the goal is to replace a vague brand name with a precise mental model. People hear 'TensorFlow' and picture a single monolithic thing, then get lost the moment they open the docs and find dozens of modules. The fix is to see it as a layered stack rather than one tool.

The whole series treats each framework the same way: first say clearly what it IS, then argue why it matters, then open the hood. This post is the map you keep coming back to.

The definition deliberately leads with two capabilities rather than features: numerical computation on tensors, and automatic differentiation. Those two together are the entire reason a numerical library becomes a deep-learning engine. Hardware acceleration (CPU, GPU, TPU) is the third pillar that makes it practical at scale.

Notice what is missing from this definition: neural networks. TensorFlow does not start from 'neural network' — it starts from 'fast differentiable array math', and networks are just one thing you can build on that foundation. Holding that order in your head explains why the low-level API looks the way it does.

The tensor is the atom of the whole library, which is why the framework is named after it. The key difference from a plain NumPy array is that a TF tensor is designed to live on an accelerator and to flow through a computation graph that can be differentiated and optimized.

Rank is the vocabulary worth memorizing: rank-0 is a scalar, rank-1 a vector, rank-2 a matrix, and higher ranks stack from there. A batch of color images is rank-4 (batch, height, width, channels). Almost every shape bug you will ever hit is a confusion about rank and the order of those dimensions.

This snippet is intentionally tiny so the reader can run it in seconds and see that a tensor is concrete, not abstract. The four prints surface the three properties that matter most in practice: shape, dtype, and the operations you can run on it.

The last line, x.numpy(), is the bridge back to the familiar world. Eager TensorFlow lets you drop out to NumPy at any point, which is enormously reassuring when you are learning — you are never trapped inside an opaque graph the way you were in TF 1.x.

The stack diagram is the single most useful image in this post. Reading bottom to top: tensors and ops are the raw math; GradientTape adds automatic differentiation; Keras is the high-level model API most people write; and the deployment family takes a trained model to servers, phones, and browsers.

The practical payoff is knowing which layer to reach into for a given problem. Performance tuning lives near the bottom; model architecture lives in Keras; shipping lives at the top. When something feels missing, you are usually looking in the wrong layer.

Eager versus graph execution is the concept that most distinguishes modern TF from the version people remember disliking. Eager mode runs operations immediately and returns real values, so it behaves like NumPy and is easy to debug. This is the default in TF 2.x.

When you need speed, you wrap a function in @tf.function, and TF traces it into a static graph it can optimize and run without per-line Python overhead. The win is that you no longer choose between interactivity and performance up front — you prototype eagerly and compile the hot paths later.

This comparison puts the two execution modes side by side so the trade-off is explicit rather than folklore. Eager is for learning, exploration, and debugging: you can print any tensor and step through with a debugger. Graph mode, triggered by @tf.function, is for production speed: ops get fused, Python overhead disappears, and the result deploys cleanly.

The important nuance is that these are not rival frameworks — they are two modes of one framework. The mature workflow is to develop in eager mode, then decorate the performance-critical functions once the logic is correct.

This flow makes the hardware story concrete. A tensor carries a dtype and a shape; TensorFlow places it on a device (CPU, GPU, or TPU); operations run there using optimized, often fused kernels; and you read results back with .numpy() when you need them in Python.

The reason this matters is that data movement, not computation, is often the real cost. Knowing that tensors live on a device and that crossing back to the CPU has a price helps you understand why some loops are slow and why you batch work rather than ping-ponging values in and out.

Defining what TensorFlow is NOT prevents a whole class of confusion. It is not synonymous with Keras (Keras is one layer), it is not an AutoML button that picks a model for you, and it is not a single binary — it is a stack of cooperating pieces.

The most common trap is mixing eras: tutorials written for TF 1.x talk about sessions, placeholders, and feed dicts, none of which you need in eager TF 2.x. When something in the docs feels alien, check whether it predates 2.0. Knowing the boundary keeps you from importing old habits into a modern API.

This is the compressed mental model to carry away. Tensor is an accelerator-ready NumPy array; GradientTape gives you derivatives for free; Keras is the API you actually write day to day; @tf.function compiles a graph when you want speed; and the deployment family ships the result anywhere.

If you remember nothing else, remember those five lines. They map cleanly onto the layered stack and tell you exactly which part of the library to think about for any given task.

The cover and CTA bookend the post. This first day establishes the map; the next post argues why TensorFlow is still worth learning in a world where PyTorch dominates research, which sets up the rest of the day's progression from why, to how, to a full example, to the mistakes.