Fairer intersections

In this text, an attempt is made to present a simple (the simplest?) version here, and to wait with improvements until Part III. In this section, there will be an exception: The modification presented here is not strictly necessary. Not including it does, however, result in strong artifacts and asymmetries in the traffic dynamics.

A disadvantage of the above code for intersection movement is that certain incoming links always get served earlier than others. A useful way to improve the situation is to go through the incoming links in random sequence. This can be achieved by

{}
    typedef multimap<double,Link*> RndLinks ;
    RndLinks rnd_links ;
    // go through all inLinks, give them a random number, and insert
    // them according to it:
    for ( VLinks::iterator ll=inLinks_.begin(); ll!=inLinks_.end(); 
          ++ll ) {
        Link* link = *ll ;
        rnd_links.insert( make_pair( myRand(), link ) ) ;
    }
    // retrieve the inLinks in the order of their random numbers:
    for ( RndLinks::iterator ll = rnd_links.begin(); 
          ll != rnd_links.end(); ll++ ) {
        Link* inLink = ll->second ;

and then continue as above.

The above algorithm goes through all incoming links and gives them a random number and then inserts them into the multimap using the random number as key. A multimap is similar to the map we used for links and nodes with the only difference that keys do not have to be unique; this is necessary since it could happen that two random numbers are identical. The links are then taken out of the multimap in increasing order of the random number.