Assignment 3, due Sep 8

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

Background: In the lectures for this week, our description of a road network assumes that all roads into a particular intersection are interchangable. In fact, this is not true. Coming into the intersection of Iowa Avenue and Madison St. from Iowa Avenue, there are 3 lanes, a right-turn lane, a left turn lane, and a center lane that can turn either right or left. This means that the lane you enter the intersection on matters because it determines the choice of lanes you have when you exit the intersection.
Thus, the file describing a road network must state not merely that road a leads to intersection b, it must state which incoming lane of that intersection it connects to. For example, we might say that road a leads to the eastbound right-turn lane of intersection b.
Similarly, while and, or and exclusive or functions are symmetrical, other functions such as the and not function discussed in the previous homework are not. For such functions, we cannot just say that a wire connects to a gate, we must state which input to that gate it connects to. So we might say that wire a connects to the inverting input of gate b.
A Problem: Suggest a syntactic notation allowing you to write the fact that a road leads from a specific outgoing lane of one intersection to a specific incoming lane of another (a similar notation could connect a specific output of one logic gate to a specific input another). (0.5 points)
There is no one solution to this problem, but consider the following example notations as reasonable solutions for describing a road from lane y of intersection x to lane w of intersection z:
- road x.y z.w
- road x[y] z[w]
Background: Now consider the problem of representing, inside the computer, a connection from a road to or from a particular incoming connection to an intersection. There are numerous solutions! First consider going perhaps a bit overboard and having a separate object for each lane in and out of an interesection. Where we used to have just one intersection object, we how have a constellation of objects, one central one for the intersection itself, and one for each lane in and out of that intersection.
A Problem: How would this change the definition of class Road. Concentrate on changes to the data, ignore changes in the methods. (0.5 points)
Given that an intersection now has lane objects corresponding to each lane in or out of that intersection, roads now link lanes to lanes, and we leave it to each lane object to determine what intersection it is part of. So, class Road will now look something like this:
```
class Road {
    float travelTime;         //measured in seconds
    Lane destination;         //where the road goes
    Lane source;              //where the comes from
    ...
}
```
Background: As mentioned above, there are many solutions. Now, consider trying to avoid creating multiple objects for each intersection. It is just one intersection, with an array of incoming lanes and an array of outgoing lanes. Each array is indexed by lane number. Incoming and outgoing lanes may have textual names, but once a connection is made from a road to an intersection, lane numbers are used.
A Problem: How would this change the definition of class Road. Concentrate on changes to the data, ignore changes in the methods. (0.5 points)
Where we used to just refer to an intersection, we must now refer to an intersection and the array index.
```
class Road {
    float travelTime;         //measured in seconds
    Intersection destination; //where the road goes
    int dstlane;              //lane number of the destination
    Intersection source;      //where the comes from
    int srctlane;             //lane number of the source
    ...
}
```
Background: Java Scanner objects have lots of methods associated with them.
A Problem: List all of the Scanner methods that can be used to pick successive numeric values from the input stream. (0.7 points)
- nextBigDecimal()
- nextBigInteger()
- nextBigInteger( int radix )
- nextByte()
- nextByte( int radix )
- nextDouble()
- nextFloat()
- nextInt()
- nextInt( int radix )
- nextLong()
- nextLong( int radix )
- nextShort()
- nextShort( int radix )
Background: The notes for Lecture 6 suggest having a call to Errors.fatal() if there are extra arguments, but the code doesn't tell the user about the extra arguments it found. In contrast, the call to Errors.fatal() given for a file that can't be opened gives useful feedback.
a) Suggest simple code for the error message for extra arguments that shows the first extra argument. (0.4 points)
```
Errors.fatal( "Unexpected extra argument: " + args[1] );
```
b) Briefly explain why part a above only asked for the first extra argument. (You might try working out the code you'd have to write if you wanted the message to show all the extra arguments, but do not turn in this code, just explain what about that code made it unappealing in this context.) (0.4 points)

It is very easy, knowing that there is at least one extra argument, to get the text of that argument. The code to print all of the extra arguments, in contrast, would involve a for loop to concatenate the successive extra arguments into a temporary variable before concatenating this with the error message text. Given that this is only an error message where the extra information is of little value to the user, this is not worth the effort.