Relational operations in a programming language

Operator	Meaning	AQA pseudo-code	Example	Result
Equal to	Are the two values the same?	=	5 = 5	True
Not equal to	Are the two values different?	≠	5 ≠ 3	True
Less than	Is the left smaller?	<	3 < 5	True
Greater than	Is the left bigger?	>	3 > 5	False
Less than or equal to	Is the left smaller or the same?	≤	5 ≤ 5	True
Greater than or equal to	Is the left bigger or the same?	≥	5 ≥ 6	False

The key idea: they produce Booleans

A relational operation is not a calculation — it is a question, and the answer is always True or False.

total ← 5 + 3        # arithmetic → produces a NUMBER (8)
isBigger ← 5 > 3     # relational → produces a BOOLEAN (True)

That is why relational operators sit inside conditions: an IF needs something that is either True or False in order to decide which branch to take.

IF score ≥ 40 THEN      # 'score ≥ 40' evaluates to True or False
    OUTPUT 'Pass'
ENDIF

A neat consequence. Because the comparison itself produces a Boolean, you can store it:

hasPassed ← score ≥ 40      # hasPassed is now True or False
IF hasPassed THEN           # no comparison needed here at all
    OUTPUT 'Pass'
ENDIF

This links directly to 3.2.1 — a Boolean variable can be tested directly in a condition, which is why IF hasPaid THEN is cleaner than IF hasPaid = True THEN.

AQA tip. The specification says students should use these operators "within their own programs" and "be able to interpret them when used within algorithms". So you must both write them and read them — trace-table questions frequently hinge on evaluating a condition correctly.

The specification notes: "different languages may use different symbols to represent these operators."

Meaning	AQA pseudo-code	Python	C#	VB.NET
Equal to	=	==	==	=
Not equal to	≠	!=	!=	<>
Less than	<	<	<	<
Greater than	>	>	>	>
Less than or equal to	≤	<=	<=	<=
Greater than or equal to	≥	>=	>=	>=

Only the first two really differ. <, >, <= and >= are essentially universal; it is equal to and not equal to where languages diverge.

The = versus == trap

This is worth understanding properly because it causes real bugs.

Context	Symbol	What it does
AQA pseudo-code assignment	←	Stores a value: x ← 5
AQA pseudo-code comparison	=	Asks a question: IF x = 5
Python/C# assignment	=	Stores a value: x = 5
Python/C# comparison	==	Asks a question: if x == 5

In AQA pseudo-code there is no ambiguity, because assignment has its own symbol (←). In Python or C#, writing if x = 5 instead of if x == 5 is a genuine error — in Python it is a syntax error; in some older languages it silently assigns 5 to x and the condition becomes permanently true.

AQA tip. In an exam, if the question says "write pseudo-code", use ← for assignment and = for comparison. If it says "write program code", use the correct symbols for your taught language. Mark schemes accept the conventions of any of the three supported languages, but they must be used consistently.

≤ includes the boundary value. < excludes it. Almost every off-by-one logic error on Paper 1 traces back to this.

Worked comparison

Suppose age is exactly 18:

Condition	Evaluates to	Does 18 qualify?
age < 18	False	No — 18 is not less than 18
age ≤ 18	True	Yes — 18 is less than or equal to 18
age > 18	False	No
age ≥ 18	True	Yes
age = 18	True	Yes
age ≠ 18	False	No

Translating English into the right operator

This is what scenario questions actually test:

English in the question	Operator	Example
"at least 18"	≥	age ≥ 18
"at most 10"	≤	items ≤ 10
"more than 100"	>	score > 100
"under 18" / "less than 18"	<	age < 18
"18 or over"	≥	age ≥ 18
"up to and including 10"	≤	n ≤ 10
"between 1 and 10" (inclusive)	≥ and ≤	n ≥ 1 AND n ≤ 10
"not equal to zero"	≠	n ≠ 0

Watch "between". In everyday English "between 1 and 10" almost always includes 1 and 10, so it needs ≥ 1 AND ≤ 10. AQA's own validation example is "checking if data entered lies within a given range (eg between 1 and 10)", and the boundary data for that range is 0, 1, 10, 11 — which only makes sense if 1 and 10 are the accepted extremes.

