Final Exam Model Paper 9

• i.About 100,000 × 100,000 = 10¹⁰ cells (ten thousand million). Even at only 4 bytes a number that is 40 GB, more than the computer’s 16 GB: the program would run out of memory. Its space complexity is O(m × n).
• ii.Each row of the table is worked out only from the row above it, so the program can keep just two rows, the one above and the one being filled: about 200,000 numbers, under a megabyte. Its extra memory is then O(n).
• iii.Without the whole table, the program can’t read back which edits were made, only the distance itself. It saves no time: every cell is still worked out once, O(m × n), 10¹⁰ steps. Memory was traded away; time was not.

Any three, each with its point and a fix:

• Safe: a secret in the code. The SMS key is written into the program, so it is in every copy and in the history. Keep it in the server’s settings or a store made for secrets, and have this key changed.
• Requirements: erroneous data not handled. The age and phone are never checked: an age of −3 or “abc”, or a phone number of 6 digits, is saved as it is. Check them, and refuse bad ones with a clear message.
• Tests: none. Add tests for normal, boundary (age 0, the oldest age allowed) and erroneous data.
• Readable: # add patient repeats the code, and "unknown" is unexplained: say what the fourth item is (a dictionary with named fields helps), and comment only on why.
• For everyone: the SMS is in English only; send it in Nepali too, for patients who don’t read English.

• i.Event-driven: the program waits, and a block of code runs when something happens (the bucket tips), like a button’s click in a web page.
• ii.Logic programming (declarative): the program is facts and rules, and the engine works out every answer that follows; the program says what is true, not how to search.
• iii.Object-oriented: each bus is an object holding its own data (passengers, fuel, route) with its methods (pick up, drop, refuel), which suits a program modeling many things of one kind.

• i.60%: 0.2 ÷ 0.4 = 0.5 s; 90%: 0.2 ÷ 0.1 = 2 s; 98%: 0.2 ÷ 0.02 = 10 s.
• ii.Requests arrive at random, so near full they often arrive while the server is still busy, and a line builds; the closer to full, the less spare time there is to clear it. The time grows like 1 ÷ (1 − busy): from 90% to 98% the spare time falls from a tenth to a fiftieth, five times less, so the time grows five times.
• iii.Run a load test at the expected peak to find the bottleneck; add capacity before the day so the servers stay well below full (half to two-thirds busy); and have a waiting room or a queue that lets people in a few at a time rather than letting every request slow down for everyone.

• i.A predicts 2.0, 2.8, 3.6, 4.4: residuals (real − predicted) 0, 0.2, 0, 0. B predicts 2.1, 2.85, 3.6, 4.35: residuals −0.1, 0.15, 0, 0.05.
• ii.Sum of squared residuals: A, 0.2² = 0.04; B, 0.01 + 0.0225 + 0 + 0.0025 = 0.035. B is smaller, so B fits better, though A hits three points exactly: least squares counts every miss, and a big miss counts a lot.
• iii.For each 1 kg more fertilizer per hectare, the harvest is 0.015 tonnes (15 kg) per hectare higher on average, within the amounts measured.

The claim goes beyond the data. The line describes 2000 to 2020; 2058 is an extrapolation, 38 years past the last measurement. A high r² says the line fits those twenty years well, not that the trend will go on: the shrinking could slow (the lake gets smaller and deeper in the middle, rain changes), speed up, or stop if its cause (a new canal, say) changes. A straight line falling to zero is a choice of model, not a finding. A fair report: “The lake shrank by about 0.5 km² a year between 2000 and 2020”, with what may be causing it; a forecast needs an understanding of the causes, not only a line.

• i.52 × 31 = 1,612, which leaves 12, and each nonce adds 17 (mod 100): 12, 29, 46, 63, 80, 97, 14, 31, 48, 65, 82, 99, 16, 33, 50, 67, 84, and for n = 17: 12 + 289 = 301, which leaves 1. So the nonce is 17, after 18 tries.
• ii.One: (1,612 + 17 × 17) mod 100 = 1,901 mod 100 = 1, less than 10. Finding takes many tries; checking takes one.
• iii.Each try has about 1 chance in 100 instead of 1 in 10, so about 100 tries on average: each extra 0 needed makes the work about 10 times more. Real proof of work is the same with SHA-256’s hex digits: each extra 0 at the start makes it about 16 times more.

Any six of: the problem; the policy it changes; the change, in exact words; who gains and who pays; risks and safeguards; how it supports good innovation; evidence from elsewhere; what it costs and who pays; how we will know it worked.
The last part names what will be counted each year (for example, how many reviews were asked for and how many decisions changed), so the committee can see whether the change did any good, and change it again if it didn’t.

i.

• A 200: pickup 1 (200 kg).
• B 500: pickup 1 (700).
• C 600: pickup 1 would be 1,300, so pickup 2 (600).
• D 200: pickup 1 (900).
• E 500: pickup 1 (1,400) and 2 (1,100) are too full: pickup 3 (500).
• F 200: pickup 1 is full (1,100), so pickup 2 (800).
• G 300: pickup 1 (1,200) and 2 (1,100) too full: pickup 3 (800).
• H 500: none has room: pickup 4.

