Friday 29 March 2013

COMPUTER SCIENCE #6

It's kind of cool how in my previous post I was talking about the relationship of laziness and how that allowed us to create new innovations in order to accommodate for our need to make things more accessible and easier to use. However, in this weeks class, Danny touched upon the idea that technology may actually impede the improvement of our lives. In fact, production actually dropped for the first few decades after the Industrial Revolution and lengthened the working day. Although this seems almost impossible because technology now-a-days represents shortcuts, it is understandable as to why technology actually worsened the lives of citizens in the late 1700s to the early 1800s. My prediction is that technology during the Industrial Revolution had not been working as efficient and quickly as contemporary machines. In fact, it probably broke down requiring constant maintenance or repair. Thus, in order to fix these bugs or small mechanical mistakes, it took time and money away from the workers. So, why would shop owners turn to technology if machines had these glitches? The answer to this would be the fact that machines do not need breaks nor food in order to survive. Accounting the cost to pay for a worker far exceeds the cost of obtaining and maintaining a machine.
Anyways, back to this weeks class. We also talked about work and the effects of current technology in decreasing ones time needed to create the same amount of output. One interesting fact I learnt was that the "Crunch Mode" is ineffective due to the fact that the maximum level a long-term worker can input effectively is 40hrs/week. Productivity will drop substantially if these workers work overtime. In fact, did you know that if you work over 21hrs your optimal amount of time, it's equivalent to being legally drunk?
I guess this just shows the importance technology plays within our lives. Without technology, the work we could put into 40hrs would be considerably less. In fact, by having these technological advances, it saves us from having to over-work ourselves to the point that we are continuously making careless mistakes due to the drop of our cognitive ability.
I guess this demonstrates the fact that humans have a limit unlike machines. However, what we have that machines don't have is motivation and our ability to improve through practice. With our motivation, we can work harder and faster. In fact, we can learn from our mistakes and continue to learn without a need of a program.

I wonder if machines will ever reach the stage of having this ability to self-improve. If that day ever comes, will there really be a difference between technologically-made machines and humans? Food for thought : )

Thursday 21 March 2013


Computer Science #5
RECURSIONS RECURSIONS RECURSIONS





Bursting into the CSC 100 classroom on Tuesday at 10:15 am, I am handed a picture of myself standing in the CSC 100 classroom, the clock reads 10: 15, and I am staring at a picture of myself standing in the CSC 100 classroom and so on... This is how I would conceptualize or rather intuitively describe what a recursion is. A recursion is this idea of repeating items in a "self-similar" way. A fine example of this can be found in the image to the left of this paragraph.
<---------- Sierpinski Triangle
These recursions, like the one shown in the picture, can be pretty mesmerizing and makes me wonder in a general sense, if the world in itself, might be the microcosm of something greater...but I digress...returning back onto the idea of recursions, these self-similar images actually reminded me of something we learnt way back in the first few months of class; Fibonacci numbers. Fibonacci numbers were calculated using a long equation in which you'd have to look back to previous computations in order to calculate the original inputted value. This took a really long time when you'd increase the value inputted into the equation.
After doing the recursion calculations on the handout manually on Tuesday's class (such as the square design, snowflake design, and Sierpinski triangles), I realized the difficulty computers faced having to construct these images within a few seconds. The handouts that were given to us on Tuesday when first glanced, looked like sheets full of incomprehensible functions and operational demands. However, with further inspection, it was a handout of recursions with clear directions which required you to place different values into the functions and predict what image the value would produce.
It took a lot of patience and meticulous speculations to ensure that you inserted the right value into the correct section of the equation. Because recursions usually, maybe always, have conditions, you have you double check your work. After you've securely placed the right value in the correct location of the equation, you'd compute the image based on the functional demands. And, in order for you to find the image created by the recursion equation with larger input values, you'd have to know the image of the previous number and well I found this to be a tiresome job. It was actually at this moment that I was taken back to the first midterm when we had to calculate the Fibonacci values. It the same process of choosing the right equations to input the values and then ensuring that the previous answers would be incorporated into the overall computation.
This process made me wonder that if computers have trouble having to calculate large Fibonacci numbers, wouldn't it take them an extremely long time to calculate large values of Sierpinski triangles? In fact, wouldn't it be even more time-consuming because they are making images? If that's the case, is there a shorter way to calculate these values? As I had written in my previous post, we, computer scientists, are decently lazy and like to make our lives more convenient by finding new and more efficient ways to calculate labor intensive equations. So, I guess for this post, I'll finish it off with a question...are there more effective/shorter ways to produce the value of recursion equations?

