CST370 - Week 3 Reflection

Week 3 Learning Recap

        Another week, another dizzying array--or in my case with the homework, vector--of concepts, time-complexity conundrums, and new perspectives on age old programming cornerstones I have only vaguely glanced upon prior to CST370. As the perilous march to the top of the Algorithm mountain persists, I feel both comforted and daunted. On one hand, it is evident that the best cases and best algorithmic solutions to complex problems are a constant moving target that can require varying blends of planning, experimentation, calculation, brute force, and elegance--perhaps even all at once, when necessary. On the other hand, amid the raw mass of strategies and concepts I find myself somewhat awash in a sort of mountainside river that can quickly carry you downstream and force you to retrace your steps back up the range. 

        In an attempt to gain more stable footing on this week's slew of mental hikes, I will once again briefly map out the stops and important points of interest encountered. Brute force string matching and exhaustive search made a compelling case for a correctness-first mentality. Sliding the pattern across a string of text certainly was a friendly start, just my level of computational intellect amid balancing work and trying to absorb the material.  In a similar vein, the knapsack problem is a crystal clear example of raw persistence as a computational strategy.

        During the orientation for Software Design with Dr. C, he made a joke that he conducted a "Breadth First Search" for bad career choices before finding computer science and discovering a path he excelled at. At the time I felt a little intimidated that I didn't fully understand the joke, it gets funnier as time goes on. Depth First Search and BFS both feel quite demystified to me now. DFS deep dives and BFS works it level by level. Divide and Conquer and the accompanying recursive algorithm felt quite succinct, elegant, and scalable. D&C transitioned nicely into the Master Theorem which additionally is quite clear in its rules and application. 

        I am also quite happy that the puzzles persist to exist in the weekly modules. The fake coin puzzle was an admitted failure for me but I have explained it to--and annoyed --enough people that I feel safe admitting that. The finger count also was quite the challenge that I need to practice for the exam, haunting stuff even in its most superficial conceptual state! Week 3 employed some brute force on its own by hammering in that there are many ways to solve problems.

Comments

Post a Comment

Popular posts from this blog

Week 1 - CST363 First Post: Relational Database Reflections

From the orientation, your reading from week 1, and your own experience answer the following questions: Relational database tables and spreadsheets look similar with both having rows and columns.  What are some important differences between the two? At first glance, a relational database and a spreadsheet in an application such as Excel look fairly commensurate to each other in purpose and functionality--they both are comprised of rows and columns that hold data organized by column names and row numbers. The truth is that their visual similarity is where the commensuration ends and the vast differences begin. Relational databases adhere to strict and organized rules that ensure they can manage large volumes of structured data as well as complex queries to return results from that data whereas spreadsheets can be filled out arbitrarily. Foreign keys and primary keys can tie individual values or sets of values to other tables of data which in turn impact how data can be returned or c...
Read more

Week (6/)7/8 Markov End-of-Semester Reflection

           While the Markov assignment seemed daunting upon first viewing the assignment requirements, this revisiting of the task reveals a much simpler project than the caliber of code work that now occupies my mind. Firstly, having dove into the various design patterns that CST338 covers I now am curious to identify design patterns in code prompts. In this case the various methods of the code serve to "build" chains of text collectively into what could be argued to be a Builder pattern. The Builder pattern is categorized as a creational design pattern and thusly suggests how the code will best be formulated. Functionally, this mostly serves to inform the bigger picture as during the process I was heavily focused on following the prompt in more of a "flying blind" styled approach.            In terms of how I would approach this project differently now, I can never stress enough that homing in on each of the respective r...
Read more

Week 4 Project 1 Post-Review

  Journal Prompt Reflections With whom did you work? Ethan G, Keshab N What was your strategy for solving the assignments? I first got all the fields/variables/methods in place until I matched the UML diagram, looked over the entire assignment prompt, and then flew blindly along to each method description. I wrote TODOs for what I couldn’t solve right away and sort of manically switched between each method until the test file could run. From there homed in on each failing test one by one. The first tests I singled out called methods that relied on other methods the least.  Did you start writing code right away? Did you plan it out on paper? I did initially attempt to create a checklist document but it became so overwhelming that I chose to just start working on it and the tasks that still needed to be done were readily apparent anytime I checked the tests or output. TODO’s and getting the UML matching were essentially the planning aspect.   What was THEIR strategy for sol...
Read more