Remove colour attributes from body and strip most of the font tags out

This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions

View file

@ -24,7 +24,7 @@
<!--CHAPTER=59//-->
<!--PAGES=1107-1110//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -36,13 +36,13 @@
</TABLE>
</CENTER>
<P><BR></P>
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Inorder Walks of BSP Trees</FONT></H3>
<H3><A NAME="Heading8"></A>Inorder Walks of BSP Trees</H3>
<P>It was implementing BSP trees that got me to thinking about inorder tree traversal. In inorder traversal, the left subtree of each node gets visited first, then the node, and then the right subtree. You apply this sequence recursively to each node and its children until the entire tree has been visited, as shown in Figure 59.9. Walking a BSP tree is basically an inorder tree walk; the only difference is that with a BSP tree a decision is made before each descent as to which subtree to visit first, rather than simply visiting whatever&rsquo;s pointed to by the left-subtree pointer. Conceptually, however, an inorder walk is what&rsquo;s used to traverse a BSP tree; from now on I&rsquo;ll discuss normal inorder walking, with the understanding that the same principles apply to BSP trees.
</P>
<P>As I&rsquo;ve said again and again in my printed works over the years, you have to dig deep below the surface to <I>really</I> understand something if you want to get it right, and inorder walking turns out to be an excellent example of this. In fact, it&rsquo;s such a good example that I routinely use it as an interview question for programmer candidates, and, to my astonishment, not one interviewee has done a good job with this one yet. I ask the question in two stages, and I get remarkably consistent results.</P>
<P>First, I ask for an implementation of a function <B>WalkTree()</B> that visits each node in a passed-in tree in inorder sequence. Each candidate unhesitatingly writes something like the perfectly good code in Listings 59.2 and 59.3 shown next.</P>
<P><A NAME="Fig9"><!-- </A><A HREF="javascript:displayWindow('images/59-09.jpg',112,194 )"> --><IMG SRC="images/59-09.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/59-09.jpg',112,194)"> --><FONT COLOR="#000077"><B>Figure 59.9</B></FONT></A>&nbsp;&nbsp;<I>An inorder walk of a BSP tree.</I>
<BR><A HREF="javascript:displayWindow('images/59-09.jpg',112,194)"> --><B>Figure 59.9</B></A>&nbsp;&nbsp;<I>An inorder walk of a BSP tree.</I>
</P>
<P><B>Listing 59.2 L59_2.C</B></P>
<!-- CODE //-->
@ -89,8 +89,7 @@ struct _NODE *pRightChild;
<P>And then I sit back and squirm for a minimum of 15 minutes.</P>
<P>I have never had <I>anyone</I> write a functional data-recursion inorder walk function in less time than that, and several people have simply never gotten the code to work at all. Even the best of them have fumbled their way through the code, sticking in a push here or a pop there, then working through sample scenarios in their head to see what&rsquo;s broken, programming by trial and error until the errors seem to be gone. No one is ever sure they have it right; instead, when they can&rsquo;t find any more bugs, they look at me hopefully to see if it&rsquo;s thumbs-up or thumbs-down.</P>
<P>And yet, a data-recursive inorder walk implementation has exactly the same flowchart and <I>exactly</I> the same functionality as the code-recursive version they&rsquo;ve already written. They already have a fully functional model to follow, with all the problems solved, but they can&rsquo;t make the connection between that model and the code they&rsquo;re trying to implement. Why is this?</P>
<H4 ALIGN="LEFT"><A NAME="Heading9"></A><FONT COLOR="#000077">Know It <I>Cold</I>
</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading9"></A>Know It <I>Cold</I></H4>
<P>The problem is that these people don&rsquo;t understand inorder walking through and through. They understand the concepts of visiting left and right subtrees, and they have a general picture of how traversal moves about the tree, but they do not understand exactly what the code-recursive version does. If they really comprehended everything that happens in each iteration of <B>WalkTree()</B>&mdash;how each call saves the state, and what that implies for the order in which operations are performed&mdash;they would simply and without fuss implement code like that in Listing 59.4, working with the code-recursive version as a model.</P>
<P><B>Listing 59.4 L59_4.C</B></P>
<!-- CODE //-->
@ -180,7 +179,7 @@ void WalkTree(NODE *pNode)
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->