[EM] A computationally feasible method (algorithmic redistricting)

[Jonathan Lundell]

I haven't been following this thread in great detail, but I do have a  
question: what is the distance function actually trying to measure and  
minimize? What exactly are we trying to optimize when we minimize  
"distance", by whatever measure? I might be close in a crow's-flight  
sense to a neighbor on the other side of a river or freeway with a  
driving distance of several miles.

OK, we could solve that in principle (though not too quickly) by using  
Google Maps driving time, or the like. But what does driving time have  
to do with grouping voters (unless we're drawing a precinct and  
measuring travel time t the polling place)? Maybe we mean  
communication: two people with telephones are closer in this sense  
than people without (and people with unlimited long distance are close  
in this sense independent of cartesian distance).

I live in several voting districts where geographical lines make  
sense--my local fire district is a case in point, as would water and  
sewerage (except that I provide my own in those cases, as it happens).  
But legislative districts? I can't think what I'm trying to optimize  
for which straight-line vs manhattan distance would be relevant. I've  
never met my representatives on business; I communicate with them via  
email or telephone, and I neither know nor care where there local  
offices are.

On Sep 3, 2008, at 12:17 PM, Raph Frank wrote:

> 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?
> ----
> Election-Methods mailing list - see http://electorama.com/em for  
> list info