CIS 22 - Simulations: Tips For Programming Simulations

    One of the first lessons a programmer must learn is that they make mistakes.  I can't tell you how many times I blamed my computer or even a compiler for a program not working properly only to find an extra semicolon two handfuls of hair later.  It is a rite of passage to become a humbled programmer, and it saves time not looking to blame something other than the image looking back at you in the mirror.  In fact, it's not only healthy to assume you made mistakes, but even healthier to assume you made mistakes and scrutinize your program and output.  With simulations, in my experience, a test of your program will consist of creating input files and executing the program, which creates output files and returns the prompt on the next line in a few seconds.  I call this the "Black Box" phenomenon.  There is no way to tell if the program is working properly.  I remember a fellow student asking me to debug his simulation, which was a Black Box.  I told him what I'm about to tell you:

 You need to see your program working, and slow it down enough to see that it is doing what it's supposed to.

Click to download an executable that's a Black Box

    Using a debugger is one solution, but for a simulation where a clock ticks seconds, where nothing may happen for ten minutes of simulation time, this would be tedious.  The solution I recommend is screen output.  Basically, place print statements all throughout your program, and as you gain confidence that a certain part is working, comment certain ones out.  This is even more powerful when you introduce pauses all over the program as well.  Personally, I like to include <stdlib.h> (for C) or <cstdlib> (for c++), and put the following throughout the program:

This will prompt the user to hit return to continue.  Initially, I tend to put them liberally in the following places:

 I know what you're thinking: "What does this do for me?"

 The answer: You need to put your print statements before each one:

Click to download an executable that's shows this approach

Here's the main section for the above link: (NOTE: I put them with no indentation so they'll be easier to remove when not needed)

#include "queue.h"
#include <cstdlib>

using namespace std;

int main()
{
    int i = 0;
    Queue q;

    for (i = 0;i < 10;i++)
    {
cout << "about to insert " << i << " on the queue" << endl << endl;
system ("PAUSE");
        q.insert (i);
        q.print();
    }

    while (!q.isEmpty())
    {
cout << "about to remove first item from the queue" << endl << endl;
system ("PAUSE");
    q.remove();
    q.print();
    }

    return 0;
}

 

    If using data structures like queues or stacks, call the print methods so you can see them working.  Actually, it's pretty cool to see them work.

Click to download an executable that's shows a queue at work (Use computer's pause feature to pause program and get snapshot)

Here's the main section for the above link:

#include "queue.h"

int main()
{
    int i = 0;
    Queue q;

    for (i = 0;i < 10;i++)
    {
        q.insert (i);
        q.print();
    }

    while (!q.isEmpty())
    {
        q.remove();
        q.print();
    }

    return 0;
}

    With these feedback mechanisms, you can witness if a low-priority person gets on front of a priority queue instead of the rear.  Right away you know what's wrong, and can address it accordingly.  A Black Box situation would never let you hone in so quickly.

    Another tip is to plan-out your simulation strategy with pencil and paper before coding a line.  Simulations, by their very nature, have events that occur in a specific order, and can be overwhelming to think about in an instant.  But after a few hours with a cup of coffee, the algorithm will present itself.  At this point, it's safe to code, knowing your game plan.  Too many beginner programmers wait for the starting gun and start coding.  These same people will be debugging their programs for hours while an experienced programmer who wrote pseudo code will be much better off, having planned ahead.

    With these tips, I think you'll be able to quickly create and debug your programs.  As you've probably guessed, these tips apply to any programming project.  Good luck!!!

Thomas Erno, 2003

Back to CIS 22 home page