 ; compute a sentence ending in a specific node. We can return *temporary*
 ; results, but not *partial* results (temporary by, for example, switching to
 ; the "doesn't care about end nodes" algorithm while also leaving the main
-; computation running in the background).+; computation running in the background).
+;   Okay, so it's the day after aaaand...I think I'm somehow allowing it to 
+; loop infinitely. The nature of the depth comparison should make that not
+; possible, in the traditional looping sense (as in, going around in circles
+; attempting to satisfy the end criteria - because it will be assured to end
+; when depth is overrun) but this is taking Basically Forever.
+;   Well, the algorithm is exponential, and we want to go for 153 deep, 
+; so...uh, yeah, that's Basically Forever if no such sentence exists and it has
+; to try and enumerate every node. Horrifyingly slow. As far as I can remember
+; there isn't really any way to remedy this - the efficiency is exponential by
+; size to branching factor. So, actually, you wouldn't need a loop to take
+; forever - to depth 153 at 3 branching, that's 3^153=Infinity Nodes To Search.
+; I mean, not technically infinity, but yeah, that's not happening.
+;   Hmm. That's troublesome, though.
+;   What would be a good way to estimate how long it *should* take? Because
+; right now I'm thinking maybe it would be best to estimate how long it should
+; take, and then if it takes longer than that by some margin, go and hit the
+; fallback algorithm.
; text will be less than fifty words.
;   I will do the former.

(defn time-both [n]
  (prn (str "For " n " old, then new:"))
  (do
    (binding [*rnd* (java.util.Random. 1)]
      (time (gen-sentence dmap n)))
    (binding [*rnd* (java.util.Random. 1)]
      (time (gen-sentence-true-dfs dmap n)))))
    
#_(doall (map time-both (range 80 100)))
#_(doall (map time-both (range 150 155)))
; What's happening at 153? It takes an inordinate amount of time to resolve.

;;; -----=====##### CONCERNING 153 #####=====-----
;   Watching what's happening using the true-dfs code is quite interesting. One
; thing that could be improved is predicting end branches. That is, if a node

      (or (end (last node)) (= depth n) (empty? edges))
        (recur datamap n (rest stack))
      :else
        (let [next-info (gen-next-frame true datamap node-info)
              new-node-info (update-in node-info [:edges] rest)
              next-stack (conj (cons new-node-info (rest stack)) next-info)]
          (recur datamap n next-stack)))))

(defn- dive
  "Runs a dfs, with no punctuation constraints."
  [{:keys [counts end] :as datamap} n stack]
  (if-let [{:keys [depth node edges] :as node-info} (first stack)]
    (cond
