Sorting Matters.

    Sorting seems to be a favourite I've seen when demonstrating the differences in the run-times of algorithms, my guess is because there are so many different ways that you can do it, and what's more so many different behaviours that each algorithm can have. We saw the most evident of these differences on the larger scale tests in the penultimate lab, but it's always entertaining for me to see the drastically different results that the means with which one handles data can have on the data management efficiency. 

    It happens to be of particular interest to me in Cognitive Science because it can show that the particular way that you take in and manage information, has a significant effect of how quickly you can use it, and in what contexts. With things such as working memory that are so tied to problem-solving abilities and general intelligence, information-handling efficiency is particularly important because of how limited working memory is both in capacity and in the amount of time information can be held in it. Showing a distinct difference in sorting algorithm run-times suggests that even in our own working memory, the way that we encode and manipulate information in our own brains might be a factor in how well we are able to solve problems and efficiently carry out tasks. It's really a fascinating thing.

Home Stretch

The funny part is that I'm looking at the course calendar and I'm seeing only three lectures left, but I don't quite believe it.
Really.
It seems pretty much like the usual "OMG THE SEMESTER WENT BY SO FAST WHAT?" but it's accompanied by this weird feeling of "I swear I learned something...I'm not quite sure what...but SOMETHING."

The issue I'm having now is of course, the only issue left, the exam. I compare the first mid term and the second midterm in terms of difficulty, but the apparent range of difficulty between the two tests was such that I can't ballpark where the exam is gonna be. I could average the difficulties of the two and guess it will be somewhere in the middle...or I can take the safe, common sense way of thinking and figure that it will just be more difficult than the first.

After this I can just worry about dealing with CSC165...Dammit.
I should start a sister blog for that titled "I Don't Know How to Math"
I really don't.
It's been 3 years since I've taken a MAT course.

What have I gotten myself into...

Naked and Proud?

    In lecture, Danny brought up that because of Python's apparent lack of aliasing or restrictions to instance variable names and all the like, it was said that moving over to Python from another coding language was a bit like walking into a nudist colony...

   From the perspective of somebody who knows next to nothing about programming, and has only programmed in Python this entire time, hearing this would be a bit more akin to being born and raised in a nudist colony, and then suddenly hearing that people elsewhere wore clothes...

What? People wear pants? And this is normal? Weird.

Testing, testing, 1 2 3.

The second test really just sneaks up on you doesn't it? I had an hour of relief once I had finished the assignment before I looked at the calendar and saw the second test first thing after the November break.
My angst arises from not knowing how to tell if I'm ready for the test. No really, I thought I had all the concepts down pat before, but I was wiped out by the test. I blanked out, all-gone, I forgot how to interpret a tuple. It was bad.

This time I have no idea how I'll do. The concepts about the performance of algorithms didn't quite sink in. I understand the reasoning behind the performance differences, but only on a very elementary level. I don't think I could even fathom any test-calibre questions on the subject. It doesn't help that I have a minimal recollection of how logarithms work. Other than that I don't even know what we're going to be tested on...how does one prepare for this??? How do I improve when I'm not so certain what it is that I really need study up on...

:|

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.