Computer Science #4

    For this week's class, we went over the rest of the history on operating systems and started on the history of networks. We also went through in-depth examples using recursions (I'll talk about this in my other post). Walking back in time via the progression of computer developments was an extremely interesting process because (although this is kind of naive), I sort of imagined the growth of technology was a more abrupt change rather than a linear progression. I thought that computers jumped from large, time-consuming, and noisy machines the operating system we use today. To further the list of assumptions, I thought this quick transition was due to the discovery of one man, Bill Gates. This assumption was created based on what I saw through the media back in the day. I used to hear from my parents, through magazines and the television, the importance of innovation and how Bill Gate "revolutionized" computers, which I thought meant that he CREATED computers, not contribute to the development of operating systems. In fact, I even thought operating systems was interchangeable with the word "computers." So an Apple was not an operating system but rather an Apple computer or a Windows was not a operating system but a Windows computer (hey, did you notice that the extremely popular operating systems used by large masses are named after common goods?)
    So, today's class was an enlightening one. We went through networks such as the ring, bus and star configuration as well as touch upon gateways. We also went through the difference between operators and operating machines which quickly lends its way to my recent realization. Aside from recognizing that an operating system does not really mean "computer" and rather operating systems is a tool to manage tasks run on the computer (although when you think about it, an operating system could still technically be interchangeable because without these operating systems, our "computers" would not be able to function as efficiently as it does now...so technically these operating systems make up or really allow our computers to be what they are today), I noticed that as time progressed, computers became less dependent upon humans and we, as humans, have become more dependent on computers. Of course, all computers need humans to work (...well aside from robots with human intelligence that might be created in the future) but there is a trend of dependence that is quickly escalating. Back in the beginning of classes when Danny went over the first computation devices in which humans were required to manipulate different plugs in order to conduct simple calculations. Although these machines were extremely time-consuming and inconvenient, humans were the most important input when manipulating these devices. As time progressed and technology advanced through the form of smaller computers that allowed one user to run multiple programs, what I noticed is that humans became more dependent on computers due to their laziness. We always want things to be more convenient because time means money. Thus, due to the desire to be able to split-tasks on the computer (therefore saving time), it led to task-switching and multi-tasking abilities on operating systems such as IBM and later on Windows and Apple. Rather than having to write out a story manually or having to stop a calculator program when inputting numbers into an excel document, innovations such as the unix system allowed for multi-tasking. This new discovery would reduce time spent waiting for different programs to run simultaneously, increase ones dependence on technology by replacing manual recording or calculations to computer typing and computations, and thus overall increase our laziness. So I guess I finally understand what Danny meant when he said that computer scientists are lazy; we want to make our lives easier by creating different programs (operating systems) to supplement, or rather accommodate,  our lazy disposition.

I guess after discovering all this, it just shows the importance of classes like these. It helps open your eyes to the truth and allows you to jump past ignorance and walk onto the path of enlightenment, computer enlightenment : )

Sunday 10 March 2013

COMPUTER SCIENCE #3

This week has got to have been one of the hardest since the beginning of the year. Although it was quite difficult trying to remember all the different terms during the first few weeks, project one was far beyond just memorization and my group found themselves staring at the computer screen, knowing that something was wrong not completely understanding how to identify it.
The check expect wasn’t as difficult because it requires simple substitution of numbers or letters.
EX: (define (x-five num) (* 5 num))
The following exemplar is an example of a definition or function that can be put into Dr. Racket. The expected value for when you plug in 6 for “num” would be 30. This expected value is 30 because you’ve defined (x-five num) to be (5  x num). Thus, when you check the expected result, you’d replace all the “num” placeholders with your desired num (in this case, it would be 6) and receive your desired result.
EX: (check-expect (x-five 6) (*5 6))
This tool is quite useful because it allows you to instinctively ensure that your function works and will yield your desired result. This check-expect can be done backwards by writing a function or definition based off of what you’d expect by replacing the numbers by a single variable or placeholder. So, if you were given:
EX: (check-expect (x-six 5) (*6 5))
(check-expect (x-six 7) (*6 7))
You would be able to work backwards by looking at the constant variables (in this case it’s x-six and 6). Then you’d replace the changing numbers (in this case it’s 5 and 7) with a placeholder like “num”. This would give you
EX: (define (x-six num) (*6 num))
However, the problem did not lie with the examples above, but rather with the integral make-ecosystem function. My partner and I, having read the instructions and handouts, quickly inserted what we thought was the right input.

