cs online - ralva

Reading about quick sort and median of three partitioning really reminded me of the fake coin puzzles we solved. And in some sense they are very similar -- efficiency is about dividing and conquering. Breaking something down into smaller pieces. Rather than doing exhaustive comparisons you split a large problem into smaller halves. These smaller steps allow for less cognitive load and a quicker solution overall. Median of three partitioning does the same. We look at the first, middle and last. And working with sub arrays allow us to sort much faster. It seems like a lot of this class, and finding efficiency is about finding a pattern to break something down smaller than as presented. It's an interesting concept I hope to bring elsewhere.

This week in class once of the algorithms we covered was Breadth-First Search (BFS). Unlike other search methods that traverse down a single path until they hit a dead end (like DFS), BFS explores like a more intentionally. It checks every single immediate neighbor first, and only when that layer is done does it move on to the neighbors of those neighbors. This made me think about how connections work on LinkedIn and its massive social graph. Think of LinkedIn as a giant graph, where each person is a "node" and every mutual friendship is an "edge." It starts with you as the root node and scans your immediate circle—your 1st-degree connections. It places all of them into a holding area called a "queue." Then, the algorithm moves to the next layer, pulling from the queue to check the direct connections of your friends these are your 2nd-degree connections. For these type of graphs it feels like BFS is a great way to analyze and search.

We covered a lot this week, but particularly the Tower of Hanoi is pretty interesting (beyond its appearance in the recent Planet of the Apes movie). The puzzle is solved by recursion. Initially solving the puzzle seems impossible, but by solving a smaller sub problem first you find the rest of the solution falls into place quite naturally. I have a lot of experience writing web applications, and it really made me think about nested component trees in a complex DOM Structure. For example let's say we wanted to find a simple piece of text. If you want to search to find that specific word, a regular for loop is not useful because you never know how deep the branches go (DOM can be very very nested). The solution to that is a recursive function. You just write two pieces of logic: "Check this element, and if it has descendants, tell them to run this exact same check." This allows for your logic to quickly drill down the DOM and find the text you're looking for rather tha...