JavaScript: Basic, 121–150

Kobo integers throughout, for the reason exercise 63 argues: ₦3,780 held as 3780.00 makes left / note a float division and the remainder a number like 0.00000000004, which is neither zero nor payable. In integer kobo the remainder is exact, so unpaid is trustworthy — and reporting it is the point, because 50 kobo cannot be handed over when the smallest note is ₦5. Dropping it silently is how a till goes out by a few kobo a day.

The last two assertions are the honest caveat. Taking the biggest note first is optimal for the naira ladder, and for any system where each denomination divides the next, but it is not optimal in general: with notes of 400, 300 and 100, greedy pays 600 as 400+100+100 while two 300s would do. Genuinely minimal change is a dynamic-programming problem. Greedy is the right code here because the denominations are known and well behaved — a fact worth writing in a comment, since the day someone adds a ₦300 note the algorithm silently becomes wrong.

The fourth assertion is the lesson, and it is uncomfortable: correcthorsebattery scores 3 while Lagos123! scores 5, and the nineteen-character phrase is enormously harder to guess. Composition rules measure whether you followed the rules, not how hard the password is to find — and they push people towards Password1!, which every cracking dictionary already holds. Current NIST guidance is to require length, allow everything including spaces, screen against known-breached lists, and stop mandating character classes.

So treat a meter like this as a hint in the interface, never as the gate. Two implementation notes. The checks are returned as named booleans rather than folded into a number, because "must contain an uppercase letter" is only actionable if the form can say which rule failed. And [^A-Za-z0-9] counts anything else as a symbol, which correctly includes the space — silently stripping or rejecting spaces breaks passphrases and password managers, and the user finds out at the login screen, not here.

if (mark && ...) is the entire difficulty. Three empty cells satisfy board[a] === board[b] === board[c], so the check without it returns '' for an empty board — falsy, so if (naive(board)) happens to behave, which is worse than failing: the function returns a winner of '' and the bug survives until someone renders it or compares it to null. Ask whether the cell is occupied before asking whether the line matches.

The other ordering that matters is win before draw. A full board can contain a winning line, so checking "every cell filled" first would report a draw for a won game — the wonAndFull assertion is there to keep that fixed. Three distinct outcomes need three distinct values, so this returns a mark, 'draw', or null for still playing; folding "no winner yet" and "drawn" into one falsy answer is how a game announces a draw on move two. Listing the eight lines as data rather than writing eight ifs is what keeps the function four lines long and makes it trivially extensible to a 4×4 board.

Two lines carry the weight. Math.ceil for the page count, because 97 items at 10 a page is 10 pages and Math.round or integer division gives 9 and hides the last seven tickets — a data-loss bug that only appears when the total is not a multiple of the page size. And Math.min(start + perPage, total) for the end, so the final page reports 7 rather than 10; slice would have clamped it anyway, but the number is also shown to the user as "91 to 100 of 97".

The window is the part worth studying. Centring naively — current - 2 to current + 2 — gives three numbers on page 9 and two on page 10, so the control changes width as you approach the end and the layout jumps. Computing to first, then pulling from back to to - window + 1, keeps the width constant until there genuinely are not that many pages, which the last assertion checks. Clamping current matters because the page number arrives from a URL a user can edit: unclamped, ?page=99 gives a negative-free but empty slice and a paginator with no way back.

Alignment is subtraction, and the trap is that padEnd only ever adds. A name of 22 characters comes back 22 characters long, the quantity column starts six places late, and every row below it in that column is crooked — so the name must be cut to fit and then padded (exercises 37 and 103 are the two halves of that). Cutting to NAME_WIDTH - 1 leaves room for the ellipsis, which is itself one character.

The float assertion is the reason the units are kobo. The same three amounts added as naira decimals come to 5701.599999999999, so a receipt built that way prints ₦5,701.5999999999995 or, once rounded for display, a total that does not equal the sum of the lines shown above it — the complaint arrives from the customer, not the test suite (exercise 61 is the underlying arithmetic; exercise 74 the formatting). Integers throughout, formatted once at the edge.

