<div dir="ltr"><div><div>Yes, the definition of Simmons' method, MDDA(pt/2) should be added to Electowiki.<br><br></div>Should Forest get the first option to do that?<br><br></div><div>Michael Ossipoff<br><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 21, 2016 at 6:29 PM, Monkey Puzzle <span dir="ltr"><<a href="mailto:araucaria.araucana@gmail.com" target="_blank">araucaria.araucana@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Forest, Michael, Chris:</div><div><br></div><div>It seems that you are converging toward consensus on a modified version of ICA that is equivalent to MDDTR(pt/2), if </div><div><br></div><div>Both these methods have scattered definitions on the list that go back years, and the current discussion has moved toward something different than the ICA description here: <a href="http://wiki.electorama.com/wiki/Improved_Condorcet_Approval" target="_blank">http://wiki.electorama.com/<wbr>wiki/Improved_Condorcet_<wbr>Approval</a> .</div><div><br></div><div>Would it be possible to have a concise restatement/correction of the method(s) somewhere, preferably on electorama?</div><div><br></div><div>Thank you!</div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div class="m_8769498125928290891gmail_signature" data-smartmail="gmail_signature"> Frango ut patefaciam -- I break so that I may reveal<br></div></div>
<br></span><div class="gmail_quote"><div><div class="h5">On Mon, Nov 21, 2016 at 3:03 PM, Michael Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><span><div>"Just the knowledge that a failure of Mono-add-Plump is
theoretically possible could reduce people's enthusiasm for voting
and make it more<br>
likely that those who like to vote by just plumping for their
favourite will stay home."<br><br></div></span>...or make you rank your favorite last instead of first in IRV because ranking hir first instead of last could make hir lose?<br><br></div><div>...or just not vote because you know that IRV can act oppositely to changes in your vote?<span class="m_8769498125928290891HOEnZb"><font color="#888888"><br></font></span></div><span class="m_8769498125928290891HOEnZb"><font color="#888888"><div><br></div>Michael Ossipoff<br></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sat, Nov 19, 2016 at 12:18 AM, C.Benham <span dir="ltr"><<a href="mailto:cbenham@adam.com.au" target="_blank">cbenham@adam.com.au</a>></span> wrote:<br></span><div><div class="m_8769498125928290891h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224moz-cite-prefix"><span>On 11/19/2016 3:14 AM, Michael Ossipoff
wrote:<br>
<blockquote type="cite">If the more embarrassing Mono-Raise
failure doesn't give IRV any acceptance or enactment problem,
then why should the less embarrassing Mono-Add-Plump failure of
MDDTR give MDDTR an acceptance or enactment problem?</blockquote>
<br></span>
Because what you consider more or less "embarrassing" I am sure
isn't in accord with what most people would find unacceptably
ridiculous. <br><span>
<br>
<blockquote type="cite">With MDDTR, if your plump for X makes X
lose, it's because you added a ballot. It has nothing whatsoever
to do with the fact that you voted favorably to X.</blockquote>
<br></span>
That's right. "You" should have found some way to vote for X
without adding a ballot. Unfortunately removing someone else's
ballot when you are in the <br>
polling station is usually impossible or legally risky.<span><br>
<br>
<blockquote type="cite">Anyway, if IRV is so widely used and
successful, then why would nonmonotonicity be a problem for
MDDTR?</blockquote>
<br></span>
Because IRV has a traditional and (for many) intuitive algorithm,
and a solid "maximal" set of criterion compliances and MDDTR
doesn't.<br>
<br>
Earlier you attempted to ridicule my observation that MDDTR fails
Irrelevant Ballots Independence by suggesting that might
indirectly motivate a higher<br>
turnout. Well, just as some might have an interest in promoting
that (for voters who'll ignore the competitive/viable candidates)
so as to wash away<br>
an otherwise likely majority-defeat disqualification so would
opposed forces have an interest in doing the opposite.<br>
<br>
In fact you could have post-election recriminations reminiscent of
those that were aimed at Nader and those who voted for him
supposedly allowing Bush to<br>
win a few years ago. "Those idiots weren't even really interested
in who won, why didn't they just stay home?!" could be the lament.<br>
<br>
Just the knowledge that a failure of Mono-add-Plump is
theoretically possible could reduce people's enthusiasm for voting
and make it more<br>
likely that those who like to vote by just plumping for their
favourite will stay home.<br>
<br>
Whereas IRV doesn't just meet mono-add-plump. It also meet
Mono-add-Top.<br>
<br>
<blockquote type="cite">C: Failing mono-add-plump is as stupid as
a quasi-"intelligent" device can be, in a pure and starkly
obvious way, and with the lamest possible excuse.<br>
<br>
The algorithm/device decides that X should win, and then
receives some more ballots that contain nothing whatsoever but
the pure and simple message:<br>
"You are right! X should win" and responds with the bizarre
malfunction "I've changed my mind, Y should win" and offers the
nonsensical excuse "Hey those<br>
extra ballots didn't just say that X should win. They also
increased the total number of ballots!".<br>
<br>
<br>
<blockquote type="cite">C: What (arguably) desirable properties
(or criterion compliances) are incompatible with meeting
Mono-add-Plump?<br>
<div><br>
</div>
<div>Mike: FBC, CD, & wv-like strategy are evidently
require failing Mono-Add-Plump, or having MMPO's
Hitler-with-2-votes problem.<br>
<br>
</div>
With MDDTR, the price of FBC, CD & wv-like strategy is
Mono-Add-Plump.</blockquote>
<br>
C: There are methods that meet FBC and CD and mono-add-plump.
So your proposition boils down to saying that it's worth giving
up compliance with <br>
mono-add-plump just to gain "wv-like strategy".</blockquote>
<br>
Chris Benham<div><div class="m_8769498125928290891m_-5477982820469109009h5"><br>
<br>
<br>
On 11/19/2016 3:14 AM, Michael Ossipoff wrote:<br>
</div></div></div><div><div class="m_8769498125928290891m_-5477982820469109009h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>I don't mean that IRV isn't ok.
IRV's Mono-Raise failure doesn't
bother me.<br>
</div>
<div>Neither does MDDTR's
Mono-Add-Plump failure. <br>
</div>
<div><br>
</div>
Voting's purpose is probabilistic
anyway. You vote to improve the
probability of a better outcome. The
possible nonmonotonicity of IRV<br>
</div>
& MDDTR doesn't invalidate that.<br>
<br>
</div>
My point, in asking about when you make
someone lose by raising hir from last
place to 1st place, was just that IRV is
popular and widely used. It's been used in
Australia for a long time, and it's used
in a fair number of cities in this
country. ...and now has been adopted by
the state of Maine.<br>
<br>
</div>
...in spite of its Mono-Raise failure.<br>
<br>
</div>
If the more embarrassing Mono-Raise failure
doesn't give IRV any acceptance or enactment
problem, then why should the less embarrassing
Mono-Add-Plump failure of MDDTR give MDDTR an
acceptance or enactment problem?<br>
<br>
</div>
<div>There of course have been objections to
IRV, some valid, some not. But I haven't heard
any of the IRV critics in the various cities
complain about its nonmonotonicity. They
object to implementation complexity. They
invalidly claim voting complexity. They
invalidly complain because supposedly voting
is supposed to be by Plurality. They repealed
IRV in Burlington because of the elimination
of a CWv. But none of the complaints that
I've heard, in cities using it or considering
IRV, have been about its nonmonotonicity.<br>
<br>
</div>
<div>Why I say that Mono-Raise failure is more
embarrassing:<br>
<br>
</div>
With MDDTR, if your plump for X makes X lose,
it's because you added a ballot. It has nothing
whatsoever to do with the fact that you voted
favorably to X.<br>
<br>
</div>
With IRV, if raising X from bottom to top makes X
lose, then X lost for no other reason than because
you helped hir more.<br>
<br>
</div>
There are 2 kinds of nonmonotonicity:<br>
<br>
</div>
Did you make X lose _in spite of_ voting favorably for
hir?<br>
<br>
</div>
or<br>
<br>
</div>
Did you make X lose _because_ you voted hir more
favorably?<br>
<br>
</div>
Of those 2 kinds of nonmonotonicity the 2nd one is more of
an embarrassment to the method. There, the method is more
directly acting oppositely to your action.<br>
<br>
</div>
Maybe it could be said that the 2nd kind of nonmonotonicity is
twice as embarrassing to the voting-system.<br>
<br>
</div>
<div>Anyway, if IRV is so widely used and successful, then why
would nonmonotonicity be a problem for MDDTR?<br>
<br>
</div>
<div>I now feel that IRV's (mitigated) problem isn't an
unusually high price for CD, isn't more than the "going rate"
for CD. IRV & its derivatives are at the top of my ranking
of method-merit for electorates who want &/or need
ranking.<br>
<br>
</div>
<div>Michael Ossipoff<br>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 18, 2016 at 1:23 AM,
Michael Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Forest--<br>
<br>
</div>
You wrote:<br>
<div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
But MAI still fails FBC.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Failing both FBC & CD isn't good.<br>
<br>
</div>
<span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
So to me the best proposal
is ICA with default approval
cutoff at truncation to help
punish burial and truncation
with an option to raise the
cutoff to withstand a CD
attack.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>But buriers or truncators could raise that
approval cutoff too. Someone could bury X
under Z without having to approve Z. That
loses the deterrence that would exist if that
burier had to approve Z in order to rank hir
over someone, as would be so if ranking is
counted as approval.<br>
<br>
</div>
<div>So CD still comes at the cost of a lot less
protection against burial, or, in ICT's case,
trunction too.<br>
<br>
</div>
<div>But that just means that it isn't _better_
than MDDTR in that regard. It doesn't mean
that it's worse.<br>
<br>
</div>
<div>And it doesn't have Mono-Add-Plump failure.<br>
<br>
</div>
<div>So, the method has CD as MDDTR does, and
trades truncation-proofness for
Mono-Add-Plump.<br>
<br>
</div>
<div>I value strategy protections more than
embarrassment criteria. (But I realize that
proposal-opponents can use embarrassment
criteria criticisms, and that proponents
aren't likely to be able to afford as much
media time, to answer the criticisms.)<br>
<br>
</div>
<div>[Replying farther down] :<br>
<br>
</div>
<span>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
Here's my version (slightly
different from the original):<br>
<br>
</div>
Candidate X strongly beats
candidate Y iff<br>
<br>
</div>
the number of ballots on which X
is ranked over Y is greater than<br>
<br>
</div>
the number of ballots on which Y is
<u><i><b>ranked</b></i></u> equal to
or greater than Y.<br>
<br>
</div>
[Note Y is not ranked equal to X if Y
is not ranked.]<br>
<br>
</div>
If not all of the candidates are
strongly beaten, disqualify all of the
ones who are.<br>
<br>
Elect the most approved qualified
candidate.<br>
<br>
</div>
<div>I think that this method has all of
the good properties of MDDA with
mono-add-plump to boot.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>I've only had a preliminary look at it, but
it seems to me, right now, that the separate
approval-cutoff that the voter can raise from
the default spoils protection from burial
& truncation.<br>
<br>
</div>
<span>
<div><br>
</div>
<div>You wrote: <br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>We still need to explore MDDA with
the half power truncation rule, since it
would also satisfy mono-add-plump if I
am not mistaken.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Yes, it seems to me that a 1/2
power-truncation would get rid of the
Mono-Add-Plump failure. If, by not ranking a
certain 2 candidates, you give them each at
least half of a vote against eachother, that
would bring Mono-Add-Plump compliance, it
seems to me.<br>
<br>
</div>
<div>So maybe it would avoid criticism of MDDA.<br>
</div>
<div><br>
</div>
<div>But, if used with MDDTR, it would spoil CD.<br>
<br>
</div>
<span>
<div>You wrote:<br>
<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>I agree with Chris Benham that
mono-add-plump failure would be fatal in
a public proposal.<br>
</div>
</div>
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619HOEnZb">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619h5">
<div class="gmail_extra"><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>What if you're going to rank X last in your
ranking. With all the ballots, including
yours, X will win. But then you move X to 1st
place in your ranking, and that makes X lose.<br>
<br>
</div>
<div>Would that be ok?<br>
<br>
</div>
<div>
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224h5">
<div>Michael Ossipoff<br>
<br>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619HOEnZb">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619h5">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Nov
17, 2016 at 2:12 PM, Michael
Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>I meant to ask: Did you
say that MTRI doesn't pass
FBC? How does FBC failure
happen? In return for FBC,
it should beat MDDTR at
vulnerability to burial,
and not be vulnerable to
truncation.<br>
<br>
</div>
Anyway, anything you can
tell me about the properties
comparison between MTRI
& MDDTR would be
helpful.<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb"><font color="#888888">MIchael
Ossipoff<br>
</font></span></div>
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Thu, Nov 17, 2016 at
5:05 PM, Michael
Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>For this
method, MTRI,
the procedural
definition is
more
understandable
than the
recursive
definition
(though the
recursive
definition's
brevity could
be useful).<br>
<br>
</div>
So this is
what I
understand
MTRI's
procedural
definition to
be:<br>
<br>
</div>
1. Order the
candidates by
their
top-count
score, with
higher scores
at top.<br>
<br>
</div>
2. Switch the
lowest pair of
adjacent
candidates
whose lower
candidate
pair-beats the
higher one.<br>
<br>
</div>
Repeat till
there are no
more pairs to
switch. The
highest
candidate in
the order at
that time
wins.<br>
<br>
------------------------------<wbr>-----------------<br>
<br>
</div>
As a CD rank
method, this
method is a
competitor of
MDDTR. What
are the
property
differences
between MTRI
& MDDTR?<br>
</div>
<br>
</div>
In particular, how
does MTRI compare
with MDDTR in
regards to
protection of a
CWs against
truncation &
burial?<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb"><font color="#888888">Michael
Ossipoff<br>
<br>
</font></span></div>
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb">
<div class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Thu, Nov 17,
2016 at 2:55
PM, Forest
Simmons <span dir="ltr"><<a href="mailto:fsimmons@pcc.edu" target="_blank">fsimmons@pcc.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><span>On
Thu, Nov 17,
2016 at 10:54
AM, Michael
Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span>
wrote:<br>
</span>
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>But
wouldn't
Smith//Approval,
with approval
cutoffs in the
rankings,
share MDDTR's
burial-vullnerability?<br>
<br>
</div>
...with,
additionally,
vulnerability
to truncation,
which MDDTR
_doesn't_
have?<br>
<br>
</div>
And
Smith//Approval
trades MDDTR's
FBC for Smith,
which I
consider an
unfavorable
trade.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Perhaps
make
truncation the
default
approval
cutoff, but
let voters
move it higher
as an option:<br>
<br>
</div>
<div>45 C<br>
</div>
<div>30 A>B
or A>>B<br>
</div>
<div>25 B<br>
<br>
</div>
<div>Voting
A>>B
would be the
chicken
defense (where
sincere is 25
B>A).<br>
<br>
</div>
<div>Voting
A>B would
be the
truncation
defense (where
sincere is 45
C>B).<br>
<br>
</div>
<div>With this
option, MDDA
would be an
FBC compliant
method that is
truncation and
burial
resistant as
well as quasi
CD compliant.<br>
<br>
</div>
<div>Is there
a way to
modify MDDA to
make it
satisfy
mono-add-plump?<br>
<br>
</div>
<div>How about
incorporating
some form of
power
truncation.
When you plump
X and reduce
the majority
victory of Y
over Z to a
sub-majority,
it would
revert to a
majority if
you counted
the common
truncation of
Y and Z
against each
other as even
half a point.<br>
<br>
</div>
<div>Btw, in
case you
didn't see it,
one of my new
favorite
non-FBC
methods is
Most Approved
Immune(MAI):
Elect the most
approved
immune
candidate.<br>
<br>
</div>
<div>This
means elect
the most
approved
candidate X
that is
unbeaten
pairwise by
the candidate
that would win
(recursively)
if the method
were applied
to the same
ballot set
with X
disqualified
or withdrawn.<br>
<br>
</div>
<div>It is the
simplest
approval based
rank method
that confers
immunity from
second place
complaints on
its winners.<br>
<br>
</div>
<div>It is
quasi CD
compliant if
voters can
specify their
approval
cutoffs above
the truncation
level when
they want to.<br>
<br>
</div>
<div>A top
rank version
of this method
is fully CD
compliant:<br>
<br>
</div>
<div>Elect the
Most Top
Ranked Immune
candidate.
(MTRI)<br>
<br>
</div>
<div>In other
words elect
the most top
ranked
candidate X
that is
unbeaten
pairwise by
the candidate
that would win
(recursively)
if the method
were applied
to the same
ballot set
with X
disqualified
or withdrawn.<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350m_7800393914769801655HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
<span class="m_8769498125928290891m_-5477982820469109009m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350m_7800393914769801655HOEnZb"><font color="#888888">
<div>Forest<br>
</div>
</font></span></div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p color="#000000" align="left"><br>
</p>
</blockquote>
<p><br>
</p>
</div></div></div>
</blockquote></div></div></div><br></div>
<br></div></div><span class="">----<br>
Election-Methods mailing list - see <a href="http://electorama.com/em" rel="noreferrer" target="_blank">http://electorama.com/em</a> for list info<br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>