SSP Programme 2001 - Presentations

This years presentations will take place in the CP Lab - Room 3203. Here is the schedule of times, speakers and titles/abstracts.

Although we have scheduled 30 minutes for each speaker, we will `expect' that each presentation will not take much longer than 20 minutes. Speakers are `encouraged' to use electronic presentation of their slides, although an `old-fashioned' overhead projector is available. Hand-written slides are strongly *discouraged*.

A few points to remember when preparing these short presentations:

1. Don't overcook the slides! 10 slides will probably be better than 20.
2. Don't say too much.
3. Don't say too little.
4. Keep the maths to a minimum - qualitative descriptions are better for a mixed audience.
5. Don't use too many colours.
6. Don't use too many fonts.
7. Don't use text which is too small to be read from the back of the room.
8. Keep diagrams/charts/graphs/tables/illustrations simple wherever possible.
9. Where it makes sense to do so, re-use material from your poster and report (that's a none too subtle reminder that you also have a poster and a report to prepare).

• Jinigrid, what it was meant to do, and why it didn't, a short explanation of six weeks.
• The proposed ALife demonstrator's aims and how to meet them.
• Rendering the virtual world.
• How the environment affects the world.
• The plants.
• The creatures.
• Programming problems.

• A look at a Fortran implementation
• The Class model and Java code
• Difficulties and drawbacks (or comparing the Fortran and Java implementations)

1. presenting collective and point-to-point communications with envelopes traveling from process to process
2. converting to Swing from AWT
3. increasing independency of the beans comprising the applet and as such more general and reusable code
4. possibility of saving programs
5. choosing the number of processes the applet simulates
6. providing user help windows (not implemented yet)

1. Digital image capture for machine vision applications usually employs high-end expensive equipment to get the best possible images to work with. This project uses the departmental digital camera which can be bought relatively cheaply on the high street. Ways of overcoming poor quality captured images will be briefly discussed.
2. A small but growing number of image operators and filters have been implemented in Java for the project. The more operators that are available; the better the chance of manipulating a captured image into showing something useful. A few of these algorithms are discussed where they are particularly important to the MOCHA application.
3. This project has concentrated on using the Hough transform for pulling information out of a digital image. The classical Hough transform will be explained followed by its development into the general Hough transform. The classical Hough transform can detect any straight lines within an image. The general Hough transform is capable of detecting the presence of any arbitrary shape in a digital image. The Hough transform works in the presence of a possibly large amount of image noise.

1. Extend the back-end to include Lomond and Bobcat among the HPC service providers.
2. Integrate more software packages into the system.

Webpage maintained by mario@epcc.ed.ac.uk