Sunday, November 25, 2007

zelda

I held my sword in front, and approached the village cautiously. I would have to slaughter the terrible Yook monster disguised in one of the hapless villagers's homes. I pushed the doors open, ready to hack and slash. To my shock, all of the villagers looked exactly the same!

And each had something to say about the other Anouki:

* FoFo said that Gumo was honest.
* Kumu said Mazo or Aroo was lying.
* Dobo said Mazo was honest.
* Gumo said Fofo or Aroo was lying.
* Aroo said Kumu was lying.
* Mazo said that he and Dobo were honest.

How dastardly! Only the Yook would lie to me. And I couldn't just kill them all and let God sort them out. I had to think about this. So I did what anyone in this circumstance would do: I pulled out Alloy.


abstract sig Boolean {}
one sig True, False extends Boolean {}

abstract sig Anouki {
truthful: Boolean
}

one sig Fofo, Kumu, Dobo, Gumo, Aroo, Mazo extends Anouki {}

pred whoTellsTruth {
Fofo.truthful = True implies Gumo.truthful=True
Kumu.truthful = True implies ((Mazo.truthful=False) or
(Aroo.truthful=False))
Dobo.truthful = True implies Mazo.truthful=True
Gumo.truthful = True implies ((Fofo.truthful=False) or
(Aroo.truthful=False))
Aroo.truthful = True implies (Kumu.truthful=False)
Mazo.truthful = True implies (Mazo.truthful=True and
Dobo.truthful=True)
}

pred onlyOneIsLying {
one a: Anouki | a.truthful=False
}

run {
whoTellsTruth
onlyOneIsLying
}


Ah ha! But as I was about to raise my gleaming blade against the trembling liar, doubt came to my mind: what if there were two of them out there? Or three, or four? I thought: perhaps I should plan this out more carefully before executing my righteous justice. And maybe I should rewrite the model a little more to make it more general: who knows how many villages of liars I might run across?


/* Anouki can be friendly or antagonistic to other Anouki */
sig Anouki {
supports: set Anouki,
denies: set Anouki
} {
/* and it's nonsensical to be both supportive and antagonistic of
the same Anouki. */
no (supports & denies)
}

/* A village consists of folks who tell the truth, and symmetrically,
those who lie. And we will categorically make every Anouki a
truthteller or a liar. */
one sig Village {
truthtellers: set Anouki,
liars: set Anouki
} {
no truthtellers & liars
Anouki = truthtellers + liars
}

fact truthiness {
all a : Village.truthtellers {
all a' : a.supports | a' in Village.truthtellers
all a': a.denies | a' not in Village.truthtellers
}
}

/* Here's what everyone says about each other */
pred hearsay {
some disj fofo, kumu, dobo, gumo, aroo, mazo : Anouki {
fofo.supports = gumo
fofo.denies = none
kumu.supports = none
kumu.denies = mazo or kumu.denies = aroo
dobo.supports = mazo
dobo.denies = none
gumo.supports = none
gumo.denies = fofo or gumo.denies = aroo
aroo.supports = none
aroo.denies = kumu
mazo.supports = mazo + dobo
mazo.denies = none
fofo + kumu +dobo + gumo + aroo + mazo = Anouki
}
}

pred oneLiar {
hearsay and #Village.liars = 1
}

pred twoLiars {
hearsay and #Village.liars = 2
}

run oneLiar for 6
run twoLiars for 6


Hours passed as I played out different scenarios. By this time, the Yook had already run away, but I had a model I was happy with.

Tuesday, October 02, 2007

consistency

There's so much work that I have to do, and I've realized that one of my personal failings is not necessarily the understanding of hard stuff. Rather, it's getting the easy stuff even started.

It's a main point of Better: performance isn't about the shiny tools: it is more about the "gruntwork". It's the mundane task of being consistent, of staying on target, with which I struggle and flounder about like a floppy fish. My failure to do better isn't for lack of technical tools or skills: what I'm missing is consistency. Adults should have the firmness of mind to do something even if there are no immediate results. But my mind is still mushy and squishy. It has the consistency of oatmeal.

Friday, June 01, 2007

lists 1

One of my research topics may involve Alloy in its role as a language for developing software. The problem is, I don't know Alloy quite well enough to use it in anger yet. That's something I must fix.

I need a nice, simple TODO list-keeping application, and so I'll try modeling it with Alloy. I'll try to verbalize my thinking in real-time, just to show that software isn't written in a vacuum, but is revised and re-revised.

These are the sort of things I'd want in a TODO list manager:

  • I should be able to make Items, and going the other way, deleting should be a snap.

  • I should be able to assign items to Tags.

  • I should be able to easily share my TODO lists with other people.


It's the last requirement that seems interesting to me; I'm not quite sure what I mean by this yet, but it involves some kind of security thing that I'll think about more in a moment. But let me first start modeling the relationships between the items in my imaginary system.


