 ; 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

  [seed & code]
  `(binding [*rnd* (java.util.Random. ~seed)]
    ~@code))

(defn- pick-word
  "Takes a map of counts in the form of {'sad' 2, 'mad' 3} (values from the 

; 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).
;   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.