Advanced Data Structures

An analyst scores vertices in a directed web-link graph where a page should rank highly when it is linked to by other high-ranking pages, and the algorithm must tolerate dangling pages with no outbound links by redistributing rank through a teleportation factor. Which cuGraph algorithm matches this description?

• APageRank, because it models a random surfer that follows links and teleports with a damping factor, giving high scores to pages linked from other high-scoring pages and handling dangling pages by redistributing their rank.check_circle Correct
• BKatz centrality, because it sums weighted contributions from neighbours and so handles dangling pages through its attenuation factor in the same way.
• CEigenvector centrality, because the principal eigenvector assigns high scores to vertices linked from high-scoring vertices and inherently handles dangling vertices.
• DBetweenness centrality, because it counts shortest paths through each page and thereby ranks pages linked from important pages while absorbing dangling vertices.

Why A is correct: Correct: PageRank's random-surfer model with a damping or teleportation factor rewards pages linked from high-scoring pages and explicitly redistributes the rank of dangling pages, matching every stated requirement.

Why B is wrong: Tempting because Katz also propagates influence from neighbours through an attenuation factor, but it uses a fixed base score and decaying path weights rather than a random-walk teleportation factor, so it does not model dangling-page redistribution the way described.

Why C is wrong: Tempting because eigenvector centrality also rewards being linked from important vertices, but on directed graphs with dangling vertices it can fail to converge or yield degenerate scores, which is the exact problem teleportation was introduced to fix.

Why D is wrong: Tempting because betweenness is a well-known centrality, but it measures how often a vertex lies on shortest paths, not whether high-scoring vertices link to it, and it has no teleportation mechanism for dangling pages.

A social-network analyst needs to identify the accounts that act as bridges between otherwise disconnected communities - accounts whose removal would most fragment the network into isolated clusters. Which centrality measure directly quantifies this bridging role?

• ADegree centrality
• BEigenvector centrality
• CBetweenness centralitycheck_circle Correct
• DPageRank centrality

Why A is wrong: Degree centrality counts a node's direct connections, so highly connected hubs score well. A node can have many neighbours within a single community and score high on degree while providing no bridging function between separate groups.

Why B is wrong: Eigenvector centrality scores a node by the importance of its neighbours rather than their raw count. It rewards connection to influential nodes, not structural bridging, so an isolated bridge node between two small clusters would score poorly.

Why C is correct: Betweenness centrality counts how often a node appears on the shortest path between every other pair of nodes. Nodes that lie on paths crossing community boundaries accumulate high betweenness scores, directly measuring the bridging role.

Why D is wrong: PageRank models a random-walk process and assigns higher scores to nodes receiving links from already-important nodes. It was designed for directed web-link graphs and does not directly measure the fraction of shortest paths passing through a node.

An analyst loads a follower network into cuGraph where edge direction matters: an edge from src to dst means src follows dst. She builds the graph object from a cuDF edge list and intends to rank accounts by how many other accounts follow them. To get this semantics correct, how should she construct the cuGraph Graph and which degree should she read?

• AConstruct an undirected Graph from the edge list, then read total degree, because cuGraph treats follower relationships symmetrically once the edges are loaded.
• BConstruct a directed Graph and read out-degree, because out-degree summarises how influential a node is and therefore reflects its follower count.
• CConstruct an undirected Graph and read in-degree, because converting to undirected first guarantees the in-degree and out-degree values are populated consistently.
• DConstruct a directed Graph and read in-degree, because with edges oriented src follows dst, an account's in-degree counts the edges pointing at it, which equals its number of followers.check_circle Correct

Why A is wrong: Tempting because undirected graphs are simpler and total degree is a single number, but an undirected build discards direction, so 'follows' and 'is followed by' collapse together and the follower-count semantics are lost.

Why B is wrong: Tempting because out-degree is a real directed measure, but with edges oriented src follows dst, out-degree counts who a node follows, not who follows it, so it answers the wrong question.

Why C is wrong: Tempting because it pairs an in-degree read with a definite-sounding rule, but undirected graphs do not distinguish in-degree from out-degree, so the construction choice contradicts the measure requested and the follower count is not recovered.

Why D is correct: Correct: a directed cuGraph Graph preserves edge orientation, and in-degree counts incoming edges, which under the src-follows-dst convention is exactly the number of followers an account has.

An engineer has a cuDF DataFrame of per-store daily sales sorted by store_id and sale_date, and wants a trailing 7-day moving average of daily_sales for each store that never blends one store's readings into another store's window. Which approach produces the correct per-store rolling feature on the GPU?

• AApply a 7-period rolling mean directly to the daily_sales column of the whole sorted DataFrame without grouping, since the prior sort keeps each store's rows contiguous.
• BResample the data to a 7-day frequency and take the mean of each bucket, which yields the trailing average for every store at once.
• CSort the data by sale_date alone and apply a 7-period rolling mean, relying on the date order to keep each store's window separate.
• DGroup the DataFrame by store_id and apply a 7-period rolling mean to daily_sales within each group, so every window is bounded inside a single store's rows.check_circle Correct

Why A is wrong: Contiguous sorting is tempting because each store's rows sit together, but an ungrouped rolling window still spans the boundary between adjacent stores, contaminating the first six windows of every store after the first.

Why B is wrong: Resampling looks relevant because it aggregates over time, but it produces one non-overlapping value per 7-day block rather than a trailing window that advances one day at a time, and it does not isolate stores.

Why C is wrong: Sorting by date alone interleaves rows from different stores on the same day, so a rolling window mixes multiple stores together, which is the exact contamination the engineer wants to avoid.

Why D is correct: Grouping by store_id first restricts every rolling window to one store's rows, so the 7-period trailing mean is computed independently per store and no values cross store boundaries.

A data scientist is engineering features from a cuDF DataFrame whose 'pickup_time' column is already a datetime dtype. They want a new integer column giving the hour of day from 0 to 23 for each ride so a model can learn demand patterns across the day. Which expression produces that column efficiently on the GPU?

• Adf['pickup_time'].dt.hour, using the datetime accessor to return the clock hour of each timestamp as an integer Series.check_circle Correct
• Bdf['pickup_time'].astype('int64') % 24, treating the underlying integer timestamp as the hour by taking its remainder modulo 24.
• Cdf['pickup_time'].apply(lambda t: t.hour), iterating a Python function over each timestamp to read its hour attribute.
• Ddf['pickup_time'].str.slice(11, 13).astype('int'), extracting the hour characters from the string form of each timestamp.

Why A is correct: The dt accessor exposes calendar and clock components of a datetime column, and dt.hour returns the hour of day as a vectorised integer Series computed directly on the GPU, which is the intended way to derive this feature.

Why B is wrong: A datetime is stored as an integer internally, which makes a modulo trick seem clever, but that integer counts nanoseconds since the epoch, so taking it modulo 24 yields a meaningless residue rather than the clock hour.

Why C is wrong: Reading a timestamp's hour attribute is conceptually correct, which is tempting, but a row-wise Python lambda forces element-by-element execution that bypasses the vectorised GPU path and is far slower than the dedicated accessor.

Why D is wrong: Slicing characters would extract the hour digits from an ISO string, which sounds workable, but the string accessor does not apply to a datetime dtype, so this raises an error unless the column is first converted back to text.