module lists
sig Person {
tags: set Tag,
items: set Item
}
sig Tag {}
sig Public, Private extends Tag {}
sig Item {
tags: set Tag
}
run {}



I'm thinking of a design like delicious: a Person manages their TODO Items by tagging them. I'll keep two special tags called Public and Private, which I'll plan to use to restrict views by other people. Maybe it's premature to think about this...

Oh, I do want to say that the tags that are associated with a person are the ones used in that person's items: at the moment, my software model leaves that unconstrained. Let me fix that and revise the definition of a Person.


sig Person {
tags: set Tag,
items: set Item
} {
tags = items.tags
}




At this point, I can ask Alloy: what would a possible situation of my model look like, by executing and showing a model. Here's one sample visualization that the tool's giving me.

Ok, but I haven't yet done anything about privacy yet; I need to model the items that a person might be looking at the moment. Let me extend a Person to also include the items that they're currently looking at, and also assign an "owner" to each Item.


module lists
sig Person {
tags: set Tag,
items: set Item,
viewing: set Item
} {
tags = items.tags
}
sig Tag {}
sig Public, Private extends Tag {}
sig Item {
tags: set Tag,
owner: one Person
}
run {}



Ok, so Items know who own them, so I should be able to write an expression capturing a notion of privacy. It might not be completely right, but let me see what things look like.


pred respectsPrivacy(p : Person) {
all i : p.viewing | permit[p, i]
}
pred permit(p : Person, i : Item) {
p = i.owner || Public in i.tags
}


Cool. Hmm, when I visualize this, though, the diagram's a little cluttered. And on second thought, I don't really need to have a Person keep track of their items's tags explicitely: that's easily computable as a function.


sig Person {
items: set Item,
viewing: set Item
}
// Returns the tags used by a Person
fun personalTags(p : Person) : set Tag {
p.items.tags
}



Ok, let me visualize again, with a more interesting scenario.


pred show {
all p : Person | respectsPrivacy[p]
#Person > 1
some p : Person | some i : Item {
permit[p, i] && i.owner != p
}
}
run show



Wait a minute, the diagram doesn't look right at all. Why does Person0 see Item0: she doesn't own it. Ooooh... I didn't tell my design that a Person's items must be owned by them. Ooops. I want to prevent panhandling.

Actually, let me just simplify the model so that this issue doesn't even happen. Just as I treated the personal tags as a function, I'll just make a personalItems function to compute whenever I need it.


// Returns a set of the items owned by this person.
fun personalItems(p : Person) : set Item {
{ i : Item | i.owner = p }
}



Here's my revised model so far.


module lists

sig Person {
viewing: set Item
}

// Returns a set of the items owned by this person.
fun personalItems(p : Person) : set Item {
{ i : Item | i.owner = p }
}

// Returns the tags used by a Person
fun personalTags(p : Person) : set Tag {
p.personalItems.tags
}

sig Tag {}
sig Public, Private extends Tag {}

sig Item {
tags: set Tag,
owner: one Person
}

pred respectsPrivacy(p : Person) {
all i : p.viewing | permit[p, i]
}

pred permit(p : Person, i : Item) {
p = i.owner || Public in i.tags
}

pred show {
all p : Person | respectsPrivacy[p]
#Person > 1
some p : Person | some i : Item {
permit[p, i] && i.owner != p
}
}

assert privateReallyMeansPrivate {
all i : Item | all p : Person {
(Private in i.tags && permit[p, i]) implies (i.owner = p)
}
}

run show
check privateReallyMeansPrivate


I also added an assertion making sure that "private" really means private. There are plenty of counterexamples! It fails because my definition for permit() currently only cares about Public at the moment, and it's very easy for an Item to get tagged both with the Public and Private tag at once.

This is pretty cool stuff! To be able to talk about this software's design even without touching a single hashtable or SQL statement is really nice, and I'm already hitting core issues like handling privacy. But since the post is getting a bit long, I'll stop for now and continue this when I get back to Massachusetts tomorrow.

Wednesday, May 30, 2007

powers of two


Knuth Check
Originally uploaded by dyoo
One of my friends complained that I didn't put any interesting images on my blog. So I promised him I'd post something with an image on it. I thought this photo would bring a smile to his face.

Gotta love powers of two.

Tuesday, May 15, 2007

turing

The thing that struck me about the Turing Test, when I heard about it, was the crazy thought: how do I know that other people are anything like me? If we can't even judge faithfully between ourselves, how can we judge between humans and computers? For I can do nothing but observe reactions, the effect of my actions on others. I can't read people's minds: they could, for all I know, run entirely different mental software. Everyone is, in some sense, a black box.

