Life & Research Notes

This was originally posted as the first entry in my then private research blog on Feb 5, 2006. Reposted here today because (a) I somehow didn’t manage to transfer it when I switched to Wordpress, and more importantly (b) I’m getting extremely interested in this again. I’m looking now at doing this without continuations, instead using discrete reusable contract chunks as contract “clauses,” and keeping reference to which clause is current.

In the PLW today we spent some time discussing directions for further research and development of Openstudio. Many interesting ideas came up, some new and some recurrences from past discussions. A recurring theme was that of the economy, especially the lack of incentives for users to participate in the economy. How can we make the economy more fluid? How can we find its equilibrium? How do we make buying and selling more interesting? How do we explore and add more sophisticated transactions?

Many of the UROP projects have involved extensions to the currently simple economic model. Kate, for instance, is working on her “Hire a Designer” contract/commissioning system, in which one member of OS can hire another for a particular project. Other UROPs are developing stock markets and virtual cafes and new types of aggregate documents. Each of these projects adds further expressiveness and sophistication to the current economic system.

Perhaps inspired by my recent participation in an economics course at the Harvard Business School, I wonder if we can somehow formalize and abstract these various sorts of transactions and contracts. Specifically, I am thinking of a sort of programming language or library for describing and executing contracts. Hopefully the following very rough pseudo-code will convey the idea:

def my_contract(client, designer, document, instructions, fee)
    unless commit(client, designer, self)
        return # both parties did not commit to this
    end
    account_transfer :from => client.account,
                     :to => self.escrow,
                     :amount => fee
    designer_chances = 3
    while designer_chances > 0
        send :to => designer,
             :attachment => document,
             :content => instructions
        deliverables = nil
        while deliverables.nil?
            if time.now > deadline
                return # didn't meet the deadline
            end
            deliverables = receive_deliverables(designer)
        end
        if not verify(client, deliverables)
            designer_chances -= 1
        end
    end
    send :to => client,
         :attachment => deliverables
    account_transfer :from => self.escrow,
                     :to => designer.account,
                     :amount => fee
end

Is this interesting? Doable? Reminds me a bit of the sort of pseudo-code used to explain the Amazon mechanical turk.

At this very moment my world seems to have narrowed to only scheme and junior mints (yum!). I have a nice assignment to add a set value system to the constraint propagation being developed by Sussman and Chris Hanson in 6.891. Here is a transcript showing off where I am with this.

(declare (usual-integrations))
;Unspecified return value

(load "load")
;Loading "load.scm"
;Loading "ps-util.scm" -- done
;Loading "tms.scm" -- done
;Loading "constraints.scm" -- done
;Loading "equality-constraint.scm" -- done
;Loading "boolean-constraints.scm" -- done
;Loading "numerical-constraints.scm" -- done
;Loading "line-prefix.scm" -- done
;Loading "proofs.scm" -- done
;Loading "handler.scm" -- done
;Loading "solve.scm" -- done
-- done
;Value: d2?

(load "set-constraints")
;Loading "set-constraints.scm"
;Loading "set.scm" -- done
-- done
;Value: cp:identity

(define network
(cp:make-network 'network
(cp:make-value-model set:is_set?
set:=?
set:smallest)))
;Value: network

(define a (cp:make-connector 'a network))
;Value: a

(define b (cp:make-connector 'b network))
;Value: b

(define c (cp:make-connector 'c network))
;Value: c

(cp:make-constraint cp:intersection #f network a b c)
;Value: #[cp:constraint 13]

(cp:assume-value b (set:construct_from_list '(x y z 1 2 3)))
;Unspecified return value

(cp:assume-value c (set:construct_from_list '(x z 2)))
;Unspecified return value

(cp:has-value? a)
;Value: #t

(cp:value-of a)
;Value: (*set* #[primitive-procedure eq?] 2 z x)

(cp:assume-value a (set:construct_from_list '(x z)))
;Warning: Contradiction: #[tms:node 14]
;Warning: Contradiction: #[tms:node 14]
;Warning: Contradiction: #[tms:node 14]
;Unspecified return value

(cp:value-of a)
;Value: (*set* #[primitive-procedure eq?] z x)

(cp:value-of b)
;Value: (*set* #[primitive-procedure eq?] z x)

(cp:value-of c)
;Value: (*set* #[primitive-procedure eq?] 2 z x)

What I’ve written so far does in fact allow intersection and union, which is nice, but I’m also looking to mix in the boolean system with cp:subset?

Vincent happened to stop by the PLW briefly while I was working on this thing, and when I explained it he suggested a networked, distributed version. This is in fact something I was thinking about several weeks ago, this idea of setting up simple connector and constraint P2P client programs. Input could come from anything: sensor values, humans, stock market, etc. Each type of constraint or value node is essentially offered as a service, and people can compose them to create new nodes.

I won’t be working on that just yet, but I’ll leave it percolating up there, swirling around with social contracts and slow computing. They all seem to relate. In the meantime I have a few more junior mints to eat.

The idea here is that physical characteristics can map to data fields, for example weight might be price and size might be popularity, and then color might be something else. Then via a command line interface the world can be adjusted, remapped, and manipulated. I could turn off gravity and let the records float around, or turn off collisions and filter them through a sieve.

So this is what I’ve got now, and there’ll be more to come in the next few weeks. I was previously trying to write my own physics engine, but the collision detection was very hard, so I got smart and started using PyODE. It’s still a little slower than I’d like when the collisions start building, like when they all pile up. I also had to limit the balls from rolling into the z-dimension, so there is some real wasted processing there.