After finding out about this method of programming, I immediately began looking for ways to use it in my life. For me the most obvious use came the next day, when I was playing a game with some of my friends. The idea was to get to a certain Wikipedia page in the fewest number of clicks. An example of getting from Pair Programming to Marie Antoinette would be Pair Programming > Programmer > Offshore Outsourcing > China > List of Countries and Dependencies by Area > France > Louis XVI > Marie Antoinette. Of course, there are likely many many many other networks that lead from Pair Programming to Marie Antoinette. The challenge is to find the shortest one. And this task seems far more suited to a computer than a human. A computer can iterate through thousands and thousands of links in seconds, searching for answers. It would be ideal to use one to solve the Wikipedia game. For two specific articles, it might take the computer minutes to find the optimal solution, learning through trial and error which pages it should take.
Advanced Computer Science
Sunday, April 5, 2015
Machine Learning
When I went to UT Austin for a college visit, they had one of their best professors give us a lecture on Machine Learning, specifically in soccer playing robots. His lab had developed a method of getting the robots to teach themselves how to run the fastest, or kick the ball the furthest. It was all based off a simple process. First, one needed to define the parameters for success. For some algorithms, this was just as simple as a for loop looping through a parameter, and testing the program each time. When the parameter was finally maximized, we have finally allowed the machine to teach itself a behavior. This is one of the best ways of programming, because the program will always run optimally, given enough time.
Saturday, April 4, 2015
The Button: A Peek Into the Technology That Has Captivated Half a Million People...and Counting
Reddit.com is a social media site infamous for its silly April Fools jokes. In 2013, they announced a collectible hat trading game on the site, that split the site into two competing camps. In 2014, they announced Heddit, where users could perform site actions with their face. (Frowning, for example, down voted content.) This year, however, Reddit's joke was much simpler. It was the creation of a subreddit, /r/thebutton, which consists of a one minute timer, ticking down to 0. The aforementioned button is right next to it, which resets the timer to 60.00 whenever someone clicks it.
The subreddit has become a sort of game for thousands of people, who eagerly speculate about what will happen when inevitably, the button hits zero. In fact, the frenzy has separated redditors into two camps: those who wish to keep the joke alive as long as possible, pressing the button to prolong the agony of others, and the non-pressers, who await the moment who the clock hits zero. The speculation is almost laughable over something so simple. In this blog post, I'll be examining the technology behind the button that has captured the time of so many people.
Everything is captured in these few lines of code.
The three integral parts of the page are the button, the counter, and the chart. The button itself is coded simply as a div, "thebutton-container locked active". The script tags below it are responsible for the chart and the count down, they link to google's visualization apis which allow reddit to display their tantalizing counters and the count down chart. Nothing really new there. The html code of the site is actually being updated in real time as more and more people are clicking on the button: the span "thebutton-participants" is changing in real time as people click the button. Here, I've come to a conclusion. Nothing special will happen at 0 seconds. The code simply shows that at 0 seconds, the site will hang, waiting for unsuspecting prey to click the button once more.
PS: During the course of research for this article, the author quite unfortunately (and by accident) clicked the button...at 58 seconds.
Wednesday, April 1, 2015
SSH Tunneling
I think AISD is taking the wrong approach by restricting the internet at school. The content filters at school often get in the way of students who are looking to do actual work. Recently, I've run into a ton of restrictions while trying to complete assignments. It seems as if AISD is simply restricting more and more, and not checking their own policies. For example, recently, I was trying to create the game tic-tac-toe in javascript. However, every time I looked up tutorials, I found myself blocked by the "this site contains games content" filter. Another example would be the time I was working on a project for Great Ideas on Gender Discrimination in Primetime TV Shows. I found myself unable to look up even plot summaries of TV shows at school, because AISD was being paranoid. Control over what students do in class should be given to the teachers, and not blanket banned by the district.
A common solution to these problem would be the use of proxies or TOR, but both are blocked by the ever vigilant AISD. A solution that I think might work would be SSH Tunneling. It creates a secure "tunnel" between your network and another client, which allows a user to do things as the other computer. It's really useful for network administrators, who often need to securely access a remote server and run commands from that server. It can also be used as a form of secure file transfer, using the tunnel to transfer not only data/commands but also files. But the part that may be most applicable would be its use as a proxy. Since the user is routing traffic through another router, they are able to access the internet through the unblocked router.
An SSH tunnel is one of the best ways to bypass a firewall because it's difficult to block. Since many network administrators use SSH tunneling themselves, most organizations choose to not block that vital port, and thus using SSH as a proxy works.
A common solution to these problem would be the use of proxies or TOR, but both are blocked by the ever vigilant AISD. A solution that I think might work would be SSH Tunneling. It creates a secure "tunnel" between your network and another client, which allows a user to do things as the other computer. It's really useful for network administrators, who often need to securely access a remote server and run commands from that server. It can also be used as a form of secure file transfer, using the tunnel to transfer not only data/commands but also files. But the part that may be most applicable would be its use as a proxy. Since the user is routing traffic through another router, they are able to access the internet through the unblocked router.
An SSH tunnel is one of the best ways to bypass a firewall because it's difficult to block. Since many network administrators use SSH tunneling themselves, most organizations choose to not block that vital port, and thus using SSH as a proxy works.
Commenting Code
After my last blog post about why I stopped doing research, I thought I'd take a blog post to discuss one of the major reasons I quit the project: a lack of comments. Before starting the project, I thought it was unnecessary unless I was working with others. However, I quickly found that I forgot what my code did after a couple months. The problem was the sheer scale of the project. I was working with five or six different functions, each with their own inputs and requirements. Every time I wrote new code, I found myself writing new functions to accomplish tasks I already had functions for.
for(i in 1:length(seasons)){
if(trim == FALSE){
loop.var <- 1:length(unique(seasons[[i]]))
}else{
loop.var <- 2:(length(unique(seasons[[i]]))-1)#the first and last season are not full seasons, so you may want to exclude them
}
for(s in loop.var){
sea.s<-unique(seasons[[i]])[s]
use.s<-which(seasons[[i]] == sea.s)
goal.s<-goal[-use.s]
clinics.s<-clinic_data[-use.s,]
m.s<-lm(goal.s~clinics.s)
#which coefficients aren't na?
use.coef.s<-as.vector(which(is.na(m.s$coefficients[-1])==FALSE))
#out of sample prediction
pred.out<-m.s$coefficients[1]+rowSums(as.matrix(clinic_data)[use.s, use.coef.s]%*%as.matrix(m.s$coefficients[-1][use.coef.s]))
oos[use.s,i]<-pred.out
#checks for infinity
if(sum(goal[use.s])==0){
R2Out.i <- NA
}else{
R2Out.i<-1-(var(pred.out-goal[use.s])/var(goal[use.s]))
}
R2Out[use.s,i] <- R2Out.i
R2In[-use.s,i] <- summary(m.s)$r.squared
}#end for s
}#end for i
Here's an example of some code that I wrote, with comments delineated by the # marks. The first comment, "the first and last season are not full seasons, so you may want to exclude them" doesn't explain the code effectively, but rather indicates an option. This in itself isn't a problem, but without further commenting, it becomes very difficult for anyone to understand what my code does. The following two comments are much more useful: "#which coefficients aren't na?" and "#out of sample prediction". I shied away from more of these line-by-line explanations because I didn't want to have to include comments on every line of code. However, now I think that the line-by-line commenting is necessary for me to understand my own code. In the future, that's what I will do.
for(i in 1:length(seasons)){
if(trim == FALSE){
loop.var <- 1:length(unique(seasons[[i]]))
}else{
loop.var <- 2:(length(unique(seasons[[i]]))-1)#the first and last season are not full seasons, so you may want to exclude them
}
for(s in loop.var){
sea.s<-unique(seasons[[i]])[s]
use.s<-which(seasons[[i]] == sea.s)
goal.s<-goal[-use.s]
clinics.s<-clinic_data[-use.s,]
m.s<-lm(goal.s~clinics.s)
#which coefficients aren't na?
use.coef.s<-as.vector(which(is.na(m.s$coefficients[-1])==FALSE))
#out of sample prediction
pred.out<-m.s$coefficients[1]+rowSums(as.matrix(clinic_data)[use.s, use.coef.s]%*%as.matrix(m.s$coefficients[-1][use.coef.s]))
oos[use.s,i]<-pred.out
#checks for infinity
if(sum(goal[use.s])==0){
R2Out.i <- NA
}else{
R2Out.i<-1-(var(pred.out-goal[use.s])/var(goal[use.s]))
}
R2Out[use.s,i] <- R2Out.i
R2In[-use.s,i] <- summary(m.s)$r.squared
}#end for s
}#end for i
Here's an example of some code that I wrote, with comments delineated by the # marks. The first comment, "the first and last season are not full seasons, so you may want to exclude them" doesn't explain the code effectively, but rather indicates an option. This in itself isn't a problem, but without further commenting, it becomes very difficult for anyone to understand what my code does. The following two comments are much more useful: "#which coefficients aren't na?" and "#out of sample prediction". I shied away from more of these line-by-line explanations because I didn't want to have to include comments on every line of code. However, now I think that the line-by-line commenting is necessary for me to understand my own code. In the future, that's what I will do.
An Update Concerning Research, Or, Tact and Diplomacy
This semester, the one avid reader of my blog may realize that there recently has been a severe dearth of posts concerning research: the most common topic of my first semester posts. The astute reader may wonder why this is. After all, this research was one of the most interesting things I did--it went on every college application, gave me something outside of school to do, and was the first taste of a job I had ever had. The problem was one of time. Whether it was poor time management, or simply the fact that I wanted to enjoy senior year, I found myself completing less and less work as the year dragged on. Last summer, I was completing an assignment every week. Last semester, it dropped to an assignment every month. Finally, this semester, I have yet to do anything significant for the project. And the problem just snowballed. The less I worked with my code, the less I understood it, and the less I was able to work with my code. The experience at the very least taught me the importance of commenting code.
The hardest part of the entire process was letting the professor and the grad student know that I was stepping out of the project. I realized that I couldn't juggle both the demands of school and the demands of research in February. Still, I only took the time to draft the email a week ago, and finally sent it out today.
I learned a lot from research, and not just about computer science. Still more important, I believe was the chance to interact with others in a professional setting, and to make horrible blunders like not communicating for four months. These are things better done in high school than at a first job.
Monday, February 9, 2015
Cryptography: The Science of Minutia
I find that surprisingly, in Modern Physics, I'm often inspired to learn about Computer Science. In our nanotechnology unit, one person shared a project about a tamper-proof alternative to RSA encryption using polarized light. The method made a lot of sense to me, and I thought encryption was fascinating, so I decided to learn a bit more about encryption. I've been doing it through this Udacity Course, and so far, my main takeaway has been that although ciphers may seem very secure, even the slightest weakness can be exploited and used to crack a cipher.
A good example of this would be the Lorenz Cipher. This machine was made to use the "one-time-pad" method of encryption, where a unique key is created every time to cipher text.
A good example of this would be the Lorenz Cipher. This machine was made to use the "one-time-pad" method of encryption, where a unique key is created every time to cipher text.
| Lorenz Cipher Diagram |
A character would be encoded as 5 bits, then each would be xor'd with either a 1 or a 0, depending on the configuration of the dials K1 to K5. After that, the Lorenz Cipher would check the status of the M1 and M5 dials, and xor them together. If the result was 1, then all the S1 dials would turn. There were two large flaws in this cipher. First, because the messages were transmitted in German, the original message bits were more likely to have certain values. Secondly, because the S dials all rotated at the same time, they were more likely to be 1's than 0's. These small mechanical flaws in the machine turned what seemed to be a foolproof, random cipher into something that the Allies of WWI were able to crack after significant effort. It just shows that attackers will pour inordinate amounts of effort into breaking ciphers, and the smallest mathematical holes can lead to wars being won or lost. I plan to finish this Udacity course, and gain a better grounding in Cryptography before going to college.
Friday, January 30, 2015
Detour: P and NP
In Modern Physics, we were expected to do research on quantum computing. One of the great benefits of using quantum computing as opposed to standard computing was that it reduced problems that normally would be solved in NP time to P time. After Ryan and Jonas gave their presentation detailing this, I was utterly confused. I had no clue what the terms P and NP meant, or how quantum computing might solve these problems. To be honest, after a bit of research, I still have no idea how quantum computing reduces something from P time to NP time. The math is usually not explained in most of the explanations, and the little math that is shown is filled with jargon.
However, I did learn what P and NP time each mean, and how to apply them in a more traditional context. It's important to note here the P and NP are huge concepts in the field of computer science, where speed is of vital importance. In fact, there is a million dollar prize that will be awarded to anyone who can solve the problem of whether or not P = NP.
"John", you may say, "stop hyping up the importance of these three letters and start your explanation!"
Okay. I will. P and NP are both descriptions of how long it takes for a computer to solve a problem. Essentially, P stands for "Polynomial Time", which means that the problem is pretty easily solvable by a computer. NP stands for "Not Polynomial Time", which means that the problem takes a long time to solve. This explanation is super simplified, and maybe I'll go into some of the nuances in another, later post, but essentially, the P = NP problem simply means that for all the problems where we thought the solution would take a long time, there exists a separate solution that is much quicker. Thanks for reading!
| Typical "simplified" post. |
"John", you may say, "stop hyping up the importance of these three letters and start your explanation!"
Okay. I will. P and NP are both descriptions of how long it takes for a computer to solve a problem. Essentially, P stands for "Polynomial Time", which means that the problem is pretty easily solvable by a computer. NP stands for "Not Polynomial Time", which means that the problem takes a long time to solve. This explanation is super simplified, and maybe I'll go into some of the nuances in another, later post, but essentially, the P = NP problem simply means that for all the problems where we thought the solution would take a long time, there exists a separate solution that is much quicker. Thanks for reading!
Subscribe to:
Posts (Atom)