(- (* MOUSE-BIRTH-RATE MICE-START) (* FOX-MOUSE-MEAL-RATE MICE-START FOXES-START)) (ecosystem-mice eco))

(- (*FOX-MOUSE-EAT-BREED-RATE MICE-START FOXES-START) (* FOX-DEATH-RATE FOXES-START))
(ecosystem-foxes eco))

However, as one might quickly guess, we were wrong. What had started as a seemingly easy question quickly became a confusing composition of functions. What we found Dr. Racket yielded when we pressed “Run” was two scaled images, the fox and the mouse, not moving. We looked back at the failed function. What had we done wrong?
Looking back to the handout, re-reading the hints, and looking back at the function, we couldn’t figure it out. Thus, we went back to the function, looked at each input to see each individual significance; we did this by using the “Step” button on Dr. Racket.  At this moment, I really understood the importance of knowing what each unit meant. It was through this process of looking back at each input of Dr. Racket did we realize that we had skipped over the function that had already contained the rates of births and deaths. We realized that the defined functions of new-mice, new-foxes, dead-foxes and eaten-mice were not just there for check-expects, but rather it was to play an integral part in constructing the whole ecosystem. We suddenly felt a huge wave of relief as we thought we had figured out our problem. However, after we quickly placed our discovery back into the equation, we realized once more that our function was still not correct. The same picture of the stagnant fox and mouse looked at us through the computer screen.
After we slaved over the keyboard and was still unsuccessful, we sought help from people with more experience and wisdom. We went to the aid center.
One of the T.A’s despite his own lack of experience with Dr.Racket, provided us with valuable help and priceless guidance. He went over each step of the ecosystem function with us and together, we interpreted what each input meant. Things such as (define-struct ecosystem (mice foxes)) became clearer and by looking back at Dr. Heap’s videos for the quiz, our minds to computer science were opened once more.
By looking at each part, reading the question and realizing that this was a cyclical rather than a numeral question, my partner and I quickly understood our mistake. What we had inserted before was a number rather than a function. The MICE-START and FOXES-START was a constant rather than a function and thus what we needed to find was the right function. What we needed to find was a function in which the ecosystem could run its calculations not calculation.
Taking a few steps back and recognizing that what we should be inserting was (ecosystem-mice eco) and (ecosystem-foxes eco), we quickly placed that into the equation and discovered that once more, our sorrows were had not ended.
The fox and mouse, now tormenting us, appeared on the screen and after time-consuming deliberation, we sought help from the one man we knew couldn’t let us down. We went to Mr. Heap himself. After being invited and thoroughly helped by our teacher, we realized that what we had been missing from our almost perfect equation was a single number. We had to make the population of mice smaller.
After changing the population, with our breaths held and our fingers crossed, we ran our function once more. To our joy, the fox began to grow larger while the mouse drew smaller and then vice-versa. Our function was finally a success!
I guess what I really wanted to highlight from this whole anecdote is the fact that sometimes, the best thing to do is to ask for help. As Mr. Heap had told us before, the best method to problem solve is to identify the problem, think of possible solutions, take action and then reflect. Giving up after an obstacle never solves anything.  In addition, the gratitude and pleasure of solving a problem exceeds all hardships previously experienced. Thus, if after identifying the problem and taking action) re-reading your notes, looking back at the handout numerous times and trying to toggle functions around) doesn’t work, the help from those who have much more experience is the best resource.
From one amateur computer science student to the rest, when all else fails, the teacher never will (well...usually they don’t). 

