Archive for the ‘tree’ Tag

SICP Section 2.3.4   Leave a comment

This section puts what we’ve learned about sets into practice implementing a method of encoding and decoding messages encoded with huffman code trees, and also a method of generating the trees.

;;Exercise 2.67
> (decode sample-message sample-tree)
(A D A B B C A)

;;Exercise 2.68
The encode-symbol procedure I wrote is straightforward, but takes a rather large number of steps to encode a symbol, because we have to search the set of symbols at each node for the correct branch to take. I’m not sure if there’s a better way to do this…

(define (encode-symbol symbol tree)
  (cond ((leaf? tree) '())
        ((element-of-set? symbol (symbols (left-branch tree)))
         (cons 0 (encode-symbol symbol (left-branch tree))))
        ((element-of-set? symbol (symbols (right-branch tree)))
         (cons 1 (encode-symbol symbol (right-branch tree))))
        (else (error "symbol not in tree - ENCODE-SYMBOL" symbol))))

;;Exercise 2.69
Successive-merge was actually fairly straightforward to code, however, when I first attempted to do this, I did not fully understand the actual tree generation procedure! Perhaps this is what the authors were warning about when they said it was tricky, I was certainly tricked initially :D

(define (successive-merge leaf-set)
  (if (= (length leaf-set) 1)
      (car leaf-set)
       (adjoin-set (make-code-tree (car leaf-set)
                                   (cadr leaf-set))
                   (cddr leaf-set)))))

;;Exercise 2.70
I never knew 50s rock was so repetitive ;)
Probably better than the junk that gets put out these days though…

(define freq-pairs (list (list 'A 2) (list 'BOOM 1) (list 'GET 2) (list 'JOB 2) (list 'NA 16) (list 'SHA 3) (list 'YIP 9) (list 'WAH 1)))

(define message '(GET A JOB
                  SHA NA NA NA NA NA NA NA NA
                  GET A JOB
                  SHA NA NA NA NA NA NA NA NA
                  SHA BOOM))

(define rock50s-tree (generate-huffman-tree freq-pairs))

(define encoded-message (encode message rock50s-tree))
(define huffman-length (length encoded-message))

(define logbase2-of-8 3)
(define fixed-length (* (length message) logbase2-of-8))

fixed-length turns out to be 108 bits long, whereas the huffman-length is only 84 bits long. That’s a pretty fair length saving.

;;Exercise 2.71
I’m not really a fan of drawing large trees, so I’ll just give the code to generate it.

