CS:2820, Machine Problem 6, Fall 2015

Background: In lecture 24 on Nov. 19, we ran up against a brick wall trying to write code that called new v1.exitIntersectionEvent() (we also tried v1.new ExitIntersectionEvent()), where v1 is a specific Vehicle and ExitIntersectionEvent is a non-static inner class of Vehicle. This didn't work, so we solved the problem by moving to a static inner class, as you can see in the code posted on Dec. 1.

In Lecture 26 on Dec. 3, we solved this problem in a completely different way, although we did not apply this solution to the road network simulation.

a) Give code for the non-static version of ExitIntersectionEvent. (0.5 points)

// simulation methods for Vehicles, part of class Vehicle

class ExitIntersectionEvent extends Simulator.Event {
        /** Generic exit from any intersection, but it
         *  calls i.exit() when triggered.
         */

        ExitIntersectionEvent( float t ) {
                time = t;
                Simulator.schedule( this );
        }

        void trigger() {
                r = pickRoad( Vehicle.this, i.outgoing );
                i.exit( Vehicle.this, time );
                r.enter( Vehicle.this, time );
        }
}

b) Give code for the "crutch" that allows its initializer to be called from outside class Vehicle. (0.5 points)

// part of class Vehicle
public ExitIntersectionEvent newExitIntersectionEvent( float t ) {
        return new ExitIntersectionEvent( t );
}

c) And give the code to call the initializer from NoStops.enter(). (0.5 points)

Road d = v.pickRoad( outgoing ); 
if ( queue.isEmpty() ) {
        occupied = false;
} else {
        Vehicle v1 = queue.removeFirst();
        v1.newExitIntersectionEvent( t + travelTime );
}

The above is a rewrite of the code quoted at the start of the notes for in Lecture 24.

Note: This is mostly cut and paste work, once you figure out the necessary material. It was all covered in class.

Background: In the discussion of the concept of a hierarchy of virtual machines in the Dec. 3 lecture, it was mentioned that our road-network framework could have been divided into a hierarchy, where the top level classes in the road network were general purpose, applicable to any computation on a road network from finding the shortest path for a GPS navigation application to simulation of a road network, as we have done.

A problem: Consider all of the fields and methods in class Road. Which of these fields and methods belong in the general purpose class Road and which would belong in RoadSimulation because they are specific to a discrete-event simulation of a road? (1.0 points).

What follows is more formal than the required answer, and it duplicates some methods that belong in both. This is based on the code distributed with Lecture 17 on Oct. 27.

class Road {
        Intersection destination; //where the road goes
        Intersection source;      //where the comes from

        // initializer
        public Road( Scanner sc ) { }

        // methods
        public String toString() { }
}

class RoadSimulation extends Road {
        float travelTime;         //measured in seconds
        int population;           //how many vehicles are here

        // initializer
        public RoadSimulation( Scanner sc ) { }

        // methods
        public void enter( Vehicle v, float t ) { }
        public void exit( Vehicle v, float t ) { }
        public String toString() { }
}

Background: In Lecture 25 on Dec. 1, it was asserted that no method needs more than one parameter. In fact, following the same methodology, we can eliminate all parameters and make all methods return void. Consider the following example, based on the first code given after the heading No method needs more than one parameter:

class C {
        private int f = 0; // some field of the object
        public int m( int g, int h ) { // method m
                int t;
                t = f;
                f = g + h;
                return t;
        }
}

// somewhere else in the program
        C o;           // o is an object of class C
        i = o.m(5, 6); // apply the method C.m to o

a) Rewrite the code for class c to eliminate all parameter passing and all nonvoid return values, using transformations of the sort discussed in the lectures of Dec. 1 and 3. (0.5 points)

class C {
        private int f = 0; // some field of the object
        public int g; // parameter to m
        public int h; // parameter to m
        public int r; // return value from m
        public int m() { // method m
                int t;
                t = f;
                f = g + h;
                r = t;
        }
}

b) Rewrite the code for the call to o.m() to call your modified code from part a. (0.5 points)

// somewhere else in the program
        C o;      // o is an object of class C
        o.g = 5;  // pass first parameter
        o.h = 6;  // pass second parameter
        o.m();    // apply the method C.m(g,h) to o
        i = o.r;  // get return value

A short question: Why is a process-oriented view of simulation a poor way to think about a logic simulator? (0.5 points)

The identifiable events in the logic simulator were input and output change events for gates and wires. While we could consider the propagation of an input change to an output change as a process, it is a short-lived process, coming into being with the input change and disappearing with the output change. Furthermore, very early in the process, we eliminated half of these events by having output changes be the only events and having them directly trigger input changes. In sum, there are no long-lived active entities in a logic simulator.

Background: In the final version of the logic simulator, Gates such as and and or had inputs of the form a in1 and a in2, which made good sense, but other types of gates, not and out were more awkward, since with just one input, connecting a wire to b in seems verbose.

A question: How (focusing on object orientation) would you go about making the syntax of the destination connection wired to the input of a gate depend on the type of gate? Do not give code! Describe your design. (1.0 points)

Instead of having a method of class Wire determine the entire syntax of each wire specification, when the wire identifies the gate to which it is connecting, it should call a method of that gate to scan any required input specification and return the associated input number. For not gates, this would just return zero. For and and or gates, it would scan the input name and inspect the gate's input list.

Machine Problem 6, due Dec. 11

Solutions