Paper Folding problem

At the start of the semester the Danny presented the class the paper folding problem. The problem involved folding a strip of paper over on itself, and being able to predict the Up folds or Down folds on the strip. My partner and I used Plya's method to solve a problem.
1. Understand the problem:
We started by identifying the problem and understanding it.That being, no matter what fold we were working with, we could predict the sequence of up or down folds before the paper was folded.
2. Devising a Problem:
We discussed how we would go about solving the problem. We decided to start by folding the paper and recording the Up or Down folds each time we folded the paper and checking if we could find a pattern just by looking at it.
3. Carry out the plan:
We carried out our plan, folding the paper and writing down the Up or Down folds, indicating with a U for up or a D for down.
4. Looking Back:
We then looked at the information we gathered to search for some sort of pattern. Looking back at the data the way we had represented it there did not seem to be a pattern we could see. Because we had not solved the problem we tried a new approach.
2. Devising a Problem
We thought of a new way to go about the problem. Getting a new piece of paper we looked at a smaller case. We only looked at the first and second fold with the new paper. Examining the paper itself we concluded that on the first fold we created one U fold in the center. If we fold the paper again, we create two new folds. One Up and the other Down. The left side folded up and the second folded down. We discovered that this idea, that for each fold there would be a new fold on each side continued for the whole problem.
3. Carry out the Plan:
So we created a new list of Up or Down folds but representing it differently.

1:                                                      U
2:                                      U             U             D
3:                              U     U     D     U    U      D      D
4:                          U U D U U D D U U U D  D U  D D

4. Looking Back:
Looking at the data this way made it easier to see that earlier folds persist through the the new folds. My partner and I discovered that on each side of every second earlier fold the left side would have a new U fold and on the right, a new D fold. Writing the pattern in this "tree" pattern we could predict what the next fold would look like. Therefore solving the problem Danny proposed.

Infinite loops

In week 11 Danny went over functions that loop forever. In my computer science courses in high school, and in csc108, it is stressed that one should never make a program that loops infinitely. Either by accident or on purpose. The only way for the computer to end the loop is if it runs out of memory and the program crashes, which is also bad. This has already been a problem writing programs for my csc108 course. My partner once accidentally created an infinite loop, and the program promptly crashed after attempting to run it. It is also difficult to determine if a program is looping infinitely or just taking a very long time to run. When attempting to solve a problem in the 108 assignment I created a triple nested loop that would eventually return the correct answer. However, because there were three loops to go through, the program took a long time to run with large inputs and was not efficient. I eventually had to rewrite the program because the run time was sometimes longer than 5 minutes, but it would eventually return a value.
I found this was one of the problems with thinking about programs that have infinite loops. How is it possible to tell if  a program is simply taking a long time to return a value, or is it looping infinitely.
Danny talked about writing a function to determine if a program loops infinitely by testing it with another program. I don't quite understand how a program could test if a program loops infinitely, because calling on a function that loops will cause it to loop infinitely so it would never return anything, and the program testing it would be waiting for a return value for an infinite amount of time.

Big and small infinities

This week involved examining infinite sets. The professor started with a "simple" infinite set, the set of all natural numbers. This set is easy to understand, all numbers that you can count starting from one. It is a simple concept and it is easy to see how one could get to extremely large numbers and still be able to continue. Therefore this is an infinite set because it can continue forever without ending. Next the professor proposed a simple idea. What about the set of all even numbers? It has the same idea as the set of natural numbers, just count each even number starting from 0 or even 2. This set is also infinite yet somehow it is half as big as the infinite set of natural numbers. When thinking of even numbers it is easy to think of them as half of the numbers, since even numbers appear on every second integer. I found this thought interesting, that although the set of natural numbers is infinite, the set of even numbers (which is also infinite) is somehow smaller. That there are smaller and larger infinities. The last set we looked at was the set of rational numbers between 0 and 1 which is even more infinite! despite being a small interval in the natural numbers, the set contains even more fractions than the set of natural numbers. Firstly, no matter how many decimal places you have listed, it is perfectly reasonable to add another decimal place an infinite amount of times. Secondly, it is always possible to add another decimal that is not already in the set.
I gained some insight from another students blogs about how infinite sets relate to python. Ji Yong Choi, related the infinite set to the number of possible programs that could be written in python. He also mentioned that most of these programs probably wouldn't work, or could cause an infinite loop. I found it discouraging to think one is more likely to write a program that doesn't work than one that does.

sLog csc165 Week 7

In tutorial this week we went over how to do 3 proofs. I have noticed that the style of writing a proof is different between the TA and the professor. While there many ways to write a proof I will follow the TA's style of writing a proof. Although it is sometimes confusing looking at the examples gone over in lectures against the examples done in the tutorial.

cSC 165 week 9

In lecture this week we began learning about different sorts. We examined the code for different types of sorts. I recalled learning different sorts for Java in my computer science classes in high school. My high school teacher explained that different sorts performed more efficiently depending on the length of the list or array. At the time he breifly explained why certain sorts worked better than others and I memorized what each sort was most efficient. Now in Lecture we examined the code more throughly and explained why the codes performed differently.  I found determining the worst and best case of each sort interesting.

sLog csc165 Week 6

This week the professor covered proofs in the lectures. Earlier in the course when proofs were mentioned, I was concerned that they would be something completely new. I had never learned specifically how to do a proof in  high school. Other students in the class had talked about proofs and I was concerned that I should have prior knowledge about them. It was reassuring to learn that proofs are essentially math problems written out in a particular format. I found it interesting that for some of the easier proofs, a student would write out the answer algebraically on the side and then translate what he or she had written into a proof format. One of the difficulties I had with the proofs were the amount of steps to take between each part. Proofs are written with a specific audience in mind, in this case the proofs are written for a typical csc165 student. I feel like I would take more steps between parts than is necessary for my own reference, so that I can see how I got from each part to the next.

sLog csc165 Week 5

This week was mostly focused on the daunting mid term on Wednesday. This was my first formal test at U of T and the first time in the exam center, which was an important learning experience for future tests. I initially had trouble studying for this test. I started by reviewing my power point slides and notes, but I didn't feel like I was getting a solid understanding of the material. Later on I found it much more satisfying to redo the tutorial questions and quiz questions given in the tutorials. Answering the questions for myself, and learning from the struggles I had with particular questions helped with my learning process.
Doing the practice mid term questions also helped me prepare for the mid term. I had trouble with the first question on the mid term practice test, the question involved python functions written by Danny and at first I could not make sense of what they did. Eventually I translated what the functions were supposed to do I and I translated it into English so I could understand what the question was trying to ask me.