Two limits worth stating. String(kobo % 100) assumes a non-negative amount, so a refund line needs the sign handling from exercise 74. And fixed-width columns only line up in a monospaced font: the same receipt in a proportional font is ragged no matter how carefully the spaces are counted, which is why the browser version of this is a table or a grid, not padding.

The whole exercise rests on one property of the Date constructor: the day argument is an offset from the first of the month, not a validated day number. Day 0 is therefore the day before the first, which is the last day of the previous month — that is why new Date(year, month + 1, 0) is the idiomatic length-of-month. It also means the engine's leap-year handling is doing the work, including the century rule that catches out hand-written versions: 2100 is divisible by 4 but is not a leap year.

The same permissiveness is the trap. new Date(2026, 1, 31) does not throw and does not return an invalid date; it quietly returns 3 March, because February 2026 runs out after 28 and the extra three days keep counting. A subscription renewal or a due date built that way slips into the next month and nobody notices until a customer is charged early. Decide which you want — clamp with Math.min, or reject the input — but do not let the constructor decide for you.

Two facts do the work. A month index outside 0 to 11 is legal — month 12 means January of the next year, month -1 means December of the last — so adding months needs no year arithmetic at all. And the day must be clamped before the date is built, because Date will happily accept a 31st in a 28-day month and walk forward into March.

The last assertion is the one to sit with: adding a month twice gives 28 March, adding two months at once gives 31 March. Month arithmetic is not associative once clamping is involved, because the clamp throws information away. That is not a bug in this function, it is the shape of the problem — which is why a billing system stores the original anniversary day (31) and clamps at render time, instead of clamping once and then adding to the clamped result month after month, sliding every subsequent date to the 28th.

ISO weeks are defined by Thursdays, and once you know that the algorithm is short: shift the date to the Thursday of its own week, shift 4 January to the Thursday of week 1, and divide the gap by seven days. Everything else is bookkeeping. (getDay() + 6) % 7 is the renumbering from JavaScript's Sunday-first days to ISO's Monday-first, and forgetting it puts every Sunday in the wrong week.

The subtle line is new Date(thursday.getFullYear(), 0, 4). It uses the year of the Thursday, not the year of the input date, and that is deliberate: 1 January 2027 sits in the week whose Thursday is 31 December 2026, so it belongs to week 53 of 2026. Calendar year and ISO year are different things, and any report grouped by "week 1" without also carrying the ISO year will merge two different weeks.

Math.round rather than a plain division is protection against clocks that shift. Local dates a few weeks apart are not always an exact multiple of 24 hours when daylight saving intervenes, so the quotient comes out at 24.958 and truncation loses a week. Nigeria has no DST, but the reader's machine might.

Age is not a division. (now - birth) / 31536000000 is wrong because years are not all the same length, and subtracting the year numbers is wrong because it ignores whether the birthday has happened yet — the third assertion is that bug, and it is the one that puts an under-18 on the wrong side of a form. The correct shape is subtract each part, then borrow, exactly like long subtraction on paper.

Which month to borrow from is the detail people get wrong. new Date(on.getFullYear(), on.getMonth(), 0) is the last day of the month before the measuring date, so measuring in January borrows 31 days from December. Borrowing a flat 30, or borrowing from the birth month instead, shifts the answer by a day or two — small enough to survive review and large enough to matter on the day a tenancy or a loan term ends.

The last assertion has no objectively right answer. Someone born on 29 February 2000 has no birthday in 2026, and this code says they are still 25 on 28 February and turn 26 on 1 March. Different jurisdictions choose differently; the point is to choose deliberately and write it down, rather than discover your choice from a bug report.

