diff --git a/README.md b/README.md
index 2715671..dc934cf 100644
--- a/README.md
+++ b/README.md
@@ -18,8 +18,12 @@ information to create visual representations of exactly *where* and *how* CPytho
[specializing, adaptive interpreter](https://peps.python.org/pep-0659/)
optimizes your code.
+
+
+
+
Installation
------------
@@ -111,8 +115,12 @@ $ specialist conversions.py
After the script has finished running, `specialist` will open a web browser and
display the annotated program source:
+
+
+
+
The green areas indicate regions of code that were successfully specialized,
while the red areas indicate unsuccessful specializations (in the form of
"adaptive" instructions). Mixed results are indicated by colors along the
@@ -129,14 +137,22 @@ It can, however, specialize addition and subtraction between two `float` values!
Replacing `32` with `32.0` results in successful specializations (confirmed by
re-running `specialist`):
+
+
+
+
We can see that something similar is happening with `float` and `int`
multiplication as well. One option could be to continue converting constant
values to `float`:
+
+
+
+
However, there's a better option! Notice that CPython doesn't attempt to
specialize division at all (it's left white in the visualization). We can take
advantage of CPython's constant folding optimizations by slightly changing the
@@ -144,23 +160,11 @@ order of operations, which allows our scaling factors (`5 / 9` and `9 / 5`) to
be computed at compile-time. When we do this, CPython is able to implement our
converters *entirely* using native floating-point operations:
-
-
-A few notes on the remaining code:
-
-- The global lookup of `TEST_VALUES` is red because it hasn't had the
-opportunity to be specialized yet. Though CPython *was* able to identify
-`test_conversions` as "hot" code and quicken the body, this didn't happen until
-*after* `TEST_VALUES` was looked up (which happens only once). It would be
-wasteful to spend time optimizing code that is never run again!
+
-- Similarly, parts of the `assert` statements in `assert_round_trip` are red
-because they are "dead" code that never actually runs.
+
-- The calls to `math.is_close` are orange because it is implemented in C.
-C extensions can't be "inlined" the same way as pure-Python calls like`c_to_f`,
-`f_to_c`, and `assert_round_trip`, so most of the call sequence isn't able to be
-specialized.
+
Modes
diff --git a/examples/output-0.png b/examples/output-0.png
index 90ebc78..2a175c2 100644
Binary files a/examples/output-0.png and b/examples/output-0.png differ
diff --git a/examples/output-1.png b/examples/output-1.png
index 15e598c..770d26a 100644
Binary files a/examples/output-1.png and b/examples/output-1.png differ
diff --git a/examples/output-2.png b/examples/output-2.png
index c763084..3896b05 100644
Binary files a/examples/output-2.png and b/examples/output-2.png differ
diff --git a/examples/output-3.png b/examples/output-3.png
index 8c98dfe..10e87cf 100644
Binary files a/examples/output-3.png and b/examples/output-3.png differ
diff --git a/examples/output-4.png b/examples/output-4.png
index 01a1e92..1f377d8 100644
Binary files a/examples/output-4.png and b/examples/output-4.png differ