SE250:March 31

From Marks Wiki
Revision as of 05:18, 3 November 2008 by Mark (Sọ̀rọ̀ | contribs) (5 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

SE250 agenda and minutes for Monday 31 March 2008

  • Scripting a screencast
  • Lab 4 overview
  • Access card for computer science labs?

Minutes

Minute taker: Jsmi233 16:56, 29 March 2008 (NZST)

Scripting a screencast

Deadlines are needed for an incentive for completing screencasts.

Everyone must hand in one screencast by Monday (7 April).


A handout was distributed regarding screencasts.

 Scripting a screencast
 
 * What point is the screencast going to make?
 *  How can the point be made most effectively?
 	- program source code
 	- program output
 	- static diagrams
 	- dynamic diagrams
 	- graphs
 	- tables (e.g. spreadsheet)
 * You don’t need to use all of these props all the time
 * Aim to produce the shortest screencast sufficient to make the point
 
 
 Topics
 
 * How come memory was exhausted when the growth factor was 12, but not 14 or 16?
 * With printf(“Size = %d\n”, arraylist_size), why is the size always large and always the same?
 * Why does the program crash when the growth factor is 1.0 (or 0.5, etc.)?
 * How can you tell whether the program crashed, or just ran out of memory?
 * Why is calling realloc() a good idea in general, but a bad idea for the timing experiments?
 * What is the shape of the curve for incremental growth and front insertion?
 

Discussion of writing screencasts

  • Why does the program crash when the growth factor is 1.0 (or 0.5, etc.)?

A diagram could be useful - draw chunks of memory.

Show some program code comparing different growth sizes. For instance, the method ensure_capacity() in “arraylist.c”. Show the original version with growth factor = 2. Edit the growth factor to 0.5. Compile and run.

Show something on geometric progressions as background information. a/(1-r), where r = growth factor.

Screencasts don’t need to have program code, there are other ways to explain concepts, for instance, the elephant analogy (ask Rick =P). Analogies can be dangerous, be careful to ensure that there is a strong connection to the concept being explained.

  • How can you tell whether the program crashed, or just ran out of memory?

Show task manager with the physical memory skyrocketing. Also show code for a program which burns memory.

Visual studio: -debug box. Visual studio does different things depending whether the program crashed or ran out of memory. You can use a static image rather than a movie.

With screencasts, shorter is better.

  • Why is calling realloc() a good idea in general, but a bad idea for the timing experiments?

Run some code -> produce some tables/graphs

Compare graphs with and without realloc()

Running the code isn’t necessary – just show the output – the graphs.

Once it has been shown that there is a difference between using realloc() and using malloc(), an explanation could be provided.

Could use a diagram showing realloc’s behaviour.


Screencasts don’t need to be perfect. There may be a need to revise some screencasts, unless there are already enough other screencasts on the topic.

You Tube is a possibility for hosting screencasts, although it is rather low-res. There are a variety of alternatives to be found on the internet. Screencasts can be emailed to John Hamer or brought to his office on a memory stick, so that he can upload them to the wiki.


Access cards

There is a difficulty with getting into the CompSci labs in the weekend. The problem with this is the software in the engineering labs is not the same. For people coming during the weekends, check the ground floor, first floor and second floor CompSci labs since only one may be open.


Tomorrow’s Lab

Lab tomorrow will be on the linked list code. We have already looked at the code for printing this linked list. There will be a variety of utility functions. The lab will involve writing more functions and other linked list related activities.