Grade 9 AI & Computer Science Practice Questions — Set 6

ExplanationFlexbox operates in 1 dimension at a time: you can make a row of items or a column, but not both simultaneously. Grid operates in 2 dimensions: you define rows AND columns (e.g., grid-template-columns: 200px 1fr 200px), then place items in specific cells. This is why the claim is false — because Flexbox cannot natively handle 2D layouts without nesting. For a school website: use Grid for the overall page layout (header spanning full width across 3 columns, sidebar + main content, footer at bottom). Use Flexbox for the navigation links inside the header (e.g., justify-content: space-between distributes 5 nav items evenly). They complement each other — over 97% of professional sites use both, resulting in cleaner and more maintainable CSS.

Explanationlower() converts any string to all-lowercase: "What is AI?" becomes "what is ai?". Comparing the lowered input against a lowercase target handles ALL case variations with one check. Without normalization, "What is AI?" has 2^8 possible case combinations (each of the 8 alphabetic characters — W, h, a, t, i, s, A, I — can independently be upper or lower). The 'in' operator is NOT case-insensitive — 'AI' in 'what is ai?' returns False. Normalization (lowering, stripping whitespace, removing punctuation) is the first step in any text processing pipeline.

ExplanationThe 3.2 MB image dominates: it is 97% of total payload (3.2 MB out of 3.3 MB) and 89% of load time (4.5s out of 5.05s). Techniques: (1) Convert to WebP — a 3.2 MB JPEG typically becomes about 2.1-2.4 MB in WebP, a 25-35% reduction. (2) Resize — a hero image rarely needs to be wider than 1920px; many source images are 4000px+. (3) Use <img srcset="..."> for responsive sizing. (4) Add loading="lazy" for below-fold images. These are Core Web Vitals best practices that Google uses for search ranking.

ExplanationHTTP status codes communicate what happened: 2xx = success (200 OK), 4xx = client error (404 Not Found), 5xx = server error (500 Internal Server Error). A 404 returns because the resource (event 999) does not exist — the client asked for something that is not there. The output is: res.status(404).json({error: 'Event not found'}). A 500 returns because the server encountered an unexpected condition — a bug, crash, or database connection failure. The output is an automatic 500 with stack trace in dev mode. The distinction matters: 404 tells the client to check their request (yields a "not found" message); 500 tells the client to retry later (produces an "internal error" response). In Express.js, proper implementation uses try-catch: try { const event = await db.findById(999); if (!event) return res.status(404).json({error: 'Not found'}); } catch(err) { res.status(500).json({error: 'Server error'}); }.

ExplanationStack-based DFS: push /. Pop / → visit /, then push its children [home, var, etc] onto the stack in left-to-right order (push home, then var, then etc), which puts etc — the rightmost child — on top. Pop etc (leaf). Pop var (leaf). Pop home → visit home, then push its children [user1, user2] in left-to-right order (push user1, then user2), putting user2 on top. Pop user2 (leaf). Pop user1 → visit user1, then push its children [docs, pics] in left-to-right order (push docs, then pics), putting pics on top. Pop pics (leaf). Pop docs (leaf). Resulting order: /, etc, var, home, user2, user1, pics, docs. Because each level's children are pushed left-to-right, the rightmost child always lands on top of the stack, so this stack-based DFS visits children right-to-left at every level — the reverse of the left-to-right order a straightforward recursive DFS would produce. BFS with a queue instead gives level-order: /, home, var, etc, user1, user2, docs, pics. DFS uses O(h) memory (h = height of the tree), while BFS uses O(w) memory (w = maximum width); for deep, narrow trees DFS is the more memory-efficient choice.

ExplanationGET appends form data to the URL as query parameters: /submit?email=user@mail.com. This data appears in browser history, server access logs (100% of web servers log URLs), referer headers, and can be bookmarked. POST sends data in the request body, which is not logged in URLs. For password reset: the email is PII (personally identifiable information). Exposing it in the URL means every proxy server, CDN, and analytics tool that logs URLs would capture it, because URL logging is on by default in 99% of server configurations. POST avoids this since the body is not logged by default. Note: neither GET nor POST is encrypted on its own — HTTPS encrypts both, but the URL path (up to 2048 characters) is still logged at the server level even with HTTPS.

ExplanationIn a directed adjacency matrix, matrix[i][j] = 1 means edge from node i to node j. Count all 1s: row 0 has 1 (A→B), row 1 has 2 (B→C, B→D), row 2 has 1 (C→A), row 3 has 1 (D→C). Total = 5 edges. In-degree of node C (column 2): check matrix[0][2]=0, matrix[1][2]=1 (B→C), matrix[2][2]=0, matrix[3][2]=1 (D→C). This produces the result that in-degree = 2 because exactly 2 edges point to C. Out-degree of node C (row 2): matrix[2][0]=1 (C→A), rest are 0. Out-degree = 1. For undirected graphs, the matrix is symmetric; for directed graphs, it typically is not. Space complexity: O(V^2) = 16 cells for 4 nodes, regardless of edge count.

