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.