Linked Lists

I am gratified (and a bit alarmed, in case it's a false impression) to find we are on a topic which I feel is intuitively easier to understand.  Linked lists seem bizarre when you think of them, in some ways, but pictorially they are very easy to understand.  I think the fact that there are real-world analogies that can describe this structure-- my favourite being a train with all the cars, with the caboose as the last element in the list--makes this an easier data structure to wrap your head around.  (cprogramto.com does a great job with examples)

Courtesy of shourtline.com, a 3-element linked list.  Caboose.nxt = None!

I guess it also helps that there are not too many operations you can do with a linked list, besides 'visiting' or altering nodes, walking along a list, adding/inserting nodes in various spots, or deleting nodes.  Of course the linked lists could be more complicated (I had inquired about double-linked lists in class and found out that they exist too) and could have more attributes, but there aren't too many things to remember to get started with them, which is great.

Linked lists remind me of relational databases, although that may not be a perfect comparison, but I guess some of the same principles seem to apply in terms of organizing data in separate modules and having them point/relate to each other, rather than in one giant supertable/superlist, etc.  Maybe the similarities (or differences) will become more apparent the more I learn.

Recursion, my bugaboo

I was sorely tempted to write about ADTs and compare them to people in my life (Trees: the people who go into a discussion with you armed with their version of everything you could possibly say and everything they could possibly say in response and everything you could then reply with and [...] in order to show you up; Stacks: that dude from my spin class who arrives 20min late and leaves 15min early, typifying "Last-In, First-Out" ...) but I think I owe it to myself to write about the toughest subject for me: recursion.

I have alluded jokingly to how confusing I find it, but sadly, this ain't no joke. I struggled endlessly with the MiniMax algorithm in Assignment 2, and I had no idea why I was struggling. I felt like I had the concept down, and more importantly, like I had used the type contracts of the various methods to figure out which method I needed to apply when.  (It was kind of a cool little puzzle; realizing "OK, this one yields an instance of State class, this one yields a list but needs a State as its argument... this one yields an instance of Move class...")  But somehow I was stumbling and kept getting errors, and actually struggled with the algorithm right up until it was due.  I had a hard time figuring out how to store and maximize (or minimize) the results of each recursive state without losing a reference to those results at the next iteration. My housemates must have thought I was solving P vs NP with all the scribbles and diagrams and alternate states I had drawn over our communal chalkboard in the kitchen, but sadly, the problem was incredibly elementary and my scribblings belied my actual lack of genius, rather than the presence of it.

J Musset, Droste, c. 1904. This is an early instance of recursion,

appearing in a cocoa ad in the early 1900s. The figure-of-a-figure

recursive image style is often called the Droste effect. 

As far as I can tell, the best clue to how to solve recursion problems if you are stuck is indeed to look at the type contracts.  Step away from the computer and on paper, or on a drawing surface or something, build a 'map' for yourself: what you want to use as input, what can happen to it, and then what it can spit out (in a few cases).  For example: if you know your output must be a list, or the sum (or max) element of a list, somewhere along the way you will probably be choosing between appending an element or item that you receive, and performing another recursive loop to find that element.  Sometimes it's even helpful to stop stressing about your function/method as being recursive, and just imagine you were writing the whole thing. It will immediately become obvious that you are wanting to repeat yourself and certain steps in the pseudocode. That gives a good clue as to where the recursion comes in. 

Another stumbling block lies in improper tracing of recursive function calls, which is why it is so important to practice tracing function calls, as we did for weeks leading up to the recursion exercises.  I was grateful for these exercises, because it can be daunting to try to figure out what the computer is doing 'behind the scenes,' and because I think it makes you a better programmer to have to write some things out manually and get a sense of them.  Often, when you're struggling with a recursive function/method (or really, with any function/method), it's because you don't actually understand what it is doing, and it is generally doing something that you don't expect.  A poor man's version of tracing (a.k.a my version) involved lots of breakpoints and lots of print() statements. However, prof. Heap introduced me to the world of assert: statements, which has drastically improved my debugging skills and also looks way less awkward.  (in particular, printing repr() of an object all the time is not an ideal debugging technique.)

These techniques were particularly useful for me in getting to know the starter code that was provided for us, which is great since reading other people's code (as I mentioned in a previous post) is not something I considered my strength.  Again, it was super fun, kind of like a puzzle, and very easy to follow after a certain point. I have tried to do the same with snippets on stackexchange etc., but I find them pretty tough to follow. So it was a bit of a boost to find out that I am, in fact, capable of it, I just need to practice. (It's amazing how easy it is to forget that.)

