We had the last test today. It was a bit tougher than the first two. We'll see how I did -- but I definitely feel like I'm going to need the 10 points from this blog.
Anyway, I saw this yesterday and thought it noteworthy. This student found out about a musician's death and quickly posted a harmless but falsified quote on the musician's wikipedia entry. Some legit media outlets ran with the quote. Pretty interesting, and indicative of very poor journalistic integrity. I feel like it's hard to trust much these days, and this does not help my apprehension.
SCHOOL'S OUT!
P.S., check this out. Seriously.
Friday, May 8, 2009
Thursday, May 7, 2009
For those interested...

I don't know how many other kids grew up playing Blizzard's StarCraft, but I was excited and nostalgic when I saw that Blizzard/Battle.net had opened up their beta signups for StarCraft 2! Apparently all you do is sign into your Battlenet account and click on Manage My Games. There should be a link to "Beta Profile Settings" there. This comes from Slashdot.
While I love StarCraft (and will play the beta/final release), I am really waiting on the beta period for Diablo 3. If anyone played Diablo 2, you remember how addicting that game was. Fire Sorcs, Corse Explosion Necros (before they got nerfed on the first patch :( ), WW barbs, hammerdins. I feel like I'm 14 again. Although I was playing Diablo 2 well into high school (and even some in college, I'm ashamed to say).
TA4
Our TA4 submission was probably our best one of all. And we didn't even work in the lab together the final Sunday! All of us worked together over gmail/gchat and got our respective tasks done. Not to mention we all had worked hard on our own piece of the final project before the weekend to avoid the clusterf*ck that had been our last two submissions.
My job was to implement the Class Search and Applicant Search. What I did was create various fields to narrow down search results. For example I had a "What semester?" dropdown, and an "Assigned Or Unassigned TAs" dropdown, a multiselect box of all specializations, a select field for programming languages, instructors, previous courses. All of these could be used to narrow applicants results.
The way I implemented the search was by starting with every ApplicationEntry we had in the datastore. I would .get() each ApplicationEntry's key and use it as the key in a dictionary, results_dict. For the values, I used a boolean value that was initially set to True. As each field was probed for input, I would run through the dictionary, only modifying an entry if the input in the respective field restricted the Applicant from being returned as a result.
Thus, if the user wants ApplicantEntrys from the semester Fall 2009, we would test the semesterKey in each ApplicationEntry to see if it was Fall 2009. If not, we set the value in results_dict to False.
We did this for each field that showed input, and then once we were done, we built a list of all ApplicationEntrys that were still True in results_dict after all search fields were completed, and returned the list to the django template file, where the results were displayed.
Our project probably looked the most basic out of all of them, but since the graders say they weren't taking points off for how the app looked, we did not care.
My job was to implement the Class Search and Applicant Search. What I did was create various fields to narrow down search results. For example I had a "What semester?" dropdown, and an "Assigned Or Unassigned TAs" dropdown, a multiselect box of all specializations, a select field for programming languages, instructors, previous courses. All of these could be used to narrow applicants results.
The way I implemented the search was by starting with every ApplicationEntry we had in the datastore. I would .get() each ApplicationEntry's key and use it as the key in a dictionary, results_dict. For the values, I used a boolean value that was initially set to True. As each field was probed for input, I would run through the dictionary, only modifying an entry if the input in the respective field restricted the Applicant from being returned as a result.
Thus, if the user wants ApplicantEntrys from the semester Fall 2009, we would test the semesterKey in each ApplicationEntry to see if it was Fall 2009. If not, we set the value in results_dict to False.
We did this for each field that showed input, and then once we were done, we built a list of all ApplicationEntrys that were still True in results_dict after all search fields were completed, and returned the list to the django template file, where the results were displayed.
Our project probably looked the most basic out of all of them, but since the graders say they weren't taking points off for how the app looked, we did not care.
TA3
TA3 submission did not go smoothly. We had issues all the way up to midnight and even then we took a late-submission hit and resubmitted Monday after realizing that our matching algorithm was not working correctly. But we got it working and did fine.
Our algorithm added +1 points to a TA if he/she had listed the specific specialization and/or programming language(s) that was desired by an instructor of a class (each type a new class was considered, all available TAs started with zero points). +2 if a TA was "qualified" to teach a course, and +3 if he/she had taught the course previously.
We thought we had it all worked out until we found that our matching code was using TAs from all semester. Thus John from Fall 2008 and John from Spring 2009 could be assigned to a Fall 2009 class even though they are the same person spread among 3 semesters). So we had to resubmit but it was all OK. Hopefully TA4 will go a lot smoother. We'd better use our time wisely for the next submissions since they are stressing that they won't be as lenient for the final iteration.
As for the algorithm, a few simple modifications were used to implement the point system. After that, it was comparable to dropping in a fancy new engine into an old car. All we had to do was make the connections. A nice little break from having to code a huge piece of software since we all already had it from Project 3.
Our algorithm added +1 points to a TA if he/she had listed the specific specialization and/or programming language(s) that was desired by an instructor of a class (each type a new class was considered, all available TAs started with zero points). +2 if a TA was "qualified" to teach a course, and +3 if he/she had taught the course previously.
We thought we had it all worked out until we found that our matching code was using TAs from all semester. Thus John from Fall 2008 and John from Spring 2009 could be assigned to a Fall 2009 class even though they are the same person spread among 3 semesters). So we had to resubmit but it was all OK. Hopefully TA4 will go a lot smoother. We'd better use our time wisely for the next submissions since they are stressing that they won't be as lenient for the final iteration.
As for the algorithm, a few simple modifications were used to implement the point system. After that, it was comparable to dropping in a fancy new engine into an old car. All we had to do was make the connections. A nice little break from having to code a huge piece of software since we all already had it from Project 3.
TA2
TA2 was a hectic submission. Almost no work had been done prior to extended deadline (Wednesday after Spring Break). Thus we were all in the Taylor basement until midnight. We all had separate pages to code and we were pretty disjoint during this iteration (SB and all).
However, we ended up doing OK. Our database scheme consisted of the typical things you'd think you needed: TAApplicationEntry (holds all applicant info), UserEntry (holds names, user-types, and eids), SemesterEntry (to remember what semester was active, if TAs could apply/instructors submit preferences), ClassEntry (holds all data related to specific classes), CourseEntry (holds all courses taught), MajorEntry, ProgrammingLanguageEntry, etc. Tough to work out a useable schema but we did it and I think it works well.
However, we ended up doing OK. Our database scheme consisted of the typical things you'd think you needed: TAApplicationEntry (holds all applicant info), UserEntry (holds names, user-types, and eids), SemesterEntry (to remember what semester was active, if TAs could apply/instructors submit preferences), ClassEntry (holds all data related to specific classes), CourseEntry (holds all courses taught), MajorEntry, ProgrammingLanguageEntry, etc. Tough to work out a useable schema but we did it and I think it works well.
TA1
TA1 went good. We learned a lot on the fly. We first hardcoded every field we had with pure html in all of our .py files. We quickly realized that this practice would be cumbersome and extremely 'non-robust.' We saw one group made a Field class and extending subclasses such as "TextBoxField," "SelectField," and "MultiselectField." This made life infinitely easier, as well as enabled us to use the Django templates by passing a dictionary with strings as the keys and any other data type (lists, booleans, whatever) as the values, that were THEN callable inside the template .html files. This was a very useful implementation and had we not done that, our subsequent TA submissions would have been the cause of many more headaches than they were anyhow.
Monday, March 23, 2009
Oops?
Yeah, been a while since the last post. Got caught up in pre-SB tests and SB itself. But school is starting up again today for the home-stretch. Got absolutely no work done over spring break and will spend most of my night in the Taylor basement. My team has not communicated but I'm confident we'll be fine as we'll iron out who does what today in class. More to come after I work on my part of TA1.
Friday, March 6, 2009
Man, busy week. I started and finished SMP yesterday. Funny since my last blogpost a week ago was about starting on that day. Anyway, it's not too bad. I used a dictionary for the women's preferences. One of the form { man number : rank } where man number is the ... number of the man, and rank is obviously his rank.
Thus a woman ranking her men as 5 2 4 3 1 will generate a dictionary of { 5:1, 2:2, 4:3, 3:4, 1:5 }.
Then we compare her current fiances' ranking to a competing free male's ranking (i.e., dict[single_male_number] < dict[competing_fiance_number]) when determining whether her current engagement will end (if single_male.number is less than competing_fiance.number) or not (if dict[single_male_number] is greater than dict[competing_fiance_number]). I used a dictionary for Woman since women must keep track of their preferences and I didn't feel I'd be able to implement this the way I wanted via a stack. However, a man can "pop()" a preference and if she doesn't accept his proposal, she never will, so it works out for Man in a man-optimal implementation.
I created a Woman, Man, and Stack class and have the algorithm run within a loop of the form: while(there_is_an_unmatched_couple()). This works by iterating through a list of Man to see if any Man is single. Any single male implies there is a single female out waiting for him. If so, find him a mate!
Thus a woman ranking her men as 5 2 4 3 1 will generate a dictionary of { 5:1, 2:2, 4:3, 3:4, 1:5 }.
Then we compare her current fiances' ranking to a competing free male's ranking (i.e., dict[single_male_number] < dict[competing_fiance_number]) when determining whether her current engagement will end (if single_male.number is less than competing_fiance.number) or not (if dict[single_male_number] is greater than dict[competing_fiance_number]). I used a dictionary for Woman since women must keep track of their preferences and I didn't feel I'd be able to implement this the way I wanted via a stack. However, a man can "pop()" a preference and if she doesn't accept his proposal, she never will, so it works out for Man in a man-optimal implementation.
I created a Woman, Man, and Stack class and have the algorithm run within a loop of the form: while(there_is_an_unmatched_couple()). This works by iterating through a list of Man to see if any Man is single. Any single male implies there is a single female out waiting for him. If so, find him a mate!
Friday, February 27, 2009
Been a while since last post. Busy with studying for an Automata midterm we had last night. Wasn't too bad though. I going to begin working on the SMP project today after class. I also think I'm going to stay in classroom and sit it on Prof Downing's next class (in the same room) which is mainly about c++ (I think?) Sam convinced me to do, and I know it would greatly help me for 354 (Graphics) because everyone in there knows C++ (better than I do, anyway). Anyway, once I get into this project I will post some more SMP-specific stuff. So for now...
Wednesday, February 18, 2009
Australian Voting
Adam and I have started working on our current project, Australian Voting. We've created 3 classes: a candidate, ballot, and testcase class. These three will be used to implement our method of counting votes. We feel we have a good solution in adding the testcase class, because all of our computation will be done inside this class, using the classes candidate and ballot to communicate that a certain candidate is out, etc. Many groups have used just the two, candidate and ballot. So we'll see if we've dug ourselves a hole. We aren't done yet. Updates pending.
Sunday, February 15, 2009
We had our first test on Friday, the 13th. I think I did fine on the programming questions but the questions about the reading get me. I haven't the slightest clue what a spike solution is. I thought the test was fair and we had ample time to code our answers, test, and double-check. List comprehension "unrolling" was probably the toughest question.
Anyway, my partner (Adam M) and I will start working on Project 3 today. Looking at the problem, perhaps creating a sort of "candidate" class would simplify this problem. I'll see what it's like one we dive in.
Anyway, my partner (Adam M) and I will start working on Project 3 today. Looking at the problem, perhaps creating a sort of "candidate" class would simplify this problem. I'll see what it's like one we dive in.
Saturday, February 7, 2009
Summation of Four Primes
Here's a different algorithm for our current project, Summation of Four Primes.
If you could write a next_lowest_prime(n) method, you might use it to find n's next lowest prime (if n is prime, return n).
Then you could do it again, this time calling the method with next_lowest_prime(n - [the "previous" next lowest prime]). If you do that 4 times, you'll get 4 primes that add up to your n. But say n = 20.
next_lowest_prime(20) = 19. So, 19 is one.
n' = 20 - 19 = 1. Obviously we have a problem. But there is a simple solution to fix this. Declare a variable, r = 6.
Why 6?
We'll always be able to obtain the first prime, but in cases such as the one above, the next lowest prime is one (or zero, two, or three...) below n. So we must have a way to guarantee that there are 3 spaces for the minimum prime, 2. So 2x3=6.
Then:
four_primes[i] = next_lowest_prime(n' - r)
n' = n - four_primes[i]
r -= 2
guarantees you will obtain a prime that leaves enough room for the rest of the 4 primes. Run the algorithm for n = 20, again.
N.L.P(20 - 6) = 13
N.L.P(7 - 4) = 3
N.L.P(4 - 2) = 2
N.L.P(2 - 0) = 2
If you could write a next_lowest_prime(n) method, you might use it to find n's next lowest prime (if n is prime, return n).
Then you could do it again, this time calling the method with next_lowest_prime(n - [the "previous" next lowest prime]). If you do that 4 times, you'll get 4 primes that add up to your n. But say n = 20.
next_lowest_prime(20) = 19. So, 19 is one.
n' = 20 - 19 = 1. Obviously we have a problem. But there is a simple solution to fix this. Declare a variable, r = 6.
Why 6?
We'll always be able to obtain the first prime, but in cases such as the one above, the next lowest prime is one (or zero, two, or three...) below n. So we must have a way to guarantee that there are 3 spaces for the minimum prime, 2. So 2x3=6.
Then:
four_primes[i] = next_lowest_prime(n' - r)
n' = n - four_primes[i]
r -= 2
guarantees you will obtain a prime that leaves enough room for the rest of the 4 primes. Run the algorithm for n = 20, again.
N.L.P(20 - 6) = 13
N.L.P(7 - 4) = 3
N.L.P(4 - 2) = 2
N.L.P(2 - 0) = 2
Thursday, January 29, 2009
First blogpost for CS 373
Actually, my first blogpost ever. This blog is for the Software Engineering class taught by Glenn Downing at the University of Texas. I am about to start working on my first project: 3n+1.
The actual problem is easy, especially since we've done it before in CS 315, also with Downing. I'm not too sure about Subversion, but we'll see how it goes. Updates pending...
The actual problem is easy, especially since we've done it before in CS 315, also with Downing. I'm not too sure about Subversion, but we'll see how it goes. Updates pending...
Subscribe to:
Posts (Atom)