[EM] A computationally feasible method (algorithmic redistricting)

[Raph Frank]

On Wed, Sep 3, 2008 at 1:57 PM, Brian Olson <bql at bolson.org> 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?