The act of empathy, then, is a little presumptuous and magical: I trust that we can share an understanding with each other, with the assumption that because I share a similar hardware architecture with you, that there's a very strong chance that I share the same kinds of thoughts and values too. I think that's why we put so much emphasis on physical bodies. If someone looks different, I may fear them: they don't look like me, and so they might be thinking in an entirely different way. We all know the dilemma of the Turing Test deep in our bones, and we cheat a little (or a lot) by using irrelevant physical similarities in our judgements of one another.

I suppose I could be silly and wry and conclude that this is why women are mysterious and terrifying to me.

But I think that there's something there that deserves more serious thinking.

Wednesday, May 09, 2007

aliasing renaming

People are often particular about naming. Names still hold special power: we may rationalize that names don't matter, but there's something hardcoded in human beings about choosing the right name for a thing. It's a hard thing to fight.

Programmers are people too, and programmers also keep concerns (sometimes too much) about the right name for a thing. As a concrete example, the word lambda scares off a few people since it's a foreign word. We might like to be brief and be able to say:

(def (make-adder x)
(fn (y) (+ x y)))

where def and fn are really meant to behave like define and lambda, respectively. One nice thing about Scheme is that it's plastic enough to absorb a trivial change like this. Here's a small library for aliasing identifiers:

(module alias mzscheme
;; Practice writing macros that themselves generate macros.

(provide alias)

;; (alias old-keyword new-keyword) SYNTAX
;; Creates a new syntax for new-keyword; any occurrence of new-keyword
;; is replaced with the old-keyword.
(define-syntax (alias stx-1)
(syntax-case stx-1 ()
[(_1 orig new)
(syntax/loc stx-1
(define-syntax (new stx-2)
(syntax-case stx-2 ()
[_2
(identifier? stx-2)
(syntax/loc stx-2
orig)]
[(_2 e (... ...))
(syntax/loc stx-2
(orig e (... ...)))])))])))


Once we have a tool like this, then we can test it out:

(module test-alias mzscheme
(require "alias.ss")
(alias lambda fn)
(alias define def)

(def (make-adder x)
(fn (y) (+ x y))))


That being said, the above example is a silly thing to do. Even in competent hands, this is easy to abuse; in the wrong hands, one can end up with something that belongs to an obfuscation contest.

> (alias alias a)
> (a define d)
> (a if i)
> (d (f x) (i (= x 0) 1 (* x (f (- x 1)))))
> (f 3)
6


Communication between people means that we "come to terms", and the inherent abuse here is to turn the language into something that no one else can read. In PLT Scheme's case, the above is especially bad because there's already an established mechanism for controlled renaming of identifiers as part of PLT Scheme's module system.

(module test-alias mzscheme
(require (rename mzscheme fn lambda)
(rename mzscheme def define))

(def (make-adder x) (fn (y) (+ x y))))


