CS-315H: Algorithms and Data Structures (56280) Fall 2006
CS-315H: Algorithms and Data Structures (56280)
Fall 2006
IMPORTANT LINKS

  • CLASS WIKI - This is where you will find all key information relating to the class material.
  • Professor Lin's Page - he makes announcements as well.
  • Project Turn In - at the Microlab. Make sure you hit the CHANGE button when selecting the class.

    URGENT ANNOUNCEMENTS:

  • Project #7 been graded and returned. Congratulations - you guys REALLY kicked that las t one out of the park! For explanation of grading see below.

  • Tetris, both Projects 4a and 4b, have been graded and returned. For explanation of grading see below.

  • FINAL EXAM: FRIDAY, DECEMBER 15, 9-12am in GEO 2.218 (So don't oversleep!)

  • An IMPORTANT REMINDER: If you turn in your assignment more than a couple days late, be sure to email me to let me know you have done it. I cannot scan the turn in system and tell if there has been a sudden new submission. And please use the [cs315h] tag in your subject line - that's how I find your email.

  • Dr. Lin has posted Dijkstra's Algorithm on his website.

  • Project #8 is still live [Karma Suture].

  • We now have a SINGLE PAGE on the Wiki for all current questions so you can just go to one place. (This is called the "pseudo newsgroup").

  • The Turing class of 2006 gallery is now up! See how your creativity compares with previous years.

  • When you email me, please put [CS 315H] in the subject line so I don't miss your email. (I get hundreds a day.) Also, make sure to check out the wiki as I'm always adding useful info to it and answering your questions.

  • My office hours are now being held in the Microlab in Painter's. If you have any questions, feel free to email me. NOTE that there is a desk in front of the lab (outside) facing the main Painter entrance and I might be working there just outside the room.


    SAMPLE REPORTS

    Assignment #7:
    Chau Nguyen and Matt Wilson
    Chris Agerton and John Sheu
    John Wright and Colin Wragg

    Assignment #6:
    John Wright
    Bryce van de Geijn
    Matthew deWet

    Assignment #5:
    John Wright and Colin Wragg
    Chris Agerton and John Sheu
    Matt Dewett and Chris Wiley
    Lee McCuller and Jeff Zhu
    Dan Chimene and Jeff Shi

    Assignment #4a:
    Matt Dewett and Chris Wiley
    Bryce van de Geijn and Ankur Rathi
    John Wright and Colin Wragg

    Assignment #4b:
    Lee McCuller and Jeff Zhu
    Chris Agerton and John Sheu
    Adam Setapen and Thomas Jack
    Matt Dewett and Chris Wiley
    Finally, there was an excellent report by Bryce van de Geijn and Ankur Rathi which they forgot to turn in electronically so I can't show you.

    Assignment #3:
    Jeff Zhu and Lee McCuller
    Vincent Liu and Youngsuk Lee
    Adam Setapen and Thomas Jack

    Assignment #2:
    Yidi Yu
    Thomas Jack

    Assignment #1
    Adam Setapen
    Elizabeth Barham

    Assignment #0
    Forrest White
    Chris Wiley

    ASSIGNMENT #8

    Project #8 - Karma Suture. This project is completely optional and can be done alone or in pairs. If your grades or lagging or if you just didn't get time to that last fun thing during the semester, here is the chance you've been weighting for. Just make sure you finish Project 7 first!

    NOTE: The code base came without documentation. My impression so far is this: Create a class called "BSPTree" that implements the BSP interface. It appears that this is all you have to implement. The rest should work like magic. I will let you know if I find out additional information. WARNING - this package contains naken class files that may be difficult to use in Eclipse.

    Assignment #8 code base
    Assignment #8



    ...
    ARCHIVE (remember when?)

    QUICK INDEX: (Wow! You did ALL THAT coding!)

    Assignment 8 =>
    Assignment 7 =>
    Assignment 6 =>
    Assignment 5 =>
    Assignment 4 =>
    Assignment 3 =>
    Assignment 2 =>
    Assignment 1 =>
    Assignment 0 =>

    ASSIGNMENT #7 - GRADING!

  • Here are some model reports from Project #7:

    Chau Nguyen and Matt Wilson
    Chris Agerton and John Sheu
    John Wright and Colin Wragg

    This project was out of 125 points. As mentioned, the primary focus of this assignment was on analysis - how did you choose your data structures for optimal time/space performance? What some of your didn't realize (and some learned) was that if an algorithm is poor in space it can often become poor in time as well, so the best solution is econmical in time and space.

    Here is the breakdown:

  • ANALYSIS - 30 points. How well did you analyze your algorithmic decisions regarding the design of your index database and your query engine?

  • FUNCTIONALITY - 28 points. Did your program correctly generate indexes and perform all of the base level queries?

  • REPORT - 37 points. Report outside of analysis and functionality: How good was your testing procedures? Did you remember the XP log? How well did you describe the implementation of your algorithms? How good was your report organization?

  • STYLE - 30 points. In the end, how efficient was your code? And how stylish was your code? Was it readable? Did you have comments?

    ASSIGNMENT #7

  • Project #7 is still live as of Wednesday.

    Here is information on the final mandatory programming assignment. Congratulations! You made it!

    Supplementary Material and implementation guidelines by Adam Brown
    Assignment #7 code base
    Assignment #7

    ASSIGNMENT #6

  • Here are some initial model reports from the Treap project.
    John Wright
    Bryce van de Geijn
    Matthew deWet

  • Project #6 (Treap) has been graded. Below is a summary of what your grade means.

    This assignment spelled out the algorithms in detail, so a little more emphasis was put on correctness, i.e., the machine tests. As with Boggle, there was almost no middle ground - there were people who aced the testing and those that did not do so well. However, like with Critters, in many cases it was obvious what the outcome would be.

    There were 22 tests in all. Below is a histogram. Amazingly, the class of 2006 really showed their prowless in testing as 6 students got a 21 or better, with 4 perfect scores slamming the amazing class of 2004! I consider a 17 or better an A+. The correctness score (testing) made up 35% of the assignment grade, so unfortunately, if you weren't with the group of good testers, you likely didn't get an A. Similarly, if you turned in your assignment late, you weren't likely to get an A. And if you weren't a good tester AND you turned in your assignment late - well - let's just say you should take me up on my resubmission offers. (I truly hate giving out low scores.)


    Test Score Histogram

    The breakdown for the rest of your score is as follows:

  • Correctness: Out of 35 points, this is your scaled machine score. Avg was 17.7/35.0.

  • Code: Out of 20 points, this is the style thing - how well did you comment, how clean and readable is your code, how efficient was your code? Avg score was 14.3/20.0 (we had some non commenters this time.)

  • Testing: Part of your report, this was a primary emphasis of the project and was worth 15 points. This was a chance for those of you who did impressive testing yet still got slammed by the machine to make up some ground. Avg score was 10.3/15.0. (Some people still don't recognize that they are just testing a single common case.) How did you validate correctness? What input tests did you use to pinpoint corner cases?

  • Analysis: Analysis should be part of any report. It was not emphasized by this project, so it was only worth 10 points, but I thought it good to break it out this time so you get some feedback. Avg score was 6.3. The main emphasis of the project was recognizing that a Treap is a randomized algorithm and the purpose of the randomization was to balance the tree so that O(h) operations would approach O(lg n) operations. Realize that the height of the tree was not guaranteed to be log n. Look at the performance of the randomizer - most of your correctly realized that it generally got within 2x of the ideal tree. And that it did better with exponentially more nodes. Which made it compare quite favorable with the RB tree. Some didn't understand balance factor - it is relative to the ideal tree height = lg(n+1)-1. Also includes a basic order analysis of the data structures you chose and why you chose them. Again, it was only 10 points this time but it's important. As always, you can make poor choices as long as you discuss them intelligently.

  • Report: This was just the rest of your report - organization, implementation details, clarity, brevity. The remaining report was worth 20 points - avg score was 14.9

  • Total: Out of 100 points. I consider a 75 to be a solid A. Average was a 57.9. If you did poorly, e.g., below a 40, odds are you either bombed the test, turned the project too late or both. In which case, take me up on offers of retests. I want you guys to succeed.
  • The focus of the Treap project (besides making sure that nobody ever forgets how to do tree rotations) is in utilizing high level code - to leverage both for writing additional routines and black box testing code. The primary emphasis on this project was on testing. Interestingly enough, while black box testing is a creative challenge, so far people who did black box testing are scoring much higher than those who did detailed white box testing. (Not that I would ever restrict ANY form of testing - the black box testing was simply an important thought experiment since in the real world it's by far the most important type of testing.)

  • Project #6 is STILL live and the deadline has been extended until Wednesday.

    As you've probably figured out, a "Treap" is a revolutionary way to use randomization to keep a tree balanced in the expected case. (Naturally, the worst case would still be a linked list, but this is highly unlikely.) This assignment seems pretty straight forward.

    Assignment #6 interface
    Assignment #6


    ASSIGNMENT #5

  • Here are some sample reports from the Boggle project. They are not perfect but they struck me as above average. The reason I listed so many is because there are some people that are still giving me a "list of methods" glossary instead of summarizing their implementation in a meaningful way.

     John Wright and Colin Wragg
    Chris Agerton and John Sheu
    Matt Dewett and Chris Wiley
    Lee McCuller and Jeff Zhu
    Dan Chimene and Jeff Shi

  • Assignment #5 is now live.
    This time you have the full code base up immediately. Another piece of good news is that project 5 is actually easier than Project 4, so those of you working alone will find this one easier to bear. In fact, Project #5 is designed to be a chance for everyone to catch their breath and relax a little, with the only "karma" being the optional GUI interface.

    Assignment #5 code base.
    Assignment #5
  • The BOGGLE Project has been graded and returned, but here are some statistics and explanation of your scores

  • Testing: There were 57 machine tests worth 57 total. I considered anything above a 21 to be excellent. One god like team hit 55, coming within 1 of the all time record. Here is the histogram:


  • Analysis: This was 68 points, as for Boggle the primary focus of the entire project was analysis of your algorithms. It was important to describe the choices you made in your data structures. Avg score was 52, so you did pretty good.

  • Code: Again, this was emphasized in boggle and worth 45 points. Here, the ultimate efficiency and speed of your code was critical, even down to the time constants. As always, style and commenting was important as well. Avg was 38.6.

  • Report: This was your report outside of the analysis, which included testing, organization, etc. Worth 30 points. Avg was 25.

  • Total: 200 points, avg was 148.


    ASSIGNMENT #4 - GRADING!

    Yes, it's FINALLY here! The project that didn't get graded because I was really sick in the first half of October. The good news - this was perhaps the strongest Project ever! You guys really, really did well on Tetris, despite how incredibly long and onerous it was. So congratulations for sticking it through.

    PROJECT 4a

  • Project 4a was incredibly specific about algorithms and had a very specific test goal. Consequently, there was not a huge emphasis on reports. In fact, the primary emphasis of 4a was on not breaking encapsulation between your Piece class and your Test class (which was really a rendering class.) 50% of your project grade was machine determined correctness.

  • So rather than have a machine STRESS test, this project underwent a machine ENCAPSULATION test, which was quite simple - your two classes were tested individually. As long as they obeyed the interfaces and didn't use hidden information, they worked great. And for those that violated encapsulation, we also tested your two classes together to verify correctness. Encapsulation represented 40% of the project grade.

  • Despite having a picture of the intended result in the handout, some people did have minor errors such as not centering pieces correctly, having pieces and / or skirts upside down, missing skirts entirely, or listing pieces out of order. However, I made these kinds of errors a mere 10% of the project total.

  • 30% of your grade was the Report. Small though the report was, many groups had many interesting things to say, and several discussion points in the report were mandated by the handout. How good were your implementation details? How was your analysis? There was a big focus on speed here. Did you remember the XP log if working with a partner? Did you discuss the time you spent on each phase of the programming as per the handout?

  • The final 20% of your grade was your code. This was split between style and efficiency, and some of the efficiency was based on your description in your report.

  • Perhaps not surprisingly, this had a rather high average of 86.7%. However, there were people that had unfortunately low scores because they blew encapsulation in one or both directions.

  • Here are some model reports from <4a>:

    Adam Setapen and Thomas Jack
    Jeff Zhu and Lee McCuller
    Vincent Liu and Youngsuk Lee

    PROJECT 4b

    This project was absolutely massive, and you guys absolutely conquered it! One interesting point to make about grading, though. Many of you on this project had minor problems with the code base and had to slightly modify the interfaces to make your projects work. In addition, I had almost no available time to grade this project. The two factors fit nicely together and so I made the decision to NOT DO THE MACHINE TEST this time. Instead, programs were graded on LEVEL OF FUNCTIONALITY ACHIEVED instead of stress tests. So this means many of you might have had much lower scores.

    I also tried to be sensitive to the teams that had so many problems that they never got around to implementing the Brain and Adversary. So to keep these teams from being crushed, I made the AI portion of the assignment worth only 20% of the project grade. Teams that did truly exceptional AIs additionally received Karma points.

  • Functionality - 40%. Put simply, how far did you get in this assignment? To get full points you needed a fully working brain and adversary, and you needed to back it up with comparative testing and analysis to show how good it was. The maximum score with no AI implemented was a 20.

  • Style - 20%. As in part one, a part of this was efficient algorithms, which were especially important for the brains. Some people still lost points from uncommented code, but this project is from the past... There were no exit(1)s at this time.

  • Report - 40%. How well did you discuss your implementation details, your testing, your results? How well did you analyze your algorithms and your AI? How much time did you spend on the different parts of the assignment (as per handout)? Some people still forgot to put in XP logs, but again, this is from the past...

    So on 4b, people that actually got brains working in general got an A for the assignment. But those that never got that far in most cases weren't all that far behind. So you guys should be proud - it was truly exceptional work on a very hard assignment.

  • Here are some model reports from Project 4b: (in no particular order)

    Lee McCuller and Jeff Zhu
    Chris Agerton and John Sheu
    Adam Setapen and Thomas Jack
    Matt Dewett and Chris Wiley

  • Finally, there was an excellent report by Bryce van de Geijn and Ankur Rathi which they forgot to turn in electronically so I can't show you.

    ASSIGNMENT #4
    Yes, it's FINALLY here! The project that didn't get graded because I was really sick in the first half of October. The good news - this was perhaps the strongest Project ever! You guys really, really did well on Tetris, despite how incredibly long and onerous it was. So congratulations for sticking it through.

    PROJECT 4a - GRADING

  • Project 4a was incredibly specific about algorithms and had a very specific test goal. Consequently, there was not a huge emphasis on reports. In fact, the primary emphasis of 4a was on not breaking encapsulation between your Piece class and your Test class (which was really a rendering class.) 50% of your project grade was machine determined correctness.

  • So rather than have a machine STRESS test, this project underwent a machine ENCAPSULATION test, which was quite simple - your two classes were tested individually. As long as they obeyed the interfaces and didn't use hidden information, they worked great. And for those that violated encapsulation, we also tested your two classes together to verify correctness. Encapsulation represented 40% of the project grade.

  • Despite having a picture of the intended result in the handout, some people did have minor errors such as not centering pieces correctly, having pieces and / or skirts upside down, missing skirts entirely, or listing pieces out of order. However, I made these kinds of errors a mere 10% of the project total.

  • 30% of your grade was the Report. Small though the report was, many groups had many interesting things to say, and several discussion points in the report were mandated by the handout. How good were your implementation details? How was your analysis? There was a big focus on speed here. Did you remember the XP log if working with a partner? Did you discuss the time you spent on each phase of the programming as per the handout?

  • The final 20% of your grade was your code. This was split between style and efficiency, and some of the efficiency was based on your description in your report.

  • Perhaps not surprisingly, this had a rather high average of 86.7%. However, there were people that had unfortunately low scores because they blew encapsulation in one or both directions.

  • Here are some model reports from <4a>:

    Adam Setapen and Thomas Jack
    Jeff Zhu and Lee McCuller
    Vincent Liu and Youngsuk Lee

    PROJECT 4b - GRADING

    This project was absolutely massive, and you guys absolutely conquered it! One interesting point to make about grading, though. Many of you on this project had minor problems with the code base and had to slightly modify the interfaces to make your projects work. In addition, I had almost no available time to grade this project. The two factors fit nicely together and so I made the decision to NOT DO THE MACHINE TEST this time. Instead, programs were graded on LEVEL OF FUNCTIONALITY ACHIEVED instead of stress tests. So this means many of you might have had much lower scores.

    I also tried to be sensitive to the teams that had so many problems that they never got around to implementing the Brain and Adversary. So to keep these teams from being crushed, I made the AI portion of the assignment worth only 20% of the project grade. Teams that did truly exceptional AIs additionally received Karma points.

  • Functionality - 40%. Put simply, how far did you get in this assignment? To get full points you needed a fully working brain and adversary, and you needed to back it up with comparative testing and analysis to show how good it was. The maximum score with no AI implemented was a 20.

  • Style - 20%. As in part one, a part of this was efficient algorithms, which were especially important for the brains. Some people still lost points from uncommented code, but this project is from the past... There were no exit(1)s at this time.

  • Report - 40%. How well did you discuss your implementation details, your testing, your results? How well did you analyze your algorithms and your AI? How much time did you spend on the different parts of the assignment (as per handout)? Some people still forgot to put in XP logs, but again, this is from the past...

    So on 4b, people that actually got brains working in general got an A for the assignment. But those that never got that far in most cases weren't all that far behind. So you guys should be proud - it was truly exceptional work on a very hard assignment.

  • Here are some model reports from Project 4b: (in no particular order)

    Lee McCuller and Jeff Zhu
    Chris Agerton and John Sheu
    Adam Setapen and Thomas Jack
    Matt Dewett and Chris Wiley

  • Finally, there was an excellent report by Bryce van de Geijn and Ankur Rathi which they forgot to turn in electronically so I can't show you.

  • Quick Point About Tetris Grading - as you've all figured out by now, it usually takes me at least 2 weeks to grade a project. (And believe me, I'm not slacking off.) But with Tetris I'm trying to grade what is really 2 projects in the span of a single week. However, I wanted you to know that I'm working night and day on it and will do everything in my power to get it back to you graded by Friday morning. Thank you all for your patience.

    Base Tetris Assignment

    Project #4 had two parts and two submissions, an 'a' and a 'b'. Note that some students have found what is not exactly a bug but an inelegant and unexpected behaviour in the base JTetris.java, which is subclassed to make JAdversaryTetris.java. It concerns when commit() is called and can lead to some pretty difficult bugs. See the wiki for details. I am recommending this project base be altered for next year. (Thanks for catching it, guys.)

    Assignment #4 code base.
    Assignment #4


    ASSIGNMENT #3
  • Assignment #3 has been graded and returned. This was why your Boggle deadline was extended to Wednesday - to give you a chance to learn from your mistakes in project 3. Overall, the class of 2006 loved Critters and hit it it out of the park! The worst scoring teams still turned in a working project on time. This was the first project in which I gave extra credit for doing an absolutely outstanding job on certain aspects of the report to help offset weak areas - that's so no one sees their grade fall just because they got careless. However, there were limits to what you can make up for.

    GRADING DETAILS

    GRADING: 100 points, half code, half report (although they are intimately related.)

    Correctness (25 points) - your code was put through 22 tests executing small Critter programs and comparing the results with a base test. There was one perfect score. (See Histogram):



    If you put much effort into testing and got a low score, you might want to think carefully about your test cases and what they really were testing. Did you just test code to see "if it worked" or did you try code that went against the main development logic to find mistakes? Some code worked so poorly I was amazed you got your own critter to run.

    STYLE (25 points) - always a misnomer, this score was (technique + clarity) and included several categories - how efficient was your algorithm? How maintainable was your design from a software engineering perspective? How understandable and clear was your code? How good were your comments?

    REPORT - IMPLEMENTATION DETAILS (23 points). As one report so elegantly stated, the implementation goal of Critters was to design an efficient intermediate representation of the critter program for fast execution. Naturally, it was critical that I be able to tell HOW you did this, so this was the single more important area to describe in detail about your code. The two key categories that made up REP_IMP was the description of your base algorithm (did I have to read your code to tell what you did?) and the ANALYSIS of your algorithm. Why did you pick it? How did it compare to alternative choices? How did it fare from a software engineering or efficiency point of view? How did it satisfy the goal of the assignment to minimize execution time? Did you at least say something about your design process / tribulations that would hint at properties of your algorithm? There was a high correlation between people who didn't describe their algorithm and people who had a poor algorithm, and you can see why - they didn't think it was important enough to write about or think about.

    REPORT - GENERAL/MISC (27 points). This was made up of a dozen categories covering the rest of your report: TESTING - how did you test your code? What were your test cases? How did you design your testing software? What did you find out? (Most people who didn't have a good plan here didn't do well on the machine test.) XP-LOG: if you had partners did you follow the directions and keep an actual log? Did you mention anything about the pair programming experience? ORGANIZATION: Was your report divided into logical sections or did you keep jumping back and forth between subjects? CRITTERS: Did you remember to describe your critter logic or show that you had thought about the critter language?

    GRADE INTERPRETATION: As I mentioned, you guys did so well that you shouldn't feel bad about being low on the curve. I personally consider the curve to be a 75 as the A+/A line and a 60 to be the A/B line. IMO, people who scored below an A were simply weak in too many key areas to recover from.


  • I have just made a final update to the code base to make some of your lives easier. See further description in the Project 3 section below.
  • Assignment #3 is now live. Electronic submission is due Wednesday, October 4th at 4:00pm AT THE SAME TIME AS THE HARD COPY. We'll NEW! I have now posted additional documentation that you may well find useful for this assignment. New2! You now have the GUI world sim!
    • Here is a high level summary of this project that may help clarify your thoughts.

    Pretend there is this high level simulator that runs a Critter Battle. It manages the board and all the critters on it. On each turn of the battle, the simulator goes to each critter in turn and says "OK, Critter, what is your move?" The Critter then expresses its move at a high level by simply calling a method like "infect" - so critters think for themselves, the simulator doesn't have to.

    So what must you do? You are the critter. Notice that you are simulating the Critter, not the World. Your code must (1) correctly parse in the critter description file and store it in a convenient, non textual form for easy interpretation of its moves. (Once the critter loads, you should NOT be doing any more parsing on text - this is far too slow.) So now your code has (1) verified the input file is correct, and (2) created an internal version in symbols of the critter's program.

    Now that you've made a symbolic (non textual) representation of the critter's brain, you must act as the interpreter and RUN its logic. That is, when the world simulator asks your critter for its next move, you must traverse the critter's internally stored symbolic program correctly and select the correct action. You then signal this correct action to the Simulator by calling the corresponding member.

    When making your code, you need to test that it's really working so you need to make some simple back end that displays the functions the critter is asking to do and make sure it follows the critter's programming correctly. Also, you need to simulate situations that might come up during a world battle in order to thoroughly test the critter's logic - for example, you may have to simulate a barrier in front of the critter or an enemy near the critter to test these cases. But this does not mean you need to simulate a critter board - just make the critter think it's in each situation.

    For all this to work, your system must implement exactly the same (signatured) functions as our simulator. For example, if you implement a function Eat() but our interface uses the function eat(), then your critter simulator will fail to compile with our world simulator, and you will get a VERY low score. For this reason, just like in the real world we have provided a detailed interface document to show exactly how you should write the member functions that the Critter calls to indicate his actions in the third link below.

    NEW CUMULATIVE CODEBASE UPDATE

    The specifications for Critter, CritterSpecies, and CritterInterpreter were actually detailed in the included javadocs that came with the project, and many teams have already implemented the Critter stubs to commence with development. However, due to popular demand I have decided to supply the 3 classes (2 as interfaces) to spare some people the tedium of typing in all the subs by hand. This may annoy some of you who've already done this, but look at it this way - you guys are now almost done with the project and have lots of time to play around with Critter brains.

    NOTE: As hinted at above, you will be subclassing Critter to instrument it with testing code. We would like you to describe this instrumentation in your report and turn in your Critter test class. HOWEVER, REMEMBER that in the actual game sim, your Critter file is NOT used, so be sure not to have any Critter logic in there.

    New Assignment #3 cumulative code base.
    Assignment #3[updated]

    NEW GUI WORLD SIM TO TEST YOUR AI!

    So you've debugged your interpreter and come up with some ideas for a Critter brain. This is a fun way to see how well your critters do (although it's far more helpful in testing critters than code.)

    Instructions:
  • Unzip the proj3Gui folder.
  • Place in this folder (in the same directory as TestGUI.jar) a copy of your Interpreter.class file and any other .class files your Interpreter depends on.
  • In the species subfolder, copy in all the .cri files you wish to test.
  • Then, just double click on the jar file or in the command prompt type java -jar TestGUI.jar
  • If the command line gives a Class not found error, than you are missing some class files needed to make this all work. If everything was implemented in class Interpreter then one .class file should be sufficient.
  • If you violated the interface, then this also won't work - now's a great time to figure this out.
  • If it DOES work, a GUI window will pop up. The first thing you do is select FILE->New Simulation, and choose the Species type and amount for your battle. Your own critters should automatically appear in this menu if you put them into the included directory.

    DOWNLOAD CRITTER GUI WORLD SIM NOW
    ASSIGNMENT #2
  • Assignment #2 has been graded! You guys had a little bit harder time on this one - I can tell many of you just didn't have the time to put in on it. There were a total of 200 points this time in 3 categories:
    - Report (100 points) - this included project testing.
    . A significant part of this grade was how well you were able to explain the way your algorithm actually worked.
    - Correctness (50 points) - did your code pass the tests, and was it understandable?
    - Style (50 points) - this included how effectively you used comments in your code as well as code readability and the efficiency of your implementation. I would consider 165 to be roughly the "A" line.

    Here are two sample reports:
    Yidi Yu
    Thomas Jack

    Assignment #2
    Assignment #2 code base.
    ASSIGNMENT #1

  • Assignment #1 has been graded! And you guys should be proud - you did well. The assignment is out of 140 points [50/50/20/20] with a slight upwards curve, so a 120 is a SOLID A. The highest grade was a 133, but few people broke 130. People who got less than 120 generally did not have mediocre projects, but rather, they excelled at most things and then fell down in a few key areas. Five people turned in projects late - for three of them, it seems to have paid off.
  • Three of you (STILL!) need to figure out how to use turn in because I am missing your electronic copies! See the Wiki for your names. For the rest of you, Assignment #0 has finally worked. ;)
  • People who did Karma points on Assignment #1 - here is your chance to show off and be immediately visible by your professor and peers. We need you all to make sure you have electronically turned in your sample pictures and information. Please see the wiki for details on how we'd like you to turn in your photos so we can put them in a cherished gallery. Let's see if this class can proudly beat the reigning champions - CS315H 2004.
  • As promised, to help you, besides my special lecture last Tuesday, here are two "good" reports from Assignment #1:

    An absolutely excellent report
    More concise but very nice
  • Also, back by popular request, here is a gallery of image results from prior years. How did the Turing Scholars of 2006 compare?


    Assignment #1
    Assignment #1 code base.

    ASSIGNMENT #0


  • I thought it might be helpful to show everyone two "good" reports from Assignment #0. I'm not saying they're the best in the class, or that they hit on every area that should be in a report, but they do show that it's not size that makes a good report, but thoughtfulness:
    Short but good
    Structured and good


  • Make sure you sign up for a CompSci account! You need this to access the Microlab, and the process can take 1-2 days.

    Assignment #0 is due by 4pm Sunday, September 3rd.
    You must submit your completed code and report using the special web turnin in the Microlab.
    Note that you need a CompSci account to do this.
    Hardcopy is due by 4pm on Tuesday, Sept 5th to Gem Naivar's Office in ACES 3.422

    Assignment #0 (This is now the official version.)
    Assignment #0 code base.