ExplanationGraph coloring maps directly to scheduling: each color = 1 time slot. If two classes conflict (same teacher/students), they share an edge and MUST get different colors (different time slots). The chromatic number χ(G) is the minimum number of colors needed. χ(G) = 4 means at least 4 time slots are required because there exists a subgraph (like K4, complete graph on 4 nodes) where every pair conflicts. Finding the exact chromatic number is NP-hard, but greedy algorithms give good approximations. Real-world use: IIT/NIT exam scheduling uses graph coloring for 5000+ students across 100+ courses.

ExplanationLinear model: y = mx + b. price = 0.85 * 1000 + 12.5 = 862.5 lakhs. The coefficient 0.85 is the slope — each sqft adds 85,000 rupees. In Mumbai's premium areas (Bandra, Powai, Lower Parel), actual rates range from 30,000-1,50,000/sqft, making 85,000 a plausible mid-range estimate. The intercept 12.5 lakhs captures non-area factors (building age, floor, view). To evaluate model quality: R-squared > 0.7 indicates good fit, residual plots should show no patterns, and predictions should be within 15-20% of actual listings on property portals. Multiple regression adding bedrooms, floor, and age would improve accuracy.

Explanationtypeof null === 'object' is JavaScript's most famous bug — in the original implementation, values were stored as type tag + value. null was stored as a NULL pointer (0x00), and objects also had type tag 0, causing typeof to misidentify null as 'object'. This was never fixed because millions of websites depend on this behavior. typeof undefined === 'undefined' is correct. Loose equality (==) performs type coercion: the spec specifically defines null == undefined as true (they're both "empty" values). Strict equality (===) requires same type AND same value: null (object) !== undefined (undefined), so false. Rule: always use === in JavaScript to avoid coercion surprises.

ExplanationREST (Representational State Transfer) principles: (1) URLs are nouns representing resources (/students, not /getStudents). (2) HTTP methods are verbs: GET=read, POST=create, PUT=update, DELETE=remove. (3) Status codes communicate results: 200 OK (success), 201 Created (new resource + Location header), 204 No Content (successful delete, empty body), 404 Not Found, 422 Unprocessable Entity (validation error). A successful POST returns 201 Created with the new resource in the body and Location: /api/students/43 in the headers. This is the standard convention used by GitHub, Stripe, and Razorpay APIs.

ExplanationThe line `neha_wallet = priya_wallet` does not build a new Wallet — it makes neha_wallet a second name for the exact same object priya_wallet already points to (aliasing). `raj_wallet = Wallet(700)`, by contrast, builds a genuinely separate object with its own balance. When `neha_wallet.balance += 200` runs, it updates the balance stored inside that one shared object, so priya_wallet.balance changes too — both now read ₹700, since priya_wallet and neha_wallet are just two labels on the same data. That makes `priya_wallet.balance == raj_wallet.balance` evaluate to True, because 700 equals 700. The identity check `priya_wallet is neha_wallet` is also True, because `is` checks whether two names point to the identical object in memory, not whether their attribute values match — and here they do point to the same object. The last line is where the trap lies: the Wallet class never defines a custom `__eq__` method, so Python falls back to the default equality inherited from `object`, which — just like `is` — compares object identity rather than attribute values. Since priya_wallet and raj_wallet are two distinct objects (even though their balances now happen to both be ₹700), `priya_wallet == raj_wallet` returns False. The lesson: without an explicit `__eq__`, equal-looking objects are still "not equal" in Python unless they are literally the same object.

ExplanationA biological neuron integrates signals from all its dendrites and only fires an action potential once the combined signal crosses a threshold — the net total is what decides firing, not any single input in isolation. The code models this directly: it multiplies each input by its weight, sums the three products, adds the bias, and checks whether that final total is at least 0. Working through the numbers: 0.6×0.4 = 0.24, (−0.3)×0.7 = −0.21, and 0.5×0.3 = 0.15, so the three weighted terms sum to 0.24 − 0.21 + 0.15 = 0.18. Adding the bias of −0.25 gives 0.18 + (−0.25) = −0.07. Since −0.07 is less than 0, the condition `total >= 0` evaluates to False, so the function returns 0 — the artificial neuron does not fire. The bias is not a minor adjustment layered on top of a decision the weighted sum has already made — it is exactly what tips this neuron from firing to not firing, since the weighted sum alone (0.18) is positive but the bias pulls the total below zero. A negative weight is also not an instruction to drop that input from the calculation; it means the input actively suppresses firing, and its full signed product (−0.21) must be subtracted from the total, not ignored, which is why treating it as absent gives the wrong sum (0.14) and the wrong outcome. And weights are not a separate "intensity" layer that leaves the fire/no-fire decision to the raw, unweighted inputs — the threshold check only ever looks at the final weighted, signed total, so a large unweighted sum like 1.4 has no bearing on the decision at all.

