Learn
8.1.3 | INPUT, OUTPUT AND USER PROMPTS
01 | A PROGRAM NEEDS INFORMATION FROM SOMEWHERE
A ticket program can calculate a cost, but it first needs to know how many tickets the user wants. It also needs to tell the user the result. This creates a simple conversation between the user and the program.
Input is data supplied to a program. Output is information communicated by it. In this lesson, we use a keyboard-and-screen model to make the interaction easy to follow.
A prompt such as “Enter ticket quantity” is itself output. The user’s response, such as three, is input. The calculated cost shown afterwards is another output.
The direction is defined from the program’s point of view: data comes in; information goes out. Keep that distinction clear even when everything appears on the same screen.
02 | INPUT STORES A SUPPLIED VALUE
The INPUT instruction receives a value and stores it in the named variable. Declare the variable first so its intended type is clear.
DECLARE Quantity : INTEGER INPUT Quantity
If the user supplies three, Quantity receives three. Later instructions can use that value in a calculation.
INPUT Quantity does not mean that the user types the word Quantity. Quantity is the program’s variable name; the user supplies its value.
The instruction also does not explain what the user should enter. Without a prompt, a program may wait for data while giving little useful guidance. We will fix that with OUTPUT.
For this short example, assume the user supplies a valid whole-number quantity. Input validation and conversion are separate concerns, not automatic consequences of writing INPUT.
03 | OUTPUT COMMUNICATES TEXT OR VALUES
OUTPUT can display literal text, the current value of a variable or the result of an expression.
DECLARE Quantity : INTEGER Quantity ← 3 OUTPUT "Welcome to ticket booking" OUTPUT Quantity OUTPUT Quantity * 2
The outputs are the welcome message, three and six, in that order. The final instruction evaluates the expression for output; it does not change Quantity to six.
To change a variable, use an assignment. Displaying its value simply reads it.
| Instruction | Effect |
|---|---|
| OUTPUT Quantity | Display the current Quantity |
| OUTPUT Quantity * 2 | Display twice the current Quantity without replacing it |
| Quantity ← Quantity * 2 | Replace Quantity with twice its current value |
Exactly how an implementation places output on lines depends on its output facility. Our examples show successive output events in their execution order.
04 | A PROMPT IS OUTPUT BEFORE INPUT
A user prompt tells someone what response the program needs. Place it before the corresponding INPUT so the user sees the instruction before supplying the value.
DECLARE Quantity : INTEGER OUTPUT "Enter the number of tickets" INPUT Quantity
First the program displays the request. Next it receives a value. Quantity now holds the response for later use.
Changing the order changes the interaction: INPUT before the prompt asks for a response before explaining what that response should be.
Use a prompt that describes the information, rather than exposing an internal variable name. “Enter the number of tickets” is more helpful than “Enter Q”, even if the variable itself were called Q.
05 | MAKE PROMPTS SPECIFIC AND USEFUL
“Enter value” is vague. A user needs to know what the value represents, its unit where relevant and any important permitted format or range.
| Vague prompt | Clearer prompt | Why it helps |
|---|---|---|
| Enter value | Enter the number of tickets as a whole number | Explains quantity and format |
| Enter temperature | Enter temperature in degrees Celsius | Specifies the unit |
| Enter score | Enter a whole-number score from 0 to 10 | States type and range |
| Enter code | Enter the four-character ticket code, including leading zeros | Protects an important representation |
Do not invent a restriction that the task does not have. If the specification allows zero, a prompt saying one to ten contradicts it.
A clear prompt helps a user supply suitable data. It does not enforce the rule: the program still needs an appropriate check if invalid entries must be handled.
06 | LITERAL TEXT AND A VARIABLE VALUE
Quotation marks mean literal text. An unquoted variable identifier retrieves the stored value.
DECLARE PlayerName : STRING PlayerName ← "Maya" OUTPUT "PlayerName" OUTPUT PlayerName OUTPUT "Hello, ", PlayerName
| Output instruction | Result |
|---|---|
| OUTPUT "PlayerName" | PlayerName |
| OUTPUT PlayerName | Maya |
| OUTPUT "Hello, ", PlayerName | Hello, Maya |
In Cambridge pseudocode, comma-separated output items allow a label and value to be output together. Include intended spaces inside the text, such as the space after the greeting comma.
Do not assume that placing a variable’s name inside a string automatically substitutes its value. OUTPUT "Hello, PlayerName" produces those words literally.
07 | BUILD A COMPLETE INPUT–PROCESS–OUTPUT EXAMPLE
A ticket costs a fixed four point five zero. The user supplies a valid non-negative whole-number quantity. The program calculates the cost and displays it.
CONSTANT TicketPrice ← 4.50 DECLARE Quantity : INTEGER DECLARE TotalCost : REAL OUTPUT "Enter the number of tickets as a whole number" INPUT Quantity TotalCost ← Quantity * TicketPrice OUTPUT "Total cost: ", TotalCost
Quantity stores input. Multiplication is the process. The prompt and final labelled cost are outputs. TicketPrice is a constant because the rule stays fixed during execution.
For three tickets, the calculated cost is thirteen point five. A display might format that as 13.50, but decimal formatting is not specified by this pseudocode.
Do not hard-code thirteen point five as the answer. The calculation must use the supplied quantity so that a different valid input produces its appropriate result.
08 | TRACE THE INTERACTION, NOT JUST THE FINAL NUMBER
| Step | Program output | User input | State after the step |
|---|---|---|---|
| 1 | Enter the number of tickets as a whole number | None | Quantity not yet assigned |
| 2 | None | 3 | Quantity = 3 |
| 3 | None | None | TotalCost = 13.5 |
| 4 | Total cost: 13.5 | None | Both values unchanged |
The prompt counts as output. The user’s three is an input, even if the console visibly echoes the typed response. Do not count an echoed keystroke as an OUTPUT instruction from the pseudocode.
Three does not become output until an output instruction communicates it. In this algorithm the final output uses the cost rather than the quantity.
A trace table can record inputs, variable changes and output events separately. Make clear which is which; a single list of numbers without labels hides the interaction.
09 | TRY THE BOOKING CONVERSATION
This small demonstration uses the same price rule. Supply a whole-number quantity and compare the prompt, input and result. The demo checks its form input; the short pseudocode above assumes valid input.
Try zero and four. Zero tickets gives zero cost; four tickets give eighteen. The price remains fixed while input and calculated output vary.
10 | TWO INPUTS NEED TWO CLEAR REQUESTS
Now receive both a name and a quantity. Use a prompt for each so the user knows which value is required next.
DECLARE StudentName : STRING DECLARE Quantity : INTEGER OUTPUT "Enter your name" INPUT StudentName OUTPUT "Enter the number of tickets" INPUT Quantity OUTPUT "Booking for: ", StudentName OUTPUT "Tickets requested: ", Quantity
If the supplied values are Maya and three, StudentName receives Maya and Quantity receives three. The final outputs label both values.
The order matters. Two unlabeled INPUT instructions can be difficult to use because the user may not know whether to enter their name or quantity first.
This fragment demonstrates input and output only. It does not claim that places have been reserved, payment taken or a record saved.
11 | ANOTHER INPUT CAN REPLACE THE OLD VALUE
Each INPUT to the same variable stores a new value in that variable. Earlier input is not automatically preserved as a history.
DECLARE Score : INTEGER OUTPUT "Enter the first score" INPUT Score OUTPUT "First score: ", Score OUTPUT "Enter the second score" INPUT Score OUTPUT "Second score: ", Score
For inputs four then seven, the first labelled result contains four and the second contains seven. At the end, Score holds seven.
If you need both values later, use separate variables or another suitable data structure. Reusing one variable is fine when only the current value is needed, but unsuitable when the task requires earlier values to remain available.
OUTPUT before replacement still communicates the earlier value. It does not itself keep a copy inside the program for future processing.
12 | PROMPTS DO NOT CONVERT OR VALIDATE DATA
“Enter a whole number from zero to ten” describes the expected response. It does not by itself reject eleven or turn arbitrary text into a number.
DECLARE Score : INTEGER
REPEAT
OUTPUT "Enter a whole-number score from 0 to 10"
INPUT Score
UNTIL Score >= 0 AND Score <= 10
OUTPUT "Accepted score: ", ScoreAssume every input supplied here is already a whole number. The condition performs the range check. With inputs twelve then eight, the prompt occurs twice; twelve is retried and the final output reports eight.
The declared type explains intended data. A real language or input facility may receive keyboard data as text, require conversion or reject a mismatch. Follow the question’s stated assumptions and do not invent a universal automatic conversion rule.
Notice the boundary: input receives the response, validation checks it, and output provides guidance or a result. These jobs work together but remain distinct.
13 | LABEL OUTPUTS SO THE RESULT HAS MEANING
A bare output of eighteen might represent tickets, currency or minutes. A useful label connects the value to its meaning.
OUTPUT "Tickets requested: ", Quantity OUTPUT "Total cost: ", TotalCost
For measurements, include the specified unit. If Duration holds minutes, OUTPUT "Duration in minutes: ", Duration is clearer than OUTPUT Duration.
Do not display a claim that processing has not established. “Booking confirmed” is misleading if the algorithm merely calculates a cost and never checks or records a booking.
Keep the result tied to its current variable value. A copied literal such as OUTPUT "Total cost: 13.50" cannot adapt when the input quantity changes.
14 | INPUT AND OUTPUT ARE WIDER THAN A KEYBOARD AND SCREEN
The pseudocode model makes the direction clear, but a program can obtain data from sensors, files or other systems, and communicate through files, network messages or physical outputs.
For example, a temperature reading entering a controller is input. A command sent from that controller to an actuator is output. In a booking program, a file record read into the program is input, while a report written out is output.
Later lessons cover file handling and other operations. Here, use the given source and destination rather than assuming every INPUT is necessarily a keyboard and every OUTPUT a screen.
For the console examples in this lesson, keyboard responses and displayed messages are the specific model we are tracing.
15 | CHECK YOUR UNDERSTANDING
Input versus prompt: a prompt is output; the supplied response is input.
Receiving versus checking: INPUT stores a response, but validation needs its own rules.
Display versus assignment: OUTPUT reads or evaluates information for communication; it does not automatically replace the variable.
Literal versus value: quotes give fixed text, while the unquoted identifier gives its current value.
Clear versus unsupported: label results accurately and do not claim work that the algorithm has not performed.
Practise explaining a complete interaction: first the program prompts, then the user supplies data, the program processes it, and finally it outputs a labelled result. The next lesson focuses on sequence and assignment.