Three decisions are worth naming out loud. The range is inclusive of both ends, which is what a human means by "from Monday to Friday" and not what slice or a naive difference gives; state it in the function's name or its documentation, because the off-by-one is invisible otherwise. The weekend is Saturday and Sunday, which is a cultural assumption, not a fact — it needs to be a parameter the moment the calendar covers a country where the week ends elsewhere. And holidays are checked only after the weekend, so a public holiday on a Saturday costs nothing, which is the truth in Nigeria unless the government declares the Monday in lieu.

The loop itself teaches the other half: day.setDate(day.getDate() + 1) steps across month ends and year ends with no special handling, because setDate takes an offset from the first of the month. And it mutates, which is why the function copies the incoming date before touching it — the last assertion is there because a helper that quietly moves its caller's Date is a bug that surfaces three functions away.

The design decision that makes this testable is the second parameter. Every version of this function that calls Date.now() inside can only be checked by eye, and the one case you most want to check — a timestamp slightly in the future — is impossible to stage. Pass the clock in; the caller supplies new Date() at the edge.

Future timestamps are not hypothetical. Browser clocks drift, phones are set by hand, and a record created with the client's time and rendered against the server's time routinely arrives a few seconds ahead. Without the negative branch a fresh comment reads -3 seconds ago or, worse, 1 year ago once the arithmetic goes through Math.abs somewhere careless. Absorbing anything under 45 seconds into "just now" hides most skew for free.

Two things are deliberately imprecise. Math.round, not floor, so 59 minutes reads as an hour rather than "59 minutes"; and a month is 30 days, because nobody reading a feed is counting. Precision here is not accuracy — the label is a rough anchor, and the exact timestamp belongs in a tooltip.

The round-trip is the whole technique. Rather than encoding month lengths and the leap-year rule, build the date and read it back: new Date(2026, 1, 31) comes back as 3 March, the day no longer matches the 31 that went in, so the input is rejected. Twelve month lengths, the four-hundred-year leap rule and every edge case collapse into three comparisons.

Everything else here is about refusing to guess. new Date('15/01/2026') is a non-standard format, so what it does is up to the engine; new Date('03/04/2026') is worse, because every engine reads it happily and reads it as the American month-first order, so the 3rd of April becomes the 4th of March with no error anywhere. A two-digit year is the same problem: 26 might be 2026, 1926, or the literal year 26, and the honest answer is to reject it and let the form ask again.

The last assertion is the one that catches people who did switch to ISO strings. '2026-01-15', date-only, is defined to be parsed as UTC, while '2026-01-15T00:00' is local — so in any timezone behind Greenwich the first one prints as the 14th. If a string carries no timezone, construct the date from its parts and keep the ambiguity out of the code.

1d 1h 1m 1s is precise and unreadable. Cutting to the two largest non-zero units is what makes a duration scannable, and the sixth assertion shows what is being thrown away deliberately. Note that the units dropped are the smallest ones, so the error is always small relative to the number shown — cutting the largest units instead would be a catastrophe.

The zero-unit case is the interesting one. Because parts are collected only when non-zero, 1441 minutes comes out as 1d 1m rather than 1d 0h, which is what a fixed days + 'd ' + hours + 'h' template would print. Whether you want that or a padded 1d 0h 1m is a product decision; the array-then-slice shape makes either one a one-line change.

-0m from full(-0.5) is the loose end. The sign is taken from the input while the digits come from the truncated absolute value, so a duration that rounds away to nothing keeps a minus it has not earned. If durations can arrive fractional, decide at the boundary whether to round or truncate, and do it before the formatter sees the number.

The trick that makes this simple is refusing to think in rows. Build one flat list — blanks, then days, then blanks — and only slice it into weeks at the end. Trying to decide, inside a nested loop, whether cell (row, column) holds a day is where the off-by-one errors live.

(getDay() + 6) % 7 is the Monday-first conversion, and it is worth understanding rather than memorising: it rotates Sunday from 0 to 6 and pulls everything else down one. Nigerian calendars are usually Monday-first, US ones Sunday-first, and the difference is exactly this one expression — the second assertion shows the same date needing a different lead under each convention.

