Similar to assignment 1, when first opening "fx.rkt" and "fractal.rkt" I shamefully blanked out again. Even though I already had an idea from the in-class demonstrations of what the codes do, I still had trouble understanding the codes upon first glance. However, drawing upon experiences from assignment 1, I started reading the function contracts and check-expects. Man, weren't they ever so helpful. The contract gave an overall idea of what the function takes in and what the function churns out, while the check-expects essentially served as examples of the aforementioned inputs and outputs, making the understanding of functions so much easier. In addition, not only did the check-expects promote the understanding of the function, they also served as step-by-step checks as I worked my way through the code, making sure that everything I wrote produced the desired output. Working on the code bit by bit, making sure one part works before proceeding to the next, certainly had its charms. It made bug-hunting so much easier as you know the previous parts you have done definitely work, and that you only need to focus your attention on the newly added stuff. Following this strategy I was able to complete both codes in a matter of few hours, and it was such a huge improvement compared to the days I had to spend on assignment 1 to hunt for bugs.
One aspect of "fx.rkt" and "fractal.rkt" that I really liked was the added capability to respond to user input. This made the program so much more interesting when compared to the completely autonomous simulation we did previously. Pressing a key and seeing the program changes accordingly provided instant gratification and kept me occupied for hours after completing the assignment. I was especially fascinated by the use of "token", which is essentially a structure containing various parameters that take on different values in response to user key strokes. This token would then be fed into another function that specializes in producing certain effects in response to the parameters provided, and these effects were finally drawn onto the screen under the "big-bang" simulation. In some sense, the token was functioning as input for each function, which in turn served like one of those old computers before multitasking were implemented. This is something I'll be sure to use later on if I ever find myself in need of writing programs.
The most difficult part about the assignment, however, was the writing of a recursive function that produced patterns of different depth and size depending on the parameters provided. I had to start from the smallest unit and work my way up, basically figuring out how to draw the pattern when given the smallest input possible first, then figuring out how to draw the second largest pattern from the smallest by calling the function itself, and finally testing out to see if the function works for larger inputs. I had to practice writing simpler recursive functions in a separate program first, before moving onto more difficult ones, and finally integrating the desired function into the desired program. Things worked out very well using this approach in the end.
Demonstrations of the end products:
Fractal: A program that produces patterns of different size and depth depending on user input.
Fx: A program that changes the chameleon into user's desired color.
Tuesday, 26 November 2013
Sunday, 24 November 2013
Computer Architecture
Things have been getting really interesting in class.
I've had an intense interest in computers since I was really small. I still remember how thrilled I was when I first encountered those fantastic DOS games and later the Windows 98 ones which kept me engaged for weeks and months. Those fondness for games soon spread into the domains of computer hardware as development of games necessitated increasingly faster CPUs and larger RAMs. Even now that I no longer have much time to play games I still find myself needing to deal with the nitty-gritty of computers on a daily basis, such as trying to figure out why the heck my internet is down again. However, after years of dealing with computers I was still in the dark with regards to the basic mechanisms by which computer works. Sure, many people of my age nowadays probably have a sound knowledge of what kind of gears to get for their latest gaming machine, which type of CPU goes with which motherboard and which graphics card, but how does computer actually work at the fundamental level? How do hardware run on a binary number system and how does such a simple system transform into the awesome graphics and mechanics of Skyrim or COD? All my knowledge about computers seemed to have been built in the air and that really bothered me.
This is no longer the case! The knowledge about hardware architectures, OS, and network covered in class has really rooted almost everything I've learned about computers in the past years, and that's such a wonderful feeling. We learned that digital computers utilize two states, in this case, ON and OFF states of a tiny capacitor to represent "1" and "0". Strings of these "1"s and "0"s can then be converted into complicated numbers using IEEE floating point scheme; into all kinds of characters using Unicode; into images using the RGBa scheme, and finally into sounds with LPCM. Moreover, we learned about the basic method in which CPU works: the Program Counter of the Control Unit keeps track of the steps of the program, the Instruction Register decodes instructions of the program, while other Registers store temporary information and the Arithmetic Unit carries out the hardwired procedures of arithmetic and logical operations. We also learned about how Bus is a limiting factor for the overall computing speed of a computer (hence why it's a complete waste of money to get a top-notch CPU but only equip it with a cheap motherboard). The lecture also cleared my doubt with regard to how computers store information: magnetic dipoles on concentric tracts of a platter in hard drives, pits on spiral tracts of a compact disc, electron chambers of a flash drive. It also satisfied my curiosity about OS: what actually is a kernel? Well, it's simply a shell that layers between users and hardware, taking care of all the basic level hardware operations needed for running a high level command from the user. It also really surprised me when Danny mentioned how Mac OS actually developed from Linux, and that Linux/Unix are not only running on desktops, but also mainframes. Oh, don't even get me started on the network typologies and communication protocols. How my home Ethernet works have bothered me for years, and now I finally have an idea of what IP addresses, gateways, TCP/IP mean when fixing my crappy internet. Hooray!
I've had an intense interest in computers since I was really small. I still remember how thrilled I was when I first encountered those fantastic DOS games and later the Windows 98 ones which kept me engaged for weeks and months. Those fondness for games soon spread into the domains of computer hardware as development of games necessitated increasingly faster CPUs and larger RAMs. Even now that I no longer have much time to play games I still find myself needing to deal with the nitty-gritty of computers on a daily basis, such as trying to figure out why the heck my internet is down again. However, after years of dealing with computers I was still in the dark with regards to the basic mechanisms by which computer works. Sure, many people of my age nowadays probably have a sound knowledge of what kind of gears to get for their latest gaming machine, which type of CPU goes with which motherboard and which graphics card, but how does computer actually work at the fundamental level? How do hardware run on a binary number system and how does such a simple system transform into the awesome graphics and mechanics of Skyrim or COD? All my knowledge about computers seemed to have been built in the air and that really bothered me.
This is no longer the case! The knowledge about hardware architectures, OS, and network covered in class has really rooted almost everything I've learned about computers in the past years, and that's such a wonderful feeling. We learned that digital computers utilize two states, in this case, ON and OFF states of a tiny capacitor to represent "1" and "0". Strings of these "1"s and "0"s can then be converted into complicated numbers using IEEE floating point scheme; into all kinds of characters using Unicode; into images using the RGBa scheme, and finally into sounds with LPCM. Moreover, we learned about the basic method in which CPU works: the Program Counter of the Control Unit keeps track of the steps of the program, the Instruction Register decodes instructions of the program, while other Registers store temporary information and the Arithmetic Unit carries out the hardwired procedures of arithmetic and logical operations. We also learned about how Bus is a limiting factor for the overall computing speed of a computer (hence why it's a complete waste of money to get a top-notch CPU but only equip it with a cheap motherboard). The lecture also cleared my doubt with regard to how computers store information: magnetic dipoles on concentric tracts of a platter in hard drives, pits on spiral tracts of a compact disc, electron chambers of a flash drive. It also satisfied my curiosity about OS: what actually is a kernel? Well, it's simply a shell that layers between users and hardware, taking care of all the basic level hardware operations needed for running a high level command from the user. It also really surprised me when Danny mentioned how Mac OS actually developed from Linux, and that Linux/Unix are not only running on desktops, but also mainframes. Oh, don't even get me started on the network typologies and communication protocols. How my home Ethernet works have bothered me for years, and now I finally have an idea of what IP addresses, gateways, TCP/IP mean when fixing my crappy internet. Hooray!
After more than a decade of playing this game, I finally have a faint idea of how it's working now... sweet :)
Subscribe to:
Posts (Atom)


.png)