The Final Entry... or is it?

So now that the term has finally come to a close, I guess this post will be about on my thoughts for the course. I initially took csc148 as redemption. I wanted to redeem myself for my performance in csc108. I didn't do bad in 108, but I found the material too easy so I slacked off and it really showed on those assignment marks. But anyways I guess I am satisfied with this course, it got me back into programming and taught me some neat tricks.

The highlight of the course was definitely recursion. Refer to my earlier post in October for a more detailed explanation on recursion. It saves a lot of space and makes the code visually look nicer. I like to program mini-games once in a while, hopefully I can implement this along with all the other stuff I learned this semester to do some things I didn't know how to do before.

In terms of the actually term work, I thought it was pretty fair. More difficult than 108 for sure but still not too hard. The work load was alright. I wasn't happy about having exercises every week but since there was only six of them it ended up being good. I'm not sure yet how csc207 runs but I definitely look forward to that.

Looking back, way back

So as this course is coming to an end, I decided to look back at some of the code I wrote when I was 11-12 years old. It's part of a mario fan game I made in the program Gamer Maker 5. After looking through it, it is extremely unorganized, and the only thing I knew how to use was 'if' statements. I remember I didn't even know what a string was.

A lot of the code was repetitive, because I didn't know of any tricks such as inheritance or recursion to save lines. I definitely could of used inheritance, since there is a build in option for that when making objects ( a little check box indicating if it has a parent or not). At the time though I didn't know what this did and I never bothered experimenting with it.

I would post something examples, but the code is too long and it's a different style than python, although it is very similar, I won't because anyone reading this probably won't understand what it's supposed to do, and posting very simple line (like setting the horizontal speed when holding down the right key) seems pointless.

I guess the point of this post is just me going over the old times when I tried to teach myself coding around grade 5 and 6, and how this course would definitely allow me to do certain things a lot more efficiently. Maybe over the winter break I'll try to make another game using some of the tricks I learned this semester.

Week 11: Almost the end...

Now that there's pretty much no more work besides writing these slogs, it feels good to have more free time to focus on studying and doing work for other courses. Before when we had exercises
almost every week, even though they weren't hard, it was bothersome to work on them when I had problem sets due every Friday for thermal physics and sometimes for astronomy. I must say though that I miss doing coding homework and look forward to future computer sciences courses.

Anyways, this week we went over quite a few things. Just to name a few: read-only things, properties, equivalent objects, bundling up an iterable, and reducible functions. The highlight of it for me was the part on customizing an equivalency function. I used to mess up on copying something and making two things equal, and even though this section was irrelevant, the memory made me want to play around with some equivalency functions. The example we did in class was checking if two reg ex trees were equal. Since there's no more coding work, it's nice to take a break from directly working with trees and learn some useful tools to make coding easier in the future.

Week 10: 2nd Midterm Test

So today was the 2nd midterm test, which went a lot better than expected. I was hoping big Oh was on going to be on it, since that's what I was looking over the most, but I guess it will be on the final instead. Luckily I had memorized and written down a function on my aid sheet that counted stuff as you traversed a tree:

def counts(n: BTNode, m: int) -> int:
    count = 0
    if n.right: count += counts(n.right, m)
    if n.left: count += counts(n.left, m)
    if n.data < m: count += 1
    return 0 if n is None else count

*This exact code was not for the binary search trees in lab 7, it was a test for more general trees.

I could change the line ' if n.data < m: count += 1' to a different statement depending on what I wanted to count, such as interior nodes, leaves, and even numbers so this made Q1 and Q2 fast and easy.

Anyways, hope everyone did well!

Week 9: Sorting

I'll use this post to talk about the sorting algorithms we talked about this week. Three of them are selection sort, quick sort, and merge sort.

Selection sort divides a list into two parts: the sorted and the unsorted. Initially, the sorted part is empty, while everything else is the unsorted part. The algorithm then goes through the unsorted part, and takes out the first item you want to find depending on how you want to sort. So if you want to sort in ascending order, it will look for the smallest item, then add it to the sorted part, then look for the smallest item again in the unsorted part until you have finished.

Quick sort starts by taking a pivot. So you pick an item, make that the pivot, decide where the pivot goes with respect to the rest of the list, then recursively do the same on the two sub-lists.

Merge sort takes two lists, and merges them while sorting them. It looks at the first item in each of the lists, then compares which one is smaller, and if there is anything smaller in the rest of the lists, then adds the smaller element to the new sorted list.

My favorite is merge sort because the algorithm looks cool, and visually it looks really cool too, and it out of the other three, if you do it manually it feels like the most challenging puzzle. You can also change the code so it doesn't have to be in ascending, and when playing around with how you merge them, it's fun and interesting to see the different results.

Here is a picture off of wikipedia showing merge sort being done:

Week 8: Big Oh

We finally talked about Big Oh, which has to do with run time analysis. We want to look at the worst case time scenario. For example, a really easy one would be just finding a character c in a list of length n. When iterating through the list, the worst possible scenario is that c is at the very end of the list (assuming it is in the list). Therefore, the worst case time complexity in big oh notation would be O(n).

The topic was on the past midterm given around the first midterm, but we didn't cover it at that time. So now I able to look back at that given test and attempt question number two. After discussing with my friend, it's pretty easy once you go over some examples and notice some patterns in the iterations.

Update: Since the topic was not on term test 2, it is safe to say that it will be on the final. I spent a lot of time analyzing different cases of iteration, so I was hoping it would be on this term test, but at least I'll be ready for it if it does appear on the final.

Week 7: Linked Lists and Nodes

This week we talked about linked lists and nodes.

Link lists are made up of nodes, where each node points to the next one. This makes link lists recursive in nature.

Each node will have a value, and is an object of the node class defined as:

class Node:
    def __init__(self, value=None, next=None):
        self.value = value
        self.next  = next

    def __str__(self):
        return str(self.value)

Each node has a value and a following node. If the node is at the end of the link list, its following node is None.

We define __str__ to return the string representation of the node's value. We do this so we can visually see and test the nodes.
By setting the 'next' variable of the node to another node, we then make them linked.

An example would be:

node2 = Node(2)
node1 = Node(1, node2)

or we can do:

node1 = Node(1)
node2 = Node(2)
node1.next = node2