Week 5 SLOG - Recursion

My task for today is to demonstrate a little bit of what I have learned about recursion so far in my programming course. Recursion has been a big topic in the course so far, and I believe it will continue to be, so it's very important that I understand it and can put it into practice.

Recursion is when a function is called within itself. Sometimes when you're using a function to code, the task being performed by the function can be broken up into smaller instances of the same task. By figuring out how to complete these smaller versions of the task, you can use them to complete a bigger version of the task which contains the smaller versions. By 'plugging in' the smaller versions of the task to the bigger version, you are using recursion. Any time that you can break up a problem into smaller, easier versions of the same problem is probably a good time to use recursion. When you are writing recursive code, you need to start with the base case. This is the case which does not involve any recursion, and all following cases will build off of it (the smallest version of the task). It is very important that you have a base case, otherwise your program will probably go into an infinite loop.

I personally feel that recursion is a very useful tool in computer science. The more that we look at it in class, the more I start to understand how integral it is to writing code. It makes coding certain problems much easier and much shorter when you can understand how it is done. It can cut out a lot of repeated code, because you're calling a function within a function, instead of writing out more code in place of the inner call to the function. Although it seems complicated at first (or at least, it did to me), it actually has a very intuitive feel to it once you get going. I've found that there's actually a risk of overthinking a recursion problem; it can be better to keep your code pretty much as simple as the problem itself.

I also think that it's important not to forget the basics though. There are times when a problem could be solved through recursion or through another way, such as a for loop, and just because you can use recursion doesn't mean you should. Recursion can take a lot of steps to complete things, so there are definitely times when a straightforward approach would be much better than a nested approach like recursion. For instance, when trying to find the number of items in a nested list, it would be better to have a variable that keeps track of the number of items as you add to it, rather than use recursion to look at all of the elements of the nested list each time you wanted to know the number of items.

Overall, I find recursion to be very interesting and useful, and I'm looking forward to learning more about it.

Week 4 SLOG - Assignment 1

Since the due date for my first assignment in CSC148 just passed, I thought I would take this SLOG to reflect on the assignment - what I enjoyed, what I found interesting, and what was a challenge.
I really enjoyed working on this project. I almost always enjoy projects in my computer science courses, because they give me such a large sense of accomplishment at the end. Not only have I completed the project, but I have a working program! One that does something, if not useful, then at least entertaining. I love the feeling that I'm actually doing something worthwhile, not just work for work's sake. I really loved that I could see a graphical version of my work at the end as well. It made the code feel very tangible, and it was an amazing feeling to know why what I was seeing on the screen was actually working.

My favourite part of the assignment was coding the recursive function tour_of_four_stools. I found it very interesting to see recursive code in action, especially recursive code that I had written. I liked being able to apply the recursive three-stool function we had learned in class to a new function. It really solidified for me how the recursion was working. This assignment made me feel much more confident in recursion. Although I was beginning to grasp what it was before, I really think I'm starting to understand WHY it works much more now.

One of the most challenging parts of the assignment for me was the coordination between the different parts of the code. Getting one code file working would cause another to stop working and vise-versa. The same thing happened within files as well - just when one function started working, another would stop. Often it wouldn't even be the functions I were tweaking that caused these problems, but some third function that was also related to both of them! I had trouble figuring this out a couple of times. Debugging this program could be really frustrating at some points, but figuring out problems in my code was also really satisfying once I found them.

Now that assignment 1 is finished, it's time to start studying for the midterm! Hooray!

Week 3 SLOG - Scope

I found the section on scope in this week's lectures very interesting. After going to the lecture on scope, I realized that quite often the bugs I find in my code are to do with scope, which I didn't realize before. I can be sloppy with variable names, so I find myself reusing a variable name several times throughout my code to reference several different things in several different scopes. This tends to return unexpected results a lot of the time, but I've gotten away with it by just tweaking a couple of names here and there until it works. Now that I understand scope, I realize that I really need to be more careful with my variable names; it will help me escape a lot of avoidable problems.

In the lecture, we looked at some code that played around with scope - names.py. During the lecture, I found it slightly confusing - and it was supposed to be, so that was okay! When I got home, I took a look at the code again. At first, I didn't understand why when asked to print spam, the code printed nonlocal spam after both the nonlocal spam assignment and the global spam assignment. Now I understand that it's because Python looks to the nonlocal scope before it looks to the global scope. So even after a global spam is assigned, Python still looks to the nonlocal scope first, and returns the value of spam from there before it ever even gets to the global value.

Even though scopes can be confusing, I think that as long as you take the time to carefully trace out what's going on in your code, you can always figure out how Python is using the different scopes to look at your variables.

Week 2 SLOG - Unittest

With the past couple of weeks being filled to the brim with midterms and projects, you can probably see that I have neglected my SLOG. I know. Terrible. However, what I did do was write down some notes on things I wanted to talk about, so today, tomorrow and the day after that I'm going to post a SLOG summarizing some of the things I wanted to talk about in my SLOG for the two weeks that I missed, plus a SLOG for this week.

Today, I will go back to the SLOG Week 2 version of me.

This week, I completed lab 3, which involved unittesting. This lab was a huge wakeup call for me. Although we'd briefly looked at unittesting in my past programming course, throughout the course of this lab I realized that I actually had no idea how it worked. My partner and I managed to make it through the lab with our limited knowledge of unittesting, but over the past week I've been starting to review how it really works. I don't quite have a grasp of it yet; it just doesn't seem intuitive to me. But each time I look at it, I feel like I understand a little more.

One thing I definitely understand about unittest now is its purpose. It makes testing easier by making it automatic. Instead of typing your test cases into the Python shell over and over again, you can type them once into unittest code and just run the code to test it. It also allows you to group test cases together, which can make your code more organized. Unittest uses the setUp() function to create an object to be tested. It then has a function for each test case, the names of which should describe what you're testing. Using the 'assert' keyword, you can test whether performing certain actions on the object returns the values you are expecting. For instance, you can use assertTrue to check whether the test object or an action performed on the test object returns true.

Hopefully as I continue to look at unittest, it will become more and more clear to me until I no longer have any trouble with it at all.

An Introduction/Object-Oriented Programming

Hi there, and welcome to my SLOG!

What exactly is a SLOG you ask?

SLOG stands for courSe LOG. I am currently taking an introductory course in computer science called CSC148, and part of this course is to keep a record of my experiences in the course. In the coming weeks, I will be making a post at least once a week to talk about what I'm doing in CSC148 - the parts I enjoy, the parts I don't, things I'm learning, challenges I'm facing, how I'm dealing with them, and more.

For this week, I would just like to start with a brief description of an important part of my course so far - object-oriented programming. I took an introductory programming course last semester to prepare for this one, and in that course I began looking at the Python programming language. This course focused on the basics of Python, and mainly taught me about Python functions, which lead me to believe that functions were the most important part of Python. Almost immediately in my new course, I realised that this is not the case.

Python is what is called an object-oriented programming language (also known as OOP). This means that objects are the main focus of Python instead of functions. Objects are instances of classes (such as the str class and int class, but you can also define your own classes and created instances of them), and include attributes, which are the data the object is holding. Attributes tell you information about the object. Objects also have methods, which allow objects to perform functions.

I will be continuing to learn about OOP in the coming weeks, so in my upcoming posts I will continue to talk about it. Have a good week!