TensorFlow Core in Python

TensorFlow is Google's open-source framework for building and deploying machine learning models at scale. It began as an internal tool for running large neural networks across Google's data centers and now powers systems like Search ranking, YouTube's recommendation engine, and the perception stack in Waymo's self-driving cars.

What sets TensorFlow apart from smaller experimentation libraries is its focus on the full lifecycle of a model: not just training, but exporting a model that can run on a server cluster, a mobile phone via TensorFlow Lite, or embedded hardware. That production orientation explains why large engineering teams often reach for TensorFlow when a research prototype needs to become a service that handles millions of requests.

PyTorch, by contrast, grew out of academic research, where the priority is fast iteration and a natural, run-as-you-write coding style. Neither framework is objectively better — they optimized for different stages of the same pipeline, and this course focuses on the parts of TensorFlow that make it a serious production choice.

Module 01 covers TensorFlow Core — the low-level layer beneath the friendlier Keras API you'll use later in this course. At its foundation, TensorFlow is a math engine: it takes matrix and vector operations and executes them efficiently on whatever hardware is available, whether that's a laptop CPU, a datacenter GPU, or a Tensor Processing Unit (TPU) built by Google specifically for this workload.

Everything in TensorFlow is expressed in terms of Tensors — the generalization of scalars, vectors, and matrices to any number of dimensions. A single number is a rank-0 tensor, a list of numbers is rank-1, an image's pixel grid is rank-2 or rank-3 with color channels, and a batch of images is rank-4. Understanding this Tensor abstraction early matters because every layer, loss function, and gradient computation you'll write later is just an operation on tensors.

Because TensorFlow Core handles this raw computation, it can automatically distribute tensor operations across multiple GPUs or TPU cores without you rewriting your model code — the higher-level APIs simply describe what to compute, and the Core engine decides how and where.

In practice, the split between TensorFlow and PyTorch tracks fairly closely with the split between research and production. Academic papers and rapid prototyping have leaned heavily toward PyTorch in recent years because its eager, Python-native style makes it easy to debug and experiment with new architectures.

TensorFlow's strengths show up on the other end of the pipeline: once a model is validated, deploying it reliably at scale — on mobile devices with TensorFlow Lite, in browsers with TensorFlow.js, or through serving infrastructure like TensorFlow Serving and TFX — is where TensorFlow's tooling has historically been more mature. Large enterprises with existing production ML pipelines, especially in mobile and embedded contexts, have often standardized on TensorFlow for this reason.

Neither framework is tied to a single company by ownership, and the technical gap between them has narrowed since TensorFlow 2.0 adopted eager execution. But the historical center of gravity — research versus production — is still a useful way to reason about which tool a given team is likely to be using.

The name 'TensorFlow' is literal: it describes Tensors flowing through a directed graph of mathematical operations. In this mental model, data enters the graph as tensors, passes through a sequence of nodes — each representing an operation like matrix multiplication, addition, or an activation function — and the results flow onward until they reach the final output.

This graph-based view isn't just a metaphor; it's how TensorFlow historically executed code. Every operation you define becomes a node, and every tensor that moves between operations becomes an edge in that graph. Even though TensorFlow 2.x hides most of this behind Python-friendly syntax, the underlying execution model still builds and optimizes graphs when you use tf.function or export a model for deployment.

Understanding this data-flow picture pays off once you start debugging shape errors or performance issues: a 'tensor' is just data moving through the graph, and a 'flow' is the sequence of operations transforming it from input to prediction.

When you first encounter the name 'TensorFlow,' it's easy to assume it's just a branding choice, but it maps directly onto the framework's architecture. Tensors are the multi-dimensional arrays that hold every piece of data the framework works with — inputs, weights, gradients, and outputs are all tensors, regardless of shape.

The 'flow' half of the name refers to the computational graph: a directed structure where tensors move from operation to operation, being transformed at each step. This design has practical consequences. Because the graph describes dependencies between operations explicitly, TensorFlow can analyze it to schedule work in parallel, place different parts of the graph on different devices, and compute gradients automatically by tracing the graph backward.

So the name isn't decorative — it's a compact description of how computation actually happens inside the framework, and keeping that picture in mind makes concepts like graph mode and automatic differentiation much more intuitive later in the course.

Early versions of TensorFlow (1.x) required you to build the entire computational graph before running any data through it. You would define placeholders for your inputs, wire together the operations symbolically, and only then open a tf.Session and call sess.run() to actually execute anything and get real numbers back.

This two-phase 'define, then run' workflow made TensorFlow 1.x powerful for optimization — the framework could analyze the whole graph ahead of time — but painful to develop with. You couldn't simply insert a print() statement in the middle of your model to inspect an intermediate value, because at that point the operation hadn't actually run yet; it was just a symbolic node waiting to be executed later inside a session.

This friction was one of the main reasons researchers gravitated toward PyTorch during that period, and it's exactly the gap that TensorFlow 2.0 set out to close with eager execution, which you'll see in the next steps.

TensorFlow 1.0's difficulty came down to its static computation graph model. Writing a TensorFlow 1.x program meant describing math symbolically — tf.placeholder for inputs, a chain of operations for the model — without any of it actually executing. Only after calling sess.run() inside a tf.Session did real numbers flow through the graph you'd built.

This broke the debugging habits most Python developers rely on. A standard print(some_tensor) inside a TF 1.x graph-building block wouldn't show you a value — it would show you a symbolic tensor object with no data yet, because the computation hadn't happened. Diagnosing a shape mismatch or a wrong gradient meant reasoning about the graph structure abstractly, often with specialized tools, rather than stepping through code line by line.