(define freq-pairs-5 (list (list '1 1) (list '2 2) (list '3 4) (list '4 8) (list '5 16)))
(define freq-pairs-tree-5 (generate-huffman-tree freq-pairs-5))

(define freq-pairs-10 (list (list '1 1) (list '2 2) (list '3 4) (list '4 8) (list '5 16) (list '6 32) (list '7 64) (list '8 128) (list '9 256) (list '10 512)))
(define freq-pairs-tree-10 (generate-huffman-tree freq-pairs-10))

The number of bits required for n=5 code are
Largest frequency: 1
Lowest frequency: 4
For n=10
Largest frequency: 1
Lowest frequency 9

It’s fairly obvious that the largest frequency will always have 1 bit, and the lowest frequency will have (n-1) bits.

;;Exercise 2.72
As we descend the tree we have to search the list of symbols at the node we are on, which is of the order O(n). We will need to descend n levels worst case, therefore n searches n deep is O(n2)


SICP Section 2.3.3   Leave a comment

The focus of this section is on representing mathematical sets with Scheme’s built-in data structures, and methods of combining these data structures to enable us to write faster algorithms for performing set operations. We go from a basic list based representation, to binary trees. I found this section to be quite a test of my abstract thinking skills; visualizing the operations on the representations was quite difficult for me.

;;Exercise 2.59
Implementing union-set is fairly straightforward for the unordered-list representation.

(define (union-set set1 set2)
  (cond ((null? set1) set2)
        ((null? set2) set1)
        ((element-of-set? (car set1) set2)
         (union-set (cdr set1) set2))
        (else (cons (car set1) (union-set (cdr set1) set2)))))

;;Exercise 2.60
This exercise was pretty interesting, it makes you think about situations in which what would seem to be an inefficient algorithm is actually the best for a job. Here’s my implementation of the set operations for an unordered set which allows duplicates.

(define (element-of-set? x set)
  (cond ((null? set) false)
        ((equal? x (car set)) true)
        (else (element-of-set? x (cdr set)))))

(define (adjoin-set x set)
  (cons x set))

(define (intersection-set set1 set2)
  (cond ((or (null? set1) (null? set2)) '())
        ((element-of-set? (car set1) set2)
         (cons (car set1)
               (intersection-set (cdr set1) set2)))
        (else (intersection-set (cdr set1) set2))))

(define (union-set set1 set2)
  (append set2 set1))

From the code we can see that, when duplicates are allowed,

  • element-of-set? is still O(n)
  • adjoin-set is O(1) from O(n)
  • intersection-set is still O(n^2)
  • union-set is O(n) from O(n^2)

By allowing duplicates, we have sped things up quite a bit, even if the algorithms are going to use up a lot more memory. In choosing which algorithm to use in a certain situation, we need to take into account the environment it will be used in. If we are, for example, on a machine with limited CPU speed, but a lot of memory (not uncommon in machines that have been upgraded), the duplicate representation would be best. On the other hand, if we were dealing with huge numbers, it would be a big drain on memory to use the duplicate representation, and the non-duplicate representation would be better for keeping overhead down.

;;Exercise 2.61
Now we’re starting to optimize the representations a bit more, it’s really neat to see how simple ideas like ordering the sets can produce fairly large performance gains :)

(define (adjoin-set x S)
  (cond ((null? S) (list x))
        ((< x (car S)) (cons x S))
        ((> x (car S)) (cons (car S) (adjoin-set x (cdr S))))
        ((= x (car S)) S)))

The ordered-list representation will take less time to adjoin, on the average, because we will not necessarily have to process the whole list in order to know if a duplicate exists.

;;Exercise 2.62
This particular exercise required a fair bit of thought. Here’s my explanation.
If the first element of set1 is less than the first element of set2, we make that element the car of a new list, and the cdr of the new list is the union of the cdr of set1 and set2…

(define (union-set set1 set2)
  (cond ((null? set1) set2)
        ((null? set2) set1)
        ((< (car set1) (car set2))
         (cons (car set1) (union-set (cdr set1) set2)))
        ((> (car set1) (car set2))
         (cons (car set2) (union-set set1 (cdr set2))))
        ((= (car set1) (car set2))
         (cons (car set1)
               (union-set (cdr set1)
                          (cdr set2))))))

;;Exercise 2.63
I think this exercise is designed to see how well we can transform a diagram into the actual representation of a tree as the most difficult part was writing down the trees :D

(define tree1 (make-tree 7
                         (make-tree 3
                                    (make-tree 1 '() '())
                                    (make-tree 5 '() '()))
                         (make-tree 9
                                    (make-tree 11 '() '()))))

(define tree2 (make-tree 3
                         (make-tree 1 '() '())
                         (make-tree 7
                                    (make-tree 5 '() '())
                                    (make-tree 9
                                               (make-tree 11 '() '())))))

(define tree3 (make-tree 5
                         (make-tree 3
                                    (make-tree 1 '() '()))
                         (make-tree 9
                                    (make-tree 7 '() '())
                                    (make-tree 11 '() '()))))

After running these through both functions, you’ll see that both the recursive and iterative procedures produce the same result, which is expected if they are to do the same job…

Yes, they both have the same order of growth, however tree->list-2 uses less memory than tree->list-3, and thus could be faster in certain situations.

;;Exercise 2.64
Partial-tree works in a very recursive fashion :)
The best way I can explain is to work through an example.
Let’s say we have the list '(1 2 3 4 5) to turn into a tree.
Partial-tree first assigns equal, or almost equal sizes for the left and right branch of the new tree. So for our tree left-size will be 2, and right-size will be 3 (because the size of the list is not even). Then, partial tree conses together the result of partial-tree on the left and right halves of the given list. It’s quite a bit for me to wrap my head around, to be sure!

The list looks like so:

;;Exercise 2.65
Still a work in progress for me…

;;Exercise 2.66
The lookup procedure is basically element-of-set?, except instead of returning true or false, we return the item requested by key, or false if it’s not found.

(define (lookup key records)
  (cond ((null? records) false)
        ((= key (entry records)) (record-value (entry records)))
        ((< key (entry records))
         (lookup key (left-branch records)))
        ((> key (entry records))
         (lookup key (right-branch records)))))

;;Where a record structure looks like
(define (make-record key value)
  (cons key value))

Posted 23/09/2010 by Emmanuel Jacyna in Scheme, SICP

Tagged with , , , , , , , , ,

A new project   Leave a comment

I’ve started work on a new project, pyafg (pyafg is an affine fractal generator). It’s a little python program that generates affine fractals using the iterated function system algorithm. I was inspired to start it whilst reading the computational beauty of nature; I’ll write a post up about my experiences hacking it later. For now, download it, play around with it, and enjoy!

(Note, I did only hack this up in 2 days. It’s nowhere near complete, but I’ve made a very good start to it. Expect more features!)

Computer Generated Fern

A Fern I generated

Posted 08/04/2010 by Emmanuel Jacyna in Code, pyafg, Python

Tagged with , , , ,

SICP – Section 2.2.2   Leave a comment

Phew, finished another section of chapter 2! This one was pretty fun, mucking around with tree structures :)

P.S. For people who don’t have a hardcopy of the book, you can check out these exercises online.

;;Exercise 2.24

When doing these by hand (which I did) remember that we simply expand like so:
(list 1 (list 2 (list 3 4)))
(cons 1 (cons (cons 2 (cons (cons 3 (cons 4 nil)) nil)) nil))

Thus, the interpreter spits out:
(1 (2 (3 4)))
Here’s the box & pointer diagram:

Box and Pointer diagram for (1 (2 (3 4)))

Box and Pointer diagram for (1 (2 (3 4)))

And the Tree Diagram:

Tree Diagram for (1 (2 (3 4)))

Tree Diagram for (1 (2 (3 4)))

;;Exercise 2.25

> (define a (list 1 3 (list 5 7) 9))
> (display (car (cdr (car (cdr (cdr a))))))
> (define b (list (list 7)))
> (display (car (car b)))
> (define c (list 1 (list 2 (list 3 (list 4 (list 5 (list 6 7)))))))
> (display (car (cdr (car (cdr (car (cdr (car (cdr (car (cdr (car (cdr c)))))))))))))

;;Exercise 2.26

> (display (append x y))
(1 2 3 4 5 6)
> (display (cons x y)
((1 2 3) 4 5 6)
> (display (list x y))
((1 2 3) (4 5 6))

;;Exercise 2.27

This was an interesting exercise in thinking recursively. One of my favourite things about recursion is that so long as you define a base case, the function works almost magically. We are indeed controlling the spirits in the machine :)

(define (deep-reverse l)
  (define (iter l r)
    (cond ((null? l) r)
             ((pair? (car l)) (iter (cdr l) (cons (deep-reverse (car l)) r)))
             (else (iter (cdr l) (cons (car l) r)))))
  (iter l '()))

;;Exercise 2.28

This one I did last night, with good old pen & paper, and the trusty human evaluator, the brain :)
One of the things I love about lisp is its really easy syntax which makes it possible for me to parse it logically. Anyway, the first time I did this, I was using cons in place of append, which was preserving the original structure of the lists. After a bit of head scratching, I realized that what I actually wanted to be done was to merge the lists. Hence the use of append and only returning lists in this function.

(define (fringe l)
  (cond ((null? l) '())
        ((not (pair? l)) (cons l '()))
        (else (append (fringe (car l)) (fringe (cdr l))))))

;;Exercise 2.29
;;Part A
The selectors just have to take into account that we are dealing with lists not conses. That is the structure is:

a = (cons 'left-branch (cons 'right-branch nil))

So to access right-branch we do:

(car (cdr a))
Code follows:

(define (left-branch mobile)

  (car mobile))

(define (right-branch mobile)
  (car (cdr mobile)))

(define (branch-length branch)
  (car branch))

(define (branch-structure branch)
  (car (cdr branch)))

;;Part B
This procedure is best defined by referring to a branch weight, as well as a mobile weight. This way we do not use extraneous code (abstraction, remember!), and it just flows better in the mind.

(define (branch-weight branch)
  (if (number? (branch-structure branch))
      (branch-structure branch)
      (total-weight (branch-structure branch))))

(define (total-weight mobile)
  (+ (branch-weight (left-branch mobile))
     (branch-weight (right-branch mobile))))

;;Part C
This one had me confused for a while, but again, to achieve enlightenment, we must talk about a branch being able to be balanced, as well as an actual mobile.

(define (torque branch)
  (* (branch-length branch) (branch-weight branch)))

(define (branch-balanced? branch)
  (if (number? (branch-structure branch))
      (balanced? (branch-structure branch))))

(define (balanced? mobile)
  (and (= (torque (right-branch mobile)) (torque (left-branch mobile)))
       (and (branch-balanced? (right-branch mobile))
            (branch-balanced? (left-branch mobile)))))

;;Part D
Because of our wonderful abstraction, the only thing we need change are the selectors!

(define (left-branch mobile)
  (car mobile))

(define (right-branch mobile)
  (cdr mobile))

(define (branch-length branch)
  (car branch))

(define (branch-structure branch)
  (cdr branch))

;;Exercise 2.30

This one’s pretty easy, I think they just want to make sure we see the possibility to abstract.

(define (square-tree tree)
  (cond ((null? tree) '())
        ((not (pair? tree)) (square tree))
        (else (cons (square-tree (car tree)) (square-tree (cdr tree))))))

;;Exercise 2.31

And here is the abstraction :)

(define (tree-map op tree)
  (cond ((null? tree) '())
        ((not (pair? tree)) (op tree))
        (else (cons (tree-map op (car tree)) (tree-map op (cdr tree))))))

;;Exercise 2.32

I found this one quite tricky, but reasoned that we must do something with (car s). So I figured that they wanted us to pair (car s) to rest somehow. The most obvious way to do this is using a cons in the function. I have italicized the added part.

(define (subsets s)
  (if (null? s)
      (list '())
      (let ((rest (subsets (cdr s))))
        (append rest (map (lambda (x) (cons (car s) x)) rest)))))

I can’t give a mathematical explanation for this, as my darned high school education hasn’t said much about set theory so far. However, it’s not too hard to follow, that we are basically appending the car of each iteration, onto the cdr, in order to get (() (1) (2) (1 2)).

Okay, so that’s not a clear explanation :D
Anyone have a better one ;)

Posted 03/04/2010 by Emmanuel Jacyna in Code, Scheme, SICP

Tagged with , , , ,