Free Mathematics & logic lessons
Representation is the first engineering decision
Real situations contain unlimited detail. A representation deliberately preserves some distinctions and discards others: a graph keeps entities and relationships; a bitmap keeps sampled colour; an account balance keeps an agreed unit and precision. An algorithm is only meaningful after those states and operations are defined.
A support queue can be a FIFO list when fairness means arrival order, a priority heap when severity dominates, or several queues when service classes have separate promises. The customers did not change. The representation changed which operation became cheap and which policy became natural.
How software earns a guarantee
A universal claim must survive every valid case, so one counterexample defeats it. A constructive proof shows how to produce an object. Induction handles recursively built or repeated structure. In programs, an invariant is a statement kept true before and after each step; together with termination, it turns local reasoning into an end-to-end guarantee.
Maintain this invariant: if the target exists, it lies inside the current half-open interval [low, high). Comparing the midpoint removes only a region that cannot contain the target, so the invariant survives. The interval strictly shrinks, so the loop terminates. At termination the remaining state determines found versus absent.
Sets, graphs, matrices, and probability
Sets answer membership and overlap. Graphs expose relationships and paths. Matrices encode linear transformations and pairwise structure in a form machines can process efficiently. Probability represents uncertainty rather than pretending incomplete knowledge is certainty. Mature problem solving means switching lenses without confusing the model for the world.
Users and films form a bipartite graph. The same edges form an interaction matrix. A model can then estimate a probability that a user values an unseen film. Each view supports a different operation: traversal, linear algebra, or calibrated decision-making.
Prove the model survives a changed assumption
Define valid inputs, required outputs, invariants, and explicitly excluded cases before choosing code. Then an implementation can be tested or proved against that contract. When requirements change, you can identify which assumption broke instead of patching symptoms blindly.
Represent the lift with floor, direction, door state, and pending requests. State the invariant “the car never moves while a door is open.” A transition that sets direction before closing the door is a concrete counterexample trace. The repair belongs in the transition rules, and tests should include the once-failing trace.