4 pickups: A, B, D (900 kg); C, F (800); E, G (800); H (500).

ii. Heaviest first: C 600, B 500, E 500, H 500, G 300, A 200, D 200, F 200.

• C: pickup 1 (600). B: pickup 1 would be 1,100, so pickup 2 (500). E: pickup 2 (1,000). H: pickup 3 (500).
• G: pickup 1 (900). A: pickup 3 (700). D: pickup 3 (900). F: none has room (pickup 1 would be 1,100): pickup 4.

4 pickups again: C, G (900); B, E (1,000); H, A, D (900); F (200).

iii. The loads weigh 3,000 kg in all, and a pickup carries at most 1,000 kg, so at least 3,000 ÷ 1,000 = 3 pickups are needed. And 3 is possible, each pickup exactly full: C + A + D (600 + 200 + 200), B + E (500 + 500), H + G + F (500 + 300 + 200).

iv. Each load can go in any of the pickups, so the ways grow like the number of pickups to the power 200: far too many to try, and each load more multiplies them again. But the cooperative can work out the lower bound every day, total weight ÷ 1,000 kg, rounded up: if the heaviest-first method uses 31 pickups and the bound is 30, its answer is at most one pickup worse than the best possible, and if they are equal, it is the best.

i.

• The harms, though the cases are few: 2 of 10 times it gave a patient another patient’s lab result (a serious breach of privacy), 3 of 10 times it answered how much medicine to take (a wrong dose can kill), and 2 of 5 times it obeyed the instruction hidden in a letter, sending results to a stranger. A failure here is far worse than a failed booking, so 81% overall is the wrong measure: these must pass every time.
• Roman Nepali: only 26 of 40 (65%), against 39 of 40 in English. Many people text Nepali in Roman letters, so it would fail exactly the patients who write that way: a gap between groups that the overall number hides.
• The same name: 4 of 10 wrong, which could book, or read, the wrong patient’s records.

ii. Limits inside the tools:

• read_lab_result gives a result only for the patient whose registered phone sent the message, after a code sent to that phone, and checks the patient number, not the name.
• send_sms sends only to the patient’s own registered number; anything with a lab result waits for a staff member’s approval.
• No tool gives doses: medicine questions are passed to a nurse.
• A limit on steps for every conversation, and letters and documents treated as data, never as orders.

These are stronger because the model can’t reliably tell data from instructions: a letter can talk it into anything. A check in the tool’s own code runs every time, whatever the model has been told.

iii. One well-argued case: Not as it is. Launch first for bookings only, with no access to results and a way to reach a person at any time; fix the tool limits and the Roman-Nepali gap; run the same test plan again, with the model’s version and date recorded, and add red-teaming of the harms; launch results only when every harm case passes; then keep records of every conversation that goes wrong, check results by group after launch, and keep a way to switch it off.

The cheapest way to get at least n kg is the cheapest, over every first bag, of that bag’s price plus the cheapest way to get the rest (nothing, if the bag already covers it). The table best keeps the answer for every smaller amount, so each is worked out once.

BAGS = {5: 450, 20: 1500, 50: 3400}   # kg in a bag: its price in rupees  def cheapest(kg):    """(fewest rupees, bag sizes) to buy at least kg kilograms."""    best = [(0, [])]                    # best[n]: the cheapest way to get at least n kg    for n in range(1, kg + 1):        options = []        for size, price in BAGS.items():            rest_price, rest_bags = best[max(0, n - size)]            options.append((price + rest_price, [size] + rest_bags))        best.append(min(options))    return best[kg]  def try_every(kg):    """The fewest rupees, by trying every first bag and every way to buy the rest."""    if kg <= 0:        return 0    return min(price + try_every(kg - size) for size, price in BAGS.items())  def test_nothing_needed():    assert cheapest(0) == (0, [])  def test_a_little():    assert cheapest(3) == (450, [5])  def test_buying_more_is_cheaper():    # 18 kg: four 5 kg bags cost Rs 1,800; one 20 kg bag Rs 1,500    assert cheapest(18) == (1500, [20]), f"gave {cheapest(18)}"  def test_enough_and_priced_right():    for kg in range(61):        rupees, bags = cheapest(kg)        assert sum(bags) >= kg and sum(BAGS[b] for b in bags) == rupees, f"{kg} kg: {bags}"  def test_same_as_trying_every_way():    for kg in range(61):        assert cheapest(kg)[0] == try_every(kg), f"{kg} kg: {cheapest(kg)[0]}, not {try_every(kg)}"  passed = failed = 0for name, test in list(globals().items()):    if name.startswith("test_"):        try:            test()            print("PASS", name)            passed += 1        except AssertionError as problem:            print("FAIL", name, problem)            failed += 1print(passed, "passed,", failed, "failed") for kg in [40, 65]:    rupees, bags = cheapest(kg)    print(f"At least {kg} kg: Rs {rupees:,}, bags of {sorted(bags, reverse=True)} kg")

