====
Is it ok if my basic algorithm always moves packets vertically before
horizontally? It's the opposite, but I don't see any real difference...I
certainly could do it the original way, but it's more natural in my code
to do it the opposite way.

Since we're only concerned with the average time it takes for a node
to be delivered...is it ok if the standard deviation to be big, so that
some nodes will wait longer (but eventually will make it),
while others get delivered faster.

Could you elaborate on what would be needed to get the full 10 extra
credit points? How much faster should we try to make our algorithm
compared to the basic one? The "elegance" and "implementation" part don't
really make any sense. If it's a fast algorithm, how can it not be elegant
and a good implementation. Are you expecting us to minimize "real
time" running time as well?
====

These are some very good questions.

I'm not sure why it's more natural for you to implement
the vertical then horizontal algorithm, but I'll trust
that it's somehow easier.  I'd prefer if you stick to the
original description of the algorithm (horizontal, then vertical).
It will make it easier to grade if all 30 or so projects
implement the same algorithm.

Although we are interested in fast average times, we are
also interested to some degree about "fairness" (i.e.,
packets should get some fair opportunity to advance
eventually).  Remember, we are trying to simulate a
"real" environment, and so we want packets to eventually
make it to their destinations.

You do NOT want to implement an algorithm where 1,000,000
packets get delivered fast but the central queues of the
nodes in the network contain lots of packets that have
been there the whole time.  In fact, I am considering making
that part of the average delay computation: not only will
we use the delivery time of the 1,000,000 delivered packets,
but we will also use the time in the system of those packets
that are still left in the system after the 1,000,000 packets
have been delivered.  Let me think about it more before you
change your simulators.

Something I didn't mention in the handout is that although
every "time step" is just one unit for our purposes, in
real life, the actual time the time unit represents would
depend on how simple the algorithm is.  For example, since
the dimension order algorithm is simple, a small amount
of hardware would be needed to implement it, and so the time
associated with one time unit for that algorithm is relatively
small.  (This is why the dimension order algorithm is used
in practice.)

In contrast, suppose we had a really complicated algorithm
that computed all sorts of things before deciding what
packets should be assigned to neighboring vertices.  In that
case, the time unit would be long and it probably wouldn't
be a good algorithm to actually use (even though the average
delivery time in our abstract time units is small).

So, that's why the "elegance" and "implementation" are
important for this assignment.

It would be great if we could somehow predict how long a
hardware implementation of the routing algorithm would take
based on how long the software simulator takes to run, but
there is no easy way to correlate the two, since the hardware
implementation is essentially a parallel program (all nodes
are executing simultaneously and operations within a node
can happen simultaneously), whereas our simulator is a
sequential one.

As for how the bonus points will be awarded, there
will some degree of subjectiveness.  A simple yet fast
algorithm will be a likely candidate for bonus points.
(This is one reason why you want to build you simulator
so that it is flexible enough to implement several
routing algorithms.)

Think of the bonus points for this project as being the
BattleBots contest for CSE326.

I'll send some more e-mail this weekend concerning
some more issues about the project.

-- Donald