And another thing!

Shoutout: I effin' love Big Nerd Ranch. We had this assigned reading on debugging and logs, it was so helpful and well-written.  The course notes for this class are immensely helpful and awesome. That's all.

CS counting: 1 thumb up! Binary counting: 10 thumbs, way up!

Character Flaws

I have been thinking of some of my weaknesses when it comes to this course, and I am almost afraid to mention them in case the Powers That Be (that is, that be ...able to identify me on Markus) encourage me to switch it up for the second half of the semester, which I honestly don't want to do. My biggest issue that I believe is counter to the approach of this class is that I prefer to work alone for almost everything. Labs, assignments, whatever.

I tried doing the first lab with a partner, and found it frustrating--we ran out of time, I had a very clear idea of how to accomplish the lab tasks, but it was different than my partner's, and we weren't able to communicate our ideas to each other. So we both wanted to 'compromise' and not be bossy, but we ended up with a non-functioning committee-designed, time-crunched piece of code, and where I (thought) I could see how we could fix it and make it work, we just couldn't really understand each other enough in the time constraints to make it happen.  I was also navigating, not driving, so perhaps my suggestions amounted to a lot of backseat driving. 

Anyway, I am a friendly, open-minded person, but I am sure I can be fussy and I usually want to do things my own way.  I am also marks-oriented, and probably part of this fussiness is the desire to do well on projects and make sure everything is good. I loved working on assignment 2 alone because I could get a sense of the whole picture and do exactly that.  This is a total weakness, because in the 'real world,' I know projects are done in groups and it is impossible and undesirable to accomplish everything on your own. 

This also brings me to my second weakness, which is that I'm not the best at understanding other people's code.  I document the sh*t out of my code, perhaps to an annoying extent, because when I look at other people's code, I have such a hard time seeing intuitively what it does, and it makes me impatient.  To me, these conjoined weaknesses are very negative and are things that I have to overcome if I am to progress farther in this field (which I now actually really want to do).  But I am still a stubborn-ass gal (yep, gal--further identifying myself here) and I find it hard to do in this course, especially given my work schedule, unpredictable hours, and general dislike of spending time on campus.

My solution for self-improvement is to challenge myself to read through as much code as possible of other people's (thank God Python is part of an open-source/collaborative CS spirit) and understand, modify, and play around with it until other people's work is not so foreign to me.  I don't know if I will become patient enough to do this right away within the confines of this course, but who knows. At minimum I wanted to mention that I am not going to stay all curmudgeon-y, I recognize that this is a weakness and I plan to address it.

OOP

My understanding of object-oriented programming may be limited in that I have very little basis on which to make a comparison. I have a limited understanding of relational databases from a bit of experience with ArcGIS and some faithful listening to an online SQL tutorial lecture series. But I don't have a working knowledge of any non-object-oriented programming languages, and I can't exactly conceive clearly how they would work. (I know you can use object-oriented languages in a procedural manner, but...holy geez, that still serves to confuse things).

So anyway, my understanding of OOPs is constrained by my relative lack of comparison, but so far, I am intrigued by all the different abstract data types that we are learning.  I like Trees. I don't totally understand how to navigate within them, but I like them! I have been playing around with other python modules that use trees, such as NLTK, but more on that later. I even like Stacks (although at this point my understanding of them is just 'list that has been implemented funny,' which is probably grossly inaccurate). I have made efforts to learn more about Stacks, but even the Python documentation conjures up images of somewhat Sphynxlike lists that will only give you a little bit of information at a time.

Ask for more than LIFO and I will bite your bloody head off.