This is also why TF 1.x is now considered legacy: TensorFlow 2.x runs eagerly by default, executing each operation immediately as it's called, so ordinary Python debugging techniques work again.

Before testing your understanding, it's worth being precise about what changed between TensorFlow 1.x and 2.x execution. TensorFlow 2.x didn't remove the graph — it changed when and how the graph gets built. By default, TensorFlow 2.x runs in eager mode, executing each operation immediately, the moment it's called, exactly like ordinary Python and NumPy code.

Graphs haven't disappeared, though. When performance matters — for training loops or deployment — you can still compile a Python function into a graph using the @tf.function decorator, gaining back the optimization and portability benefits of the old graph-based execution without losing the ability to write and debug that function eagerly first.

Make sure you can articulate the difference between eager execution (the TF 2.x default) and graph execution (opt-in via tf.function) before moving on — this distinction comes up repeatedly in later modules on performance and deployment.

With TensorFlow 2.0, Google restructured the framework around eager execution, a shift heavily influenced by the developer experience PyTorch had already popularized. Instead of requiring you to build a graph and run it inside a session, TensorFlow 2.x evaluates each operation the instant it's called, returning concrete tensor values immediately.

This change had a cascading effect on the rest of the API. Keras became the official high-level API for building models, tf.Session and tf.placeholder were removed from everyday use, and ordinary Python control flow — if statements, for loops, standard debugging — started working directly on tensors the way it would on any other Python object.

The result is a framework that feels far closer to writing regular Python while still retaining the option to compile performance-critical code into graphs, giving developers the best of both the old and new execution models.

The ability to print() a tensor and immediately see its value is a direct consequence of eager execution being TensorFlow 2.x's default mode. Every operation — a multiplication, a layer call, a loss computation — runs as soon as Python reaches that line of code, producing a concrete tensor with real numbers rather than a symbolic placeholder in an unexecuted graph.

This is a meaningful shift from TensorFlow 1.x, where the same print() statement on a tensor mid-graph would only show you metadata about the operation — its name, shape, and dtype — because no session had run it yet. In TF 2.x, a tensor behaves much more like a NumPy array: you can inspect it, convert it with .numpy(), and reason about intermediate values the same way you would in ordinary Python.

Being able to explain this clearly — that eager execution evaluates operations immediately rather than deferring them to a graph run later — is exactly the kind of fundamentals check that distinguishes someone who understands TensorFlow's execution model from someone who has only memorized syntax.

With the paradigm shift from static graphs to eager execution established, you're ready to move from TensorFlow's history into its low-level Tensor operations — creating tensors, inspecting their shape and dtype, and performing the arithmetic that every higher-level Keras layer ultimately reduces to.

This grounding matters even if you plan to spend most of your time in the high-level Keras API later in this course. When a model throws a shape-mismatch error or a training loop behaves unexpectedly, the fastest way to debug it is by reasoning directly about the tensors flowing through your code — exactly the mental model this module has been building.

From here, the course moves into hands-on tensor creation and manipulation, building the vocabulary you'll need before layers, models, and training loops start assembling these primitives into full neural networks.

Welcome to the TensorFlow course. TensorFlow is Google's massive, production-grade Deep Learning framework. It powers Google Search, YouTube recommendations, and Waymo.

Module 01 covers the "Core" of TensorFlow. This is the low-level math engine that executes matrix operations on GPUs and TPUs.

In the modern AI industry, what is the primary difference in use cases between TensorFlow and PyTorch?

• →TensorFlow only works on CPUs.
• →PyTorch dominates academic research, while TensorFlow has traditionally dominated massive-scale enterprise production and mobile/edge deployments.
• →PyTorch is owned by Google, and TensorFlow is owned by Meta.

TensorFlow gets its name from its architecture: Tensors (multi-dimensional arrays of data) "Flowing" through a mathematical graph of operations.

What does the word "TensorFlow" actually mean?

• →It refers to how fast the internet flows into the GPU.
• →It refers to 'Tensors' (multi-dimensional data arrays) 'flowing' through a directed computational graph of mathematical operations.
• →It is a random word chosen by Google engineers.

In TensorFlow 1.x, you had to manually build the entire graph before you could run any data through it. It was incredibly difficult to debug.

Why was TensorFlow 1.0 notoriously difficult for beginners to learn compared to PyTorch?

• →It used 'Static Computation Graphs', meaning you had to write all the math first, compile it, and run it later, making it impossible to debug with standard Python print() statements.
• →It required learning C++.
• →It did not support GPUs.

Now, prepare yourself. We are about to enter the ADA Defense Protocol. Ensure you understand TensorFlow 2.x execution modes.

In TensorFlow 2.0, Google copied PyTorch's architecture. They introduced "Eager Execution", which runs code line-by-line instantly.

ADA DEFENSE: A senior developer looks at your TensorFlow 2.x code and asks how you are able to use a standard Python print() statement on a Tensor to see its value. How do you respond?

• →I bypassed the security protocols.
• →TensorFlow 2.x enables 'Eager Execution' by default, meaning operations are evaluated instantly as they are called in Python, rather than being added to a static graph.
• →It is a bug in the system.

Threat neutralized. Paradigm shift acknowledged. Proceeding to low-level Tensor operations.

Compute a Real Tensor Rank. Finish tensor_rank(): rank is just the number of dimensions.