From ab0abf13b69d0911cde46bdafedcef4d485f63f3 Mon Sep 17 00:00:00 2001 From: bnewbold Date: Sun, 29 Mar 2009 16:57:47 -0400 Subject: done... --- ps07_amb/bnewbold_ps07.txt | 56 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) (limited to 'ps07_amb/bnewbold_ps07.txt') diff --git a/ps07_amb/bnewbold_ps07.txt b/ps07_amb/bnewbold_ps07.txt index 27bc791..aa91f6a 100644 --- a/ps07_amb/bnewbold_ps07.txt +++ b/ps07_amb/bnewbold_ps07.txt @@ -13,7 +13,61 @@ the who-owns-what-yacht pairings by hand because it only takes one elimination. [see code in bnewbold_ps07_work.scm] -Problem 7.2: +Problem 7.2: Continuation Returning +--------------------------------------- +At the return of every branch I printed the result; if a #t result thunked up +through the return structure normally, there would be a series of statements +printed, instead there's just the #t. + +[see code in bnewbold_ps07_work.scm] + +Problem 7.3: Depth vs. Breadth +-------------------------------- +The breadth-first essentially trys all combinations by incrementing the final +element of the triple while the depth first increments the first digit; the +first-digit incrementing comes to (12 16 20) with fewer steps. I checked this +by pp-ing every tested triple. + +The extra fail calls are coming from the require in integer-between; eg when +i=10, j increments up to j=20 at which point the selection of k fails. + +The depth-first method would try to first enumerate all possible first-digits +then proceed to the second digits; with a-pythagorean-triple-from, the number +of possible first-digits is infinite, so evaluation would never proceed beyond +that point. + +[see code in bnewbold_ps07_work.scm] + +Problem 7.4: No Such Problem? +----------------------------------------------- + +Problem 7.5: Alternative Alternation Orders +----------------------------------------------- +I wrote an itinerary generator based on budget; you wouldn't want to go through +the itineraries with a regular left-to-right type schedule or really any order, +you would want a randomly different itinerary (fitting the constraints and +not something you've done before) every time. + +In the end though, the list comes out fairly ordered, I guess the only way to +really get a totally random list would be to build an entire search schedule +without evaluating the last step of each, then randomize the entire schedule +and go through evaluating. + +[see code in bnewbold_ps07_work.scm] + +Problem 7.6: -------------------------------- +This doesn't seem too mysterious to me, maybe I don't fully understand the +question. When each variable {x,y,z} is assigned an amb value withing a let, +that value (within the let environment) is stored in following continuations. +When using set! the variable values are not stored in later continuations, or +more technically, the set! alters the value of the variables in all +continuations (globally). So when a continuation gets called, the value of +{x,y,z} is not the value from when that continuation was stored, but global +value, aka the last value set!. +When going depth-first, the continuations reach back far enough that the +variables get reset properly. Another way of stating this is that the order of +evaluation procedes in just the right order so that the globaly set! value +is the appropriate one for each individual alternative continuation. -- cgit v1.2.3