The row count is not fixed. Five is normal, four happens only for a non-leap February beginning on a Monday, and six is needed whenever the lead plus the day count passes 35 — a 31-day month starting Saturday or Sunday. A layout that assumes five rows will clip a week roughly twice a year, which the last two assertions pin down.

The inner loop is the exercise: above[c - 1] + above[c], with a missing neighbour read as 0 so the edges fall out of the same expression instead of needing their own if. Note out[r - 1] || [] for the first row — out[-1] is undefined, and indexing into it would throw, which is the one place this can go wrong.

Row sums being powers of two is not decoration. Row r of the triangle is the binomial coefficients of r choose k, and they sum to 2^r because that counts every subset of r things. So this loop is also a way to compute combinations without factorials, which matters because 21! already exceeds what a JavaScript number can hold exactly while every entry in these rows stays a small integer.

The centring is arithmetic worth reading twice. padStart((width + length) / 2) asks for a string whose length is the midpoint, which adds exactly half the shortfall on the left; padEnd(width) then fills the right so every line is the same length. Without the padEnd the lines look centred and are not the same width, which shows up the moment anything is aligned against them.

The sieve inverts the question. Trial division asks "is this number prime" once per number and redoes the same divisions over and over; the sieve asks "what is definitely not prime" and crosses composites off in one pass. For a range, that is much less work — and the crossings count makes it concrete.

Two bounds are doing the optimising, and both are easy to get wrong. The outer loop runs while p * p <= limit, because any composite up to the limit has a factor at or below its square root, so nothing above that can cross out anything new — for a limit of 100 only 2, 3, 5 and 7 ever run the inner loop. The inner loop starts at p * p rather than 2 * p, because every multiple of p below p² has a smaller prime factor and was already crossed out; starting at 2 * p still gives the right answer, just with more wasted writes. Wasted writes do not disappear either way: 74 composites take 104 crossings here, because a number with several prime factors gets crossed out once per factor.

The cost is memory: an array the size of the limit. That is fine for a hundred thousand and wrong for a trillion, which is the honest trade — trial division is O(1) space and answers about one number, the sieve is O(n) space and answers about a range. Pick by the question you are actually asking.

Two base-16 conversions and one padding rule. parseInt(pair, 16) reads hex into a number, number.toString(16) writes it back, and the padStart(2, '0') is not cosmetic: 11 becomes 'b', and three single-character channels concatenate into a string of the wrong length that no browser will accept.

The eighth assertion is the classic. parseInt('1f') is not an error and not NaN — it reads as far as it understands and returns 1, so a missing radix produces a plausible wrong colour instead of a crash. Always pass the base. Note the two functions are not perfect inverses either: hexToRgb('#0b0') then rgbToHex gives '#00bb00', the same colour spelled the long way, which is why the round-trip assertion uses full-length inputs.

The clamp belongs in the writing direction, not the reading direction. Hex can only express 0 to 255, so a computed channel of 300 or -5 — easy to produce when lightening a colour — has to be brought into range before it is formatted, or (300).toString(16) quietly emits 12c and the string is seven characters long.

One bit per permission is why the values are 1, 2, 4, 8 and not 1, 2, 3, 4. Powers of two never overlap, so READ | WRITE is 3 and can still be taken apart; with 1, 2, 3 the combination of the first two is the third and the information is gone. & ~flag for removal reads oddly at first: ~WRITE is a number with every bit set except that one, so the & keeps everything else and drops it.

The seventh assertion is the one that bites. editor & WRITE is 2, not true, and editor & PUBLISH is 0, not false. Inside an if that works by truthiness and reads fine, but returned from a function, stored in JSON, or compared with === true, it is a number pretending to be a boolean. Hence the explicit !== 0 in has.

