Archive for December, 2008

Public domain

Saturday, December 20th, 2008

I found a rather spectacular article on copyright while reading about the Copyright Term Extension Act:

Scott M. Martin, “The Mythology of the Public Domain: Exploring the Myths Behind Attacks on the Duration of Copyright Protection”, Sep 24, 2002.

There’s no shortage of absurdity, but here’s one of the highlights:

Copyright Encourages, While the Public Domain Discourages, Progress in the Arts

At the risk of speaking words of heresy, it is copyright protection that encourages innovation and creativity, while the public domain discourages both innovation and creativity. Why create something new if you can reprint or reuse something that already exists? Why invest in untested new works if you can instead distribute royalty-free existing works?

The fact that creators of new works cannot merely re-use the expression contained in copyrighted work of others without permission forces them to be creative. Composers cannot rehash the melodies created by earlier composers, they must create their own new original melodies. Writers must invent new characters and plots instead of recycling the efforts of others. Animators and motion picture studios cannot freeload on Mickey Mouse; copyright protection forces them to create their own original cartoon characters. This promotion of fresh creation is an entirely appropriate goal for Congress to pursue through legislation.

Yes: he’s arguing that public domain is actually a bad thing by itself, even ignoring the trade-off between whether a work is copyrighted or free. I.e., it is the legitimate job of the government to mandate creativity directly by disallowing reuse of existing work. Without this forced creativity, artists would just sell existing art.

Brilliant!

Christmas Tree

Friday, December 19th, 2008

This is pretty sweet. It took me a bit to register that this was a real picture and not a photoshop trick. Nicely done, Mom.

In the past we’ve always picked a tree the correct way, by searching through the woods and cutting one down (one year the tree was the top of a large tree removed from the edge of the yard). Mom claims we’ll fix it, but if we have to resort to buying one to do that the virtual tree might be a cooler alternative.

Visualizing collisions

Friday, December 19th, 2008

We added visualization of collisions to physbam’s opengl viewer for the high resolution cloth paper. These turn out to be one of the prettiest things it generates. Here are screenshots of edge-edge collision pairs (two edges colliding) and point-face collision pairs (a point colliding with a face) for a scene with a bunch of soft deformable objects:

Never do this

Thursday, December 18th, 2008

Here’s a snippet of code to sneak into someone’s .pythonrc if you want them to hate you:

    import sys
    from numpy import *

    class Evil:
        size = array(1).itemsize
        __array_interface__ = {
            'shape' : (1,),
            'typestr' : '<i%d'%size,
            'data' : (id(1)+2*size, 0) } 

    asarray(Evil())[0] = 2
    assert 1 == 2

It’s even platform independent! (Note: it will be less innocuous if the class isn’t named Evil.)

Balancing circles

Monday, December 15th, 2008

After extensive testing with glasses of water, I’ve determined that it’s impossible to stably balance one infinitely thin circle on top of another. This is true whether the circles are the same size or different, and does not depend on the mass distribution of the circles. This is because two circles intersect at either zero or two points (unless they are the same, and that still isn’t a stable configuration).

Interestingly, two circles seem to be the only two dimensional simple closed curves for which this property holds; any other pair of curves can be scaled or rotated until they intersect at four points, and I believe these intersections can be arranged so that their convex hull contains the center of mass (for balance). I spent a while on the plane trying to prove this, but no luck yet.

Hydrogen to electricity?

Sunday, December 7th, 2008

Here’s a good candidate for the silliest energy idea I’ve heard in a while:

http://www.ted.com/index.php/talks/reinventing_the_car.html

Larry Burns, the vice president for R&D at GM, notes that 4% of cars equal the power generation ability of the entire current electric grid, and dreams of a future where fuel cell vehicles are used to generate electricity while parked. This is great because hydrogen can come from a wide variety of sources, so as long as each community has their own tailor-made method for generating it, we can use the cars to cheaply generate electricity. Finally, we can close the loop on this convenient diagram from wikipedia:

Python closures and stack frames

Monday, December 1st, 2008

I use closures quite a lot in python, but the variable lifetime semantics of closures are undocumented as far as I can tell. For example, consider the following code:

    def f():
        a=1
        b=1
        def g():
            return b
        return g

If we call ‘f’ and store the value, ‘b’ will be kept alive. Is ‘a’ kept alive? A naive implementation of closures might store a reference to the entire stack frame of ‘f’ inside the ‘g’ closure, causing ‘a’ to live even though it will never be used. This would be very bad, since generating a closure inside a long function could potentially cause a large memory leak. I wouldn’t expect this since python is implemented by smart people, but it’s worth checking.

Happily, it appears the variable lifetime semantics are as expected. Here’s a test program:

    class A(object):
        def __init__(self,name):
            self.name=name
            print 'creating',name
        def __del__(self):
            print 'destroying',self.name

    def f():
        a=A('a')
        b=A('b')
        c=A('c')
        def g():
            print 'inspecting',b.name
        def h():
            print 'inspecting',c.name
        return g,h

    g,h=f()
    print 'only b and c should be alive'
    del h
    print 'only b should be alive'
    g()
    del g
    print 'done'

The output of this program in CPython is

    creating a
    creating b
    creating c
    destroying a
    only b and c should be alive
    destroying c
    only b should be alive
    inspecting b
    destroying b
    done

All variables die at the correct times, so CPython appears to have correct lifetime semantics in the presence of closures.