So yeah, Trees. I feel like the concept of recursion has clarified a bit for me, although boy did I struggle in the last tutorial.  Was slammed with work that week, didn't do more than read over the tutorial handout ahead of time, arrived and struggled with the first question for almost the whole time. It was brutal. I understood what to do, but couldn't make my code pass all the tests.  Spent the whole entire class struggling with it. Poor Rajeet tried his best to help me, but he may need some ice for that bruise after spending so much time banging his head against a wall. (Note: There was no actual violence or self-injury. This is humour. Nobody was physically harmed in tutorial, although it may have been touch-and-go at times cause I can be pretty dense.) Thanks also to mystery female classmate (don't know her name) who was kind enough to look at my code and ultimately point me in the right direction.
  
Anyway, take-home point is that it is a terrible idea to go to tutorial without having at least a bit of the handout worked through. Such a mistake. Don't do it. Hopefully next (next) week will be better, although I have been crazy busy and only get home at 8:30pm Tues and Thurs, (and the odd time, I have work Friday mornings before tutorial!) so my preparation is not always adequate.  At least I have reading week to do more on the labs and on Assignment 2, which I can already see will require a bit of brain-stretching to understand.

Delinquent

I have not been SLOGging as much as perhaps I ought, due in part to the assignments that I have been working on (for CSC148 and 165, respectively). I went at Assignment 1 like a crazy person the day it was announced, and I was sure I was getting a jump on things.  Still ended up submitting it the day it was due, although that is because I rewrote the whole program twice, fueled by an obsessive Martha Stewart-esque desire to have an impeccably organized inheritance system (if you imagine classes as roasted cherry-tomato Triscuit cups, this analogy holds up a little better).

I am incredibly proud of the assignment, especially since I was not sure if I was going to sink or swim in this course. But I guess I shouldn't rejoice until I get my grade back.  It's possible that I overthought and overcomplicated things...in a quest to make my code 'generic,' I did have to create quite a number of methods in a couple classes, and I hope they were not redundant.

Yeah, also: recursion has been blowing my mind.  I have even been having list comprehension dreams, which helps a lot conceptually but still leaves me feeling sort of weird in the morning.  It's like in Inception when Leonardo DiCaprio asks Ellen Page to remember how she got to that cafe, and she's all confident at first, like "Oh, we just walked from the...." "We just...."  Recursion seems to make perfect sense to my dream-self, and then I try to nail down the specifics and the certainty just slips away.  

This dream within a dream sh*t is trippy, Bleeker.

Anyway, I am sure it will crystallize before the test on Wednesday, especially if I trace some more horrible lists made by sadistic people.  If my boyfriend made me a shopping list zipped to a nested tuple of ingredients like ('eggs,' 'milk', 'bread', 'veggies ('spinach', 'carrots', 'lettuce'('1 head romaine', '175oz arugula')), [1, 2, 1, 5[1, 4, 1, [1, 1]] ], and I had to count my total items to see whether I could use the express lane or had to line up behind that old person who buys 374 cans of tuna in preparation for the Snowpocalypse, I would raise the biggest motherlovin' exception he has ever seen.

First few weeks of SLOG

SLOG has been interesting for me, mostly because I approached it with a little bit of irritation (full disclosure here).  I think that overall, it is a beneficial exercise, and I think that the integration of communication and personal reflection into STEM courses (and STEM life in general) can only be a good thing.  However, I've been up to my ears in coursework and 2 jobs, and I definitely suppressed a sigh when I realized that there would be this additional piece of the course, as well as the assignments, tests, and labs (the labs I find I spend a lot of time preparing for, only to run out of time despite my efforts and their 2-hour duration!)

Anyway, that was then, this is now.  I have actually been enjoying the blogging. Of course, in order to do that, I have had to be fairly casual, and perhaps even irreverent. But I tell myself that a) the TAs can probably appreciate a bit of levity as they slog through the SLOGs, and b) I may be making jokes and posting pictures of hamburger phones, but I actually take the reflection and the topics seriously; I want to be honest, do a good job, and mean what I write.

The nice thing about academic structure is that, when well designed, it forces you (for grades) to do things that are honestly beneficial to you, like reflective writing. If someone told me to keep a journal, I could maybe stick to it for like...a week.  Or two if I was good.  But the mandatory (well, grade-rewarded, to the extent that that is mandatory) nature of SLOG means that writing and reflective time, which are on the whole healthy and self-bettering pursuits, are built into the daily grind.  I'd say this is a win-win.

Way to change my mind, CSC! And thanks for listening to my honesty. It's not the rosy, butt-kissing version, but it's the truth and that counts for something.

<3