The last assertion is the hard ceiling. Every bitwise operator converts its operands to signed 32-bit integers first, so bit 31 lands on the sign bit and bit 32 disappears entirely. Thirty-one flags is the practical limit; past that use BigInt, a Set of names, or several numbers. And be honest about the trade: a packed integer is compact and fast, and it is also unreadable in a database column, so most application code is better off with named booleans unless the packing is a protocol requirement.

Walking from the right is what makes the formula length-independent: a 16-digit Verve number and a 15-digit Amex have their doubled digits in different absolute positions but the same positions counted backwards. And d -= 9 is not a trick — doubling a digit can only reach 18, and for any two-digit result subtracting 9 equals summing its digits.

Luhn catches every single-digit mistake, which the sixth assertion checks exhaustively across all 16 positions and all 9 wrong digits. It also catches most transpositions of neighbours, but not all: the pair 0 and 9 is invisible to it, because doubling 0 contributes 0 either way and doubling 9 gives 18 which folds back to 9. The eighth assertion swaps a 0 and a 9 and the number still passes.

So Luhn is a typo filter, not a validity check. It tells you the digits are internally consistent, which is worth doing in the browser before a payment request goes anywhere. It tells you nothing about whether the card exists, has money on it, or belongs to the person typing — only the issuer knows that. Treat a pass as "worth sending" and never as "accepted".

The base variable is the idea: subtract the code of the case's first letter to get a position 0 to 25, do the arithmetic there, add the base back. That is what keeps upper and lower case separate without two copies of the logic, and it generalises to any contiguous alphabet.

((x % 26) + 26) % 26 looks like superstition until you check the last assertion. JavaScript's % is a remainder, not a mathematician's modulo, so it keeps the sign of the left operand: -1 % 26 is -1, which added to the base of 'a' gives the backtick character. Every wrapping index — clock faces, circular buffers, carousels stepping backwards — needs the same guard.

Nothing here is encryption. A shift cipher has 25 possible keys, so it is broken by trying all of them, and English letter frequencies give it away instantly. It is a puzzle and a good exercise in character arithmetic. Anything that actually needs to be secret goes through crypto.subtle, not through this.

The encoder is two nested walks with one pointer, which is the shape worth learning: the inner loop measures the run, the outer loop jumps past it, so every character is looked at once. The decoder needs the digit loop because a run of 12 is two characters — reading a single character as the count is the bug that makes a12 decode to one a followed by a stray 2.

The last two assertions are the real lesson, and it is about formats rather than loops. This encoding has no way to tell a literal digit in the input from a count, so 'a1' encodes to 'a111' and decodes to 111 copies of a. Nothing throws. The output is a plausible string of the wrong length, which is how corruption spreads. A format that can express any input needs an escape character, or a length prefix, or a restricted alphabet stated up front.

And compression is not free. Run-length encoding doubles the size of text with no repeats, which is most text — it earns its keep on scanned black-and-white images, simple bitmaps and sensor readings that hold steady, not on prose. Measuring before and after, as the sixth assertion does, is the habit.

low = mid + 1 is the whole exercise. The + 1 is what guarantees the range shrinks: once the middle has been compared and rejected it must be excluded, or a range of two elements can produce the same mid for ever. The seventh assertion is that infinite loop, held down by a step cap so this page still finishes — and the eighth shows why the bug survives review, because the same broken function returns correct answers whenever the target happens to be at a midpoint.

Returning low on failure is worth the extra line. When the loop ends, low is the index where the value would keep the array sorted, so the same function powers "insert in order" and "find the nearest" without a second pass. That is what Array.prototype.findIndex cannot give you cheaply.

The last assertion states the precondition that makes any of this legal. Binary search on unsorted data is not slow, it is wrong: it reports -1 for a value sitting in the array, because every comparison it makes assumes an order that is not there. The speed is real — ten comparisons against a thousand — but it is bought entirely with that assumption, and the cost of sorting has to be counted against however many searches you plan to run.

sort with no comparator converts everything to strings and compares them character by character, which is why [10, 9, 100] comes back as [10, 100, 9]. That is not a quirk to work around once; it is the default, and every sort of anything numeric needs a comparator.

