Count The Target Ticket

The Bug Report

The program reads a line of raffle ticket numbers and a target ticket number, then prints how many times the target appears in the list. It runs cleanly, never raises an error, and prints a number every time. The number is always 0.

Input that shows the problem

7 3 7 12 5
7

What the program prints

0

What it should print

2

The target 7 is sitting right there at the start of the list and again in the middle. The program finds neither. Worse, it looks correct on any input where the true answer happens to be 0, which is how this one got as far as it did.

Input Format

The input has exactly two lines:

• Line 1: the ticket numbers, as integers separated by single spaces (at least one).
• Line 2: a single integer, the target ticket number.

Output Format

Print one line containing a single integer: how many entries in the list are exactly equal to the target. Print 0 if the target does not appear at all.

How to Debug It

"Always prints 0" is a much stronger clue than "sometimes prints the wrong number", so start by pinning that down instead of assuming it. Reproduce with the smallest possible input — one ticket that is the target, so the only correct answer is 1. If that still prints 0, then the counter is never incrementing at all, which means the body of the if never runs on any input, which means the problem is the condition rather than the arithmetic around it.

So inspect the condition rather than staring at it. Immediately before the if, print both sides of the comparison, and print what kind of value each one holds: print(ticket, type(ticket), target, type(target)) in Python, or console.log(ticket, typeof ticket, target, typeof target) in JavaScript. Run it on that one-ticket input. Both values will look identical in the output, because printing hides the difference you are looking for — but the types beside them will not match.

That is your hypothesis, and it is testable in one line: the two sides of the comparison are different kinds of value, so an equality test between them can never succeed no matter what is typed. Change exactly one thing — how the target is read — and re-run. Then re-run the second sample as well, the one whose answer is genuinely 0, to confirm you have made the program right rather than merely different.

What Was Wrong

The ticket list was converted to numbers when it was read: tickets = list(map(int, input().split())) in Python, .map(Number) in JavaScript. The target line was not. It was read as input().strip() / readline().trim() and left as text.

Then the comparison ticket == target (Python) or ticket === target (JavaScript) asks whether the number 7 equals the string "7". In both languages the answer is no, and — this is the part that makes it hard to spot — neither language complains. Python's == between an int and a str simply returns False rather than raising, and JavaScript's === requires the two operands to be the same type before it will even look at their values. So the condition is false for every ticket on every input, the counter stays at 0, and nothing anywhere reports an error.

The fix is to convert the target the same way the list was converted, so both sides of the comparison are numbers:

target = int(input())

const target = Number(readline().trim());

It is worth knowing the near miss here. In JavaScript, 7 == "7" is true, because the loose == operator converts one side before comparing. Swapping === for == would therefore make this particular program print 2 — and would be the wrong fix, because it papers over a value that is the wrong type instead of correcting it, and the same loose comparison bites back elsewhere (0 == "" is also true). Convert the input at the boundary where it is read, then compare strictly.

Common Mistakes

• Using JavaScript's == to make the mismatch go away. It makes this input pass while leaving a string where a number belongs. The moment that value is used for anything other than equality — sorting, adding, comparing with < — the string behaviour comes back, and the next bug is harder to find than this one was.
• Converting with parseInt and forgetting what it accepts. parseInt("12abc") yields 12 rather than refusing, and parseInt("") yields NaN. For a line that is supposed to be one whole integer, Number(...) is the stricter and clearer choice, and int(...) in Python raises rather than guessing.
• Comparing str(ticket) == target instead, to make the types line up as text. It appears to work on the samples, but it makes 7 and 007 different tickets and -0 a separate value from 0. Numbers should be compared as numbers; text comparison quietly changes what "equal" means.