Saturday 9 February 2013

Post #2

 These past few weeks have passed by so quickly. We've established the history of computers, been introduced to the concept of algorithms, learnt the basic tools to manipulate images and created a short stimulation with big-bang. Within a span of a month, that's quite a bit! 
 My favorite thing we did this week probably would've been the barracuda timer in which we constructed a moving barracuda so that it resembled a clock. The fact that it moved was fascinating. I knew image manipulation could be done through Dr. Racket, I had no idea that we could make the images move though! 
 The biggest challenge this week would've been having to study for the test. The content wasn't too difficult, it was the small details that took its toll. For an example, the same way that (flip-horizontal) is completely different from (fliphorizontal), (rotate-cw) is completely different from (rotatecw). 
 However, after considering why these functions (although so similar) are different, it is understandable and necessary that these differences are implemented in order to separate each function. If our mistakes were auto-corrected like when we text on a phone, it could lead to disastrous consequences for computer assumptions are not always correct. For an example, if you wanted to define (fliphorizontal) however it thought you wanted to write (flip-horizontal), if would lead to an error rather than allow you to define the variable "fliphorizontal". 
In fact, instead of being able to run the program, you'd see: 
define: expected at least one variable after the function name, but found none
 Seeing how humans created computers and its algorithms and human are not perfect, computer assumptions are therefore not perfect. Anyways, getting to the point, what I wanted to state was that from these experiences in which I made countless mistakes, I learnt the importance of being detail-oriented. 
 Another difficulty I found was understanding the contents of lolcatz. Particularly the "subjective-completion" section. I tried to understand the implications of each function but stumbled on this input
(string-append adjective " " noun " is " adjective))
I wondered why there was a " " before the noun. Why couldn't we just insert :
(string-append adjective noun " is " adjective))
 However, when I tried putting that into Dr. Racket and received a failed check-expect test, I quickly identified my mistake. 
 I realized that the " " represented the insertion of a space between the adjective and noun. Tweaking these formulas really helped me understand its content and the importance of having each component.  
 Hopefully these next few weeks will also be full of new lessons and new functions that I can't wait to manipulate and further understand. 

Friday 18 January 2013

Computer Science is a daunting subject in retrospect. The idea that one simple mistake (a forgotten comma or one mispelt word) could ruin a perfectly planned system, can and should put any untrained professional or student into a sudden state of fear. When I accidentally put (scale x/y) instead of (scale/xy) and only saw "error" instead of an image scaled to the values I imputed, it was frustrating. Nevertheless, because of the fact that I knew that the mistake was contained in the second half of the code, I quickly referred back to the video and solved the problem right away. Although I know there will be many other episodes similar to this one, why join computer science if you aren't ready for a new challenge?

This week, we learnt the basics of computer science consisting of useful tools one can use on Dr. Racket, a brief discussion of algorithms in lecture, and a compelling concept of what one can do with the knowledge now presented to them. Although the steps we've learnt so far don't seem to match up to the complex and almost inconceivable amount of effort put into computers and laptops now-a-days, it's kind of exciting to know that we're one step closer to being able, at the very least least, to understand them. Something new that I learnt in this course would basically be everything. Yes, even that a toaster is not a computer. I've never taken a computer science course so basically everything that is presented to me is something new; a new truth.

I'm pretty content with the materials covered this week; everyone needs to know the basics before moving onto the the more advanced lessons. It's almost like we're un-programmed computers with our lessons being imputed into our hard drive (okay, that was a bad joke). But in all seriousness, I kind of wish I was a computer that could have a simple chip inserted into my brain so that I would be able to accurately and proficiently understand and do basically everything.

Going off on a slight tangent, maybe in the future we'll be able to use our DNA to represent money instead of credit cards. We could have scanners that would scan our fingerprint and that information would be linked to our bank accounts! Then the fact that I'm forgetful would be completely irrelevant when purchasing a desired item; unless you can lose your DNA...which according to my biology 12 teacher, can't happen.    

One achievement this week would probably be the fact that I actually understood what Dr. Racket entails and I didn't get lost in the midst of letters, symbols and numbers. Hopefully that will remain constant for the up-coming classes to come.