X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=implementing_trees.mdwn;h=f83823a92d126cfb0ebab4c1fcc718d8b4e696f3;hp=31dc3fd01cadcf915d08d22352f554dbb4cf22b9;hb=0a79dd27b99169648a1f03ec0b8847a1c5b822fc;hpb=a4c3bd5c0bcebbd8f550ec6f6033f16f98cd2a8e

diff --git a/implementing_trees.mdwn b/implementing_trees.mdwn
index 31dc3fd0..f83823a9 100644
--- a/implementing_trees.mdwn
+++ b/implementing_trees.mdwn
@@ -128,9 +128,9 @@ where the previous tree should be placed.
 
 However, when using trees as a computational tool, one usually does have
 latitude about how to structure a larger tree---in the same way that we had the
-freedom to implement our sets with lists whose members were just appended in
-the order we built the set up, or instead with lists whose members were ordered
-numerically.
+freedom to implement our [sets](/week4/#index9h1) with lists whose members were
+just appended in the order we built the set up, or instead with lists whose
+members were ordered numerically.
 
 When building a new tree, one strategy for where to put the new element and
 where to put the existing tree would be to always lean towards a certain side.