What does a beginner actually learn when a machine learning lesson moves from theory to code? The real answer is simple: how numbers become tensors, how tensors become models, and how a model gets trained, checked, and saved.
That sounds broad. It is broad. But the useful part is the sequence. Once that sequence is clear, the two big frameworks, PyTorch and TensorFlow, stop looking like rival mysteries and start looking like different ways to do the same job.
The first idea is a tensor
A tensor is just a container for numbers. One number is a scalar. A list is a vector. A grid is a matrix. Add more dimensions, and the same idea can hold images, batches, embeddings, and model weights.
This matters because modern machine learning is built on tensors. When a model learns, it is changing numbers inside these containers. When data moves through a model, it moves as tensors. Even the gradients used for learning are tensors.
PyTorch and TensorFlow both work with tensors, but they make the experience feel a little different. TensorFlow uses tf.math.* for many tensor operations. PyTorch uses torch.*. Both can run in eager mode, which means the code behaves in a direct, readable way while it runs.
A small example makes this less abstract. An image might be stored as height, width, and color channels. If you process several images at once, a batch dimension is added too. So a model may see data shaped like a stack of images, not a single picture. That shape is part of the problem, not an extra detail.
Two frameworks, same goal, different habits
PyTorch is known for a Python-first style. It uses dynamic computation graphs, which makes it feel natural for research, experiments, and custom model ideas. That style is one reason many learners find it easy to read.
TensorFlow offers both eager execution and graph-based execution. It is often used where deployment matters a lot, including production systems, mobile apps, and TPU-friendly workloads. Its Keras interface gives a cleaner high-level path for building models without writing every low-level piece by hand.
The practical difference is not that one is “smart” and the other is “simple.” It is more about emphasis. PyTorch often feels like a notebook-friendly workshop. TensorFlow often feels like a route from model idea to deployed package.
That tradeoff is worth noticing early. It keeps the framework choice from becoming a loyalty test. The better question is which style fits the work in front of you.
A model begins with layers
The lesson’s model-building stage starts with a small neural network. In TensorFlow, that can be done with Keras and a Sequential model. In PyTorch, the model is usually written as a class that inherits from nn.Module.
The difference is structural. Keras stacks layers in order. PyTorch asks the writer to define layers in __init__ and the forward path in forward(). Both lead to the same idea. Inputs go in. Transformed values come out.
A simple binary classification model might use one hidden layer and one output layer. In Keras, a hidden layer might use ReLU. The final layer might use sigmoid so the output stays between 0 and 1. In PyTorch, the same shape of model can be built with nn.Linear layers and a forward method that sends data through them.
The point is not the exact syntax. The point is that a model is a set of layers with a defined path. Once that is clear, the code becomes less magical and more mechanical.
Training is a loop, not a one-time event
Training has four steps. First, the model makes a prediction. Second, a loss function measures how far that prediction is from the truth. Third, gradients are computed. Fourth, an optimizer changes the weights.
This repeats over many epochs. An epoch means one full pass through the training data. A batch is the smaller group of samples used before each weight update. That is why batch size and learning rate matter. They shape how fast and how smoothly the model changes.
For regression, mean squared error is a common loss. It punishes big mistakes more than small ones. For classification, cross-entropy is common because it fits class prediction tasks better. SGD and Adam are two standard optimizers. Adam is popular because it adapts step sizes and often works well with a default learning rate near 0.001.
A concrete case helps here. If the task is predicting ice cream revenue from temperature and day of week, the model will output a number, not a class label. That makes it a regression problem. The loss should measure distance between predicted revenue and actual revenue, and MSE fits that shape well.
Data handling is part of the model story
Training gets messy if the data pipeline is messy. TensorFlow often uses tf.data.Dataset. PyTorch often uses DataLoader. Both help with batching, shuffling, and preprocessing while data is being fed to the model.
That matters for speed and for sanity. If images must be resized or features scaled, doing it on the fly keeps the workflow cleaner. It also helps the model see data in a more useful order. Shuffling reduces the risk that the model learns the order of the dataset instead of the pattern inside it.
A larger example from the lesson is digit recognition with EMNIST. With tens of thousands of images, a manual loop would be clumsy. A data loader or dataset pipeline keeps the training code focused on learning, not on file handling.
Debugging is mostly shape work and curve watching
Most model bugs are not dramatic. They are ordinary mismatches. A layer expects one shape and gets another. A learning rate is too large. Gradients blow up or vanish. The model fits the training data but fails on validation data.
The first move is often simple. Print shapes. If tensor sizes do not line up, the rest of the code may still run badly or not at all. The next move is to watch the loss curve. If the loss jumps around wildly, the step size may be too high. If it barely changes, learning may be too slow.
Gradient clipping can help when gradients grow too large. Validation checks can show whether the model is overfitting or underfitting. TensorBoard and basic plots make these patterns easier to see. None of this is glamorous. It is maintenance work. But it is the part that turns a fragile demo into something usable.
Saving the model closes the loop
A trained model is not useful if it cannot be stored and loaded again. TensorFlow makes this straightforward with model.save() and load_model(). PyTorch usually saves a model’s state dictionary with torch.save(model.state_dict(), ...) and loads it into a recreated model later.
That difference is small, but it matters in practice. TensorFlow leans toward saving a packaged model. PyTorch leans toward saving the learned parameters and rebuilding the structure in code. In both cases, checkpoints are wise during long training runs. They reduce the cost of interruptions.
This is one of those details that looks dull until it saves a day. Training jobs stop. Machines restart. Files vanish. A saved checkpoint turns that into a setback instead of a loss.
What the hands-on exercise is really teaching
The ice cream revenue exercise is not about ice cream. It is a compact path through the whole workflow. Load numeric data with NumPy. Standardize the inputs with StandardScaler. Build the model. Choose MSE and Adam. Train with the forward, loss, backward, optimizer cycle. Then compare predictions with actual revenue.
That sequence teaches the shape of applied machine learning. It shows how data preparation, model structure, optimization, and evaluation fit together. It also shows the limits. A simple regression task is a good teaching tool, but it does not prove the model is ready for every business setting or every messy real-world dataset.
That honesty matters. A small example teaches the mechanism. It does not promise mastery.
By the end of this lesson, the reader can see how PyTorch and TensorFlow both express the same learning loop, how tensor shapes drive the whole process, and how a model moves from raw data to saved weights. That is enough to understand the logic of a first working model without treating the frameworks like black boxes.
The practical next step is to keep the idea small and real. One practical technical idea, one learning decision, and one useful network resource each edition is exactly the kind of shape I trust, and that is why The Dravelo Field Notes feels like a good fit for this kind of work.