diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7ef8ce42..d2d13b68 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -4,6 +4,7 @@ Change Log / Ray Tracing in One Weekend
 # v4.0.2 (in progress)
 
 ### Common
+  - Fix    -- Fixed some dangling references to `random_in_unit_sphere()` (#1637)
 
 ### In One Weekend
   - Fix    -- Fix equation for refracted rays of non-unit length (#1644)
diff --git a/books/RayTracingInOneWeekend.html b/books/RayTracingInOneWeekend.html
index 63c3ec82..79c10876 100644
--- a/books/RayTracingInOneWeekend.html
+++ b/books/RayTracingInOneWeekend.html
@@ -2344,7 +2344,7 @@
         }
     }
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-    [Listing [random-in-unit-sphere]: <kbd>[vec3.h]</kbd> The random_unit_vector() function, version one]
+    [Listing [random-unit-vector-1]: <kbd>[vec3.h]</kbd> The random_unit_vector() function, version one]
 
 </div>
 
@@ -2369,11 +2369,11 @@
         }
     }
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-    [Listing [random-in-unit-sphere]: <kbd>[vec3.h]</kbd> The random_unit_vector() function, version one]
+    [Listing [random-unit-vector-2]: <kbd>[vec3.h]</kbd> The random_unit_vector() function, version two]
 
 <div class='together'>
-Now that we have a random vector on the surface of the unit sphere, we can determine if it is on the
-correct hemisphere by comparing against the surface normal:
+Now that we have a random unit vector, we can determine if it is on the correct hemisphere by
+comparing against the surface normal:
 
   ![Figure [normal-hor]: The normal vector tells us which hemisphere we need
   ](../images/fig-1.13-surface-normal.jpg)
@@ -4042,7 +4042,7 @@
 
 Since we'll be choosing random points from the defocus disk, we'll need a function to do that:
 `random_in_unit_disk()`. This function works using the same kind of method we use in
-`random_in_unit_sphere()`, just for two dimensions.
+`random_unit_vector()`, just for two dimensions.
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
     ...
diff --git a/books/RayTracingTheRestOfYourLife.html b/books/RayTracingTheRestOfYourLife.html
index 42e6df8d..e860ecb0 100644
--- a/books/RayTracingTheRestOfYourLife.html
+++ b/books/RayTracingTheRestOfYourLife.html
@@ -69,12 +69,12 @@
 will take to get there. The classic example of a Las Vegas algorithm is the _quicksort_ sorting
 algorithm. The quicksort algorithm will always complete with a fully sorted list, but, the time it
 takes to complete is random. Another good example of a Las Vegas algorithm is the code that we use
-to pick a random point in a unit sphere:
+to pick a random point in a unit disk:
 
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C++
-    inline vec3 random_in_unit_sphere() {
+    inline vec3 random_in_unit_disk() {
         while (true) {
-            auto p = vec3::random(-1,1);
+            auto p = vec3(random_double(-1,1), random_double(-1,1), 0);
             if (p.length_squared() < 1)
                 return p;
         }
@@ -82,7 +82,7 @@
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     [Listing [las-vegas-algo]: <kbd>[vec3.h]</kbd> A Las Vegas algorithm]
 
-This code will always eventually arrive at a random point in the unit sphere, but we can't say
+This code will always eventually arrive at a random point in the unit disk, but we can't say
 beforehand how long it'll take. It may take only 1 iteration, it may take 2, 3, 4, or even longer.
 Whereas, a Monte Carlo program will give a statistical estimate of an answer, and this estimate will
 get more and more accurate the longer you run it. Which means that at a certain point, we can just