Still, I thought the macro definition was cute (even if it's silly), and it's one of the more direct applications of a "macro-generating macro" that I've seen. But maybe this is all just syntax, futzing with words, distracting us from the real work on nailing down the semantics of our thoughts.

Wednesday, May 02, 2007

logical

I didn't get this so strongly before, but there's a correspondence between the language and structures of first-order logic, and the signatures and units of PLT Scheme (as well as the signatures and structures of ML). I guess the analogy is something like: "language::signature as structure::unit."

As a concrete example, a first-order language might just have equality (=), and a 2-arity P relation. Once we have a language, we can start writing statements in that language. Here are two statements using the language:

  • for all x, y, z: P(x, y) and P(x, z) implies y = z

  • for all x: there exists y: P(x, y)


These two sentences, taken together, are trying to say "P must be a relation that represents a total function". These sentences don't have a true or false value without being evaluated in the context of some structure. A structure tells us what domain of thingies (the universe) we're iterating over when we say "for all" or "there exists", and also provides a concrete definition for the relations of the language.

There are some structures that might satisfy this, and other structures that don't. Structures that satisfy the sentences we care about are called "models". One example of such a model for those two sentences might be the natural numbers (0, 1, 2, ...), where the interpretation of P is:

P(x, y) if and only if y = square(x)

But an example of a similar structure that wouldn't fit the above conditions would be natural numbers under a P that's not a function relation, like:

P(x, y) if and only if x < y

and so we'd say that this structure isn't a model of those sentences.

Programmers have an intuitive idea about this: it's similar to the distinction between "interface" and "implementation": the language provides the interface, and the structures provide implementations for that language. And when we have an interface, we usually have some implicit idea of how that interface should behave; if we have an interface called Stack, we have an expectation about what it should do. We can make those assumptions explicit by writing contracts or predicates with that interface: the things that satisfy our expectations are good implementations.

Again, to make this concrete, when we're programming with signatures and units, we first have to specify the things we're going to be fiddling with. For example, a signature like:

;; A function^ model consists of a universe of elements,
;; and a 2-place predicate P between elements.
(define-signature function^ (universe
P))

gives us a language for talking and using units that implement this signature. For example, to build a unit where P is the squaring relation, we can do this:

(define-unit squaring@
(import)
(export function^)
(define universe (list 0 1 2 3 4 '>4))
(define (P x y)
(cond
[(equal? x '>4)
(equal? y '>4)]
[(> (* x x) 4)
(equal? y '>4)]
[else
(equal? y (* x x))])))

(I'm defining the P function a bit peculiarly since I want the universe of elements to be finite.)

But again, not all implementations of the function^ signature will do the right thing. Here's a structure that doesn't satisfy the intent of the function^ signature.

(define-unit less-than@
(import)
(export function^)
(define universe '(1 2 3))
(define (P x y)
(< x y)))


How do we capture intent? We want to be able to catch implementations that don't do what we expect, and one way is to write code to exercise the units. Here's one example:

;; function-model?: function@ -> boolean
;; Checks to see if the given unit satisfies what we
;; expect out of functions, that their domain is total
;; and that each element of the domain maps to
;; just one element of the range.
;;
;; In first-order logic:
;; (for all x, y, z: P(x, y) and P(x, z) implies y = z)
;; and
;; (for all x: there exists y: P(x, y))
(define (function-model? model@)
(local ((define-unit-binding a-model@
model@ (import) (export function^))

(define-unit function-tester@
(import function^)
(export)
(and (for-all* (lambda (x y z)
(implies? (and (P x y) (P x z))
(equal? y z)))
universe universe universe)
(for-all* (lambda (x)
(exists? (lambda (y) (P x y))
universe))
universe))))
(invoke-unit
(compound-unit/infer
(import)
(export)
(link a-model@ function-tester@)))))

(There are a few definitions I've left out here; see logic-practice.ss for the other definitions.)

Once we have this, we can now check to see if squaring@ and less-than@ satisfy the function-model? predicate.

> (function-model? squaring@)
#t
> (function-model? less-than@)
#f

Monday, April 30, 2007

spring

It finally feels like spring has arrived here in Worcester. The flowers are blooming from the trees, in great white poofy and pink blossoms. After my first winter here on the East Coast, it feels glorious to stand outside and just soak in the sun.

This semester is finally over. I still feel a little unsatisifed with my performance in Dan's logic class; the simplest things trip me up. Ever time I do a logic session, I come out feeling mentally pummeled. Brain squish just like grape! But not because the material's necessarily difficult, but just that I come in with so much mental confusion.

For example, I got confused with the concepts of Skolem Hull and the Herbrand universe, which are different concepts. The Skolem Hull submodel only contains points that are interpretations of all the nameable elements of a language. A Herbrand universe, on the other hand, is a set containing only the nameable terms themselves. A hash collision.

We talked about models that include "junk" (elements that can't be named by terms) and "confusion" (named terms that go to the same element). It's funny, though, how the terms of logic are adopted by other subcultures, things like "compactness" and the "no junk, no confusion" properties, and in ways that are totally different from the definitions in mathematical logic.

I should probably spend a few more days in the sun and try to weed out the junk and confusion in myself, the ill-formed and redundant thoughts.

Friday, April 20, 2007

function of the day: fold

The fold function does very much what the name implies: it's meant to fold ingredients into a big mixing bowl, of course. Here's a definition:


;; fold: (ingredient bowl -> bowl) bowl (listof ingredient) -> bowl
;; Folds in a list of ingredients into a bowl with a folding-action.
(define (fold folding-action a-bowl ingredients)
(cond
[(empty? ingredients) a-bowl]
[else
(local ((define mixed-bowl (folding-action
(first ingredients)
a-bowl)))
(fold folding-action mixed-bowl (rest ingredients)))]))


FOLD here adds an ingredient at a time, using the folding-action to mix in every ingredient thoroughly into our large bowl. Once we have this incorporating function, we can roll up our sleeves and whisk some pancake batter:


;; make-pancake-batter: -> string
;; Example of FOLD to make pancake batter.
(define (make-pancake-batter)
(local ((define (whisk an-ingredient a-bowl)
(string-append a-bowl an-ingredient))

(define pancake-ingredients '("flour" "sugar" "eggs" "milk"))

(define empty-bowl ""))
(fold whisk empty-bowl pancake-ingredients)))

Oh! I forgot the baking powder, so those pancakes will be a little stiff. Oh well.

Of course, we might even want to whisk in a slightly different way:

(local
((define (whisk an-ingredient a-bowl)
(cond [(string=? an-ingredient "eggs")
(string-append a-bowl "egg-white-only")]
[else
(string-append a-bowl an-ingredient)])))
(fold whisk "" '("flour" "eggs" "cabbage")))

Now we've got the basics of an okonomiyaki, I suppose.

We might even be silly enough to mix things that aren't even food!

> (fold + 0 '(1 2 3 4 5))
15

but this seems like a boring example compared to whisking.

Folding is popular, but for some reason it goes by different names by different programming camps. Python programmers call it REDUCE, and Ruby programmers call it INJECT. I don't know about these names, though: I think they sound a little bit aggressive for my taste. As for me, I like the homeliness of "fold": it reminds me of the kitchen.

Tuesday, April 17, 2007

death and taxes

I can't help feeling haunted about the deaths in yesterday's shooting. The shooting itself makes no sense to me.

I can appreciate that people are trying to find meaning in the murderer's actions, trying to blame video games, or psychotic drugs, or jealousy, or divine retribution. It can't all be random, can it?

I suppose there's a story about the murderer that remains to be told, the motives and the exposure of lurid, petty details. Still, he is meaningless to me.

I do see clear meaning in the actions of people like Liviu Librescu. How gloriously different are the saints. I'd rather think about Professor Librescu and the others like him, who faced death with courage, teaching one final lesson: "Love is stronger than death." Another one of those lessons that I'm trying to believe.

Sunday, April 15, 2007

stick a fork() in it

Sometimes I really really dislike C for its low-levelness.

Here's one concrete example why. Predict the output of the following program:

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>

int main(int argc, char** argv) {
printf("hello world\n");
if (fork() == 0) {
printf("child\n");
} else {
printf("parent\n");
}
return 0;
}


with the following:

dyoo@dyoo-desktop:~/work/net-2$ gcc -Wall test-fork.c
dyoo@dyoo-desktop:~/work/net-2$ ./a.out
[predict your output here #1]
dyoo@dyoo-desktop:~/work/net-2$ ./a.out | cat
[predict your output here #2]

Yes; I was surprised too, but #1 and #2 can produce different output.

At least, this is what I see:

dyoo@dyoo-desktop:~/work/net-2$ ./a.out
hello world
child
parent
dyoo@dyoo-desktop:~/work/net-2$ ./a.out | cat
hello world
child
hello world
parent


The bug here is the interaction between the low-level fork() and the way that buffered output works in C. In the second case, since I'm piping through cat, there's more output buffering going on. The first printf() is buffered and not immediately printed but rather stored somewhere. The fork() duplicates the process. So when both the child and parent processes close, they flush their respective buffers... and we see this unusual output.

Some man pages do talk about this, like the one from SGI IRIX. Linux's man pages, not so much. Ah well.

Thursday, April 12, 2007

cyberdyne

I went to the NEPLS conference at Tufts University on Wednesday. It was a lot of fun; I got to hear programming language theory talks and meet with other people interested in the same sort of crazy things that pull my attention. I did like Dave's talk: the idea of collapsing idempotent type checks to preserve space seemed perfectly reasonable. I wonder if any of that will trickle back into PLT's contract system.

The last presentation, on Spatial Computing, was especially fascinating. At a first glance, it seemed ridiculous, and the scope of the project so breathtakingly absurd. I clamped my hands over my mouth to muffle my giggles. But as the speaker presented more and more, the whimsical thought came into to me: maybe this is how Skynet begins.

I hope that I too will someday build something that brings both laughter and pondering thoughts. And I'll also keep in mind to try avoiding the development of systems that might lead to the creation of bloodthirsty androids.

Friday, March 30, 2007

birthday

I felt a little silly today, and just learned about SRFI 42 (Eager Comprehensions), so I thought I might play with it on a trivial example.


(module happy-birthday-song mzscheme
(require (lib "etc.ss")
(lib "42.ss" "srfi"))

(provide sing)

;; sing: string -> void
;; Prints out the popular happy birthday stanza.
(define (sing person)
(local ((define (trailer i)
(cond [(= i 2)
(format "dear ~a" person)]
[else
"to you"])))
(do-ec (: i 4)
(begin
(display "Happy birthday ")
(display (trailer i))
(newline))))))

Thursday, March 29, 2007

forgive

It's one thing to intone in a dull monotony: "Forgive those who trespass against us," where repetition drains the blood out of a revolutionary and crazy idea. It's quite another thing to try to put the spirit of forgiveness into real action. Serious forgiveness seems to me something superhuman, and I'm finding it hard to do.

Early Monday, right around 1am, I got taken by a pair of con artists who pretended they needed to make an emergency call outside. I let them use my cell, and when they handed the phone back, I didn't realize they'd yanked the battery and the SIM chip inside.

Still, I did get the physical phone back, and there wasn't really much damage, except one night of uneasy sleep and an afternoon buying cellphone components. I should say that I forgive the people who did this to me. A part of me tries doing so, but another part feels that it's a baldfaced lie, and I catch myself wanting something bad, something karmic to happen to the thieves.

But I think about it some more. Frankly, I got off easy: it could have been a lot more perilous, because the two thieves could have gone after much more than my cellphone. The guy had me in a bear hug at one point, pretending to be thankful. I couldn't get out of his grip. He could have squeezed me more tightly, and then I would have been in real trouble. So I am thankful and lucky not to have been crushed in this encounter.

If something this insignificant raises my ire, how hard it must be to forgive when people truly hurt each other! It just makes me wonder.

Thursday, March 01, 2007

Programmed Learning

As I was listening to Guy Steele from a talk he gave at Dan Friedman's 60th birthday, I was a little shocked when Guy voiced the relationship between B.F. Skinner's Programmed Learning method and the style of the conversation used in the Little Schemer.
I didn't really think of it that way, and now I'm trying to sort out why I have a negative feeling about Programmed Learning and positive feelings about The Little Schemer.

What both seem to do right is quick iteration: rather than lecture (which bores me to tears), they instruct with a running conversation, Socratic style. I think what's different, at least in the examples that Guy gave, was the degree of difficulty in the questions. In the examples with Skinner, the respondent answer in one-word sound bites, and there's a feeling of rote memorization and little thinking. In contrast, in the Little Schemer, the questions require a lot more out of the student. The stepping stones are spaced widely.

So there are two ideas I'm picking out of this: just as in Agile development, I should be aiming toward iterative learning. At the same time, even though the iterations are fairly regular, the goals in each iteration shouldn't be trivial, but have some real substance behind it.

Thursday, February 08, 2007

crazed

I think I came out a bit raving during Thursday's Coding Dojo; I did a quick-and-dirty derivation of the brute-force countdown program for last afternoon's session, and I only had an hour to work with. Not only that, but I had to try to explain what I was doing while coding things up, and that almost inevitably gets me into trouble. And I needed to write unit tests too. And make unintentional mistakes to justify those unit tests. I'll show one of those mistakes at the end of this post.

Actually, it was really exciting! But my body felt so totally exhausted at the end of it. Much of it is performance, exaggerations and all. My stage persona is one that's, well, a bit crazed. I'm not exactly sure what the audience thought about it. I hope folks thought was worth it and that the content was useful.

The function where I made a mistake was this: we were writing a function to see if any number expression was reused. One way to check for this condition is to do a depth-first traversal across the expression, watching to see if any number appears twice.

Here's a variation of what I did:

(require (lib "plt-match.ss"))

;; Data structures, of course, for our expressions:
(define-struct num (n))
(define-struct comb (left op right))

;; is-legal?: expr -> boolean
;; Returns true if no num is reused more than once in the expression
;; or its subexpressions.
(define (is-legal? expr)
(define ht (make-hash-table))

(define (seen-already? expr)
(hash-table-get ht expr #f))

(define (mark-as-seen! expr)
(hash-table-put! ht expr #t))

(let loop ([expr expr])
(match expr
[(struct num (n))
(cond
[(seen-already? n) #f]
[else
(mark-as-seen! expr)
#t])]
[(struct comb (l o r))
(and (loop l) (loop r))])))


Thankfully, I also wrote a test case.

(require (planet "test.ss" ("schematics" "schemeunit.plt"))
(planet "text-ui.ss" ("schematics" "schemeunit.plt")))

(define simple-test-suite
(test-suite
"testing"
(test-true "check simple case"
(is-legal? (make-num 3)))
(let ([n1 (make-num 4)])
(test-false "check false"
(is-legal? (make-comb n1 + n1))))))

(test/text-ui simple-test-suite)


And the test case quickly showed that I screwed up somewhere.

Welcome to DrScheme, version 369.6-svn24jan2007 [3m].
Language: Pretty Big (includes MrEd and Advanced Student).
testing > check false
check false has a FAILURE
name: check-false
location: struct:object:...ascheme/diva-link.ss:124:4>:39:5
params: (#t)
1 success(es) 1 failure(s) 0 error(s) 2 test(s) run


Oh no! Terror! But thankfully, I figured out I had made a type error: the hash-table should always hold expressions, and to my chagrin, I stuffed the primitive number into it instead. Easy to fix.

(define (is-legal? expr)
(define ht (make-hash-table))

(define (seen-already? expr)
(hash-table-get ht expr #f))

(define (mark-as-seen! expr)
(hash-table-put! ht expr #t))

(let loop ([expr expr])
(match expr
[(struct num (n))
(cond
[(seen-already? expr) #f]
[else
(mark-as-seen! expr)
#t])]
[(struct comb (l o r))
(and (loop l) (loop r))])))

And hesitantly pressed Run on my tests.

Welcome to DrScheme, version 369.6-svn24jan2007 [3m].
Language: Pretty Big (includes MrEd and Advanced Student).
2 success(es) 0 failure(s) 0 error(s) 2 test(s) run

Hurrah.

In all, it was a fun day.

Thursday, February 01, 2007

countdown

Recently, I've been going to a Coding Dojo to practice my programming chops. One of the problems presented so far has been the Countdown program from RubyQuiz. I thought I might give it a shot, and cooked up a solution in Scheme, and it wasn't too bad.

I'll try to give an write-up on how one might attack the problem starting from scratch, and rather than just give a perfect solution, I'll go at this iteratively. (And make accidental mistakes along the way!)

The idea behind the countdown problem is that we are doing exhaustive "brute-force" search for all arithmetic expressions. For example, if we limit ourselves to the numbers 3, 4, and 5, and the only operations are addition and multiplication, here's a conceptual trace of what expressions we'll be brutishly looking at:

3
4
5

That the first phase. Then we take pairs of numbers here, and build new expressions:

3 + 4
3 + 5
4 + 5
3 * 4
3 * 5
4 * 5

Ok, now we take pairs again, combining stuff from previous phases and the phase we just generated:

3 + (4 + 5)
3 + (4 * 5)
4 + (3 + 5)
4 + (3 * 5)
5 + (3 + 4)
5 + (3 * 5)
3 * (4 + 5)
3 * (4 * 5)
4 * (3 + 5)
4 * (3 * 5)
5 * (3 + 4)
5 * (3 * 5)

Whew! Even with three numbers, this gets a bit long.

I should be more formal for a moment. By an expression, I mean either a number, or something that involves two smaller expressions and a number. In Backus-Naur Form, that's:

expression = number
| expression op expression

Let's create a data definition in Scheme for this.

(module countdown mzscheme
(provide (all-defined))
;; An expression is either a
;; (make-num n)
;; where n is a number, or
;; (make-comb l o r)
;; where l and r are expressions, and op is an operator.
(define-struct num (n))
(define-struct comb (left op right)))

Ok, we have our expression data definition. We should also make a quick-and-dirty helper function to help us visually read expressions; let's call this expression->string:

(module countdown mzscheme
(require (lib "plt-match.ss"))

;; [data definition omitted]

;; expression->string: expression -> string
;; Makes a nice human-readable expression.
(define (expression->string an-expr)
(define (operator->string an-op)
(cond
[(eq? an-op +) "+"]
[(eq? an-op *) "*"]))

(match an-expr
[(struct num (n)) (format "~a" n)]
[(struct comb (l o r))
(format "(~a ~a ~a)"
(expression->string l)
(operator->string o)
(expression->string r))]))


Ok, now that we've got this, let's exercise the code.

> (expression->string (make-comb (make-num 3) + (make-num 4)))
"(3 + 4)"

Good. But I'm feeling guilty; we should really make this a unit test. Let's pull in SchemeUnit, the unit testing framework for Scheme.

(module countdown mzscheme
(require ;; [other packages omitted]
(planet "test.ss" ("schematics" "schemeunit.plt" 2))
(planet "text-ui.ss" ("schematics" "schemeunit.plt" 2)))

;; [code omitted]

(define countdown-tests
(test-suite
"tests for countdown"
(test-equal?
"expression->string simple test"
(expression->string (make-comb (make-num 3) + (make-num 4)))
"(3 + 4)")))

(test/text-ui countdown-tests))

If we run this module, we see:

1 success(es) 0 failure(s) 0 error(s) 1 test(s) run
>

Very good.

Now let's see if we can build new expressions from old ones. The idea is that, if we have an existing collection of expressions, we want to pair two of them up together and do something with them. We might do this naively:

;; for-each-pairs: (X X -> void) (listof x) -> void
;; Calls f on distinct ordered pairs in the collection.
(define (for-each-pairs f collection)
(let outer-loop ([i 0])
(when (< i (length collection))
(let inner-loop ([j (add1 i)])
(when (< j (length collection))
(f (list-ref collection i) (list-ref collection j))
(inner-loop (add1 j))))
(outer-loop (add1 i)))))

Does this work?

> (for-each-pairs (lambda (x y) (printf "~a ~a~n" x y)) '(red blue green))
red blue
red green
blue green

Looks reasonable. Of course, now we want to use this to collect up all the pairs and build an addition and a multiplication from x and y. Let's call this build-next-generation. Oh, let's write our unit test first:

(test-equal?
"build-next-generation simple"
(map expression->string
(build-next-generation (list (make-num 3)
(make-num 4))))
(list "(3 + 4)" "(3 * 4)"))

Ok, let's roll up our sleeves and do it.

;; build-next-generation: (listof expression) -> (listof expression)
;; Constructs new expressions from pairs of old ones.
(define (build-next-generation expressions)
(define next-gen '())

(define (collect! an-expr)
(set! next-gen (cons an-expr next-gen)))

(define (visit-pair e1 e2)
(collect! (make-comb e1 + e2))
(collect! (make-comb e1 * e2)))

(for-each-pairs visit-pair expressions)
(reverse! next-gen)
next-gen)

Ok, should work. On every pair, we combine two expressions, and collect them. We do a reverse! to put things in the order expected by the test case. (Although that might be a little silly.) Let's rerun our unit tests.

tests for countdown > build-next-generation simple
build-next-generation simple has a FAILURE
name: check-equal?
location: #:67:5
params: (("(3 * 4)") ("(3 + 4)" "(3 * 4)"))
actual: ("(3 * 4)")
expected: ("(3 + 4)" "(3 * 4)")
1 success(es) 1 failure(s) 0 error(s) 2 test(s) run

What?! Yes, there's something wrong here.

It turns out that I've misused reverse! here: I should just take the result of reverse! and return it directly.

(define (build-next-generation expressions)
(define next-gen '())

(define (collect! an-expr)
(set! next-gen (cons an-expr next-gen)))

(define (visit-pair e1 e2)
(collect! (make-comb e1 + e2))
(collect! (make-comb e1 * e2)))

(for-each-pairs visit-pair expressions)
(reverse! next-gen))

Hurrah for unit tests. But maybe we shouldn't do the reverse after all. Let me just fix up the test case to expect the paired expressions in a different order. Since I've made so many changes, let's show what the code looks like now:

(module countdown mzscheme
(provide (all-defined))
(require (lib "plt-match.ss")
(planet "test.ss" ("schematics" "schemeunit.plt" 2))
(planet "text-ui.ss" ("schematics" "schemeunit.plt" 2)))

;; An expression is either a
;; (make-num n)
;; where n is a number, or
;; (make-comb l o r)
;; where l and r are expressions, and op is an operator.
(define-struct num (n))
(define-struct comb (left op right))


;; expression->string: expression -> string
;; Makes a nice human-readable expression.
(define (expression->string an-expr)
(define (operator->string an-op)
(cond
[(eq? an-op +) "+"]
[(eq? an-op *) "*"]))

(match an-expr
[(struct num (n)) (format "~a" n)]
[(struct comb (l o r))
(format "(~a ~a ~a)"
(expression->string l)
(operator->string o)
(expression->string r))]))

;; for-each-pairs: (X X -> void) (listof x) -> void
;; Calls f on distinct ordered pairs in the collection.
(define (for-each-pairs f collection)
(let outer-loop ([i 0])
(when (< i (length collection))
(let inner-loop ([j (add1 i)])
(when (< j (length collection))
(f (list-ref collection i) (list-ref collection j))
(inner-loop (add1 j))))
(outer-loop (add1 i)))))


;; build-next-generation: (listof expression) -> (listof expression)
;; Constructs new expressions from pairs of old ones.
(define (build-next-generation expressions)
(define next-gen '())

(define (collect! an-expr)
(set! next-gen (cons an-expr next-gen)))

(define (visit-pair e1 e2)
(collect! (make-comb e1 + e2))
(collect! (make-comb e1 * e2)))

(for-each-pairs visit-pair expressions)
next-gen)


(define countdown-tests
(test-suite
"tests for countdown"
(test-equal?
"expression->string simple test"
(expression->string (make-comb (make-num 3) + (make-num 4)))
"(3 + 4)")
(test-equal?
"build-next-generation simple"
(map expression->string
(build-next-generation (list (make-num 3)
(make-num 4))))
(list "(3 * 4)" "(3 + 4)"))))

(test/text-ui countdown-tests))

Ok! Does this do what we'll need for brute-forcing the countdown problem?

> (define expressions (list (make-num 3)
(make-num 4)
(make-num 5)))
> (define generation-1 (append expressions (build-next-generation expressions)))
> (define generation-2 (append generation-1 (build-next-generation generation-1)))
> (map expression->string generation-2)
("3"
"4"
"5"
"(4 * 5)"
"(4 + 5)"
"(3 * 5)"
"(3 + 5)"
"(3 * 4)"
"(3 + 4)"
"((3 * 4) * (3 + 4))"
"((3 * 4) + (3 + 4))"
"((3 + 5) * (3 + 4))"
;; ... a LOT of output omitted
"(3 * (4 * 5))"
"(3 + (4 * 5))"
"(3 * 5)"
"(3 + 5)"
"(3 * 4)"
"(3 + 4)")

It's a beginning. It's not quite right, but it's getting there. Since this post is getting long, I'll split this up with another blog post later.

latex


So I visited Amazon today to buy an egg timer. I was amused to see the following from Amazon's computerized recommendation system. The items were supposedly based on my prior purchases. I've put a screenshot of it here, just in case anyone else gets a chuckle out of it.

Sunday, January 14, 2007

new year

I came in last night from California back into Worcester. I opened my apartment door, half-expecting a nest of mice to scatter. If there were any, I didn't see them. I fell blissfully asleep. I've been sleeping too much lately. Classes start tomorrow, so I suppose that will be remedied.

I'm about to fall asleep again, but before that happens, let me mention DivaScheme 2.1.

Here's hoping this New Year is a good one!