On Wed, Sep 3, 2008 at 1:57 PM, Brian Olson <[EMAIL PROTECTED]> wrote: > I checked my code and I'm not doing the expensive square root. It's not > quite the second though, it's actually: > ((dx*dx + dy*dy) * weight) > > The weight gets nudged by multiplying by 1.01 or 0.99. Squaring the weight > or not and how it's nudged is probably just an efficiency issue and not a > correctness issue, it should still get to the weight it needs, just maybe > along some suboptimal curve.
I think it is equivalent anyway. Well, you might have to multiple by 1.02 and 0.98 instead to get the same as weight squared. > I think multiplicative weight makes more sense. No chance of underflow, and > might scale better between districts with different densities. Well, negative distances are fine too :). However, it could mean that the point ends up outside its district. > Yes, the block shape file determines adjacency. They handily label every > line segment with what block is on either side of it, so I can pretty > quickly filter that to keep a list of all pairings I've seen. Ahh, cool. I might have a look at that file again. It just seemed more trouble than it was worth. In my software, I just assume that the people are compressed down to the location point given in the block group table. >Of course I do > also wind up going back and rendering that geometry to an actual map. So, the maps on your site draw the boundary as it using the block-group boundary info? ---- Election-Methods mailing list - see http://electorama.com/em for list info
