Notes on UROPs and HYPs

Last updated on: Tue Mar 6 12:01:01 GMT-8 2007

This was written during my first year at SoC, and the first time I had to review UROPs and HYPs. I have made some observations about this process that I think might be useful for students. Your comments and constructive criticism are welcome. N.B. - These are my personal comments and observations and should not be construed as any official position by NUS or SoC.

During that year (Semester II, 2003), the grading process took the form of a poster session. Students were given 30 minutes to discuss with two examiners. Students prepared an A1-sized poster of their work and answered questions about their work. Demonstrations were carried out as necessary. Grading works such that a student's project supervisor did not have any direct influence on the project grading; rather, the advisor was free to offer assessments to the examiners, but the assessment did not need to be taken into account.

You may also want to review some notes on how to begin to do research as part of your HYP and UROP. If you want do a project related to the Web or eventually working for Google, you might consider working with me and my group or WING. If you're thinking of doing your HYP with me, please read how I select and rank candidate students at the bottom of this page.

1. Notes about doing your HYP in the course of the year.
   • Demonstrate initiative. One thing that looks particularly good to examiners is to hear from their supervisors that the HYP/UROP student was independent and motivated to do work. Less supervision from your project advisor means that you are capable of taking the problem and running with it. Over the course of your project, you should demonstrate to your advisor that you can do many things on your own and take the initiative to find background reading, appropriate techniques and datasets.

   • Evaluate properly. If there are accepted ways of evaluating your work, make sure you use them. If there are other results in the literature that are comparable, re-print them. If there are other results that aren't compatible, list them and explain why they aren't comparable.

   • Balance your workload throughout your year. Try not to tail off after doing a lot of work at the beginning, and don't try to rush to finish things at the end of the semester towards the presentation. Many projects require adequate background knowledge to do properly. In many cases you'll need to spend a sizeable portion of time to acquire that knowledge. The summer before the official start of the project is a particularly good time to get this base covered and to start working on the project.

     Also try to balance your workload per semester. Many students like to load their remaining modules in Semester 1 and leave Semester II mostly for the HYP. This may sound like a great idea, but in many fields it is not particularly good, as research conference deadlines are usually at the end of Semester 1. Converting your research into a research paper submission (and possible acceptance) in the problem area looks remarkably good to both HYP grades as well as graduate schools and recruiters.

   • Learn software to support your HYP. There are also a number of things you'll typically have to deal with in project work. If you haven't already, learn how to use CVS/subversion to deal with code revisions and backup. I advise my students to use a Unix working environment and also to learn LaTeX for formatting and writing their thesis.

2. Notes about the thesis and thesis writing.
   • The thesis itself is a document that is limited in size. The more succinct your thesis the more likely your reader will actually examine it. If it's not main material, you can always move it to an appendix. That shows that you know how to prioritize and save your reader time.

     (Updated: Mar 07) I still hear from students who are anxious that their thesis is not "long enough". There is a difference between having too little material to present versus structuring and editing your thesis to be succinct. Bottom line: gobs and gobs of unedited text isn't going to do any favors to you or help your evaluator. Make sure you save time to edit your work.

   • Get your papers proofread. The thesis may actually be read by your committee members. It's embarassing to have your scientific contributions that your modules have had obscured by poor English or incorrect grammatical use. Yes, your evaluators will try to be objective and not take these factors into consideration (past the marks allocated for it). But there's really not much excuse for having your thesis not spell checked and read by others first.

     Let me put it this way: would you want to bug your friends for help (and possibly an in-kind review of their thesis) rather than have a disgruntled professor do it for you?

   • In general, examiners don't have time to review your code. But you still want to let them know about the time and complexity of the coding task that you were assigned to do. Give them a good idea of the overhead you've incurred or the time that you've consumed in creating your demo or workable code. This goes with both code (in KLoCs for example) as well as for prototypes, initial approaches tried that may not have made it into the final project/implementation.

   • Tell the examiner about the competing work. There's anyways prior relevant literature and work. My advice is to start taking notes on the papers you read right at the outset of your project. You need to cite competing approaches and to properly evaluate the work against them.

   • Your examiners will be assessing your projects, but they may be unfamiliar with the area, and may not know what is considered new and novel and what is considered dry and done. You need to differentiate and distinguish your work from others. After reading the abstract, introduction and conclusion of your thesis, the examiner should know at a high-level what the 3 to 5 contributions you've made.

3. Notes about the presentation session. From what I understand it used to be an actual presentation of work. With the poster session, certain things have changed and are still changing, but these are some observations I have noted during this last HYP review:
   • You have to check out Dr. Terence Sim's observations on giving a technical presentation. If you have time, watch the webcast also (only for people in NUS)

   • Go to a HYP/UROP poster presentation session, especially when other students are defending their thesis. Note what makes a good demo or poster session. Note how questions can be diplomatically answered and how they can be concise. An answer to a question does not necessarily have to be very long. If you're not sure you understand the question, instead of asking to repeat the question, you can try to paraphase it back to the examiner to see wehther you've understood it correctly.

   • Accurately gauge the level of expertise an examiner has in your project. If your evaluator hasn't read the thesis before seeing you, then you have a chance to give that 15-minute spiel that you have prepared. However, if she's read the thesis in detail or asks you one or two questions early on that demonstrates she understands it well, you may want to move quicker or jump directly to answering questions.

   • There are some nice ways to structure your poster for presentation. You can look at past pictures of HYPs or UROPs to see how they've structured their posters. There are also some excellent guidelines for creating posters from the web.

   • (updated Mar '07) A demo is sometimes a double-edge sword. It may be nice to show results visually or demonstrate that you have a working solution but it also significantly detracts from time that your examiners can be asking you more pointed questions about your projects. If you do demo, make sure that it is not gratuitous. Conversely, don't worry if you don't have a demo; in most cases, a demo is not a suitable presentation method.

Certain projects that I offer often have multiple students coming to inquire about them. How do I (and possibly others) decide which to choose? Here are some criteria:

1. Your availability: This is a primary concern for me. Are you going to be around during the summer? Are you planning to go overseas for a semester? How much coursework do you have left to do in the final year? The more time you have available to HYP, the higher the likelihood you can do something substantial. Certain project require a substantial time commitment in terms of learning the necessary prerequisites.
2. Previous research work: If you are part of the USP or special programme, or have done a UROP, you'll be more experienced with how to do research. Coming up with a suitably structured problem and hypotheses is difficult, writing a thesis for the first time is difficult; so the more experience you have here the easier it will be for you.
3. Requisite knowledge: For certain projects, you will be required to know some prerequisite knowledge. Practically all my projects require familiarity with CS 3243 Foundations of Artificial Intelligence.
4. Initiative and personality: This I can only determine in the interviews. It's a two way street: you'll want to interview with various potential supervisors to see whom you feel most comfortable with.
5. CAP: This doesn't tell me about your research ability but it helps me ascertain how much time you need to spend on coursework. The higher, the less time I will have to worry about your coursework, and thus the more availability you'll have for project work (see point #1)

Min-Yen Kan <kanmy@comp.nus.edu.sg>

Created on: Mon Apr 21 18:25:47 2003 | Version: 1.0 | Last modified: Sat Feb 23 17:28:21 2019

This document, hyp.html, has been accessed 309 times since 25-Jun-24 11:57:13 +08. This is the 1st time it has been accessed today.

A total of 191 different hosts have accessed this document in the last 181 days; your host, 3.136.17.195, has accessed it 1 times.

If you're interested, complete statistics for this document are also available, including breakdowns by top-level domain, host name, and date.