graph input bug, DFS exercises

Author: lee-naish

src/algorithms/extra-info/DFSInfo.md

@@ -20,16 +20,36 @@ Geeks for Geeks Link: [**Iterative Depth First Search**][G4GLink]
 
 ## Exercises/Exploration
 
+In AIA, the coding of various graph algorithms is designed to show
+their similarity. Iterative DFS, breadth first search, Dijkstra's
+shortest path algorithm, heuristic search and Prim's minimal spanning
+tree algorithm all have *identical* top-level pseudocode - check it out!
+Can you re-write the code for this and/or for other algorithms to make
+it as simple as possible, rather than emphasising similarity?
+
 For Graph2 can you find a combination of start and end nodes so the path
 found includes all nodes in the graph?
 
+Experiment with the iterative and recursive versions of DFS. Can you
+convince yourself that, given the same graph input, they both always
+produce the same parent array output, and the parent array elements have
+their final values assigned in the same order?
+
 Both the iterative and recursive codings of DFS have the line "for each
 node m neighbouring n". For iterative DFS, the neighbours are considered
 in increasing node number order whereas for recursive DFS the order is
 reversed. Why is this done?
 
 The "frontier" nodes for iterative DFS are fairly easy to determine
-from the animation - they are the nodes in the stack that have not
+from the data structures - they are the nodes in the stack that have not
 yet been finalised.  How does this compare with the animation of the
 recursive version?
 
+Given a graph with **N** nodes, what is the maximum size of the stack?
+Hint: look at the animation for graphs that have lots of edges.
+
+How can you code iterative DFS so it uses less stack space in the worst
+case?  Hint: consider what information is on the (implicit) stack for
+recursive DFS and how that is coded.
+
+

src/algorithms/extra-info/DFSrecInfo.md

@@ -27,7 +27,14 @@ in increasing node number order whereas for recursive DFS the order is
 reversed. Why is this done?
 
 The "frontier" nodes for iterative DFS are fairly easy to determine
-from the animation - they are the nodes in the stack that have not
+from the data structures - they are the nodes in the stack that have not
 yet been finalised.  How does this compare with the animation of the
 recursive version?
 
+The (implicit) stack shown only includes values for **n** and **p**.
+In an actual implemenetation the other argument, **G**, would also
+generally be on the stack.  What additional value(s) would also be on
+the stack?
+
+Given a graph with **N** nodes, what is the maximum height of the stack?
+

src/algorithms/parameters/helpers/EuclideanMatrixParams.js

@@ -5,7 +5,7 @@
 /* eslint-disable react/prop-types */
 
 // Support for graphs with Euclidean (X-Y) coordinates defined for each
-// node. In flux currently. Student version used tables only for input of
+// node. Older student version used tables only for input of
 // graphs - lots of screen real-estate.  Also a bunch of other problems
 // and annoyances/limitations.  Now supports input of X-Y cordinates
 // and edges/weights via text boxes, plus having predefined example
@@ -238,8 +238,8 @@ function EuclideanMatrixParams({
   const [heurCalc, setHeurCalc] = useState(H_EUCLIDEAN);
 
   // (currSize) affects number of columns.
-  const columns1 = useMemo(() => makeColumnCoords(currSize), [currSize]);
-  const columns2 = useMemo(() => makeColumnArray(currSize), [currSize]);
+  const columns1 = useMemo(() => makeColumnCoords(size), [size]);
+  const columns2 = useMemo(() => makeColumnArray(size), [size]);
   // window.alert(columns.Header);
   const { dispatch } = useParam();
 

src/algorithms/parameters/helpers/Table.js

@@ -33,7 +33,6 @@ function Table({
     algo,
   }); 
 
-
   // add the header in left side of table
   let counter = 0;
   const incrementCounter = () => { counter += 1; };