Explanationmain and feature both started from the same commit B, so B is their shared ancestor. After the branch was created, main moved forward on its own with commit E, while feature moved forward independently with C and D. Because main's tip (E) is not an ancestor of feature's tip (D), and D is likewise not an ancestor of E, the two branches have diverged — a fast-forward is only possible when the branch being merged in already contains every commit the current branch has, and here main has E, which feature lacks. So Git instead performs a three-way merge: it compares the changes made since the common ancestor B on both sides and creates a brand-new merge commit with two parents, E and D. That merge commit sits on top of the existing history without altering or duplicating any of the five original commits (A, B, E, C, D), bringing the total commit count in main's history to six.

ExplanationRun Dijkstra's algorithm starting from S, tracking the best-known distance to every node. Initial distances: S = 0, and A, B, C, D = infinity. Visit S (distance 0): relax its edges. A becomes 10, C becomes 3. Visit C (distance 3, the smallest unvisited value): relax C's edges. A improves from 10 to 3 + 4 = 7. B becomes 3 + 8 = 11. D becomes 3 + 2 = 5. Visit D (distance 5, now the smallest unvisited value): D's only outgoing edge goes to B, giving 5 + 9 = 14, which is worse than B's current value of 11, so B stays at 11. Visit A (distance 7, the smallest unvisited value): relax A's edge to B, giving 7 + 2 = 9, which improves B from 11 down to 9. Visit B (distance 9, the smallest unvisited value): B has no outgoing edges to relax, and every node is now finalized. The minimum delay from S to B is 9 ms, along the route S → C → A → B (3 + 4 + 2 = 9). This is exactly why Dijkstra's algorithm keeps every node's distance tentative until that node is actually selected as the current minimum: the direct-looking two-hop routes S → C → B (11 ms) and S → A → B (12 ms) both look cheaper at first glance, but the three-hop route through C and A ends up cheaper once all the relaxations are carried out. Stopping the search as soon as any path to B is found, or trusting the path with the fewest hops, are the two most common mistakes that lead to the wrong answer here.

ExplanationFiltering with `df[df["Amount"] > 500]` uses a strict inequality, so it keeps only rows where Amount exceeds 500 — it drops Delhi's ₹480 row and, just as importantly, also drops the ₹500 row, since 500 is not greater than 500. That leaves four rows: Delhi ₹620, Pune ₹710, Mumbai ₹590, and Delhi ₹900. Only after this filtering does `groupby("City")` split the remaining rows by city and compute a separate mean for each group — Mumbai's group has just ₹590, Pune's has just ₹710, and Delhi's group has ₹620 and ₹900, averaging to (620 + 900) / 2 = ₹760.00. The remaining values come from skipping a step in this two-stage pipeline: averaging all four original Delhi rows ignores that the filter runs before the grouping; including ₹500 confuses the strict ">" with ">="; and averaging all four filtered rows together ignores that groupby splits the data into separate per-city groups before each mean is computed.

Explanation`book()` is defined once in `Vehicle`, but every call it makes through `self` — `self.fare(...)` and `self.surcharge(...)` — is resolved dynamically against the actual object's class, not the class where `book()` happens to live. This is the core idea of polymorphism: the same inherited method body produces different behaviour depending on which subclass instance calls it. For the `Vehicle` instance: `fare(10)` is Vehicle's own, giving `10*10 = 100`; `surcharge(100)` is also Vehicle's own, giving `0`. Booking total = `100 + 0 = 100`. For the `Auto` instance: `Auto` doesn't override `fare`, so Python walks up the MRO to `Vehicle.fare`, giving `100` again. But `surcharge` IS overridden in `Auto`, so `self.surcharge(100)` runs `Auto`'s version: `100 * 0.05 = 5.0`. Booking total = `100 + 5.0 = 105.0`. For the `Cab` instance: `Cab` overrides `fare`, so `self.fare(10)` runs `Cab`'s version: `10*15 = 150`. Then `self.surcharge(150)` runs `Cab`'s `surcharge`, which calls `super().surcharge(150)`. `Cab`'s MRO is `Cab -> Auto -> Vehicle -> object`, so `super()` inside `Cab` resolves to the *next* class in that chain — `Auto`, not `Vehicle`. That gives `150 * 0.05 = 7.5`, and `Cab.surcharge` adds its own flat `+20`, totalling `7.5 + 20 = 27.5`. Booking total = `150 + 27.5 = 177.5`. Grand total: `100 + 105.0 + 177.5 = 382.5`. The distractor of ₹300.0 comes from assuming that because `book()` is written inside `Vehicle`, its internal `self.fare`/`self.surcharge` calls must always run `Vehicle`'s own versions — that would make every vehicle behave identically (`100 + 0 = 100` each), which defeats the entire purpose of overriding methods. The distractor of ₹375.0 comes from assuming `super()` always jumps straight to the topmost ancestor class (`Vehicle`) rather than to the next class in the MRO (`Auto`); that would make `Cab.surcharge = 0 + 20 = 20`, giving a Cab total of `170` instead of `177.5`. The AttributeError distractor comes from assuming a subclass must explicitly redefine every method it wants to use — in reality, `Auto` inherits `fare()` unchanged from `Vehicle` simply by not overriding it, and calling it works exactly as inheritance is meant to.

