Warning This class is being recorded (and transcribed) (assuming Teams succeeds).
Approximate overview
Academic
Cultural
Peer
Wellness
Misc
A report from conversations with Sam’s therapist.
Can you explain marked?
Many graph algorithms require you to mark the vertices as part of the algorithm.
For example, a typical traversal of the graph will require us to visit vertices and, at at each vertex, add its neighbors to the list of things we want to traverse.
But we don’t want to visit a vertex more than once. So we need a way to keep track of the ones we’ve traversed already.
Although people could do this by hand, the designers (Sam) decided it should be part of the
Graphclass.
Plus, it’s a fun way to play with bytes.
What’s the underlying representation?
We use arrays to keep track of the vertices. Internally, we think of a vertex as a number.
One array maps vertex numbers to vertex names.
vertexNames.
For going backwards (from Name to number) we use a hash table.
Another array map vertices to all the edges eminating from that vertex. That’s called
vertices.
We hide it from the client by providing lots of utility methods.
What’s this failFast thing? (Or what have you observed?)
“Sam, tracing code that relies on multiple assumptions is hard!”
Goal: We want
to fail quickly, rather than later.
Background: Every time we modify the graph, we update
this.version.
It’s helpful to know how many times we modify the graph.
If we’re iterating the graph and the graph changes, we probably need to signal that to the client.
Each iterator has it’s own information about the version that was current when it was created.
failFastcompares that to the current version and throws an exception if they aren’t the same.
Followup: Won’t this.version change, so we won’t know?
Sam is insufficiently creative. Sam chose the same field name for the iterators and the graph. In both cases, it’s
version.
In the iterator,
this.versionrefers to theversionfield associated with the iterator.
In the graph,
this.versionrefers to theversionfield associated with the graph.
How do we interpret the word this?
It always corresponds to the object’s class.
For an anonymous inner class, it’s the anonymous class.
What if we want to refer to a field in the class that encloses the anonymous inner class?
ClassName.this.fieldName.
Can you explain this code?
public Iterable<Edge> edges() {
return () -> {
return new Iterator<Edge>() {
...
}; // new Iterator<Edge>
};
} // edges()
return new Iterator<Edge>()builds a iterator using anonymous inner classes.
Anonymous inner classes are designed for the situations in which we just need one-off classes that might reference the enclosing class.
Conveniently,
Iterableis a functional class. That is, it has only one required function.
When you have a functional class, you can use a lambda to build an object in that class. (It’s a simpler syntax that aic.)
Why did Sam make
edges()return anIterablerather than anIterator/
O: Obnoxious? Object-oriented? (NOpe)
You can use the for-each syntax with Iterables but not iterators.
WIth the current design, we can write
for (Edge e : g.edges()) {
...
} // for
With the iterator design, we’d have to write something like
``` Iterator edges = g.edges(); while (edges.hasNext()) { Edge e = edges.next(); … } // while
Isn’t the new dump implemented already?
Um, yes. It appears that I screwed things up in updating the
Graphrepo for this semester.
Skipped.
Yay! It’s time for LIA! (Layout, Implementation, Analysis)
TPS: How would you store a graph?