Chapter DDeep learningPage 7 of 8

Deep learning

Set release boundaries for the two-layer XOR network

Page 7 advances one concrete two-layer XOR network: explain the decision, run the code, inspect failure, measure evidence, and keep only what is ready to ship.

~14 minSafety and operations

Before you start

Why this matters

Without running code, predict the output of this page's example and name the intermediate value that would prove your prediction. Then write one sentence answering: “What could look successful while actually being wrong?” For this stage, focus on dead or dimensionally broken network. Keep the prediction nearby; comparing it with the real output is the first debugging exercise, not a quiz about syntax.

1Learn the idea

Read

Build focus

Before release, define what the artifact refuses to do. The operational risks here are dead ReLU paths, incompatible tensor shapes, exploding activations, and mistaking depth for guaranteed quality. Validate ranges, minimize retained data, pin the reviewed configuration, and assign an owner who can disable the feature. Safety is implemented at the boundary and release process; it is not a warning paragraph placed after an unsafe function.

The artifact's user-facing goal is specific: show why a hidden layer can solve XOR while a single straight decision boundary cannot. Its accepted input is the four binary XOR examples, represented as two floats and one binary target. Those statements are intentionally narrower than “build an AI system.” Narrow scope lets us inspect every input and expected result, and it prevents a toy result from being presented as a production claim. Run this gate as part of a release command. A failed assertion means stop, investigate, and do not publish.

Read

Run the example

Save this as lesson.py and run python3 lesson.py. It uses only the language standard library, so the example is reproducible offline.

x=[1.0,0.0]
assert all(0<=v<=1 for v in x)
max_weight=1.0
assert max_weight<=5
print('input and weight bounds passed')

Expected output: input and weight bounds passed. Exact floating-point formatting may vary slightly, but the asserted behavior must not. Read the output as evidence about this stage, not merely proof that the interpreter started.

Read

Debug the stage

Print both hidden activations for all four XOR rows. A hidden unit that is zero for every row is dead and contributes nothing; revisit its weights before changing the output threshold. When a dot product fails, print both dimensions and repair the architecture, not the input by truncation. Keep the linear baseline visible: XOR's value is demonstrating representation, not merely obtaining four correct labels.

At the safety and operations stage, save the smallest failing fixture beside the expected result. Change one cause at a time and rerun the exact command printed above; that makes the repair reviewable and keeps this chapter's progressive artifact reproducible.

Read

Evaluate before continuing

Assert the exact XOR truth table, then calculate hidden-unit activation coverage and prediction margin. Compare with the best single linear boundary, which cannot classify all four corners. Perturb each input slightly only if the declared domain permits non-binary values, and state that this fixed-weight demonstration explains a forward pass rather than proving a trained deep model will generalize.

For this safety and operations page, preserve the fixture and result as evidence for the next page. Label observations separately from conclusions: a passing assertion establishes the behavior it names, while broader usefulness requires the chapter's full evaluation set and stated operating limits.

Checking tutor…

Continue learning · glossary & guides
  • [ ] Is there a concrete release blocker and named owner?
  • [ ] Are data range, retention, and rollback rules executable?
  • [ ] Can the reviewed version be identified after release?
  • [ ] Can I show which hidden unit represents each XOR difference?

Glossary: deep learning · Glossary: loss function

Previous · Next