The natural comparator is the same idea applied to mixed text: split into digit and non-digit runs, then compare like with like. Returning Number(a) - Number(b) for digit chunks is what puts Hall 2 before Hall 10, and returning -1 or 1 for text chunks avoids the trap of subtracting strings. The fallback left.length - right.length handles one label being a prefix of another.

Two things to know before shipping it. sort mutates the array it is called on and returns that same array, so [...list].sort(...) is the habit unless you meant to reorder the original. And for human names, especially with accents, a.localeCompare(b) is the right tool — it knows that é sorts with e, which no amount of chunking will tell you. This comparator is for labels with numbers, not for a phone book.

Modelling a menu as (screen, key) => nextScreen is the useful idea here. There is no state hidden in variables, so any journey is a fold over the keys pressed — the walk helper is three lines and can replay a whole session. That is what makes a flow like this testable at all, and it is the same shape a reducer takes.

Every branch returns, which is deliberate. switch falls through by default, so a break left out anywhere silently runs the next case's code; returning from each branch makes falling through impossible rather than merely unlikely. Where fallthrough is wanted, as with the three finished screens stacked above one shared return, it is doing real work: three labels, one behaviour, no repetition.

Two details that matter more in production than they look. switch compares with ===, so a key that arrives as a number matches no case '1' — USSD input is always text, and coercing at the boundary is the fix, not case 1: as well. And the default in the outer switch is a real requirement: a session can resume on a screen an older version of the code wrote, and a menu that returns undefined for an unknown screen crashes the next line up.

Math.round is documented as rounding a tie towards positive infinity, not away from zero. For positive money that is the half-up everyone expects; for refunds and reversals it is not, and a column containing both drifts in one direction. The fix is one line — round the magnitude and reattach the sign.

Half-to-even exists because half-up is biased. Over the eight halves above it gains four kobo out of thirty-two, and that bias is systematic: every tie moves the same way, so a million rounded interest credits leave a real hole in the ledger. Sending ties to the nearest even number splits them evenly and the totals come out level, which is why it is the default in most financial standards and in Intl.NumberFormat's more careful cousins. The trade-off is that it surprises people reading a single row.

The last three assertions are the reminders. Math.round(-0.5) is -0, which prints as 0 and compares === 0, so it slides through every check except Object.is — then shows up as -0 in a JSON payload or as -Infinity after a division.

And a rounding rule can only act on a tie that survives being stored. 1.005 * 100 is 100.49999999999999, so both rules round it down and the tie is never considered; 2.675 * 100 lands on exactly 267.5 and rounds up to 268, while (2.675).toFixed(2) — working from the stored value, which is a hair under — says '2.67'. Two defensible routes to the same rounding, two different answers, on a number a person typed as three decimal places. Rounding rules decide what to do with a tie. Only integer kobo decides whether the tie is real.

The second assertion is the whole explanation. Typing 1.005 does not store 1.005; the nearest double is 1.00499999999999989342, which is genuinely below the halfway point, so toFixed is rounding correctly and the input was already wrong. No rounding mode fixes this, because there is nothing to decide — it is not a tie.

Everything else is a separate surprise worth knowing. toFixed returns a string, so total.toFixed(2) + shipping concatenates and you ship '10.001' to the customer. It rounds halves away from zero, unlike Math.round, so the two disagree on every negative half. And past 10²¹ it abandons fixed notation entirely and hands back '1e+21', which no currency field wants.

The toPrecision(12) nudge works by re-reading the scaled number with fewer significant digits than the error hides in, so 100.49999999999999 becomes 100.5 and rounds up. Use it if you inherit float money and cannot change the storage. Understand that it is a patch: it moves the boundary where the problem appears rather than removing it, and the actual fix is the one from exercise 63 — hold money as an integer number of kobo, and format only at the edge.