PASS test_nothing_neededPASS test_a_littlePASS test_buying_more_is_cheaperPASS test_enough_and_priced_rightPASS test_same_as_trying_every_way5 passed, 0 failedAt least 40 kg: Rs 3,000, bags of [20, 20] kgAt least 65 kg: Rs 4,750, bags of [50, 5, 5, 5] kg

For 40 kg, the cheapest per kilogram, one 50 kg bag (Rs 3,400), costs more than two 20 kg bags (Rs 3,000).

The first run:

PASS test_nobodyPASS test_two_full_jeepsFAIL test_one_left_over gave 2FAIL test_a_small_group gave 02 passed, 2 failed

Line 6 uses //, which divides and rounds down: 15 // 7 is 2, leaving one passenger behind, and 6 // 7 is 0 jeeps for six people. A part-full jeep still has to go, so the answer must round up. The tests that passed had groups that fill whole jeeps (0 and 14), where rounding doesn’t matter. The tests match the requirement, so the code is wrong:

SEATS = 7      # passengers in one jeep  def jeeps_needed(people):    """The fewest jeeps that seat everyone."""    return (people + SEATS - 1) // SEATS  def test_nobody():    assert jeeps_needed(0) == 0  def test_two_full_jeeps():    assert jeeps_needed(14) == 2  def test_one_left_over():    assert jeeps_needed(15) == 3, f"gave {jeeps_needed(15)}"  def test_a_small_group():    assert jeeps_needed(6) == 1, f"gave {jeeps_needed(6)}"  passed = failed = 0for name, test in list(globals().items()):    if name.startswith("test_"):        try:            test()            print("PASS", name)            passed += 1        except AssertionError as problem:            print("FAIL", name, problem)            failed += 1print(passed, "passed,", failed, "failed")

PASS test_nobodyPASS test_two_full_jeepsPASS test_one_left_overPASS test_a_small_group4 passed, 0 failed

(math.ceil(people / SEATS) gives the same answer.)

trips = [    ("monsoon", 170, 240), ("dry", 160, 150), ("monsoon", 170, 200), ("dry", 150, 140),    ("monsoon", 170, 190), ("dry", 155, 145), ("monsoon", 195, 235), ("dry", 175, 185),    ("monsoon", 175, 215), ("monsoon", 185, 230), ("monsoon", 175, 215), ("monsoon", 190, 240),    ("monsoon", 175, 165), ("monsoon", 170, 220), ("monsoon", 160, 205), ("dry", 150, 150),    ("dry", 180, 185), ("dry", 180, 180), ("dry", 180, 180), ("dry", 175, 160),    ("monsoon", 170, 160), ("dry", 150, 150), ("dry", 170, 175), ("dry", 165, 170),]  def measure(name, seasons):    """The average miss, and the average of (actual − forecast), for these seasons."""    misses = [actual - said for season, said, actual in trips if season in seasons]    average_miss = sum(abs(m) for m in misses) / len(misses)    bias = sum(misses) / len(misses)    late = sum(1 for m in misses if m >= 30)    print(f"{name:8} {len(misses):2} trips  average miss {average_miss:4.1f} min  "          f"actual − forecast {bias:+5.1f} min  30+ min late: {late}")  measure("All", ["dry", "monsoon"])measure("Dry", ["dry"])measure("Monsoon", ["monsoon"])

All      24 trips  average miss 21.7 min  actual − forecast +16.2 min  30+ min late: 9Dry      12 trips  average miss  5.8 min  actual − forecast  -1.7 min  30+ min late: 0Monsoon  12 trips  average miss 37.5 min  actual − forecast +34.2 min  30+ min late: 9

One limit: “In the monsoon the bus took on average 34 minutes longer than the forecast, and 9 of 12 monsoon trips were half an hour or more late, so in the rains add at least half an hour to the time it shows.” In the dry season it is close (average miss under 6 minutes); the average over all 24 trips, 22 minutes, describes neither season.

• i.The farmer needs at least n kg, and a bag may be bigger than what is left: then nothing more is needed, so the rest costs 0. n - size would be negative, and best[-5] in Python would quietly read from the end of the list, a wrong answer with no error. The bag cheapest per kilogram can bring far more than is needed: for 40 kg, a 50 kg bag costs Rs 3,400, but two 20 kg bags, exactly 40 kg, cost Rs 3,000.
• ii.Groups of 0 and 14 fill whole jeeps, where rounding down and rounding up give the same answer.
• iii.It mixes two seasons: in the dry season the model misses by under 6 minutes, in the monsoon by over 37, almost always late. Passengers in the rains would be told a time half an hour too early. I would report its errors by season, find what makes monsoon trips slower (landslides, wet roads, traffic) and give the model the season or the day’s weather, then test it again on new trips.