Why this connects to test data

Boundary (extreme) test data in 3.2.11 exists precisely to catch < versus ≤ mistakes. For an allowed range of 1 to 10, AQA specifies boundary data of 0, 1, 10, 11 — the values immediately either side of each limit. If you wrote n > 1 instead of n ≥ 1, testing with 1 would expose it instantly.

AQA tip. Whenever you write a condition, immediately test it mentally with the boundary value itself. "If the age is exactly 18, does my condition do the right thing?" That five-second check catches the majority of off-by-one errors.

Comparing numbers

Straightforward — the values are compared numerically. 9 < 100 is True.

Comparing strings and characters

Strings are compared character by character, using their character codes (3.3.5). This makes comparison effectively alphabetical, not numerical.

'apple' < 'banana'     # True  — 'a' has a lower code than 'b'
'cat'   < 'cattle'     # True  — identical so far, but 'cat' is shorter
'Zebra' < 'apple'      # True  — uppercase codes are LOWER than lowercase

How the comparison actually works: compare the first characters. If they differ, that decides it. If they are the same, move to the second, and so on. If one string runs out first, the shorter one is "less".

The trap that breaks validation

Because comparison is by character code, numbers stored as strings compare wrongly:

'9' < '100'      # FALSE!  — '9' has a higher code than '1'
9   < 100        # True    — compared as numbers

This is why an age or a score stored as a string cannot be range-checked correctly, and why keyboard input must be converted before it is compared numerically (3.2.1, 3.2.8).

Case sensitivity

'YES' = 'yes'    # False — different character codes

Uppercase and lowercase letters have different character codes (in ASCII, 'A' is 65 but 'a' is 97), so they are different values. A login check comparing 'Admin' with 'admin' will fail. Real programs convert both to the same case before comparing.

Comparing Booleans

IF found = True THEN     # works, but verbose
IF found THEN            # better — the Boolean IS the condition

Both are correct, but the second is cleaner and is what experienced programmers write.

AQA tip. If a question involves comparing text that a user has typed, mentioning case sensitivity as a potential problem is a genuine, creditworthy observation in 'explain' and 'evaluate' answers.

In selection

IF temperature > 30 THEN
    OUTPUT 'Heat warning'
ELSE IF temperature < 0 THEN
    OUTPUT 'Ice warning'
ELSE
    OUTPUT 'Normal'
ENDIF

In iteration

WHILE attempts < 3          # keep going while fewer than 3 attempts used
    …
ENDWHILE

REPEAT
    …
UNTIL guess = target        # stop when they match

Combined with Boolean operators for a range check

A range check needs two comparisons joined with AND (3.2.5):

IF mark ≥ 0 AND mark ≤ 100 THEN
    OUTPUT 'Valid mark'
ELSE
    OUTPUT 'Invalid mark'
ENDIF

Note carefully: you cannot write IF 0 ≤ mark ≤ 100 in most programming languages, even though it is valid mathematics. Each comparison must be written out in full and joined with AND.

The "is it outside the range" version

IF mark < 0 OR mark > 100 THEN
    OUTPUT 'Invalid mark'
ENDIF

Notice this is the exact opposite of the previous condition — and inverting it required flipping both operators and changing AND to OR. That is a genuinely useful pattern to recognise, and it links straight to 3.2.5.

A complete validation loop

REPEAT
    OUTPUT 'Enter a mark between 0 and 100'
    mark ← STRING_TO_INT(USERINPUT)

    IF mark < 0 OR mark > 100 THEN
        OUTPUT 'Invalid — please try again'
    ENDIF
UNTIL mark ≥ 0 AND mark ≤ 100

This single fragment combines relational operators (3.2.4), Boolean operators (3.2.5), condition-at-the-end iteration (3.2.2), type conversion (3.2.8) and validation (3.2.11) — which is exactly why it appears so often in high-tariff questions.

AQA tip. When writing a range check, always include both bounds. Writing only IF mark ≤ 100 accepts negative marks; writing only IF mark ≥ 0 accepts 500. Mark schemes award the mark for a complete check.