Assignment 10, due Nov 10

Solutions

Part of the homework for CS:2820, Fall 2017
by Douglas W. Jones
THE UNIVERSITY OF IOWA Department of Computer Science

  1. Background: Machine Problem 5 requires, part 2, requires that you create a file called Gate.java containing class Gate and its subsidiary classes.

    a) Which of these classes must be marked as public? (0.2 points)

    Class Gate

    b) Which import directives are required? (The answer will be a subset of the list of import directives at the head of the MP4 version of Logic.java.) (0.2 points)

    import java.util.LinkedList because each output is connected to a list of wires.

    import java.util.Scanner is needed by the constructors and factories.

    This problem didn't ask for the explanations given above.

    c) Class Gate includes an abstract method, inputChangeEvent. All subclasses of Gate have outputChangeEvent methods, but class Gate does not have an abstract outputChangeEvent declaration. Why? (0.2 points)

    Because the versions of outputChangeEvent are not visible to the outside world, and they are either private to one class, as in the case of ConstGate, or they are shared by the subclasses of another subclass, as in the case of LogicGate.

    d) Which classes in file Gate.java can be declared to be final. (you do not need to do this in the code you submit code, but it is harmless to do so.) (0.2 points)

    Classes AndGate, OrGate, NotGate and ConstGate.

    The problem did not call for explanation, but these can be final because none of them have subclasses.

    e) Which methods in the abstract classes in file Gate.java can be declared to be final. (you do not need to do this in the code you submit code, but it is harmless to do so.) (0.2 points)

    In class Gate, method factory.

    In class LogicGate, methods registerOutput, outPinName and outputChangeEvent.

    In class TwoInputGate, methods registerInput, inPinName, CheckSanity and inputChangeEvent.

    Declaring a class to be final has the effect of making all of its methods effectively final, but if you listed all of the methods of classes AndGate, OrGate, notGate and constGate, this would not be wrong.

  2. Background: One of the program transformations discussed in the notes for Lecture 22 (Nov. 7) is to move method parameters to fields of an object, so you pass the parameter by assigning to the field before you call the method. In the posted solution to MP4, we used code like the following code to transfer the input value of a gate to its output:
    if (newVal != value) {
        value = newVal;
        Simulator.schedule(
            time + delay, (float t) -> outputChangeEvent( t )
        );
    }
    

    Scheduling an event that calls a method is not the same thing as calling the method directly, but we can still imagine this code as the result of applying this program transformation. In effect, we have passed a parameter to outputChangeEvent by assigning it to a field of the object and then calling the method.

    a) Give the code for the "original" version of the above code, arrived at by reversing the transformation discussed here. (0.5 points)

    if (newVal != value) { Simulator.schedule( time + delay, (float t) -> outputChangeEvent( t, newVal ) ); }

    the order of the parameters t and newVal is irrelevant. The key is the move from assignment to a field of a class to passing a parameter.

    b) As already mentioned, scheduling a method is not the same as calling it. As a result, the transformed code you gave in answer to part a) behaves differently from the code distributed in the assignment. Specifically, it behaves differently with respect to the "low pass filter" requirement of MP5. What is the difference? (0.5 points)

    Every single input change that could change the output now does change the output. Where the defective code for MP4 might have and output change from true to true to true, the modified code will change from true to false to true.

    Notes: If you take the time to understand what's going on, the answer is short! It does not solve MP5, but understanding what is going on here will probably help you with MP5. Experiment and theory may be equally effective in understanding what's going on here.

  3. Background: Look at class Gate in the posted solution to MP4. This class contains a number of Javadoc comments, but some are not very well written.

    a) Some of the elements (fields, inner classes, initializers, methods) of the class do not have Javadoc comments and ought to have them. Which? (0.3 points)

    name is a public field, so it is accessible to all users of the class and ought to be documented.

    delay is protected, so it ought to be documented to help authors of subclasses.

    b) The Javadoc comment on the factory method contains an error. What is missing? (0.3 points)

    Gate.java:43: warning: no @throws for Gate.ConstructorFailure
        public final static Gate factory( Scanner sc ) throws ConstructorFailure {
    

    c) The Javadoc comments for registerInput and inPinName ought to describe their relationship. Fix these comments so that they correctly explain their relationship. (0.4 points)

    /** tell the gate that one of its input pins is in use
     *  @param w the wire that is connected
     *  @param pinName the text of a pin name
     *  @return a pin number usable as input to inPinName
     *  @see inPinName
     */
    public abstract int registerInput( Wire w, String pinName )
    
    /** get the name of the input pin, given its number
     *  To understand the relationship betwee pin names and pin numbers,
     *  note that if n is a legal name of an input to gate g,
     *  
     *  n = g.inPinName( g.registerInput( w, n ) );
     *  
    * That is, inPinName recovers the name that was registered with * registerInput. * @param pinNumber a pin number previously returned by registerInput * @return pinName the textual name of an input pin * @see registerInput */ public abstract String inPinName( int n );

    This is only one possible way to comment this issue. Somehow, the comment must explain that inPinName recovers the name that was given by registerInput if the name was valid. There are many ways of explaining this.