[EM] RE : RE : Comments on the Yee/Bolson/et.al. pictures

[Kevin Venzke]

Warren,

--- Warren Smith <wds at math.temple.edu> a écrit :
> Approval with mean-as-threshold seemed to "look bad" in the sense that
> it could prevent some candidates from ever winning, and make their
> winning regions
> lie far away from them if they existed.

We know that Approval is a method that requires strategy to work. In
this case we see the need for nomination strategy. A situation where
the proper winner is an outer candidate, but the actual winner is an
inner candidate, is not a stable situation. Next time, or with better
information, candidates will try to move closer to the median. That, or
voters will do better than use zero-info strategy.

>   (This is assuming I believe the
> pictures
> I saw, which due to incorrect tiebreaking, I don't necessarily.  There
> were also some
> other interesting high-nonconvexity phenomena in tose pictures which
> again I do not
> necessarily believe due to incorrect tiebreaking.)

Well, I gave you in my last post a one-dimensional picture that clearly
showed that candidate A (an outer candidate) had no win region.

Also, again, my simulations do use random tiebreaking. I didn't start
writing my sim until after this issue came up.

> >Why implement normalized range voting? That would just be somewhat off
> >from the SU graph. I'm not even sure you would see the difference.
> 
> It could be quite different.  And I'd like to see how it differs and how
> much
> it differs from the SU graph.  Also, normalized range voting with integer
> scores (0-9, say)
> as opposed to continuum scores, might show some "sawtooth" effects due to
> roundoff to integers, which might also be interesting.

I would bet pretty much anything that you're not going to see jagged saw
teeth when the voters are evenly distributed... I would call that a
symptom of monotonicity failure.

> Finally, for those who want to speed up their code, I suggest this simple
> hack:
> keep enlarging the #voters by a factor of 1.1 each election, until you
> get
> 10 elections in a row all with the same winner, or until you get a large
> enough number of voters
> that you feel like quitting.  The point is, most pixels are elections
> that are "easy to call"
> and you want to terminate fast on those pixels with a fast decision.  The
> hard-to-call-election
> pixels, you perform full work on.  (The value of "1.1" is adjusted to get
> highest speed.)

Thanks for this suggestion.

What I've been doing is generating the graph with horrible resolution, 
and then using a mode, with an increasing number of voters, that 
reconsiders pixels that border other colors. But this mode wastes a lot
of time reconsidering pixels that are already good.

Kevin Venzke


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com