Another Week, Another Post!

Well apparently a whole week has gone by yet again, which means it's time for me to talk about my adventures in CSC148!!!

So I've just finished Exercise 2, and I'd like to say that it wasn't bad at all! The only difficulty exercise 2 posed was being aware of the new syntax and using it correctly.  The biggest "trick" to the whole exercise was knowing that E2Error was a superclass of E2OddError. That said, if an except block had:

try:

   f(x)

except E2Error:

   return 'E2Error, but could be an E2OddError'

return 'no error at all'

Now if f(x) raises an E2Error exception or E2OddError exception (since E2OddError is a subclass of E2Error), then it will return :

'E2Error, but could be an E2OddError'

In the python shell:

>>>reporter(raiser, 6)
'E2Error, but could be an E2OddError'

Here I use the reporter function used in the exercise. Reporter gives an E2OddError if x is even, and gives an E2Error  if x is the string 'Go sue me!'.  That was the most challenging part of the exercise, although hopefully not too challenging because it was discussed in class.

Stacks, Exceptions and More!

         This week we discussed stacks, which is a class. Stacks can be represented as lists except with a whole lot of restrictions! For starters, only the item at the top (last item in the list or the first item in the list, depending on what you choose to be "the top") can be removed or "popped," as the method name would suggest. A few methods we defined during lecture was is_empty(), pop() and push(). But of course we could define as many methods as are needed for the stack class. Some more useful methods for the stack could be split, which splits the stack in half, or empty, which empties the stack. As interesting as stacks are though, I was most intrigued by a new concept that was introduced to us this week and that is exceptions. Of course it's not an entirely new concept, we already know exceptions are raised when a function goes wrong. They are different in the way they handle it,  errors usually cause a program to crash/terminate and an exception when handled does not.

        The part I found most interesting was that errors often result in a program crashing, while exceptions are used to control it in a manner so that the program still works correctly. It's interesting because it allows us to do more with our programs, we now have the ability to handle the exceptions. So with this new concept we knew we would naturally need to also learn the syntax that goes along with it. Luckily, the syntax doesn't seem too daunting. What might prove to be more challenging is that there are quite a few python errors as it is... Something I found to be frustrating is knowing which types of errors are subclasses of other errors. It might not be completely obvious until we use the isinstance since it checks for inheritance to see if an error is a subclass of another error.

         During labs, one of our tasks was to make the queue class as efficient as possible. The difference between a stack and a queue is that a stack is LIFO while a queue is FIFO. It turned out that the stack class was already efficient. One reason for this could be that since a stack is essentially represented as a list, much iteration is not needed since the first one in is the first one out. On the other hand, to "dequeue", we would need to iterate over to the first item in the list and then move every element up by one. One solution I came up was that since the stack queue was efficient as is, and its pop method simply removed the last element from the list, it would also be efficient to use this idea in the dequeue method. So in the dequeue method, the list representing the queue would be reversed, the last item would be removed (like in the pop method), and the list would be reversed again, and the removed item would be returned. It turned out that it was only slightly more efficient, and so perhaps using reverse is not that efficient either.

       A concept introduced to us later in the week is idioms. Idioms are supposed to make our life easier because now you can write code that would usually take two or more lines and somehow condense it into one. Which sounds ideal, but the code itself seems rather hard to follow at this point, although we have only really focused on list compression so far. Perhaps finding similarities and differences in the original two-or-more lined code and the idiom would be a helpful way to understand it. In the original code, we would place "for <variable> in <iterable>" in the first line, this seems to be placed last, unlike the original code. And the body is placed before it. Two nested for-loops are achieved in the same bracket. List compression heavily relies on brackets. Idioms can help to shorten code, although it will require practice.

      One problem encountered was the balanced-bracket function. The goal of the function is to return false when a segment of brackets is balanced, i.e. the number of left brackets is equivalent to the number of right brackets. This was to be done using stacks. To test if the number of left brackets is the same as the number of right brackets, we would need to push a left/right bracket depending on what appears first, and then pop it when the opposite bracket appears. We first need to see which appears first in the code. We can do this using an if statement. To avoid any possibility of an error, we must take into account the possibility of an empty stack that is acted on by the pop method. We must ensure that every time we do use the pop method, that the stack is not empty. So we must push another bracket into the stack and pop it when an opposite bracket is found. Whatever type of bracket appears first in the series of brackets, is what is pushed on to the stack, and its opposite is popped from the stack. Brackets that have been "dealt with" can be removed from s (the argument representing brackets). After all this is done, we only need return stack.is_empty(). If the stack is empty, the brackets are balanced.

Getting Started (And picking up where we left off!)

Finally, CSC108 is over and done with, and I'm looking forward to CSC148! So this week in lecture, we've really just been continuing where we left off in CSC108, which would be classes. When defining a class, one must think about inheritance, and methods that are going to be defined with in the class. We did a question that was on a past midterm. At first it seemed confusing, but thinking about it a bit more, I realized that inheritance would help a lot. The lab this week was pretty much CSC148 recap. I look forward to writing more posts!