The order of the two checks is the exercise. Test the last two digits for the 11-13 range before looking at the last digit, because the teens are exceptions to the rule the last digit would otherwise give — the third assertion shows what happens when they are checked the other way round, or not at all.

% 100 is what makes it work at any size: 111 ends in 11 and takes th, while 101 ends in 01 and takes st. A version that special-cases the literal numbers 11, 12 and 13 is correct up to 100 and wrong from 111 onwards, which is exactly the sort of bug that ships because nobody tests page 111.

Math.abs before the modulo matters for a reason worth remembering beyond ordinals: -11 % 100 is -11 in JavaScript, not 89, so a negative would fall past the teen check and come out as -11st. Any range test on a remainder needs to know the sign rule.

Two rules people get wrong. Zero is plural in English — 0 tickets, not 0 ticket — so the test is n === 1 and not n > 1. And it is the magnitude that decides, so -1 is singular; Math.abs costs nothing and covers refunds and countdowns.

many || one + 's' is a deliberate compromise, and the third assertion is honest about it: the default turns bus into buss. Adding s covers most English nouns and fails on sibilants, words ending in y, and every irregular, so the parameter is not optional in practice — it is the escape hatch that keeps the helper usable. If a screen has more than a handful of these, the real answer is a message catalogue with plural forms, because languages like Arabic and Polish have three to six plural categories and no amount of n === 1 will reach them.

The list join has one interesting case: two items take no comma, which a naive items.join(', ').replace(/,([^,]*)$/, ' and$1') also gets right but by accident. Slicing off the last item states the rule directly. Whether a comma belongs before the and is a house style question, not a correctness one — this version omits it, which is the British and Nigerian convention.

The loop is four lines and the interesting part is the shape of the numbers. A chain does not descend steadily: from 7 it climbs to 52 before coming down, and from 27 it reaches 9232 — more than three hundred times its start — after 111 steps. That is why peak is tracked separately. Anything that allocated an array sized by the starting number would be badly wrong.

The cap is not defensive padding, it is intellectual honesty. The Collatz conjecture — that every positive integer reaches 1 — has been checked past 2⁶⁸ and never proved, so a loop written as while (n !== 1) is a loop whose termination nobody can guarantee. And you do not need an unproven conjecture to hit it: start at 0 and the sequence is 0, 0, 0 for ever, which the last assertion shows. Returning a capped flag rather than a wrong number is the difference between "no answer yet" and "the answer is 5".

Two practical notes. 3 * n + 1 grows fast, so a large start can pass Number.MAX_SAFE_INTEGER and the halving stops being exact — BigInt is the fix if you are exploring seriously. And repeated calls like collatz(start).steps > collatz(longest).steps recompute whole chains; that is fine for thirty starts and would need memoising for thirty thousand, since every chain ends up walking the tail of a shorter one.

Everything in this section is here. Integer kobo so the totals close (exercise 63), Math.floor plus a remainder handed to the final row so the parts sum to the whole (exercise 82), the month-end clamp so a loan taken on the 31st does not fall into March (exercise 127), padStart columns so the statement reads (exercise 103), and thousands grouping only at the moment of printing (exercise 74).

The one design decision worth arguing about is where the remainder goes. ₦120,000 does not divide into seven equal kobo amounts — the even share is ₦1,714.285 and seven of those leave five kobo unaccounted for. Giving them to the last instalment keeps every earlier row identical and makes the final balance exactly zero, which is the property that matters: a schedule whose last line reads ₦0.05 outstanding will generate a dunning letter, a late fee, and a phone call. The alternative, spreading the five kobo over the first five rows, is equally correct and harder to explain to the customer.

Interest on the reducing balance, rather than a flat fee, is why the instalments are not equal: the first month charges 2% of ₦120,000 and the last charges 2% of what is nearly nothing. That is simple interest on the outstanding amount, which is not the same as the annuity formula a bank uses to make every payment identical — that needs powers and a proper rounding policy on the final row, and the honest version of it starts exactly here, with integers and a remainder that has somewhere to go.