Nepal SEE Computer Science study materials
Nepal SEE Computer Science study resources

QBASIC marks processor: two initialisations in the wrong place

Nepal SEE Computer Science · Put your knowledge to work in context.

All case studies

QBASIC marks processor: two initialisations in the wrong place

A private secondary school in Butwal uses a QBASIC program in its SEE practical to process the marks of 30 students. For each student the program inputs marks in five subjects out of 100, adds them into T, computes P = T/5, prints T, P and a grade, and at the end prints how many students passed and the highest percentage.

The school's grade table is: 90 and above A+, 80 to 89 A, 70 to 79 B+, 60 to 69 B, 50 to 59 C+, 40 to 49 C, 35 to 39 D, below 35 E.

In the current version, T = 0 and PC = 0 (the pass counter) are both placed once, before FOR I = 1 TO 30. During the trial run the first student's percentage printed correctly as 68, but by the fourth student the program printed a percentage of 214 and the grade E, and after all 30 students it printed Students passed: 1. The teacher blames the SELECT CASE block; the student who wrote the program blames the grading table.

1. Explain the two wrong outputs - 214 followed by grade E, and 'Students passed: 1' - and state exactly where each initialisation belongs.

Read the worked answer

Both bugs come from the same misunderstanding, but they are opposite errors.

T. Because T is set to 0 only once, before the loop, every new student's five marks are added to the totals of all previous students. With an average total near 214 per student, by the fourth student T is about 4 × 214 = 856 and P = T/5 = 214. The percentage is really a running total of the whole class, not one student. T must be reset to 0 inside the loop, at the top of each pass, before the five INPUT statements.

PC. It is set once before the loop, which is correct, but the listing shows it being cleared inside the loop instead: PC = 0 at the start of each pass wipes the count for every student, so after the thirtieth student PC holds at most 1 - the last student's contribution. PC = 0 belongs before the FOR, and PC = PC + 1 (inside the IF that tests a pass) belongs inside it.

In short, the two initialisations are simply swapped. The SELECT CASE block and the grade table were never at fault - 214 matches no grade band, which is why E appeared.

2. Write the corrected SELECT CASE block for the given grade table and explain why CASE ELSE is essential, including one arithmetic trap in P.

Read the worked answer
P = INT(T / 5)
SELECT CASE P
  CASE IS >= 90: G$ = "A+"
  CASE 80 TO 89: G$ = "A"
  CASE 70 TO 79: G$ = "B+"
  CASE 60 TO 69: G$ = "B"
  CASE 50 TO 59: G$ = "C+"
  CASE 40 TO 49: G$ = "C"
  CASE 35 TO 39: G$ = "D"
  CASE ELSE: G$ = "E"
END SELECT

The arithmetic trap: in QBASIC / produces a single-precision result, so a total of 397 gives P = 79.4, which matches none of the TO bands (79.4 is not between 70 and 79) and silently becomes E. Either take INT(T/5) as above, or write the bands with decimal upper limits.

CASE ELSE is essential because it catches everything the listed bands do not - out-of-range values caused by a data-entry error, a percentage like 105, or the fractional case just described. Without it, G$ is simply left holding the previous student's grade and a wrong grade is printed against the wrong name.

3. A student scores 88, 74, 65, 91 and 82. Trace the block and state the grade. Then state what would be printed if the same bands were written as `CASE IS >= 50`, `CASE IS >= 80` and so on in that order.

Read the worked answer

Trace. T = 88 + 74 + 65 + 91 + 82 = 400; P = 400/5 = 80. In the block, CASE IS >= 90 is false, CASE 80 TO 89 is true, so G$ = "A". The remaining CASE lines are skipped - SELECT CASE stops at the first match, unlike a chain of separate IFs.

Reordered CASE IS version. If the block is written as CASE IS >= 50 first, then CASE IS >= 80 and so on, P = 80 satisfies IS >= 50 first, so the program prints C+ instead of A. This is the key contrast: bands written with TO are disjoint, so their order does not matter; conditions written with IS overlap, so they must run from highest to lowest (or lowest to highest, consistently). The same rule explains why the teacher's suspicion about the grading table was half right - the table was fine, but a badly ordered IS chain would break it.