ExplanationPython's dataclass machinery scans every field's default value while the class body is being built, and it specifically checks whether that default is a mutable object such as a list, dict, or set. The moment it sees `marks: list[int] = []`, it raises `ValueError: mutable default <class 'list'> for field marks is not allowed: use default_factory` — right when the class is defined, before `s1 = Student("Aditi")` or `s2 = Student("Rohan")` ever executes, so no Student object is ever created and no append happens at all. This guard exists precisely to prevent the trap the shared-list option describes: in an ordinary Python function, `def f(marks=[]):` really does create the list once at function-definition time and reuse that same object on every call, silently corrupting data across calls until someone hunts down the bug. `@dataclass` shuts that exact mistake down at the class level by refusing a bare mutable literal as a default, forcing you to write `field(default_factory=list)` instead — which tells it "call list() fresh for every new instance" rather than "reuse this one list forever." Type hints like `list[int]` only document what the field is meant to hold; Python does not enforce them at runtime, so they play no role in triggering or preventing this check, and marks is never quietly replaced by None here.

ExplanationApplying h_t = 0.5h_(t-1) + x_t step by step from h_0 = 0: h_1 = 0.5(0) + 8 = 8, h_2 = 0.5(8) + 4 = 8, h_3 = 0.5(8) + 2 = 6, h_4 = 0.5(6) + 6 = 9. Unfolding the recursion confirms this: h_4 = 0.5³(8) + 0.5²(4) + 0.5¹(2) + 0.5⁰(6) = 1 + 1 + 1 + 6 = 9. The earliest transaction (₹800) is shrunk by a factor of 0.5³ = 0.125 by the time it reaches the final state, while the most recent transaction (₹600) is added at full strength and untouched by any decay. This recency-weighting — not a plain running total (which would ignore the 0.5 decay entirely) and not a flat average (which would treat all four transactions as equally important) — is exactly the behaviour that makes vanilla RNNs good at picking up short-range patterns but prone to "forgetting" distant inputs. This vanishing-influence problem is the core motivation for gated architectures like LSTMs and GRUs when a model needs to remember longer transaction histories.

ExplanationTreat each user's ratings as a vector over (Dangal, KGF): Priya = (3, 4) and Karan = (4, 3). The dot product is (3×4) + (4×3) = 12 + 12 = 24. Each vector's magnitude comes from the Pythagorean theorem — the square root of the sum of squares: √(3²+4²) = √25 = 5 for Priya, and √(4²+3²) = √25 = 5 for Karan. Cosine similarity divides the dot product by the product of the magnitudes: 24 ÷ (5 × 5) = 24/25 = 0.96. A value this close to 1 tells the recommender that Priya's and Karan's tastes point in nearly the same direction, even though neither rated the two movies identically — so a movie Karan loved that Priya hasn't watched yet, such as RRR, becomes a strong recommendation for her. The raw dot product (24) by itself is not a valid similarity score because it isn't normalised: a viewer who rated everything 5 stars would produce a huge dot product with almost anyone simply because their numbers are large, not because their taste actually matches. Dividing by both magnitudes cancels out this scale effect. Computing magnitude by summing the ratings (3+4=7) instead of squaring and taking the square root skips the Pythagorean geometry the formula depends on, and averaging the smaller-to-larger rating ratios per movie is a plausible-sounding shortcut but ignores how the vectors relate to each other as a whole. This normalised, direction-based comparison is exactly why cosine similarity — not raw dot products or per-item ratios — is the standard tool behind collaborative filtering on platforms like Netflix, Spotify, and Flipkart.