Coded inequalities: decode the symbols, then read the chain

Coded inequality is one of the most reliable scoring areas in bank reasoning, because it has no ambiguity once you stop trying to do it in one step. There are always two steps: first turn the code into ordinary relations, then test each conclusion by tracing a chain. Rush the two into one and you will guess; keep them separate and the questions become mechanical.

Step one: translate the code

The paper defines symbols, for example: @ means ‘greater than’, © means ‘equal to’, # means ‘less than or equal to’, and so on. Before touching the conclusions, rewrite every coded statement in plain relations. Turn P @ Q # R into P > Q and Q ≤ R. This step is pure transcription, and doing it fully on the page — not in your head — is what prevents the silly errors that cost this topic its easy marks.

Step two: trace an unbroken chain

A conclusion about two letters is definitely true only if you can walk from one to the other along relations that never change direction. The rules for combining links:

• A > B > C gives A > C. Strict all the way, strict conclusion.
• A > B ≥ C and A ≥ B > C both give A > C. One strict link anywhere makes the whole chain strict.
• A ≥ B ≥ C gives A ≥ C. Only when every link is equal-or-greater is the conclusion equal-or-greater.
• A > B < C gives nothing between A and C. The direction reversed, so their relation is undetermined.

That single “reversal breaks the chain” rule decides most conclusions on sight.

The either-or trap

Sometimes a conclusion looks false — and so does a second conclusion about the same pair — yet the answer is “either I or II follows”. This happens when the two conclusions are complementary and exhaustive: between A ≥ B and A < B there is no third possibility, so if the chain leaves the pair undetermined, exactly one of them must be true even though neither is true on its own.

The signature to watch for: two conclusions on the same pair, both individually not-definite, one using a strict sign and the other its exact complement (> paired with ≤, or < paired with ≥, or = paired with ≠). That pattern is the either-or case almost every time.

A worked reading

Given A ≥ B, B > C, C ≥ D. Test A > C: the chain A ≥ B > C has a strict link, so A > C — true. Test A > D: the chain A ≥ B > C ≥ D still carries a strict link, so A > D — true. Test B ≥ D vs B > D: the chain B > C ≥ D gives B > D, so B > D is true and the weaker B ≥ D is also true. No reversals here, so every same-direction pair resolves.

Where the marks leak

Skipping the transcription. Reading conclusions straight off coded symbols is the single biggest source of errors. Write the plain relations first, every time.

Calling a possibility a certainty. “Could be equal” does not make A = B follow. The question asks what must be true.

Missing the either-or. When both conclusions about a pair fail and they are exact complements, check for either-or before marking “neither follows”.

Practice that transfers

The “does it definitely follow” judgement is the same muscle used in syllogism by the Venn method, so practise the two together — they even share the either-or idea. Keep the symbol translations sharp with the reasoning shortcuts cheat sheet, then put a timer on a mixed set in a full-length mock test.