Can't tell if easier...or actually improving.

I feel as though I'm in a bit of an awkward situation for the past couple of exercises. Using Linked Lists and nested lists, we looked at the binary tree structure. The seem more or less equivalent, except that the branches are calls to other objects instead of just a nested list. It would follow that the logic behind interpreting and writing code for them would be the same.

For me, this doesn't seem to be the case. While I only managed to figure out half of e4 (and even that took me a number of days), I breezed through e5 in a small number of hours. The recursive reasoning behind the binary trees in e4 seems to be the same for e5, but this time around it was a lot easier to grasp. Perhaps the reasoning is actually completely different, and I'm equating two incomparable things? Perhaps Linked Lists are simpler than nested lists? Perhaps I'm ACTUALLY getting the hang of this (not likely).

...or maybe it has something to do with the fact that I don't have two midterms on the same day this week...

cheers.

Comprehending comprehensions.

List comprehensions and generator objects seem to me to be one of the niftiest things we're covering for Python. Seriously, you get to consolidate maybe four or five lines of code down into one simple line. On top of that, the line is almost identical to an English sentence! Seriously, isn't that cheating? It feels like cheating.

What I honestly would like to know is exactly how they work, because whenever the IDLE debugger steps through it, I just see the object reference, and the MAGIC happen. Comprehensions are actually kind of a pain when debugging, because I get to slowly watch nothing I can comprehend happen. The comprehensions sometimes seen incomprehensible! I find it's a lot cleaner to write out code the long way first, and then when you get it working, thusly consolidate it into a comprehension afterwards.

Wreckusion.

    Yes, the title's a pun. The goal every year is to hit the ground running and get sufficient momentum going in the beginning of the year so as to be able to coast through the rest of the semester with less stress.

   I messed up. Recursion was one of the more challenging concepts for me to wrap my head around initially, because of course, I don't know what I'm doing. It seemed really counter-intuitive at first, almost fanciful. Why? Because recursion, to me, seemed a lot like,

ME: "So function, when I pass you these arguments, you're gonna do what you do... and then you're gonna            KEEP DOING IT...until you CAN'T DO IT ANYMORE."

FUNCTION: "But what is it that I do..?"

ME: "You know what you do."

And thusly it would work. Through some magic.
I have a better comprehension of how this works now. As I perceive it currently, when making a recursive function, one starts with a base case, which is like a goal for the function to reach. What the function body is thereafter is kind of like what you want the argument to keep doing to itself, as to reach the base case. It's kind of an iffy perception on my part because office hours for the last little while have been centered on the assignment, so I have had few chances lately to ask directly about at least intuitively considering recursion.
Until then I figure I'll just go over the readings, and stare at the code until it makes perfect sense to me.

Cheers.

Apparently I'm incapable writing code without music.

How I Learned to Stop Worrying and Love the Object.

     As far as the concept of Object-Oriented Programming is concerned, I'm in a bit of a pickle relating to a lot of people who have had experience programming in languages other than Python. I had come into this course armed only with what I had learned from CSC 108, in the Winter/Spring semester last year. My knowledge and experience of programming began and ended there, with basic Python, so as far as I knew at the time, OOP was the ONLY way of doing things.
     Object-Oriented Programming deals with the manipulation of, you guessed it, OBJECTS. These objects are very basic data structures, assigned to memory addresses in the system. Different objects are considered to be different instances of classes with their own properties, functional methods, behaviours, and attributes that distinguish themselves from each other such that they can be used and manipulated for whatever intended result. This struck me as a very intuitive way of doing things.
      In Cognitive Science, some of the first things we deal with are the different theories around categorization of concepts. The way that OOP starts from base objects and builds on to them until they have unique methods and attributes is very reminiscent of some classical Greek theories of concepts, in which concepts are based off of a conjunctive list of 'atomic' features that act as building blocks into creating categories of membership based of certain necessary and sufficient essential qualities. This is surprisingly close to defining new classes and the sub classes that are built from them.
    This is useful for computer scientists because in stead of dealing with lists of commands or subroutines, information is being embodied in its own object such that it becomes a lot more similar to the ways which human users are wont to handle and manipulate information and concepts themselves. This not only makes programming a little more intuitive (at least it does for me), but it is very useful in keeping ideas and information very self-contained.

...I think I got a little carried away...
     

WHOOPS.

So apparently we should have been writing these posts since week three...
How irresponsible of me.
In these first two months I'm not quite sure exactly how badly I've managed to sabotage my grade in this course.
None-the-less, I've invested too much time into it to stop it now.

Also, the feeling of getting your code to do exactly what it is supposed to do is far too satisfying.

Cheers.