Recipe
Check a relation and find its classes
Use when: you're handed a specific relation on a set and need to know whether it's an equivalence relation, and if so, what its classes are
Goal: either a confirmed equivalence relation with its full list of classes, or the specific property that fails
Taught in Equivalence relations and partitions, revisited
Quick recipe
-
1
Confirm a \sim a holds for every element a in the set. Don't just try a few examples and stop there.
Example
Let A = \{0,1,\ldots,8\} and x \sim y mean x and y leave the same remainder mod 4. Every x obviously relates to itself, so x \sim x holds for every x \in A.
Why: an element missing from its own class right away breaks the whole idea of a class containing it.
-
2
Confirm a \sim b implies b \sim a for every related pair. Check both directions, not just one.
Example
If x \sim y, then y \sim x too: the relation doesn't care which one is named first.
Why: without this check, an element could count as related to a while a doesn't count as related back. That leaves "the class containing a" unclear.
-
3
Confirm a \sim b and b \sim c together force a \sim c. Check every such chain in the relation, not just the pairs that come to mind first.
- all three checks pass — continue to the next step and build the classes.
- any single check fails — stop here. The relation is not an equivalence relation, and no class list can be built from it.
Why: the transitive check is the one most often skipped. Skipping it is exactly what lets "classes" overlap or leave elements out.
-
4
For each element a, collect [a] = \{x \in A : x \sim a\}. Repeat until every element of A sits in some class.
Example
Continuing with A=\{0,\ldots,8\}: sort by remainder mod 4 to get [0]=\{0,4,8\},\quad [1]=\{1,5\},\quad [2]=\{2,6\},\quad [3]=\{3,7\}
Why: once all three checks pass, the recalled theorem guarantees these classes partition A automatically. No element is left out or counted twice.
Common mistakes
- Checking that a relation is reflexive and symmetric, then skipping the transitive check because it "looks obviously fine."
- Testing a property on one or two elements, then assuming it holds everywhere, instead of confirming the general case.
- Building classes before finishing all three checks, then finding a missing pair only after the grouping is already drawn.
- Forgetting that a relation failing even one property can still group most elements correctly. That makes the one bad case easy to miss.