From moth@debian.org Wed Dec 20 21:31:43 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7932 invoked from network); 20 Dec 2000 21:31:43 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 20 Dec 2000 21:31:43 -0000 Received: (qmail 25716 invoked by uid 1000); 20 Dec 2000 21:31:32 -0000 Date: Wed, 20 Dec 2000 16:31:32 -0500 From: Raul Miller To: Norman Petry Cc: 'Steve Greenland' , 'Rob Lanphier' , 'Mike Ossipoff' , 'Buddha Buck' , 'Anthony Towns' Subject: p.s. Message-ID: <977347770.5efe3c41@debian.org> References: <001101c06a3d$6deef4e0$d2164818@mandos.accesscomm.ca> <000e01c06ab3$9d8c9420$4d01a8c0@archives.gov.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000e01c06ab3$9d8c9420$4d01a8c0@archives.gov.sk.ca>; from npetry@accesscomm.ca on Wed, Dec 20, 2000 at 12:35:22PM -0600 X-Evolution: 00000001-0010 p.s. I just read the debian weekly news, where Joey annouced that we're defering the voting fixups until this committee is ready. If we're reasonably confident that we can actually have something ready in a month, and there's no interest from other developers, I'll be happy to let my current proposal sit idle. Thanks, -- Raul From bmbuck@14850.com Wed Dec 20 22:26:44 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14114 invoked from network); 20 Dec 2000 22:26:44 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 20 Dec 2000 22:26:44 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Wed, 20 Dec 2000 17:26:37 -0500 Message-Id: <5.0.0.25.0.20001220160925.02921a80@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 20 Dec 2000 22:26:35 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 20 Dec 2000 17:25:28 -0500 To: "Norman Petry" , "'Norman Petry'" , "'Steve Greenland'" , "'Rob Lanphier'" , "'Mike Ossipoff'" , "'Anthony Towns'" , "'Raul Miller'" From: Buddha Buck Subject: Resolve Supermajority Problems In-Reply-To: <000e01c06ab3$9d8c9420$4d01a8c0@archives.gov.sk.ca> References: <001101c06a3d$6deef4e0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Evolution: 00000002-0010 I think I'll start the ball rolling by asking a rather general, but important, question: What does the concept of "Supermajority" mean in the context of ranked ballots? (For that matter, what does "majority" mean in that context? I'm sure that issue has been discussed on the EM list before, I just haven't seen it.) Does "supermajority" even have a useful mean in pairwise votes? And if not, how do we reconcile the 3:1 supermajority requirements with the desire to stay with a pairwise voting method? Especially if, as we seem to want to do, we eliminate two-stage voting? I don't think we have any way, just looking at the rankings, to determine if a voter would support or oppose his second choice on a ballot -- only that the voter would prefer his second choice to his third. As an extreme example, most people would rank receiving a $1,000,000 prize higher than a $1,000 prize higher than a $1,000,000 fine, and would approve of the first two. If it was a $1,000 fine instead of a $1,000 prize, the ranking would be the same, but only the first would likely be approved. Or, to go for a more relevant example, say an amendment X is proposed and seconded. An objection is raised that X would require Y as well, or it doesn't make sense. The original proposer of X disagrees, but the objector gets enough seconds to force X+Y on the ballot as well. (This is similar in form to the current Branden/Srivastava amendments, but not exactly identical). If the ballots say that 60% prefer X to X+Y to the Status Quo, and 40% prefer X+Y to X to the Status Quo, should Status Quo win? Everybody preferred both forms of amendment to Status Quo... I'd like to suggest a principle or criterion we may want to try to satisfy: Buck Supermajority Criterion: If an option would not win in the absence of a Supermajority requirement, that option should not win in the presence of a Supermajority requirement. From nkklrp@hotmail.com Thu Dec 21 04:20:59 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8649 invoked from network); 21 Dec 2000 04:20:59 -0000 Received: from law-f141.hotmail.com (HELO hotmail.com) (209.185.131.204) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 04:20:59 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 20:20:57 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Thu, 21 Dec 2000 04:20:56 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, moth@debian.org Subject: withdrawing suggestion to report early Date: Thu, 21 Dec 2000 04:20:56 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Dec 2000 04:20:57.0122 (UTC) FILETIME=[6A71B820:01C06B05] X-Evolution: 00000003-0010

Norm's arguments for why we should deal with all the agenda issues before reporting

to Debian sound reasonable.

 

Of course there are a few issues on the agenda that have been called open-ended, things

that aren't as urgent, and that are more a matter of opinion than fixes for glaring faults.

If some of those are at the bottom of the agenda (I'll take another look), then, when we get

to those, I'll move, at that time, to report before continuing.

 

Mike

 

 

 

 

Mike Ossipoff



Get your FREE download of MSN Explorer at http://explorer.msn.com

From nkklrp@hotmail.com Thu Dec 21 04:37:15 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31522 invoked from network); 21 Dec 2000 04:37:15 -0000 Received: from law-f17.hotmail.com (HELO hotmail.com) (209.185.131.80) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 04:37:15 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 20:37:12 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Thu, 21 Dec 2000 04:37:12 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: My ballot for the Agenda Vote Date: Thu, 21 Dec 2000 04:37:12 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Dec 2000 04:37:12.0553 (UTC) FILETIME=[AFD8AD90:01C06B07] X-Evolution: 00000004-0010



 

Though Concorde isn't well-defined in the Constitution, it's still in use, apparently because

people are interpreting the  Constitution's wording according to its intent rather than

closely looking at its meaning. So even if Concorde has to be used one more time

before the voting system is reformed, that wouldn't be so bad. Concorde doesn't meet

Smith, but it does meet the Condorcet Criterion.

As Norm said, we can do a lot better than just Smith, and it might be difficult to get

people to agree to change the voting system again, after they replace Concorde with

your proposed method.

 

>However, if you can show that my proposed method fails to satisfy either

>smith or condorcet

Would you send me a copy of the definition of the voting system that you propose,

so that I can check it out?

 

Mike

 



Get your FREE download of MSN Explorer at http://explorer.msn.com

From moth@debian.org Thu Dec 21 04:48:41 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14532 invoked from network); 21 Dec 2000 04:48:41 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 04:48:41 -0000 Received: (qmail 31104 invoked by uid 1000); 21 Dec 2000 04:48:30 -0000 Date: Wed, 20 Dec 2000 23:48:30 -0500 From: Raul Miller To: Buddha Buck Cc: Norman Petry , 'Steve Greenland' , 'Rob Lanphier' , 'Mike Ossipoff' , 'Anthony Towns' Subject: Re: Resolve Supermajority Problems Message-ID: <977373809.c1494a70@debian.org> References: <001101c06a3d$6deef4e0$d2164818@mandos.accesscomm.ca> <000e01c06ab3$9d8c9420$4d01a8c0@archives.gov.sk.ca> <5.0.0.25.0.20001220160925.02921a80@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <5.0.0.25.0.20001220160925.02921a80@armstrong.cse.buffalo.edu>; from bmbuck@14850.com on Wed, Dec 20, 2000 at 05:25:28PM -0500 X-Evolution: 00000005-0010 On Wed, Dec 20, 2000 at 05:25:28PM -0500, Buddha Buck wrote: > I think I'll start the ball rolling by asking a rather general, but > important, question: > > What does the concept of "Supermajority" mean in the context of ranked ballots? How about starting with "What does the concept of Supermajority mean"? > (For that matter, what does "majority" mean in that context? I'm sure that > issue has been discussed on the EM list before, I just haven't seen it.) > > Does "supermajority" even have a useful mean in pairwise votes? And if > not, how do we reconcile the 3:1 supermajority requirements with the desire > to stay with a pairwise voting method? Especially if, as we seem to want > to do, we eliminate two-stage voting? Supermajority is a mechanism to make certain options less likely than others. Ideally, we (debian) should be focusing on package-maintenance issues more than changing the rules we use to make decisions. Thanks, -- Raul From nkklrp@hotmail.com Thu Dec 21 05:01:22 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31453 invoked from network); 21 Dec 2000 05:01:22 -0000 Received: from law-f111.hotmail.com (HELO hotmail.com) (209.185.131.174) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 05:01:22 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 21:01:19 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Thu, 21 Dec 2000 05:01:18 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org Cc: nkklrp@hotmail.com Subject: Re: Resolve Supermajority Problems Date: Thu, 21 Dec 2000 05:01:18 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Dec 2000 05:01:19.0966 (UTC) FILETIME=[0E925FE0:01C06B0B] X-Evolution: 00000006-0010

Buddha Buck wrote:

 

>What does the concept of "Supermajority" mean in the context of
>ranked ballots?

Say we're talking about changes to the Constitution, where the 3:1 supermajority

applies. Then, the winning alternative, in addition to winning according to the

voting system's count rule, must also beat the status-quo by 3:1. Three times as many

people must vote the winner over the status quo than vice-versa.

 

In making out their rankings each voter has the opportunity to express his pairwise

preference between each pair. Those pairwise counts, then, tell the same information that

we'd get if we held a separate election between the winner and the status-quo.

 

Likewise for a simple majority, for those elections where a simple majority requirement

applies: For an alternative to win, not only must it win by the count's rules, but it must

also have a majority of all the voters ranking it over the status-quo.

 

That's what supermajority & majority mean in a pariwise-count method.

 

 

 

>

>

>Does "supermajority" even have a useful meaning in pairwise votes?

Absolutely. As I described above. Two-stage voting isn't needed to incorporate

the supermajority in the voting system.

 

>I don't think we have any way, just looking at the rankings, to

>determine
>if a voter would support or oppose his second choice on a ballot --
>only

>that the voter would prefer his second choice to his third.

Voting is relative. What we must know is if, by a 3:1 ratio, people prefer the winner

to the status quo--if they support the winner as a replacement for the status quo.

 

>Or, to go for a more relevant example, say an amendment X is
>proposed and
>seconded. An objection is raised that X would require Y as well, or
>it
>doesn't make sense. The original proposer of X disagrees, but the
>objector
>gets enough seconds to force X+Y on the ballot as well. (This is
>similar
>in form to the current Branden/Srivastava amendments, but not
>exactly
>identical). If the ballots say that 60% prefer X to X+Y to the
>Status Quo,
>and 40% prefer X+Y to X to the Status Quo, should Status Quo
>win? Everybody preferred both forms of amendment to Status Quo...

If those are Constitutional amendments, with the 3:1 supermajority requirement, then

the status quo is kept, because the winner, X, doesn't beat the status quo 3:1.

 

Any good count rule would pick X as the winner, since it's the favorite of a majority.

But the 3:1 supermajority rule says that nothing should replace the status quo unless the

voters express preference for it over the status-quo by a 3:1 ratio.

 

>

>I'd like to suggest a principle or criterion we may want to try to
>satisfy:
>
>Buck Supermajority Criterion: If an option would not win in the
>absence of
>a Supermajority requirement, that option should not win in the
>presence of
>a Supermajority requirement.

If win doesn't mean the same as "get enacted", then your criterion would be part of

the proper wording of the supermajority requirement. If the winner of the voting system's

count rule is voted over the status quo by a 3:1 ratio, then it replaces the status quo.

If not, then the status quo remains in effect and isn't replaced by anything.

 

Of course whether the count rule's winner is voted over the status quo by a 3:1 ratio

is determined by checking whether or not it is ranked over the status quo by 3 times as

many voters as vice-versa.

 

Mike Ossipoff

 



Get your FREE download of MSN Explorer at http://explorer.msn.com

From aj@azure.humbug.org.au Thu Dec 21 05:23:41 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27266 invoked from network); 21 Dec 2000 05:23:41 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 05:23:41 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 148yCB-0006VB-00; Thu, 21 Dec 2000 15:23:15 +1000 Date: Thu, 21 Dec 2000 15:23:15 +1000 From: 'Anthony Towns' To: Buddha Buck Cc: Norman Petry , 'Steve Greenland' , 'Rob Lanphier' , 'Mike Ossipoff' , 'Raul Miller' Subject: Re: Resolve Supermajority Problems Message-ID: <20001221152315.B24780@azure.humbug.org.au> References: <001101c06a3d$6deef4e0$d2164818@mandos.accesscomm.ca> <000e01c06ab3$9d8c9420$4d01a8c0@archives.gov.sk.ca> <5.0.0.25.0.20001220160925.02921a80@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20001220160925.02921a80@armstrong.cse.buffalo.edu>; from bmbuck@14850.com on Wed, Dec 20, 2000 at 05:25:28PM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000007-0030 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2000 at 05:25:28PM -0500, Buddha Buck wrote: > I think I'll start the ball rolling by asking a rather general, but=20 > important, question: >=20 > What does the concept of "Supermajority" mean in the context of ranked=20 > ballots? [...] > I'd like to suggest a principle or criterion we may want to try to satisf= y: >=20 > Buck Supermajority Criterion: If an option would not win in the absence = of=20 > a Supermajority requirement, that option should not win in the presence o= f=20 > a Supermajority requirement. Is that only if it's that particular option that needs a supermajority? What happens if a 2:1 supermajority is added to that option, and a 3:1 supermajority is added to the original winner? Another possibility: (making up a name as I go) Minority Veto Criterion: Given a supermajority requirement of N:M, a minority of M voters from every (M+N) voters must be able to vote such that that option doesn't win. ie, if you have a 3:1 supermajority on an option, a 25% minority must be able to block that option. If there are two or three different options with a 3:1 supermajority, the same 25% minority must be able to block any or all of them. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkGTw+RRvX9xctrtAQEhjwP+Jv4uU/sDkKv1sspSsHOm2QQ3bOsb85bI WhNzgCPRl5FIpydIGWWl+ma0DoqyCOw39wxkw4GbJgL9GmwIhx3lyQxGJnvdIuVK K59gAymLwAY96pLOFS2vdgwpHk7wbKBtbzqnKXlXE29ruw8bFqbPDzfwuauir2Hy t7Gv1mN5dZE= =OKmk -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From nkklrp@hotmail.com Thu Dec 21 05:59:02 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3291 invoked from network); 21 Dec 2000 05:59:02 -0000 Received: from law-f87.hotmail.com (HELO hotmail.com) (209.185.131.150) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 05:59:02 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 21:58:59 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Thu, 21 Dec 2000 05:58:59 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au, bmbuck@14850.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, moth@debian.org Subject: Re: Resolve Supermajority Problems Date: Thu, 21 Dec 2000 05:58:59 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Dec 2000 05:58:59.0502 (UTC) FILETIME=[1C9DACE0:01C06B13] X-Evolution: 00000008-0010



> Minority Veto Criterion: Given a supermajority requirement of N:M,
> a minority of M voters from every (M+N) voters must be able to vote
> such that that option doesn't win.
>
>ie, if you have a 3:1 supermajority on an option, a 25% minority must be
>able to block that option. If there are two or three different options
>with a 3:1 supermajority, the same 25% minority must be able to block any

>or all of them.

If only 25% vote the status quo over X, then that shouldn't be enough to block X being

adopted, if X is the winner of the voting system's count rule. A 3:1 supermajority rule

is complied with if X beats the status-quo 75% to 25%. But anything over 25% of course

would be enough to block X from replacing the status quo.

 

Mike

 



Get your FREE download of MSN Explorer at http://explorer.msn.com

From robla@eskimo.com Thu Dec 21 09:01:54 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1655 invoked from network); 21 Dec 2000 09:01:54 -0000 Received: from mx2.eskimo.com (204.122.16.49) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 09:01:54 -0000 Received: from eskimo.com (robla@eskimo.com [204.122.16.13]) by mx2.eskimo.com (8.9.1a/8.8.8) with ESMTP id BAA14719; Thu, 21 Dec 2000 01:01:19 -0800 (PST) Received: from localhost (robla@localhost) by eskimo.com (8.9.1a/8.9.1) with ESMTP id BAA24320; Thu, 21 Dec 2000 01:01:16 -0800 (PST) X-Authentication-Warning: eskimo.com: robla owned process doing -bs Date: Thu, 21 Dec 2000 01:01:15 -0800 (PST) From: Rob Lanphier To: MIKE OSSIPOFF cc: bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, aj@azure.humbug.org.au, moth@debian.org Subject: Re: Resolve Supermajority Problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Evolution: 00000009-0010 I'll second Mike's Supermajority Proposal #1. Rob On Thu, 21 Dec 2000, MIKE OSSIPOFF wrote: > Date: Thu, 21 Dec 2000 05:47:07 -0000 > From: MIKE OSSIPOFF > To: bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org > Subject: Re: Resolve Supermajority Problems > > > > > I agree about the desirability of getting the ball rolling right away, > and in fact I'd like > to give it another kick: I move that the supermajority rule > interpretation that I proposed > in my previous posting be immediately adopted by the committee, and that > we move on > to the next agenda item. I'll call it supermajority proposal #1. > > Obviously if more discussion is needed then you won't agree with my > motion. But if > you agree that that's what supermajority means in a pairwise-count > method, and if > the motion is seconded by 3 people, then it already has a "Yes" majority > and should > pass. > > The reason why I'm trying to hurry things along is because 2 people have > suggested the > goal that we finish in a month, and even that it's important that we > finish in a month. > > My argument for my proposal is that what it means to support a > replacement for the > status quo is to vote that replacement over the status quo. If you > vote that you like the > replacement better than the status quo, then you're supporting it as a > replacement to > the status quo. If there were a 2-altenative election between > that replacement & the > status quo, you'd vote for the replacement instead of the status quo, if > you ranked the > replacement over the status quo. > > And the pairwise count shows how each alternative fares against each one > of the others. > The pairwise-count will show whether 3 times as many people indicate > preference for X > over the status quo than vice-versa. That's what a supermajority > requirement asks for. > > So here's my proposal again--Supermajority proposal #1: > > If the required supermajority is 3:1, then, for pairwise count methods, > that means that: > > If, when the rankings are counted, and a winner is found according the > voting system's > count rule, then, if 3 times as many voters have ranked that winner over > the status-quo > than vice-versa, then that winner replaces the status quo. Otherwise > nothing replaces the > status quo, and the status quo remains in effect. > > [end of proposal] > > Does anyone second this proposal? 3 people second it, then it already has > a "Yes" > majority and should be adopted. If fewer than 3 but more than zero second > it, and > no more proposals are proposed, then doesn't that mean we vote Y/N on it? > > The question is how long the waiting period is for seconds or alternative > proposals. > > If we're going to finish in a month, with 17 issues, then we can't spend > more than 2 days > per issue. Does that mean that seconds or alternative proposals should > have to appear on > the following day? Or how about this suggestion which sounds to me like > the most > streamlined way to proceed?: > > Ordinarily, work on an agenda issue begins on the day when the previous > agenda item > is resolved. In the case of the 1st item, say work begins tomorrow, the > day after Mr. Buck > suggested that discussion begin. > > On the day when work begins on an agenda issue, members may distribute > proposals to > the committee. Upon receiving the proposals, a member may call for > discussion &/or rank > the proposals (the status quo is one of the proposals). If it turns out > that a majority call > for discussion, then the votecount is postponed. Otherwise the rankings > are immediately > counted by Schulze's method, which the EM members of this committee agree > is the > best rank-count for small committees, for choosing 1 alternative from > among several. > On the following day the Schulze winner is reported, & that winner is > automatically adopted as > the committee's proposal on that issue. That same day is the day when > work on the > next agenda issue begins, the day on which proposals are distributed. > > So it would be: > > Day 1, proposals > > Day 2, voting & calling for discussion. > > The following > day, when the vote result is reported (if there wasn't a majority calling > for discussion) > becomes day 1 for the next agenda issue. > > [end of proposal] > > I'm suggesting that procedure because it seems to me that that, or > something very > similar to it, is needed if we're to finish within about a month. Even > so, it would take > 34 days, even if no issue is discussed. Because it's going to be so > difficult to finish in a month, > or even close to it, I suggest that something like the procedure I > describe is needed. I > propose the procedure that I described above in this letter. > > I'm only suggesting this procedure if it's necessary to finish in about a > month. If it's ok to expect > to take 2 or 3 months, then I withdraw this procedure proposal. I guess I > feel as if there's > a hurry, because an interim proposal is going to be proposed to Debian if > we don't > expect to finish in about a month. > > > Mike > > > ________________________________________________________________________________ > > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > Rob Lanphier robla@eskimo.com http://www.eskimo.com/~robla From bmbuck@14850.com Thu Dec 21 12:52:56 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 10782 invoked from network); 21 Dec 2000 12:52:56 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 12:52:56 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 5DFEA15970; Thu, 21 Dec 2000 07:52:55 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: nkklrp@hotmail.com Cc: bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org, bmbuck@zaphod.datahold.home Subject: Re: Resolve Supermajority Problems In-Reply-To: Message from "MIKE OSSIPOFF" of "Thu, 21 Dec 2000 05:47:07 GMT." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Dec 2000 07:52:55 -0500 From: Buddha Buck Message-Id: <20001221125255.5DFEA15970@zaphod> X-Evolution: 0000000a-0010 Mike, can you please not send HTML? >
So here's my proposal again--Supermajority proposal #1:
>
 
>
If the required supermajority is 3:1, then, for pairwise count methods, that means that:
>
 
>
If, when the rankings are counted, and a winner is found according the voting system's
>
count rule, then, if 3 times as many voters have ranked that winner over the status-quo
>
than vice-versa, then that winner replaces the status quo. Otherwise nothing replaces the
>
status quo, and the status quo remains in effect.
>
 
>
[end of proposal]
Scenario: At the end of the vote, there are three options in the Smith Set, A, B and C. A is an amendment (3:1 requirement), B and C are resolutions (no 3:1 requirement). A wins, but defeats the Status Quo 70:30, not 75:25, so fails the super majority requirement. B would have won if A was eliminated, and has no super majority requirement. (Alternatively, Amendment A is the Condorcet Winner. Resolution B is defeated only by A. Amendment A defeats the Status Quo 70:30, and fails the Supermajority test. In A's absence, B would have been the Condorcet winner, and thus adopted.) Why should B not be adopted? I propose a modification to Mike's proposal, specifically: If the required supermajority is N:M, then, for pairwise count methods, that means that: If, when the rankings are counted, and a winner is found according to the voting system's count rule, then if N/M times as many voters have ranked that winner over the status-quo, the the winner replaces the status quo. Otherwise, the winner is eliminated from the ballots, and the ballots are recounted. Two changes from Mike's proposal: 1) generalizes the supermajority requirement to other than 3:1, and 2) does not automatically choose the Status Quo if the vote-count winner fails supermajority. -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From npetry@accesscomm.ca Thu Dec 21 14:42:12 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 18223 invoked from network); 21 Dec 2000 14:42:12 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 14:42:12 -0000 Message-ID: <001801c06b5c$262b2960$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Raul Miller" Cc: , , , , , "Norman Petry" Subject: Re: My ballot for the Agenda Vote Date: Thu, 21 Dec 2000 08:41:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 0000000b-0010 Raul Miller wrote: >> before submitting your personal proposal again. It's certainly possible >> that at the end of our deliberations you will prefer your own voting method >> to the one selected by the committee (people tend to become attached to >> their own creations, even when they're flawed). If that happens, there is >> still the opportunity to present your method as a counterproposal to the one >> offered by us. > >I'd be happy to wait, if that wait wouldn't be too long. > >However, I think we need an interim mechanism to use, until that point. >The problem we currently have is that there are ambiguities in the >constitution where it's possible to interpret it such that our current >practices are unconstitutional. > I don't think you do. The only important issue which is currently outstanding is to deal with the question of whether or not developers have the authority to amend the dfsg. As far as I know, there are currently two proposals on the table for resolving this ambiguity (Manoj's and Branden's). Debian's current rules can easily cope with a decision between two choices (there can never be a voting cycle), and there is no ambiguity as to how supermajorities are to be handled in this case. Simply conduct a pairwise vote between the two options, and then have the 2nd-stage ratification vote. Of course, it is certainly possible that the 'what if...' scenario I described in our agenda (1. SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY) will come to pass, which should provide a strong incentive for adopting our proposed change. It seemed to me that both you and Anthony agree that there is no real obstacle to proceeding with deciding this question. On December 18 you wrote: "While we're voting on fixing the balloting mechanism, let's use A.3(1) and A.3(2) to vote. In other words, we pick one choice and then have a final ballot to decide if it's acceptable. That will avoid the balloting ambiguity, and is likely to avoid the vote tallying ambiguities. And, we hope that we don't run into a balloting ambiguity (about a 95% chance, according to Norman Petry)." -- http://lists.debian.org/debian-vote-0012/msg00090.html This argument applies equally well to the consideration of the two proposals mentioned above. Furthermore, cyclic ties are impossible with two choices, so the only possible tie that could occur is a pairtie, and the STV mechanism can cope with pairties. Anthony's reply seems to indicate that he doesn't see any problems with deciding these questions under the current rules either; see -- http://lists.debian.org/debian-vote-0012/msg00096.html So why not just go ahead and advise Manoj and Branden to make their proposals, finish the discussion, and decide this question? I can't see that the current constitution presents any real obstacle to resolving this problem. If 'further discussion' wins out over the majority-preferred alternative in the final ballot, and the ambiguity is unresolved, then our proposal for dealing with this new constitutional crisis will be very timely. However, it cannot be argued that the current rules are *ambiguous* as to how this issue would be resolved, although one can certainly argue that a bad choice might be made, that is only supported by a minority. However, that seems to be the point of having supermajority rules. >The change I proposed (which I believe satisfies both smith and condorcet) >is important to avoid an indefinite stall while we wait on the results >of this committee. > >I've been proposing my change as a temporary fix, until we can hear back >from this committee. > But isn't changing the constitution a major hassle? Are people going to want to look at the issue again in a month or two, if they've already had to vote on related changes now? >> Honestly, I suspect that most developers would be quite relieved if this >> discussion disappears for a while from debian-vote, and also that if/when it >> resurfaces, they will be able to decide all the outstanding issues once and >> for all, rather than piecemeal. > >Private email I've gotten suggests that a temporary fix would be a >good thing. > >However, if you can show that my proposed method fails to satisfy either >smith or condorcet, and if you can give a reasonably solid promise to >have a draft ready in a month, then I'll withdraw my proposal and wait >till this time next month before suggesting anything further. > The latest revision of your method certainly satisfies Smith, since you now are now using its definition as part of your method: "5. The smallest set of options, such that every option in that set beats every option outside of that set is identified. All options outside this set are eliminated." This is a clear and correct definition of Smith, so whatever else your method may do, the question of whether or not it meets the Smith criterion is no longer in doubt. Furthermore, since any method which satisfies the Smith criterion is guaranteed to also satisfy the 'Condorcet Winner criterion' and the 'Condorcet Loser criterion', that test is met now also (The Smith criterion is sometimes also referred to as the 'Generalised Condorcet Criterion' for this reason). -- Norm Petry From moth@debian.org Thu Dec 21 14:56:53 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2091 invoked from network); 21 Dec 2000 14:56:53 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 14:56:53 -0000 Received: (qmail 6824 invoked by uid 1000); 21 Dec 2000 14:56:43 -0000 Date: Thu, 21 Dec 2000 09:56:43 -0500 From: Raul Miller To: Norman Petry Cc: nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: My ballot for the Agenda Vote Message-ID: <977410428.f34047ac@debian.org> References: <001801c06b5c$262b2960$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001801c06b5c$262b2960$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Thu, Dec 21, 2000 at 08:41:48AM -0600 X-Evolution: 0000000c-0010 On Thu, Dec 21, 2000 at 08:41:48AM -0600, Norman Petry wrote: > I don't think you do. The only important issue which is currently > outstanding is to deal with the question of whether or not developers have > the authority to amend the dfsg. As far as I know, there are currently two > proposals on the table for resolving this ambiguity (Manoj's and Branden's). > Debian's current rules can easily cope with a decision between two choices > (there can never be a voting cycle), and there is no ambiguity as to how > supermajorities are to be handled in this case. Simply conduct a pairwise > vote between the two options, and then have the 2nd-stage ratification vote. > Of course, it is certainly possible that the 'what if...' scenario I > described in our agenda (1. SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL > AMBIGUITY) will come to pass, which should provide a strong incentive for > adopting our proposed change. And what happens if we're in the middle of that vote when you propose we change the voting system? There are two votes which would need to take place for this. Each could take over a month, with discussion. If we're actually going to get this done in a month, then we should postpone the DFSG vote till after we've got the voting system nailed down, while if this proposal is going to be independent of debian, then debian should have something in the meantime. Thanks, -- Raul From moth@debian.org Thu Dec 21 14:59:28 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4966 invoked from network); 21 Dec 2000 14:59:28 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 14:59:28 -0000 Received: (qmail 6912 invoked by uid 1000); 21 Dec 2000 14:59:18 -0000 Date: Thu, 21 Dec 2000 09:59:18 -0500 From: Raul Miller To: Buddha Buck Cc: nkklrp@hotmail.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org, bmbuck@zaphod.datahold.home Subject: Re: Resolve Supermajority Problems Message-ID: <977410621.680e8d7f@debian.org> References: <20001221125255.5DFEA15970@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001221125255.5DFEA15970@zaphod>; from bmbuck@14850.com on Thu, Dec 21, 2000 at 07:52:55AM -0500 X-Evolution: 0000000d-0010 On Thu, Dec 21, 2000 at 07:52:55AM -0500, Buddha Buck wrote: > I propose a modification to Mike's proposal, specifically: > > If the required supermajority is N:M, then, for pairwise count methods, > that means that: > If, when the rankings are counted, and a winner is found according to > the voting system's count rule, then if N/M times as many voters have > ranked that winner over the status-quo, the the winner replaces the > status quo. Otherwise, the winner is eliminated from the ballots, and > the ballots are recounted. > It would be simpler, and I believe equivalent, to remove from the ballot, before ranking, any options which don't meet supermajority requirements. That is: if "status quo" is defined as meaning the explicit status quo option, and not any option which is status quo as far the supermajority requirement in question. -- Raul From aj@azure.humbug.org.au Thu Dec 21 15:33:51 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 17768 invoked from network); 21 Dec 2000 15:33:51 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 15:33:51 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 1497ix-0008Nt-00; Fri, 22 Dec 2000 01:33:43 +1000 Date: Fri, 22 Dec 2000 01:33:43 +1000 From: Anthony Towns To: Raul Miller Cc: Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com Subject: Re: My ballot for the Agenda Vote Message-ID: <20001222013342.A32192@azure.humbug.org.au> References: <001801c06b5c$262b2960$d2164818@mandos.accesscomm.ca> <977410428.f34047ac@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <977410428.f34047ac@debian.org>; from moth@debian.org on Thu, Dec 21, 2000 at 09:56:43AM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000000e-0030 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2000 at 09:56:43AM -0500, Raul Miller wrote: > And what happens if we're in the middle of that vote when you propose > we change the voting system? Then we delay until the current vote's taken place, or we say "these changes will apply only to new votes proposed after the change is accepted (if it is)". Note that this may overlap with the election too, nominations for which should probably start happening in the next couple of weeks. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkIi1uRRvX9xctrtAQGgSwP/brhiWk/d0poS5MuI3WWnzTknxGgilWk+ A9990gEnkiNhHKuXCbSSdx+nHG7etfrQJaKquVsFTizNs6cDsOCvj01d9B+oz9Pu h5k2hry6fb+bqr5SXkCR4tZg/Z/iUPr77Z2vvNCrHgeYWBRfQVOucX8tsMWUvOTg MNBkEfOVwSA= =iwE1 -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From bmbuck@14850.com Thu Dec 21 15:36:44 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 21546 invoked from network); 21 Dec 2000 15:36:44 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 15:36:44 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Thu, 21 Dec 2000 10:36:36 -0500 Message-Id: <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 21 Dec 2000 15:36:35 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 10:35:29 -0500 To: Raul Miller From: Buddha Buck Subject: Re: Resolve Supermajority Problems Cc: nkklrp@hotmail.com,npetry@accesscomm.ca,stevegr@debian.org, robla@eskimo.com,aj@azure.humbug.org.au,moth@debian.org In-Reply-To: <977410621.680e8d7f@debian.org> References: <20001221125255.5DFEA15970@zaphod> <20001221125255.5DFEA15970@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Evolution: 0000000f-0010 At 09:59 AM 12-21-2000 -0500, Raul Miller wrote: >On Thu, Dec 21, 2000 at 07:52:55AM -0500, Buddha Buck wrote: > > I propose a modification to Mike's proposal, specifically: > > > > If the required supermajority is N:M, then, for pairwise count methods, > > that means that: > > If, when the rankings are counted, and a winner is found according to > > the voting system's count rule, then if N/M times as many voters have > > ranked that winner over the status-quo, the the winner replaces the > > status quo. Otherwise, the winner is eliminated from the ballots, and > > the ballots are recounted. > > > >It would be simpler, and I believe equivalent, to remove from the ballot, >before ranking, any options which don't meet supermajority requirements. I actually was thinking of the above as a concrete embodiment of the following procedure: Find the winner normally. If the winner is disqualified, eliminate the winner from the balloting and recompute the winner. In this case, the disqualification would be not meeting a N:M supermajority over an explicit status quo option. But it could be otherwise. For a macabre example: Do we want to reballot if our Illustrious Leader-elect gets hit by a bus? Or do we want to simply say "Death is a disqualification, let's eliminate him/her and pick the next candidate from the same ballots". >That is: if "status quo" is defined as meaning the explicit status quo >option, and not any option which is status quo as far the supermajority >requirement in question. I think that unless status quo" is not possible (like an election), there needs to be an explicit "Status Quo" option on the ballot for this to work. >-- >Raul From bmbuck@14850.com Thu Dec 21 18:37:35 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 6264 invoked from network); 21 Dec 2000 18:37:35 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 18:37:35 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Thu, 21 Dec 2000 13:37:24 -0500 Message-Id: <5.0.0.25.0.20001221123431.02ba79c0@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 21 Dec 2000 18:37:24 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 21 Dec 2000 13:36:17 -0500 To: Raul Miller ,nkklrp@hotmail.com,npetry@accesscomm.ca, stevegr@debian.org,robla@eskimo.com,aj@azure.humbug.org.au, moth@debian.org,bmbuck@14850.com From: Buddha Buck Subject: Re: Resolve Supermajority Problems In-Reply-To: <977413250.b4dfc5fb@debian.org> References: <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> <20001221125255.5DFEA15970@zaphod> <20001221125255.5DFEA15970@zaphod> <977410621.680e8d7f@debian.org> <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Evolution: 00000010-0010 At 10:41 AM 12-21-2000 -0500, you wrote: >On Thu, Dec 21, 2000 at 10:35:29AM -0500, Buddha Buck wrote: > > I actually was thinking of the above as a concrete embodiment of the > > following procedure: > > > > Find the winner normally. If the winner is disqualified, eliminate the > > winner from the balloting and recompute the winner. > >Why this procedure? [It's not the current debian procedure for >supermajority handling.] Does this procedure have some good properties? I thought of the procedure because a) it's generic, and should work with any ranked-ballot/qualification schema, b) it does possibly time-consuming supermajority qualification calculations only on one candidate, as opposed to them all. I know it's not the current debian procedure. I happen to not trust the prescaling that the current debian produre uses. Pre-elimination may also distort the outcome as well (the fact that resolution B defeated Amendment A may help B to be the ultimate winner, even if A does not have a supermajority. Eliminating A ahead of time might make B lose. >Thanks, > >-- >Raul From moth@debian.org Thu Dec 21 15:42:03 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28737 invoked from network); 21 Dec 2000 15:42:03 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 15:42:03 -0000 Received: (qmail 7914 invoked by uid 1000); 21 Dec 2000 15:41:53 -0000 Date: Thu, 21 Dec 2000 10:41:53 -0500 From: Raul Miller To: Buddha Buck Cc: nkklrp@hotmail.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Resolve Supermajority Problems Message-ID: <977413250.b4dfc5fb@debian.org> References: <20001221125255.5DFEA15970@zaphod> <20001221125255.5DFEA15970@zaphod> <977410621.680e8d7f@debian.org> <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu>; from bmbuck@14850.com on Thu, Dec 21, 2000 at 10:35:29AM -0500 X-Evolution: 00000011-0010 On Thu, Dec 21, 2000 at 10:35:29AM -0500, Buddha Buck wrote: > I actually was thinking of the above as a concrete embodiment of the > following procedure: > > Find the winner normally. If the winner is disqualified, eliminate the > winner from the balloting and recompute the winner. Why this procedure? [It's not the current debian procedure for supermajority handling.] Does this procedure have some good properties? Thanks, -- Raul From npetry@accesscomm.ca Thu Dec 21 20:30:42 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26879 invoked from network); 21 Dec 2000 20:30:42 -0000 Received: from static24-72-33-128.reverse.accesscomm.ca (HELO aule) (24.72.33.128) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 20:30:42 -0000 From: "Norman Petry" To: "'Raul Miller'" , , , , , , Subject: Two Proposals for the Supermajority Requirement Date: Thu, 21 Dec 2000 14:30:38 -0600 Message-ID: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <977410428.f34047ac@debian.org> X-Evolution: 00000012-0010 I have two proposals to make for resolving the current problems with the way supermajorities are handled in the Debian constitution. They are listed in order of preference, but I expect that Proposal #1 might be considered too 'radical' for Debian, so I am also suggesting a second-choice alternative. Please let me know your opinions of these proposals. ***** PROPOSAL #1 - ABOLISH SUPERMAJORITY REQUIREMENTS In my opinion, the best way to deal with the problem of supermajorities is to eliminate the rules requiring them. I don't want to get into a long debate on this issue, since I do not think this proposal will be acceptable to the committee or Debian as a whole, and we don't have that much time to consider these issues. Still, I needed to make these points... It has been suggested that supermajorities are required to make it difficult to amend the founding documents of an organisation, since these define the core objectives of the group. In some sense, it ceases to be that organisation if the underlying principles are modified. However, in practice it is impossible and undesireable to keep organisations from evolving -- mere rules cannot do this. If for example, Debian's developers abandon their commitment to creating a Free Software OS distribution, their rules won't save them. The solution to this potential problem is education of new members about the ethics of Free Software, not rigid rules. Also, changed circumstances, unforseen by those preparing the founding documents, require changes in response. Only the current members of an organisation have the information needed to make these decisions. It is irrational to suppose that the founders, lacking knowledge of future events and conditions, would know better than the current members what needs to be done. Why suppose that current members are less wise, committed, and well-intentioned than the founders? This argument is a variation on the 'argument from tradition' fallacy -- the idea that because something has always been done in a particular way, there must be some good reason why that course of action should continue to be followed. It is simply used as a substitute for a rational argument when current practice can no longer be justfied any other way ("We've always had slaves, therefore we should always have slaves..."?). Supermajority requirements allow the small minority faction which benefits from the existing rules to have more power than those wanting change. This political inequality is neither fair to the members of the group, nor is it in the interests of the organisation, since it limits its ability to adapt. Another argument that has been made in support of supermajority requirements is this one, made by Anthony Towns on November 22: "I'm not sure this is an ideal way of looking at things from Debian's perspective. The usual decision making process in Debian is (supposed to be) one of reaching consensus on an issue, not one of democracy, per se. I tend to look at consensus as an attempt to disenfrachise (by ignoring their objections) no one, and voting as an attempt to disenfranchise up to 50% of the people concerned (and dictatorship as an attempt to disenfranchise everyone else but one). If consensus building is successful, then there's no need for a vote, because it's clear everyone will vote the same way, and all is well. But even if we've given up on satisfying everyone, it still seems appropriate to try satisfying 75% or 66% of people rather than 50% of people for some issues." -- http://lists.debian.org/debian-vote-0011/msg00159.html The idea is that it is better to require more than merely half the members to support an action if something is to be done. Sure, I agree it's desireable to have as much support as possible for a given course of action, and if you have a group of people who are choosing between doing X and doing nothing, it may be desireable to do nothing, rather than take an important or risky step without overwhelming support. However, this is not the choice that most organisations are faced with. In general, organisations adopt policies which govern their day to day operations. Therefore, the group is always doing *something* according to whatever standing rules are in place. It then becomes a matter of deciding whether the group will do what the minority wants, or what the majority wants. With a supermajority requirement of 3:1, it can happen that 74% of the group is forced (under existing rules) to do what the remaining 26% want, which is more unfair than if the majority gets to choose where the organisation should be headed (thereby limiting dissatisfaction to 49%, rather than 74% of members). I do think that there is one valid use of a supermajority rule, and that is when it used to make it difficult for a faction within an organisation to make surprise changes to important governing documents. If meetings of the organisation are generally poorly attended, it can be quite easy for a small and well-organised group to stack a meeting and push through important changes that would not be supported by a majority of the membership. Many organisations have rules requiring either prior notice, or else a supermajority as a way of minimising this form of 'hijacking'. However Debian's rules, together with the fact that meetings are conducted online, make it impossible for changes to be made without a full and open discussion period. Therefore, any developer who cares about an issue will know in advance of the vote, and can participate in the decision, so there is no risk of a 'false majority' changing the rules. ***** PROPOSAL #2 - DETERMINE AN "ELIGIBLE" SET OF CANDIDATES Here is a more modest proposal which the committee might want to adopt, if supermajority requirements are to be retained. Rather than just describing the concept, I've tried to write the proposal as I think it should appear as part of an actual voting method within the constitution. Some of the underlying definitions are not specified in this description ('beats', for example would either be defined here or added to a glossary), but their meaning is probably obvious to those of us on the committee. I'll describe some of the advantages of this system following the description. *** Definitions: A "restricted option" is an option which would require a supermajority to be adopted. A "regular option" is an option which would require a simple majority to be adopted Restricted options and regular options may be combined on a single ballot. However, all the restricted options appearing on the ballot must have the same supermajority requirement. To determine a winner, the following sequence of steps will be carried out, in order and without exception unless explicitly stated otherwise: 1. An initial set of "eligible" options is determined according to the following rules: a) The default option is always eligible*. b) All regular options are eligible. c) A restricted option which beats the default option by a supermajority is eligible. d) A restricted option which beats another eligible, restricted option by a supermajority is eligible. 2. All options not satisfying at least one of the conditions for eligibility specified in (1) are "ineligible", and are eliminated from consideration in the remaining steps. Any references to these options on either the ballots or in the pairwise matrix are ignored. ... [continue with definition of a pairwise method used to choose a winner from among those 'eligible'] (* note that we would need to change this part if the Secretary/DPL are given the authority to eliminate the default option under some circumstances) *** The advantages of this system are as follows: 1) It is written in the form of constraints which reduce the set of options that may be chosen at a later stage in the process. By doing it this way, it is possible to keep the supermajority requirements independent of the count rule used. For example, it is easy to use this same definition with any pairwise method we might later adopt. Alternate approaches may entangle the supermajority rules with the pairwise count rules, making them difficult to amend and forcing us to reconsider the question of how supermajorities would be implemented with each count rule under discussion. 2) The method allows options which require a supermajority to be combined with options that don't on the same ballot. This might be useful if it would be possible for the organisation to achieve a particular goal either by modifying the constitution (supermajority), or simply adopting a general resolution. Provided the restricted option meets its supermajority requirement, a simple majority will decide between the constitutional amendment and the general resolution. Normally, this shouldn't happen; different categories of policy, having different supermajority requirements, will be categorised in that way precisely because they deal with different issues (the Constitution explicitly states that its goal is to define decisionmaking processes, for example). Therefore it is unlikely that regular and restricted options on the same ballot would both be germane to the same issue. However, it is at least possible that developers may wish to do this, and by allowing both on one ballot, it is possible to avoid serialising the decisionmaking, which is always undesireable, imho. 3) The method includes a recursive definition (1.(d)) that allows an option which beats another option by a supermajority, but does not beat the current default (status quo) option by a supermajority, to be eligible. This is useful, because without this rule it is possible that an option which loses under the current status quo would be a winner under the *new* status quo, and this would prompt the supporters of that option to push for reballoting. This would be undesireable -- it is always better to settle matters once and for all, rather than have a new discussion period and re-vote just to overcome the flaws in the voting system. Consider this example: Options: {A,B,SQ} (A,B = restricted options; SQ = status quo option) Supermajority Requirement: 2:1 Pairwise totals: A>B 50:20 A>SQ 35:20 B>SQ 45:20 Without 1.(d), the winner is B, since A doesn't directly satisfy the supermajority requirement, but B does. However, if B is elected, then reballoting would result in the election of A, since it beats the new status quo option by 2.5:1. It is better to just save time and treat all these candidates as eligible, and then choose the Condorcet winner (A) on a single ballot. Note that this proposal is not mine -- it was suggested by Markus Schulze to debian-vote on November 21. See http://lists.debian.org/debian-vote-0011/msg00156.html for more details. Markus uses the term 'available' rather than 'eligible' to describe this set of candidates. However, the set I am proposing is enlarged to include any regular (simple majority) options that may be germane to the issue under consideration. Please check out this method and let me know if you find scenarios where you believe it would give the 'wrong' result, assuming that a pairwise method is used to choose a winner from among the eligible candidates. Perhaps Buddha and Anthony could check it against the supermajority criteria they have proposed. I await your comments. -- Norm Petry From moth@debian.org Thu Dec 21 21:10:47 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 17015 invoked from network); 21 Dec 2000 21:10:47 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 21:10:47 -0000 Received: (qmail 13518 invoked by uid 1000); 21 Dec 2000 21:10:36 -0000 Date: Thu, 21 Dec 2000 16:10:36 -0500 From: Raul Miller To: Norman Petry Cc: nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <977432899.c34fe084@debian.org> References: <977410428.f34047ac@debian.org> <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca>; from npetry@accesscomm.ca on Thu, Dec 21, 2000 at 02:30:38PM -0600 X-Evolution: 00000013-0010 One other issue to consider: The distinction between the majority of developers, and a majority of the voting developers. [If we abolish supermajority, it might be a reasonable to replace that with a "majority of developers" requirement -- though I believe that would ultimately be more restrictive than the current supermajority requirement.] [I'm still trying to digest your secont alternative.] Thanks, -- Raul From npetry@accesscomm.ca Wed Dec 20 04:29:43 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 760 invoked from network); 20 Dec 2000 04:29:43 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 20 Dec 2000 04:29:43 -0000 Message-ID: <001101c06a3d$6deef4e0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: My ballot for the Agenda Vote Date: Tue, 19 Dec 2000 22:29:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000014-0010 Here's my ballot for the agenda ordering poll: [15] 3:1 SUPERMAJORITY EXCESSIVELY HIGH (mo) [14] SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY (np) [10] ELIMINATE TWO-STAGE VOTING (np) [13] CLARIFY REPORTING REQUIREMENTS (np) [16] ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY (np) [8] CHOOSE NAME OF NEW VOTING METHOD (np) [9] CREATE GLOSSARY OF VOTING TERMS (np) [11] TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS (np) [12] REQUIRE SIMULTANEOUS DECISIONS (np) [17] PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY (np) [7] STATE INTERPRETATION OF TRUNCATED BALLOTS (np) [6] EXPLICITLY ALLOW EQUAL RANKINGS (np) [2] RESOLVE CIRCULAR TIE PROBLEM (np) [3] SIMPLIFY AND IMPROVE TIEBREAKER (np) [4] CONSIDER FINAL TIEBREAKER (np) [1] RESOLVE SUPERMAJORITY PROBLEMS (np) [5] DISCUSS QUORUM REQUIREMENTS (np) Generally, I chose this ordering on the basis that I would prefer to discuss issues related to the voting system first, then deal with some of the important procedural issues related to voting, and finally deal with the topics that concern questions of authority. Questions of authority can certainly influence the effectiveness of the voting system, but I think these issues are probably furthest from the scope of our work, and would be the most controversial changes to propose. So far, there have been a total of 5 ballots submitted for this poll. I'll calculate the group ordering and distribute the results tomorrow morning, so if you haven't voted and would like to, please send me your ballot before 10:00 AM CST, so I can include it in the results. -- Norm Petry From nkklrp@hotmail.com Thu Dec 21 05:47:10 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24062 invoked from network); 21 Dec 2000 05:47:10 -0000 Received: from law-f119.hotmail.com (HELO hotmail.com) (209.185.131.182) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 05:47:10 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2000 21:47:07 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Thu, 21 Dec 2000 05:47:07 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org Subject: Re: Resolve Supermajority Problems Date: Thu, 21 Dec 2000 05:47:07 -0000 Mime-Version: 1.0 Content-Type: text/html Message-ID: X-OriginalArrivalTime: 21 Dec 2000 05:47:07.0694 (UTC) FILETIME=[745864E0:01C06B11] X-Evolution: 00000015-0010



I agree about the desirability of getting the ball rolling right away, and in fact I'd like
to give it another kick: I move that the supermajority rule interpretation that I proposed
in my previous posting be immediately adopted by the committee, and that we move on
to the next agenda item. I'll call it supermajority proposal #1.
 
Obviously if more discussion is needed then you won't agree with my motion. But if
you agree that that's what supermajority means in a pairwise-count method, and if
the motion is seconded by 3 people, then it already has a "Yes" majority and should
pass.
 
The reason why I'm trying to hurry things along is because 2 people have suggested the
goal that we finish in a month, and even that it's important that we finish in a month.
 
My argument for my proposal is that what it means to support a replacement for the
status quo is to vote that replacement over the status quo. If you vote that you like the
replacement better than the status quo, then you're supporting it as a replacement to
the status quo. If there were a 2-altenative election between that replacement & the
status quo, you'd vote for the replacement instead of the status quo, if you ranked the
replacement over the status quo.
 
And the pairwise count shows how each alternative fares against each one of the others.
The pairwise-count will show whether 3 times as many people indicate preference for X
over the status quo than vice-versa. That's what a supermajority requirement asks for.
 
So here's my proposal again--Supermajority proposal #1:
 
If the required supermajority is 3:1, then, for pairwise count methods, that means that:
 
If, when the rankings are counted, and a winner is found according the voting system's
count rule, then, if 3 times as many voters have ranked that winner over the status-quo
than vice-versa, then that winner replaces the status quo. Otherwise nothing replaces the
status quo, and the status quo remains in effect.
 
[end of proposal]
 
Does anyone second this proposal? 3 people second it, then it already has a "Yes"
majority and should be adopted. If fewer than 3 but more than zero second it, and
no more proposals are proposed, then doesn't that mean we vote Y/N on it?
 
The question is how long the waiting period is for seconds or alternative proposals.
 
If we're going to finish in a month, with 17 issues, then we can't spend more than 2 days
per issue. Does that mean that seconds or alternative proposals should have to appear on
the following day? Or how about this suggestion which sounds to me like the most
streamlined way to proceed?:
 
Ordinarily, work on an agenda issue begins on the day when the previous agenda item
is resolved. In the case of the 1st item, say work begins tomorrow, the day after Mr. Buck
suggested that discussion begin.
 
On the day when work begins on an agenda issue, members may distribute proposals to
the committee. Upon receiving the proposals, a member may call for discussion &/or rank
the proposals (the status quo is one of the proposals). If it turns out that a majority call
for discussion, then the votecount is postponed. Otherwise the rankings are immediately
counted by Schulze's method, which the EM members of this committee agree is the
best rank-count for small committees, for choosing 1 alternative from among several.
On the following day the Schulze winner is reported, & that winner is automatically adopted as
the committee's proposal on that issue. That same day is the day when work on the
next agenda issue begins, the day on which proposals are distributed.
 
So it would be:
 
Day 1, proposals
 
Day 2, voting & calling for discussion.
 
The following
day, when the vote result is reported (if there wasn't a majority calling for discussion)
becomes day 1 for the next agenda issue.
 
[end of proposal]
 
I'm suggesting that procedure because it seems to me that that, or something very
similar to it, is needed if we're to finish within about a month. Even so, it would take
34 days, even if no issue is discussed. Because it's going to be so difficult to finish in a month,
or even close to it, I suggest that something like the procedure I describe is needed. I
propose the procedure that I described above in this letter.
 
I'm only suggesting this procedure if it's necessary to finish in about a month. If it's ok to expect
to take 2 or 3 months, then I withdraw this procedure proposal. I guess I feel as if there's
a hurry, because an interim proposal is going to be proposed to Debian if we don't
expect to finish in about a month.
 
 
Mike
 


Get your FREE download of MSN Explorer at http://explorer.msn.com

From moth@debian.org Thu Dec 21 19:24:25 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2245 invoked from network); 21 Dec 2000 19:24:25 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 19:24:25 -0000 Received: (qmail 11749 invoked by uid 1000); 21 Dec 2000 19:24:14 -0000 Date: Thu, 21 Dec 2000 14:24:14 -0500 From: Raul Miller To: Buddha Buck Cc: nkklrp@hotmail.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Resolve Supermajority Problems Message-ID: <977426501.077520c0@debian.org> References: <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> <20001221125255.5DFEA15970@zaphod> <20001221125255.5DFEA15970@zaphod> <977410621.680e8d7f@debian.org> <5.0.0.25.0.20001221100510.02ac6eb0@armstrong.cse.buffalo.edu> <977413250.b4dfc5fb@debian.org> <5.0.0.25.0.20001221123431.02ba79c0@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <5.0.0.25.0.20001221123431.02ba79c0@armstrong.cse.buffalo.edu>; from bmbuck@14850.com on Thu, Dec 21, 2000 at 01:36:17PM -0500 X-Evolution: 00000016-0010 On Thu, Dec 21, 2000 at 10:35:29AM -0500, Buddha Buck wrote: > > > Find the winner normally. If the winner is disqualified, eliminate the > > > winner from the balloting and recompute the winner. At 10:41 AM 12-21-2000 -0500, you wrote: > >Why this procedure? [It's not the current debian procedure for > >supermajority handling.] Does this procedure have some good properties? On Thu, Dec 21, 2000 at 01:36:17PM -0500, Buddha Buck wrote: > I know it's not the current debian procedure. I happen to not trust the > prescaling that the current debian produre uses. Pre-elimination may also > distort the outcome as well (the fact that resolution B defeated Amendment > A may help B to be the ultimate winner, even if A does not have a > supermajority. Eliminating A ahead of time might make B lose. Do we want to support tallying mechanisms where an option with no chance of winning will affect the outcome? If so, why? Thanks, -- Raul From npetry@accesscomm.ca Fri Dec 22 04:43:44 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27160 invoked from network); 22 Dec 2000 04:43:44 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 04:43:44 -0000 Message-ID: <015301c06bd1$b6d62bc0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: , , , , , , "Norman Petry" Subject: Re: Resolve Supermajority Problems Date: Thu, 21 Dec 2000 22:43:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000017-0010 Mike wrote: > >The reason why I'm trying to hurry things along is because 2 people have suggested the >goal that we finish in a month, and even that it's important that we finish in a month. > I don't consider it important that we finish in a month, but I did suggest earlier that it might be possible. Personally, I would prefer that Debian proceed with resolving important issues under their current rules, and then consider our proposal when it is ready. If we work hard, it may be possible to complete that work in a month, but even if we do have the proposal ready then, it will probably another month or so of internal debate before some version of the proposal gets adopted (hopefully). Can Debian wait that long before dealing with pressing issues? Anthony mentioned that elections for new officers are also imminent, so I doubt it. How long we take with this will really depend on how controversial some of the issues become. Considering that discussion of the supermajority issue alone began on November 14th, and was heatedly discussed for almost an entire month on debian-vote (the thing petered out about December 10th), I think we'd be making great progress if we could resolve this issue ourselves in 4-5 days. However, if other issues take even that long, it is certain that we won't finish our work that early. On the other hand, we will probably find that many issues on the agenda require little or no discussion (glossary, etc.) We'll probably also find that many of the later issues on our agenda have already been discussed and resolved as part of earlier items. Therefore, I really can't say how long this will take. All I can say is that I think a month is *possible*, but I don't think we can be bound to that as a deadline -- I'd hate to have to submit a half-finished proposal just to satisfy some arbitrary limit. >The question is how long the waiting period is for seconds or alternative proposals. > >If we're going to finish in a month, with 17 issues, then we can't spend more than 2 days >per issue. On average, that's true. However we can spend more time on the high-priority items, I think. >I'm suggesting that procedure because it seems to me that that, or something very >similar to it, is needed if we're to finish within about a month. Even so, it would take >34 days, even if no issue is discussed. Because it's going to be so difficult to finish in a month, >or even close to it, I suggest that something like the procedure I describe is needed. I >propose the procedure that I described above in this letter. > I agree that we will need to use voting to decide on the components of our proposal to have any hope of completing the work in a month's time. I also agree with your suggestion to use Schulze's method to make these decisions. However, I don't think we can set a rigid schedule to complete an agenda item every two days, and for reasons mentioned above I don't think we will have to. Even with some flexibility in the schedule, I think there's still hope (but NOT certainty) that we can get done in a month or so. -- Norm Petry From npetry@accesscomm.ca Fri Dec 22 05:23:36 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9923 invoked from network); 22 Dec 2000 05:23:36 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 05:23:36 -0000 Message-ID: <016201c06bd7$4923d680$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Raul Miller" , "Buddha Buck" , , , , , "Norman Petry" Subject: Re: Resolve Supermajority Problems Date: Thu, 21 Dec 2000 23:23:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000018-0010 Raul wrote: >> I know it's not the current debian procedure. I happen to not trust the >> prescaling that the current debian produre uses. Pre-elimination may also >> distort the outcome as well (the fact that resolution B defeated Amendment >> A may help B to be the ultimate winner, even if A does not have a >> supermajority. Eliminating A ahead of time might make B lose. > >Do we want to support tallying mechanisms where an option with no chance >of winning will affect the outcome? > >If so, why? I think this is a very good point. One of the goals of a good voting system is to eliminate or at least minimise the effects of 'irrelevant' alternatives on the outcome. A criterion called 'Independence from Irrelevant Alternatives' (IIAC) was proposed long ago as a desireable property for a voting system to have. Here's one definition: Vickrey's definition: ``The social choice between any two alternatives shall not be affected by the removal or addition of other alternatives to the field of feasible alternatives under consideration'' It turns out that no reasonable voting method can satisfy IIAC (search for Arrow's theorem for reasons for this), but it is possible to use a slightly weaker form of the criterion (MIIAC, LIIAC) and come up with a reasonable voting method. The idea of the Smith set is motivated by this, since any method which satisfies Smith will be unaffected by the addition or removal of candidates outside the Smith set (so at least *some* candidates can be safely considered irrelevant). Although the situation here is not exactly the same, it does seem to me that a candidate which cannot possibly win (due to supermajority requirements) ought to have no effect on the outcome if at all possible. Therefore, the scenario describe, where we should retain this candidate because it might do precisely this, seems undesireable to me. -- Norm Petry From bmbuck@14850.com Sun Dec 24 02:04:11 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25543 invoked from network); 24 Dec 2000 02:04:11 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 02:04:11 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 51AA415956; Sat, 23 Dec 2000 21:04:08 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: Raul Miller Cc: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns , bmbuck@zaphod.datahold.home Subject: Re: Call for Votes on Supermajority Issue In-Reply-To: Message from Raul Miller of "Sat, 23 Dec 2000 16:29:11 EST." <977606703.7ab61894@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <20001223144833.A19352@usatoday.com> <977606703.7ab61894@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Dec 2000 21:04:08 -0500 From: Buddha Buck Message-Id: <20001224020408.51AA415956@zaphod> X-Evolution: 00000019-0010 > Anthony Towns has told me (repeatedly :) that the current debian > constitution eliminates all options if there's a smith set with more > than one member -- resulting in the default option winning. > > It occurs to me that [if the constitution is aimed at a rough consensus] > this would be in line with the design intent -- and in line with existing > debian practice (going back to long before the constitution was adopted). > In other words: where there's no clear choice, we discuss things further. It -feels- like a bug, and here's why. Right now, based on A.6(2) (definition of domination), A.6(3) (elimination of options which are dominated) and A.6(4) ("Dominate all others" wins), and A.6(8) (default option wins in absence of quorum), I can see that (as per Anthony Towns) the whole Debian vote can be reduced to one simple rule: The Condorcet winner (if one exists) wins. Otherwise, the default option wins. However, A.6(5) (Use STV in case ore than one option remains) implies that there was thought given to the idea that there may be more than one option -- there was not a single Condorcet winner. This means either a) a standard run-of-the-mill circular tie of the sort that Norman Petry claims happens about 5% of the time, or b) the even more unusual circumstance where you have a non-trivial set of options that all pairwise tie each other. Option a) is eliminated by A.6(3), leaving b). Do you think they really intended for A.6(5) to be used in just that unlikely situation. I'm not even sure STV would help even then. Can anyone show me a set of ballots in which every option pairwise ties every other option, and yet STV can determine a winner? I can tell off the top of my head that it requires at least 3 options. But that's OK, we have a fall-back option. If STV fails to find a winner, A.6(6) specifies a tie-break. I find it very hard to believe that the legislative intent of A.6(5)-(6) was to deal with a very special case of circular tie, while relegating all other circular ties to the "default option". > This feels right (and if I think I owe Anthony an apology). And, unless > people in this group object, I'll withdraw my [unsponsored] proposal > from debian-vote on this basis. [I'll wait till after Christmas to give > people a chance to object.] > > Merry Christmas, > > -- > Raul -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From moth@debian.org Thu Dec 21 23:40:17 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 13824 invoked from network); 21 Dec 2000 23:40:17 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 23:40:17 -0000 Received: (qmail 15605 invoked by uid 1000); 21 Dec 2000 23:40:06 -0000 Date: Thu, 21 Dec 2000 18:40:06 -0500 From: Raul Miller To: Buddha Buck Cc: Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Status/Summary of proposals so far... Message-ID: <20001221184006.A14930@usatoday.com> References: <20001221225435.866AC15970@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001221225435.866AC15970@zaphod>; from bmbuck@14850.com on Thu, Dec 21, 2000 at 05:54:35PM -0500 X-Evolution: 0000001a-0010 On Thu, Dec 21, 2000 at 05:54:35PM -0500, Buddha Buck wrote: > To the question "What does 'supermajority' mean in a ranked-ballot > situation" the only answer I've seen was from Mike Ossipoff, that being > that an amendment can be adopted only if it defeats the status quo by a > supermajority. I've seen no other suggestion, nor any opposition to > that suggestion. I think we may have achieved consensus on that point. While I agree with this definition, I'm uncomfortable with it if status quo is not explicitly defined. In particular, I'm uncomfortable with implictly stated idea that "only an option which does nothing represents status quo". > Miller: Discard all ineligible amendments. Adopt the best option > remaining. (Note: may not have been formally proposed, claimed to be > equivilant to Buck). ... > Have I missed anything, or mischaracterized anything or anyone? Let me make that one more formal: We should discard all options which cannot win, if that can be determined before pair-wise ranking. [I'm not at all certain that the "if" part is true.] Here's what I propose, should the "if" part be false (and my intuition tells me that it should be false): Miller-2: Use supermajority criteria in the pairwise ranking by scaling down the vote counts in favor of supermajority options. [That is, if an option must have 3/4 of all cast votes, to win, when considering pairwise rankings, multiply number of votes in favor of this option by 1/3.] Thus, if we have options: [a] Release debian 3.1415 now. [b] Modify constitution to specify that distributions should always be released 2 months after they've been creation. [c] do nothing about releasing 3.1415 While [c] would of course be a status quo option, [b] must still have 3/4 of the vote when compared to [a] in order to beat it. Final note: philosophically, based on Norman's argument against supermajority, I could go along with the idea that if more than half of all debian developers have voted in favor of an option, that we ignore the "supermajority" requirement. [If we did this, we should come up with a better name than 'supermajority' because obviously it would obviously mean something else.] However, I expect that most debian votes will involve far less than half of all registered debian developers. -- Raul From aj@azure.humbug.org.au Fri Dec 22 04:13:02 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 21137 invoked from network); 22 Dec 2000 04:13:02 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 04:13:02 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 149JZb-0003XE-00; Fri, 22 Dec 2000 14:12:51 +1000 Date: Fri, 22 Dec 2000 14:12:51 +1000 From: Anthony Towns To: Buddha Buck Cc: Norman Petry , 'Raul Miller' , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com Subject: Re: Status/Summary of proposals so far... Message-ID: <20001222141251.A13079@azure.humbug.org.au> References: <20001221225435.866AC15970@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001221225435.866AC15970@zaphod>; from bmbuck@14850.com on Thu, Dec 21, 2000 at 05:54:35PM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000001b-0010 On Thu, Dec 21, 2000 at 05:54:35PM -0500, Buddha Buck wrote: > To the question "What does 'supermajority' mean in a ranked-ballot > situation" the only answer I've seen was from Mike Ossipoff, that being > that an amendment can be adopted only if it defeats the status quo by a > supermajority. There are two possible ways of answering that question: either as "what's the point of requiring a supermajority in the first place?", or as "how shall we adapt a Condorcet method to account for this?" We've got two basic answers for the latter (Mike's "compare against status-quo", and Raul's "scale the pairwise comparisons"), but very little on the former. My take is that the purpose is to allow a minority veto and nothing more, and that supports Mike's method (as that's basically all Mike's method allows you to do). Raul's method also allows a minority veto, but also goes beyond that. > I think we can also agree that if there is an option that has a > supermajority requirement, there must be a "Status Quo" option. I'd go > further and suggest that except for elections, there must be a "Status > Quo" option, even without supermajority requirements. For elections, there's a "None of the above" option. > An option is ADOPTED if it is the final outcome of the vote count > process. > An option is an AMENDMENT if it requires a supermajority to be > adopted. Note that this would define a proposal to overturn a tech ctte decision as an "amendment", which would be a bit weird. > An option is a RESOLUTION if it has no special majority or > supermajority requirements. > An option is the BEST option if it wins the "normal" vote count > An amendment is INELIGIBLE if it does not defeat the status quo by a > supermajority. > An amendment is PLAUSIBLE if it defeats the status quo by a > supermajority, or if it defeats an PLAUSIBLE amendment by a > supermajority. > So, here are the proposals, summarized by me: > Ossipoff: Find the best option. If the best option is an ineligible > amendment, adopt the Status Quo; otherwise, adopt the best option. > Buck: Find the best option. If the best option is an ineligible > amendment, discard it and find the next best option. Adopt the first > best option that isn't an ineligible amendment. > Miller: Discard all ineligible amendments. Adopt the best option > remaining. (Note: may not have been formally proposed, claimed to be > equivilant to Buck). These aren't equivalent: consider a situation like: (E requires a supermajority (3:1) which it doesn't meet, so will be a candidate for elimination, S is the status-quo) 60 ASEB 40 EBAS 21 BASE B beats A: 61 to 60 A beats E: 81 to 40 E beats B: 100 to 21 A beats S: 121 to 0 B beats S: 61 to 60 S beats E: 81 to 40 Assume Smith+STV (but others would work too) Buck: Smith = {A,B,S,E}; STV = 60:21:40:0, 81:0:40:0, A wins. Miller: E ineligible and eliminated. B beats A, B beats S, A beats S, B is Condorcet winner, B wins. Another way of handling this would be to choose a method that ranks the entire list of options, rather than just chooses a winner. Once the options are ranked, choose the highest ranked eligible option. Cheers, aj -- Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 From nkklrp@hotmail.com Fri Dec 22 06:05:27 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27058 invoked from network); 22 Dec 2000 06:05:27 -0000 Received: from law-f84.hotmail.com (HELO hotmail.com) (209.185.131.147) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 06:05:27 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 22:05:24 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 06:05:23 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, moth@debian.org, bmbuck@zaphod.datahold.home Subject: Re: Resolve Supermajority Problems Date: Fri, 22 Dec 2000 06:05:23 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 06:05:24.0317 (UTC) FILETIME=[2C6588D0:01C06BDD] X-Evolution: 0000001c-0010 >Mike, can you please not send HTML? Someone has explained to me that Hotmail has begun offering the option of rich-text (HTML e-mail), and that apparently selection of rich text is the default choice. So I've now de-selected rich-text, and the problem should be solved. Sorry about that--I didn't know about it, and even when I was told about the problem, I didn't know the cause or the fix, till someone explained it to me today. [scenario in which A requires a supermajority, and wins by the voting system's count rule, but B, which would win if A weren't in the election, doesn't have a supermajority rule] >Why should B not be adopted? Yes, now that you mention it, it would make more sense to elect B than to have to start all over, doing a whole new election and hoping that the winner qualifies under the supermajority rule. > >I propose a modification to Mike's proposal, specifically: > >If the required supermajority is N:M, then, for pairwise count methods, >that means that: >If, when the rankings are counted, and a winner is found according to >the voting system's count rule, then if N/M times as many voters have >ranked that winner over the status-quo, the the winner replaces the >status quo. Otherwise, the winner is eliminated from the ballots, and >the ballots are recounted. > > >Two changes from Mike's proposal: 1) generalizes the supermajority >requirement to other than 3:1, and 2) does not automatically choose the >Status Quo if the vote-count winner fails supermajority. That wording implies that the procedure continues till something wins that is qualified under the supermajority rule. But maybe that should be made specific, as in the following wording: Repeat the following procedure till the count rule specified by the Constitution chooses a winner that isn't prevented, by a supermajority rule, from replacing the Status-Quo: Count the rankings by the count rule specified by the Constitution. If the winner is prevented, by a supermajority rule, from replacing the Status-Quo, then delete that winner from the rankings, and re-count the ballots. [end of proposal] Let me call Mr. Buck's proposal Supermajority Proposal #2, and my proposal in the above paragraph Supermajority Proposal #3. If my Supermajority Proposal #1 didn't get 3 seconds, then shouldn't we vote among all the proposals so far? Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 06:23:54 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 15749 invoked from network); 22 Dec 2000 06:23:54 -0000 Received: from law-f59.hotmail.com (HELO hotmail.com) (209.185.131.122) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 06:23:54 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 22:23:51 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 06:23:50 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, bmbuck@14850.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au, bmbuck@zaphod.datahold.home Subject: Re: Resolve Supermajority Problems Date: Fri, 22 Dec 2000 06:23:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 06:23:51.0251 (UTC) FILETIME=[C02E4230:01C06BDF] X-Evolution: 0000001d-0010 Raul Miller wrote: >It would be simpler, and I believe equivalent, to remove from the ballot, >before ranking, any options which don't meet supermajority requirements. Shall we call that Supermajority Proposal #4?: After the rankings are counted by the count rule specified by the Constitution, delete from the rankings all the alternatives that need a supermajority and which don't beat the Status-Quo by the supermajority that they need. Then recount the ballots. [end of proposal] > >That is: if "status quo" is defined as meaning the explicit status quo >option, and not any option which is status quo as far the supermajority >requirement in question. Isn't the Status Quo just the alternative that is already in effect? The "incumbant" alternative? I don't know if #4 is equivalent to #2 & #3. But it sounds just as good. I like #2, #3, & #4 better than #1, but I claim that #3 is more explicit than #2 is about the repetition of the process. If #4 chooses different from those, I don't know which is better. Surely they're all adequate. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 06:33:21 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26461 invoked from network); 22 Dec 2000 06:33:21 -0000 Received: from law-f77.hotmail.com (HELO hotmail.com) (209.185.131.140) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 06:33:21 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 22:33:18 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 06:33:18 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com, moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Resolve Supermajority Problems Date: Fri, 22 Dec 2000 06:33:18 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 06:33:18.0766 (UTC) FILETIME=[12722CE0:01C06BE1] X-Evolution: 0000001e-0010 Buddha Buck wrote (Quoting Raul Miller): >>It would be simpler, and I believe equivalent, to remove from the ballot, >>before ranking, any options which don't meet supermajority requirements. > >I actually was thinking of the above as a concrete embodiment of the >following procedure: > >Find the winner normally. If the winner is disqualified, eliminate the >winner from the balloting and recompute the winner. That's your proposal #2. But Raul is saying that, after the 1st count, we delete from the rankings every alternative that requires a supermajority and which doesn't beat the Status-Quo by that required supermajority. Then we just do one more count. > >In this case, the disqualification would be not meeting a N:M supermajority >over an explicit status quo option. But it could be otherwise. For a >macabre example: Do we want to reballot if our Illustrious Leader-elect >gets hit by a bus? Or do we want to simply say "Death is a >disqualification, let's eliminate him/her and pick the next candidate from >the same ballots". Luckily, nonhuman alternatives can't die, and so that problem will be avoided. Later someone might propose a provision that, if the alternative in effect becomes, for some reason, no longer usable, then we recount the ballots of the election in which that alternative was chosen. But that sounds too detailed to be a concern for our recommendations. The agenda question is only about disqualification by supermajority. Also, the circumatances that make the in-use alternative no longer usable might change how we'd rank the other alternatives, and so a recount rule for that situation might not even be desirable. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 06:44:30 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5893 invoked from network); 22 Dec 2000 06:44:30 -0000 Received: from law-f80.hotmail.com (HELO hotmail.com) (209.185.131.143) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 06:44:30 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 22:44:27 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 06:44:27 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, bmbuck@14850.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Resolve Supermajority Problems Date: Fri, 22 Dec 2000 06:44:27 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 06:44:27.0703 (UTC) FILETIME=[A129DC70:01C06BE2] X-Evolution: 0000001f-0010 > > Find the winner normally. If the winner is disqualified, eliminate the > > winner from the balloting and recompute the winner. > >Why this procedure? [It's not the current debian procedure for >supermajority handling.] Does this procedure have some good properties? The existing procedure specifically refers to details of the different parts of the Concorde count. Since Concorde, we hope, will no longer be in use, a new supermajority wording is needed. Supermajority proposal #1, #2, #3, & #4 all make sense as new supermajority rules. I'm partial to #3 & #4. I don't know if they're equivalent, but surely either would be good. I believe that #3 differs from #2 only by making the iteration more explicit. I'd say that Raul has a point: As soon as we know, after the 1st count, that certain alternatives aren't going to be able to replace the Status Quo, because they don't beat it well enough, then there's no longer any reason to include them in subsequent counts. Surely an alternative that is known to be unqualified to replace the Status Quo, even if it wins the count, can't meaningfully be called an "alternative". So I prefer Raul's proposal #4 now. So I'd now rank the proposals: #4, #3, #2, #1 Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 06:56:43 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 17516 invoked from network); 22 Dec 2000 06:56:43 -0000 Received: from law-f70.hotmail.com (HELO hotmail.com) (209.185.131.133) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 06:56:43 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 22:56:40 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 06:56:40 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com, moth@debian.org, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Resolve Supermajority Problems Date: Fri, 22 Dec 2000 06:56:40 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 06:56:40.0434 (UTC) FILETIME=[55E7BD20:01C06BE4] X-Evolution: 00000020-0010 Buddha Buck wrote: >Pre-elimination may also >distort the outcome as well (the fact that resolution B defeated Amendment >A may help B to be the ultimate winner, even if A does not have a >supermajority. Eliminating A ahead of time might make B lose. Yes, I don't know, maybe Raul's (#4) 1-step elimination of all the alternatives that don't qualify to replace the Status-Quo could give a different winner than my #3 or your #2. But the question then would be: Is that a worse result, the one gotten by immediate elimination, after the 1st count, of all those alternatives that are disqualified by the supermajority rule? If the immediate deletion of all unqualified alternatives changes the result, we can't say that it's changing it away from the rightful result, unless someone can claim that the rightful thing is to have those unqualified alternatives in the count. Keeping them in the count sounds _less_ rightful to me. I know of no reason why #4's result would be worse than that of #2 or #3. Different, maybe. Worse? I know of no reason to say it's worse. And I claim that, as soon as we know, after the 1st count, that certain alternatives don't qualify to replace the Status-Quo, even if they won the count, then there's no longer any reason to call them "alternatives", and so deleting them immediately from the ballots, as Raul pointed out, is what makes the most sense. I suggest that #4 is the proposal that makes the most sense. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From npetry@accesscomm.ca Fri Dec 22 07:06:33 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28346 invoked from network); 22 Dec 2000 07:06:33 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 07:06:33 -0000 Message-ID: <018f01c06be5$abeb9600$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "'Raul Miller'" , "Mike Ossipoff" , "Steve Greenland" , "Rob Lanphier" , "Buddha Buck" , "Anthony Towns" , "Norman Petry" Subject: Re: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 01:06:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000021-0010 Buddha, I think your summary of the supermajority proposals is excellent. It is certainly an accurate description of the two proposals I suggested (although you did reorder them...). I don't really agree with the names of some of your definitions (Amendment vs. Resolution suggests the wrong idea, for example), but this is unimportant for the purposes of internal discussion, so I will use your terminology. I have some specific comments about each of the 5 methods you describe, below. >To the question "What does 'supermajority' mean in a ranked-ballot >situation" the only answer I've seen was from Mike Ossipoff, that being >that an amendment can be adopted only if it defeats the status quo by a >supermajority. I've seen no other suggestion, nor any opposition to >that suggestion. I think we may have achieved consensus on that point. I agree. However, Raul suggested, based on Petry-2, that we might want to introduce a 'majority of developers' alternative to the pairwise relative supermajority, and that might affect our final definition. More on this later. >I think we can also agree that if there is an option that has a >supermajority requirement, there must be a "Status Quo" option. I'd go >further and suggest that except for elections, there must be a "Status >Quo" option, even without supermajority requirements. Currently, the default option for elections is NOTA (none of the above). I personally don't care for this, since if NOTA wins, it is not clear that reballoting is going to help. Election of officers is important, and an organisation cannot function if the voting method cannot decide on a winner. Therefore, my preference would be to abolish the default option in these cases. I don't think it's a particularly important issue, however so it might be simpler to just leave it be. >So, here are the proposals, summarized by me: > >Ossipoff: Find the best option. If the best option is an ineligible >amendment, adopt the Status Quo; otherwise, adopt the best option. This method has the advantage of extreme simplicity. However, it will result in the selection of the status quo more often than is necessary, by rejecting winnable resolutions. >Buck: Find the best option. If the best option is an ineligible >amendment, discard it and find the next best option. Adopt the first >best option that isn't an ineligible amendment. This overcomes the above-mentioned objection to Ossipoff. However, I have two reservations about this method: 1) Outcomes can potentially be affected by 'irrelevant alternatives', since the testing for supermajority is carried out after the pairwise count. See my previous post for more on this. 2) This is a successive elimination method, and is therefore probably not monotonic. Monotonicity is criterion which is intended to guarantee that the method responds rationally to changes in individual voter preferences. Here's a definition: Monotonicity: "A voting system is monotonic if when a voter raises the valuation for a winning alternative it remains a winning alternative, and when a voter lowers the valuation for a losing alternative it remains a losing alternative. All voting systems that eliminate alternatives prior to selecting a winner violate monotonicity" Note that last sentence. On EM we have found that detecting monotonicity violations can be extremely difficult, and I have not got an example which would show that your method isn't monotonic -- I just suspect that it may not be. Methods such as STV routinely violate monotonicity, as they use successive eliminations to choose a winner. >Miller: Discard all ineligible amendments. Adopt the best option >remaining. (Note: may not have been formally proposed, claimed to be >equivilant to Buck). Like Ossipoff, has the advantage of extreme simplicity. Perhaps better than Ossipoff, because it allows amendments and resolutions to be selected from at the same time. >Petry-1: Discard all amendments that are not plausible. Adopt the best >option remaining. More complex than Miller, but allows for the inclusion of additional candidates that are winnable under successive applications of the supermajority requirement, thereby minimising reballoting. Otherwise similar to Miller. >Petry-2: Drop supermajority requirements all-together. Simplest of all, and produces the best results (imo). Probably too controversial, however. >Have I missed anything, or mischaracterized anything or anyone? Not me ;-) -- Norm Petry From nkklrp@hotmail.com Fri Dec 22 07:48:29 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8275 invoked from network); 22 Dec 2000 07:48:29 -0000 Received: from law-f50.hotmail.com (HELO hotmail.com) (209.185.131.113) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 07:48:29 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Dec 2000 23:48:26 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 07:48:25 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, moth@debian.org, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Two Proposals for the Supermajority Requirement Date: Fri, 22 Dec 2000 07:48:25 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 07:48:26.0071 (UTC) FILETIME=[91025670:01C06BEB] X-Evolution: 00000022-0010 >I have two proposals to make for resolving the current problems with the >way >supermajorities are handled in the Debian constitution. They are listed in >order of preference, but I expect that Proposal #1 might be considered too >'radical' for Debian, so I am also suggesting a second-choice alternative. Can we call Norm's 2 proposals #5 & #6, adding them to the 4 other proposals so far? > >Please let me know your opinions of these proposals. > >***** > >PROPOSAL #1 - ABOLISH SUPERMAJORITY REQUIREMENTS Norm argues convincingly for abolishing supermajority requirements. I've never liked them. When I first heard about them, they sounded undemocratic, and still do. I feel it would be better not to have them. But abolishing supermajority requirements would, as Norm suggested, be too radical to be our sole recommendation to Debian on supermajorities. Adapting the supermajority rules to the new pairwise-count voting system is more within the scope of the agenda. Of course, when we choose #1, #2, #3 or #4, to adapt the supermajority rule to the new voting system, there's no reason why we couldn't add, as an entirely separate recommendation, the abolition of the supermajority requirement. The only reason maybe to not do that would be if it would start debate in Debian that would continue so long that they'd never get around to changing the voting system. For that reason I'd be more inclined to save supermajority rule abolition for a separate proposal, after the less controversial changes, like the new voting system have already been adopted by Debian. >PROPOSAL #2 - DETERMINE AN "ELIGIBLE" SET OF CANDIDATES (This is proposal #6, when placed in the overall numbering of the supermajority proposals, in order of their proposing). > >Here is a more modest proposal which the committee might want to adopt, if >supermajority requirements are to be retained. Rather than just describing >the concept, I've tried to write the proposal as I think it should appear >as >part of an actual voting method within the constitution. Some of the >underlying definitions are not specified in this description ('beats', for >example would either be defined here or added to a glossary), but their >meaning is probably obvious to those of us on the committee. I'll describe >some of the advantages of this system following the description. > >*** > >Definitions: > >A "restricted option" is an option which would require a supermajority to >be >adopted. > >A "regular option" is an option which would require a simple majority to be >adopted You're talking about a majority of those voters who have voted a preference between that alternative and the status quo, right? It makes sense that that's the only kind of majority we'd be talking about, since the supermajority requirements are defined in terms of a ration like 3:1, meaning the number of people voting the replacement over the status quo divided by the number voting the status quo over the replacement. > >Restricted options and regular options may be combined on a single ballot. >However, all the restricted options appearing on the ballot must have the >same supermajority requirement. Why? If restricted & regular can both appear on the same ballot, then why not allow restricted options with different supermajority requirements? > >To determine a winner, the following sequence of steps will be carried out, >in order and without exception unless explicitly stated otherwise: > >1. An initial set of "eligible" options is determined according to the >following rules: > >a) The default option is always eligible*. The default option being the Status-Quo, right? >b) All regular options are eligible. >c) A restricted option which beats the default option by a supermajority is >eligible. >d) A restricted option which beats another eligible, restricted option by a >supermajority is eligible. I don't like that one. You convincingly argue, below, why your rule d) would be better. I agree that it would be better, for the reason that you give. But it would violate the meaning of the supermajority rule. It would amount to rewriting Debian's supermajority rule in a much more fundamental & controversial way. And it would amount to a meaning that differs more from the ordinary expected meaning of a supermajority requirement. So I strongly suggest that your rule d) is something that could _later_ be proposed, as a radical change in the meaning of the supermajority rule. But, for the purpose of our recommendations this time, let's stick with adapting the current notion of supermajority rules to the new pairwise-count methods. Writing a supermajority rule that doesn't only apply to Concorde. Our #1, #2, #3, & #4 are that kind of supermajority rules--adaptations of the existing supermajority rule to voting systems other than Concorde. > >2. All options not satisfying at least one of the conditions for >eligibility >specified in (1) are "ineligible", and are eliminated from consideration in >the remaining steps. Yes, that's like Raul's #4, which I agree is the right procedure. After the 1st pairwise count, it will be known which alternatives are disqualified by supermajority rules, and they should be deleted from the rankings. >Any references to these options on either the ballots >or in the pairwise matrix are ignored. > >... > >[continue with definition of a pairwise method used to choose a winner from >among those 'eligible'] >Perhaps Buddha >and Anthony could check it against the supermajority criteria they have >proposed. With the deletion of rule d), it becomes like Raul Miller's #4, except that it speaks of the initial pairwise-count as not being part of the voting system's count. It could be looked at either way. Norm's wording is more general, because it would apply to methods that aren't even pairwise-count methods. But, since a pairwise-count method will surely be used, Norm's #6 and Raul's #4 would be the same, if we delete rule d) from Norm's proposal #6. Let me name, as #7, Norm's proposal with its rule d) deleted. #7 is apparently the same as #4, except for the wording, and its reference to the initial pairwise-count, for determining supermajority disqualification, as something separate from & preceding the voting system's own count. Again, that distinction won't matter if Debian is using a pairwise-count method, as it surely will be. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 08:43:07 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28985 invoked from network); 22 Dec 2000 08:43:07 -0000 Received: from law-f69.hotmail.com (HELO hotmail.com) (209.185.131.132) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 08:43:07 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 00:43:06 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 08:43:06 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, moth@debian.org, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 08:43:06 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 08:43:06.0720 (UTC) FILETIME=[346DA600:01C06BF3] X-Evolution: 00000023-0010 Norm wrote: >I think your summary of the supermajority proposals is excellent. Yes, it seems to cover all the most seriously proposed proposals. >I have some specific comments about each of >the 5 methods you describe, below. > > >To the question "What does 'supermajority' mean in a ranked-ballot > >situation" the only answer I've seen was from Mike Ossipoff, that being > >that an amendment can be adopted only if it defeats the status quo by a > >supermajority. I've seen no other suggestion, nor any opposition to > >that suggestion. I think we may have achieved consensus on that point. > >I agree. However, Raul suggested, based on Petry-2, that we might want to >introduce a 'majority of developers' alternative to the pairwise relative >supermajority That would count as an additional proposal, but, like Norm's abolition of supermajorities, introducing a "majority of developers" radically rewrites the supermajority concept. We can add both of those rewrites as numbered proposals, but I claim that we don't want to recommend a radical rewrite. Let's just recommend one of the proposals that adapts the current Debian supermajority rules to pairwise-count methods (Miller) or all methods (Petry minus rule d) To Mr. Buck's list, I'd add my amendment of Petry: Petry without rule d. I claim that Petry's rule d amounts to a radical rewrite of the supermajority concept and would be controversial. Thereforek, though' I agree with Norm's reason why it would be more efficient to have rule d, I claim that it's too controversial, amounting to a radical rewrite of the supermajority requirement. Because rule would be an improvement, efficiency-wise, I suggest a _later_ proposal, after Debian has decided on all of our recommendations, to enact rule d. Likewise, a later proposal to abolish supermajority requirements altogether would be good. But neither of those radical rewrites belongs in our recommendations this time. > >So, here are the proposals, summarized by me: > > > >Ossipoff: Find the best option. If the best option is an ineligible > >amendment, adopt the Status Quo; otherwise, adopt the best option. > >This method has the advantage of extreme simplicity. However, it will >result in the selection of the status quo more often than is necessary, by >rejecting winnable resolutions. Agreed. I now prefer Raul Miller's proposal to delete all alternatives that need a supermajority and don't beat the Status Quo by the required supermajority in the initial pairwise count. > > >Buck: Find the best option. If the best option is an ineligible > >amendment, discard it and find the next best option. Adopt the first > >best option that isn't an ineligible amendment. Since Mr. Buck has specified that his proposal is iterative, there's no longer any need for my "#3" proposal, since now #3 is the same as #2. So I withdraw my #3. Now that Raul's proposal (immediately below) has been proposed, I agree that Raul's proposal is better, for the 2 reasons that Norm listed. > >Miller: Discard all ineligible amendments. Adopt the best option > >remaining. (Note: may not have been formally proposed, claimed to be > >equivilant to Buck). > >Like Ossipoff, has the advantage of extreme simplicity. Perhaps better >than >Ossipoff, because it allows amendments and resolutions to be selected from >at the same time. > > >Petry-1: Discard all amendments that are not plausible. Adopt the best > >option remaining. > >More complex than Miller, but allows for the inclusion of additional >candidates that are winnable under successive applications of the >supermajority requirement, thereby minimising reballoting. Otherwise >similar to Miller. ...except for its rule d, which radically rewrites the supermajority requirement. So I add the following proposal: Petry-1 without rule d. That differs from Miller only by wording the initial pairwise count as separate from the voting system's count, making the proposal apply to all voting systems, not just pairwise-count methods. But since a pairwise-count method will surely be used by Debian anyway, Petry-1 without rule d is effectively the same as Miller. Still, because of its different wording, I suggest that it be considered a separate proposal. > > >Petry-2: Drop supermajority requirements all-together. > >Simplest of all, and produces the best results (imo). Probably too >controversial, however. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From aj@azure.humbug.org.au Fri Dec 22 09:09:58 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 18547 invoked from network); 22 Dec 2000 09:09:58 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 09:09:58 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 149OCz-0004c5-00; Fri, 22 Dec 2000 19:09:49 +1000 Date: Fri, 22 Dec 2000 19:09:49 +1000 From: Anthony Towns To: Norman Petry Cc: 'Raul Miller' , Mike Ossipoff , Steve Greenland , Rob Lanphier , Buddha Buck Subject: Re: Status/Summary of proposals so far... Message-ID: <20001222190948.A16460@azure.humbug.org.au> References: <018f01c06be5$abeb9600$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <018f01c06be5$abeb9600$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Fri, Dec 22, 2000 at 01:06:13AM -0600 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000024-0010 Maths. Summary: Buck's method is always half-monotonic, but is not fully monotonic in at least some case (depending on which ranking scheme is used to choose the winner in the iterative step). I like proofs. Sue me. On Fri, Dec 22, 2000 at 01:06:13AM -0600, Norman Petry wrote: > 2) This is a successive elimination method, and is therefore probably not > monotonic. Monotonicity is criterion which is intended to guarantee that > the method responds rationally to changes in individual voter preferences. > Here's a definition: > > Monotonicity: "A voting system is monotonic if when a voter raises the > valuation for a winning alternative it remains a winning alternative, and > when a voter lowers the valuation for a losing alternative it remains a > losing alternative. All voting systems that eliminate alternatives prior to > selecting a winner violate monotonicity" Suppose the process is as follows: 1. Select a candidate winner, in a monotonic manner. 2. Work out if it beat the status-quo by the required amount, if so, we're done, if not, eliminate it, go back to 1. Then we have a sequence of candidate winners: e_1, e_2, e_3, ..., e_k, w (k >= 0) and some left overs, l_1, l_2, .., l_j (j >= 0). If we change the ranking of e_i to lower it, it'll still not meet its supermajority requirement, so won't win. If we don't change any of the e_i entries, then the final vote will be amongst w and some other candidates using a monotonic system, so the result will still be w. So the method is immune to lowering the ranking of losers. For it to fail monotonicity wrt raising the ranking of the winner, you'd have to have a ranking method that allows you to have something like: if e wins the ballot containing: e, w, l, E.., L.. (where E.. and L.. representing many options) and w wins the ballot containing: w, l, L.. and since it's monotonic and w wins { w+, l, L } (ie, w is ranked higher) has _l_ win { e, w+, l, E.., L.. } But it's a stronger requirement on the ranking method than monoticity to achieve this, I guess. Perhaps something like: { e, w, l, e' } e beats e' e' beats w (weakened) e beats w (reversed) e beats l e' beats l w beats l (strengthened) So, if your method is choose the option whose strongest defeat is the weakest, and have a vote with options, W, L, E, F, S that goes like: E beats F 93 30 F beats W 93 30 E beats W 63 60 W beats L 63 60 E beats L 63 60 F beats L 63 60 Which can be had by votes like: 63 EFWLS 30 SLWEF 30 SLFWE The outcome of that using the Buck method would be: (1) E beats all other options so wins (2) E beats S by 63:60, doesn't achieve 3:1 supermajority, removed (1) F beats all other options so wins (2) F beats S by 63:60, doesn't achieve 3:1 supermajority, removed (1) W beats all other options (63:60), so wins (2) W doesn't need a supermajority, so W is chosen If you changed the vote results to be more like: 6 WEFLS *** 57 EFWLS 30 SLWEF 30 SLFWE (ie, 6 people ranked W higher than EF instead of lower), then you'd have: E beats F 93 30 F beats W 87 36 (weakened) W beats E 66 57 (swapped) W beats L 63 60 E beats L 63 60 F beats L 63 60 So the greatest defeats are now: F: beaten by E by 63 (93/30) W: beaten by F by 51 (87/36) E: beaten by W by 9 (66/57) L: beaten by W/E/F by 3 (63/60) so L is selected, so using that ranking method (which I assume is monotonic by itself), Buck's method isn't monotonic. You might be able to use a different ranking method and have it be monotonic though, dunno. I suspect using a Smith + tie-breaker method may be able to be made work, maybe. Cheers, aj -- Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 From nkklrp@hotmail.com Fri Dec 22 09:44:51 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 15952 invoked from network); 22 Dec 2000 09:44:51 -0000 Received: from law-f90.hotmail.com (HELO hotmail.com) (209.185.131.153) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 09:44:51 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 01:44:51 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 09:44:50 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, bmbuck@14850.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Raul's proposal Date: Fri, 22 Dec 2000 09:44:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 09:44:51.0154 (UTC) FILETIME=[D4716B20:01C06BFB] X-Evolution: 00000025-0010 Raul's proposal could be worded: Conduct a pairwise count. Delete from the rankings every alternative which requires a supermajority to replace the Status-Quo, and which doesn't beat the Status-Quo by that required supermajority. Then apply to the rankings the rank-count rule specified by the Debian Constitution. The alternative that wins that count is adopted to replace the Status-Quo. [end of definition] Worded like that, it sounds the same as Petry minus rule d, and so , to simplify the proposal list, I withdraw "Petry minus rule d". Raul's proposal, quoted above, seems the best one. As Norm said, we'd have to include the definition of "beat" or "pairwise-beat". "X beats Y if more voters rank X over Y than vice-versa. Ranking X & not Y counts as ranking X over Y. For X to beat Y 3-to-1 means that 3 times as more people ranked X over Y than Y over X." Norm's proposal is like the above, but its rule d changes the meaning of "supermajority requirement" too radically for our recommendation, it seems to me. But rule d seems to be a desirable change that would result in more efficiency, and should be proposed later, after Debian has decided on our recommendations. So this is a brief repetition of Mr. Buck's list: Ossipoff Buck Miller Petry 1 (abolish supermajority requirements) Petry 2 (Miller + rule d) [end of list] I've left my initial proposal, even though I now consider Miller's proposal better. I advocatge Miller. We've heard arguments for & against these proposals, and arguments comparing their merit. Should we start voting now? My ranking: 1. Miller 2. Buck *** Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Dec 22 09:51:15 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 21715 invoked from network); 22 Dec 2000 09:51:15 -0000 Received: from law-f63.hotmail.com (HELO hotmail.com) (209.185.131.126) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 09:51:15 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 01:51:14 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 22 Dec 2000 09:51:14 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au, bmbuck@14850.com Cc: npetry@accesscomm.ca, moth@debian.org, stevegr@debian.org, robla@eskimo.com Subject: Re: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 09:51:14 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Dec 2000 09:51:14.0543 (UTC) FILETIME=[B8F5EFF0:01C06BFC] X-Evolution: 00000026-0010 Anthony wrote: >Another way of handling this would be to choose a method that ranks >the entire list of options, rather than just chooses a winner. Once the >options are ranked, choose the highest ranked eligible option. This sounds equivalent to Buck's proposal, which elects the highest finisher that is eligible. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From aj@azure.humbug.org.au Fri Dec 22 11:23:00 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2071 invoked from network); 22 Dec 2000 11:23:00 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 11:23:00 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 149QHl-00052l-00; Fri, 22 Dec 2000 21:22:53 +1000 Date: Fri, 22 Dec 2000 21:22:53 +1000 From: Anthony Towns To: MIKE OSSIPOFF Cc: bmbuck@14850.com, npetry@accesscomm.ca, moth@debian.org, stevegr@debian.org, robla@eskimo.com Subject: Re: Status/Summary of proposals so far... Message-ID: <20001222212253.B16460@azure.humbug.org.au> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Dec 22, 2000 at 09:51:14AM -0000 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000027-0030 --xHFwDpU9dbj6ez1V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 22, 2000 at 09:51:14AM -0000, MIKE OSSIPOFF wrote: > >Another way of handling this would be to choose a method that ranks > >the entire list of options, rather than just chooses a winner. Once the > >options are ranked, choose the highest ranked eligible option. > This sounds equivalent to Buck's proposal, which elects the highest > finisher that is eligible. It's not though: Buck's method can rearrange the rankings at each turn. For example, umm, if you order by strongest defeat (weaker being better): Three options, A, B, C; with A needing supermajority 50 ABCS 20 BCAS 40 CSAB Initial pairwise results: C beats A: 60 to 50 (10) A beats B: 90 to 20 (70) B beats C: 70 to 40 (30) A,B beats S: 70 to 40 (30) C beats S: 110 to 0 (110) Strongest defeats: A: 10, C: 30, B: 70, S: 110. A is eliminated. Then, either C is chosen, by just continuing down the rankings, or the pairwise results are recalculated without A, and you end up with: B beats C: 70 to 40 B beats S: 70 to 40 C beats S: 110 to 0 and B has no pairwise defeats, and wins. So each of: Miller: eliminate ineligible options, choose winner Buck: choose winner, if it's ineligible eliminate, repeat Towns: form complete ranking, choose highest ranked eligible option behave differently in at least come cases. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkM5jORRvX9xctrtAQGRpgP+LVOjiaKaNLgw3O/VDyJLAfEkgz7zZRdl +8o3D10E8vvxACQ0JCDBoieHN6T22PlkeNtSJfWDscs71+mP83pB/XLx4FsQANkn vxvYEPcSKqE6ml3ihlEJy89AABGGiOHpI+fEUMuP715tBQU5tOOx2IZlykw4egF2 GEV2fim8ueM= =eSvh -----END PGP SIGNATURE----- --xHFwDpU9dbj6ez1V-- From moth@debian.org Fri Dec 22 17:04:41 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 32116 invoked from network); 22 Dec 2000 17:04:41 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 17:04:41 -0000 Received: (qmail 28127 invoked by uid 1000); 22 Dec 2000 17:04:31 -0000 Date: Fri, 22 Dec 2000 12:04:31 -0500 From: Raul Miller To: Anthony Towns Cc: MIKE OSSIPOFF , bmbuck@14850.com, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com Subject: Re: Status/Summary of proposals so far... Message-ID: <977503495.58d05a55@debian.org> References: <20001222212253.B16460@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001222212253.B16460@azure.humbug.org.au>; from aj@azure.humbug.org.au on Fri, Dec 22, 2000 at 09:22:53PM +1000 X-Evolution: 00000028-0010 On Fri, Dec 22, 2000 at 09:22:53PM +1000, Anthony Towns wrote: > So each of: > > Miller: eliminate ineligible options, choose winner > Buck: choose winner, if it's ineligible eliminate, repeat > Towns: form complete ranking, choose highest ranked eligible option > > behave differently in at least come cases. I agree that the behavior can be different, though I'll note that the nature of this difference depends on the vote ranking system. I'll also note that a vote ranking system where this difference is significant is likely to have more problems picking the winner from a large set of options than it would picking the winner from a small set of options. If this behavioral difference is controversial, then I propose we defer deciding on how supermajority is handled until after we've decided on a vote ranking system. Personally, I like the way that Ossipoff rephrased my original conjecture, and prefer that method and that phrasing [given the underlying assumptions about the goals and nature of supermajority]. I don't have any logical basis to choose between any of the alternatives. I'm still waiting for Petry's comments on my contrast of "debian supermajority" with "majority of developers". And, I'd like to develop it further: I'd like to propose that "debian supermajority" would only apply where less than a majority of all developers prefer an option. [If this is controversial, then I'm happy to defer it to a later set of recommendations.] I don't know if the point has been made, but Debian is elitist, not democratic. The underlying idea is that a small number of people can deal with most issues, and that most people don't care about the issues. However, I see no reason for this to exclude democracy as a fallback, for potential cases where most people are interested in an issue. Thanks, -- Raul From npetry@accesscomm.ca Fri Dec 22 18:23:31 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3467 invoked from network); 22 Dec 2000 18:23:31 -0000 Received: from static24-72-33-128.reverse.accesscomm.ca (HELO aule) (24.72.33.128) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 18:23:31 -0000 From: "Norman Petry" To: "'Raul Miller'" , "'Buddha Buck'" , , , , , Subject: RE: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 12:23:28 -0600 Message-ID: <001201c06c44$48e02940$4d01a8c0@archives.gov.sk.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <20001221184006.A14930@usatoday.com> X-Evolution: 00000029-0010 Raul wrote: > Final note: philosophically, based on Norman's argument against > supermajority, I could go along with the idea that if more than half of > all debian developers have voted in favor of an option, that we ignore the > "supermajority" requirement. [If we did this, we should come up with a > better name than 'supermajority' because obviously it would obviously > mean something else.] However, I expect that most debian votes will > involve far less than half of all registered debian developers. I like this suggestion, since it ensures that when the preference of the majority is absolutely certain, the choice of that majority can never be thwarted by a minority. It is a good compromise between my more radical proposal, and the status quo. Furthermore, implementing this change is not difficult. Rather than define 'supermajority' in the constitution, we could use a different term and substitute that wherever supermajority would normally be used. For example, define 'Strong Majority' as the lesser of: 1) an absolute majority of registered developers 2) a pairwise relative supermajority of m:n against the status-quo (as before) Then to amend the constitution a strong majority (3:1), rather than a supermajority would be required. Normally, I suspect that the supermajority requirement would actually be easier to satisfy, but if the participation rate is high, then the absolute majority requirement becomes easier. Suppose: d = total developers m:n = supermajority ratio p = participation rate m1 = absolute majority = 1+d/2 m2 = pairwise relative supermajority = 1+pdm/(m+n) Then the supermajority constraint is lifted when m1 = m2, which gives: 1+d/2 = 1+pdm/(m+n), p = (m+n)/2m. For m:n = 3:1, p = 0.667 For example, suppose there are 600 developers and a 3:1 supermajority ratio. Then if only 350 voters participate (<2/3), amending the constitution by the absolute majority rule would require 85.7% in favour (300/350), which is greater than the 75% required for supermajority. However, if 450 voters participate, then only 300/450 = 67% must support the change for it to be accepted. I think that past election results probably show a participation rate of 50% or less, which means that *usually* the supermajority rules will apply. However, the absolute majority rule provides a useful 'safety valve' to prevent a certain minority of developers from thwarting the wishes of the majority. It is likely that if there was a very serious issue, and very divided opinions about how to deal with it, having rules that prevent a clear majority of developers from making the changes they deemed necessary would destroy the organisation. When participation is less than 100%, then sure there is always some doubt that the outcome of a vote reflects the will of the organisation as a whole. Therefore, supermajority provides some protection against capricious change. But when there is NO doubt about what the majority wants, they should be able to get their way. If this is what you had in mind, then I support your suggestion. -- Norm Petry From moth@debian.org Fri Dec 22 18:46:02 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 32048 invoked from network); 22 Dec 2000 18:46:02 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 18:46:02 -0000 Received: (qmail 30300 invoked by uid 1000); 22 Dec 2000 18:45:52 -0000 Date: Fri, 22 Dec 2000 13:45:52 -0500 From: Raul Miller To: Norman Petry Cc: 'Buddha Buck' , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Status/Summary of proposals so far... Message-ID: <977510319.506ab923@debian.org> References: <20001221184006.A14930@usatoday.com> <001201c06c44$48e02940$4d01a8c0@archives.gov.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001201c06c44$48e02940$4d01a8c0@archives.gov.sk.ca>; from npetry@accesscomm.ca on Fri, Dec 22, 2000 at 12:23:28PM -0600 X-Evolution: 0000002a-0010 On Fri, Dec 22, 2000 at 12:23:28PM -0600, Norman Petry wrote: > For example, define 'Strong Majority' as the lesser of: > > 1) an absolute majority of registered developers > 2) a pairwise relative supermajority of m:n against the status-quo (as > before) > > Then to amend the constitution a strong majority (3:1), rather than a > supermajority would be required. Normally, I suspect that the supermajority > requirement would actually be easier to satisfy, but if the participation > rate is high, then the absolute majority requirement becomes easier. > > Suppose: > > d = total developers > m:n = supermajority ratio > p = participation rate > > m1 = absolute majority = 1+d/2 > m2 = pairwise relative supermajority = 1+pdm/(m+n) > > Then the supermajority constraint is lifted when m1 = m2, which gives: > > 1+d/2 = 1+pdm/(m+n), > > p = (m+n)/2m. For m:n = 3:1, p = 0.667 > > For example, suppose there are 600 developers and a 3:1 supermajority ratio. > Then if only 350 voters participate (<2/3), amending the constitution by the > absolute majority rule would require 85.7% in favour (300/350), which is > greater than the 75% required for supermajority. However, if 450 voters > participate, then only 300/450 = 67% must support the change for it to be > accepted. That looks about right, with a minor arithmetic quibble (301 developers constitutes a majority if there are 600). > If this is what you had in mind, then I support your suggestion. It is. I hope that we can use this idea (what we're calling "strong majority" is an approximation of an absolute majority requirement) to gauge the relative goodness of some of the various "supermajority proposals". [That is, by looking at the behavior of the various systems, around the transition point.] However, I've not thought this through far enough, yet, to see where this leads. Thanks, -- Raul From npetry@accesscomm.ca Fri Dec 22 19:52:25 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 16227 invoked from network); 22 Dec 2000 19:52:25 -0000 Received: from static24-72-33-128.reverse.accesscomm.ca (HELO aule) (24.72.33.128) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 19:52:25 -0000 From: "Norman Petry" To: "'Raul Miller'" , "'Buddha Buck'" , , , , , Subject: RE: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 13:52:22 -0600 Message-ID: <001701c06c50$b3c835c0$4d01a8c0@archives.gov.sk.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <977510319.506ab923@debian.org> X-Evolution: 0000002b-0010 Raul Miller wrote: > > Suppose: > > > > d = total developers > > m:n = supermajority ratio > > p = participation rate > > > > m1 = absolute majority = 1+d/2 > > m2 = pairwise relative supermajority = 1+pdm/(m+n) > > > > Then the supermajority constraint is lifted when m1 = m2, which gives: > > > > 1+d/2 = 1+pdm/(m+n), > > > > p = (m+n)/2m. For m:n = 3:1, p = 0.667 > > [...] > > That looks about right, with a minor arithmetic quibble (301 developers > constitutes a majority if there are 600). > If you get to quibble, then so do I :-) You forgot to cancel the 1's (also, that's integer division I'm using in the above formulas). > > If this is what you had in mind, then I support your suggestion. > > It is. > Good. I hope others will express support for this idea as well (or at least state their concerns -- we need to get some idea if the developers on the ctte think this proposal is winnable). > I hope that we can use this idea (what we're calling "strong majority" > is an approximation of an absolute majority requirement) to gauge the > relative goodness of some of the various "supermajority proposals". It occurred to me, after posting my message that there is no reason to refer to this as anything other than a 'supermajority'. This is because supermajority is defined as: "su·per·ma·jor·i·ty (spr-m-jôr-t, -jr-) n., pl. su·per·ma·jor·i·ties. A percentage higher than 50 percent required for approval of a motion or an action determined by vote, as among the shareholders of a company." -- http://www.dictionary.com/cgi-bin/dict.pl?term=supermajority Note that there is nothing in this concept requiring that there be a *fixed* ratio of support to opposition, merely that it be greater than half the *voters*. The 'strong majority' rule I proposed therefore *is* a supermajority rule, because this will always be true for anything less than 100% participation (even then, the addition of the 1 voter to the required total ensures that the percentage is *always* strictly greater than 50%). Therefore, if this rule is adopted, I see no reason why we cannot continue to refer to it as a 'supermajority' within the constitution. Regardless of what concept of supermajority we adopt, it will be necessary to provide a clear definition anyway, since combining supermajorities with pairwise voting is certainly unusual and the meaning cannot be assumed by anyone either within or outside debian. -- Norm Petry From bmbuck@14850.com Fri Dec 22 21:59:19 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1778 invoked from network); 22 Dec 2000 21:59:19 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 21:59:19 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Fri, 22 Dec 2000 16:59:13 -0500 Message-Id: <5.0.0.25.0.20001222153002.031d8aa0@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 22 Dec 2000 21:59:06 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 22 Dec 2000 16:57:57 -0500 To: "Norman Petry" ,"'Raul Miller'" , ,,, , From: Buddha Buck Subject: RE: Status/Summary of proposals so far... In-Reply-To: <001701c06c50$b3c835c0$4d01a8c0@archives.gov.sk.ca> References: <977510319.506ab923@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Evolution: 0000002c-0010 At 01:52 PM 12-22-2000 -0600, Norman Petry wrote: >It occurred to me, after posting my message that there is no reason to ref= er >to this as anything other than a 'supermajority'. This is because >supermajority is defined as: > >"su=B7per=B7ma=B7jor=B7i=B7ty (spr-m-j=F4r-t, -jr-) >n., pl. su=B7per=B7ma=B7jor=B7i=B7ties. > >A percentage higher than 50 percent required for approval of a motion or a= n >action determined by vote, as among the shareholders of a company." -- >http://www.dictionary.com/cgi-bin/dict.pl?term=3Dsupermajority > >Note that there is nothing in this concept requiring that there be a *fixe= d* >ratio of support to opposition, merely that it be greater than half the >*voters*. The 'strong majority' rule I proposed therefore *is* a >supermajority rule, because this will always be true for anything less tha= n >100% participation (even then, the addition of the 1 voter to the required >total ensures that the percentage is *always* strictly greater than 50%). > >Therefore, if this rule is adopted, I see no reason why we cannot continue >to refer to it as a 'supermajority' within the constitution. Regardless o= f >what concept of supermajority we adopt, it will be necessary to provide a >clear definition anyway, since combining supermajorities with pairwise >voting is certainly unusual and the meaning cannot be assumed by anyone >either within or outside debian. I think that in the interest of clarity, we shouldn't use words that people= =20 THINK they know what means but give them other meanings. Most people don't= =20 see 50%+1 as a supermajority, but as a majority. We are stretching the conventional definition of "supermajority" already=20 (but with good reason). I can easily see someone voting A>B, thinking "I=20 like resolution A, hate amendment B, don't have an opinion about the status= =20 quo" without realizing that their ballot could actually help B win (Imagine= =20 99 other ballots, B beats A 60:39, B beats SQ 74:25. The AB vote would=20 make that B>A 60:40, B>SQ 75:25, B is adopted). Making it "3:1 over Status Quo for all votes cast, or 50% over status quo=20 for all developers" just muddles the issue more. We may wish to use the term "Overwhelming Support over Status Quo" instead=20 of "supermajority", and define this "Overwhelming Support" any way we find=20 reasonable. >-- >Norm Petry From moth@debian.org Fri Dec 22 22:56:49 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 32285 invoked from network); 22 Dec 2000 22:56:49 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 22 Dec 2000 22:56:49 -0000 Received: (qmail 3043 invoked by uid 1000); 22 Dec 2000 22:56:38 -0000 Date: Fri, 22 Dec 2000 17:56:38 -0500 From: Raul Miller To: Norman Petry Cc: 'Buddha Buck' , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Status/Summary of proposals so far... Message-ID: <20001222175638.A2588@usatoday.com> References: <977510319.506ab923@debian.org> <001701c06c50$b3c835c0$4d01a8c0@archives.gov.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001701c06c50$b3c835c0$4d01a8c0@archives.gov.sk.ca>; from npetry@accesscomm.ca on Fri, Dec 22, 2000 at 01:52:22PM -0600 X-Evolution: 0000002d-0010 > > > d = total developers > > > m:n = supermajority ratio > > > p = participation rate > > > > > > m1 = absolute majority = 1+d/2 > > > m2 = pairwise relative supermajority = 1+pdm/(m+n) > > > > > > Then the supermajority constraint is lifted when m1 = m2, which gives: > > > > > > 1+d/2 = 1+pdm/(m+n), > > > > > > p = (m+n)/2m. For m:n = 3:1, p = 0.667 Raul Miller wrote: > > That looks about right, with a minor arithmetic quibble (301 developers > > constitutes a majority if there are 600). On Fri, Dec 22, 2000 at 01:52:22PM -0600, Norman Petry wrote: > If you get to quibble, then so do I :-) You forgot to cancel the 1's (also, > that's integer division I'm using in the above formulas). Mind walking me through this slowly? I feel like I'm missing something d: 600 m1: 301 pd: 450 m: 3 n: 1 m2: 338.5 You had said: However, if 450 voters participate, then only 300/450 = 67% must support the change for it to be accepted. My quibble was that 301/450 must support the change for it to be accepted if there are 600 developers and a 3:1 "supermajority" is required. I don't understand your quibble. [Also, while I'm in quibble mode -- I'd say that the supermajority constraint is superceeded when m1 Delivered-To: npetry@accesscomm.ca Received: (qmail 4053 invoked from network); 23 Dec 2000 02:10:08 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 02:10:08 -0000 Message-ID: <004d01c06c85$6a479460$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "'Raul Miller'" , , , , , "Buddha Buck" , "Norman Petry" Subject: Re: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 20:09:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 0000002e-0010 Buddha Buck wrote: > >Therefore, if this rule is adopted, I see no reason why we cannot continue > >to refer to it as a 'supermajority' within the constitution. Regardless of > >what concept of supermajority we adopt, it will be necessary to provide a > >clear definition anyway, since combining supermajorities with pairwise > >voting is certainly unusual and the meaning cannot be assumed by anyone > >either within or outside debian. > > I think that in the interest of clarity, we shouldn't use words that people > THINK they know what means but give them other meanings. Most people don't > see 50%+1 as a supermajority, but as a majority. This is a valid point. Use of the term 'supermajority' is appealing, since it is one word, but I agree it might cause some confusion. Would this confusion have any effect on how people *vote*, however? If not, then it may make no difference if the terminology doesn't mean exactly what some voters would expect (initially). However, I have no problem with using different terminology if that's preferable to others. I think the first thing to decide is whether we want to use a 'strong majority' requirement, and we can later decide what to call it ('enhanced majority'? 'certain majority', 'overwhelming support'?,...). Let's just call it a strong majority for now, then. > We are stretching the conventional definition of "supermajority" already > (but with good reason). I can easily see someone voting A>B, thinking "I > like resolution A, hate amendment B, don't have an opinion about the status > quo" without realizing that their ballot could actually help B win (Imagine > 99 other ballots, B beats A 60:39, B beats SQ 74:25. The AB vote would > make that B>A 60:40, B>SQ 75:25, B is adopted). The problem of unstated assumptions about how truncated ballots should be counted is on our agenda. I think the only solution to this problem is to eliminate the ambiguity by providing a clear interpretation, and then teach people how to vote. A voter's guide, as a supplement to the constitutional rules would probably be a very helpful thing in this regard. -- Norm Petry From nkklrp@hotmail.com Sat Dec 23 02:34:20 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27972 invoked from network); 23 Dec 2000 02:34:20 -0000 Received: from law-f69.hotmail.com (HELO hotmail.com) (209.185.131.132) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 02:34:20 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 18:34:17 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 23 Dec 2000 02:34:17 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, moth@debian.org, bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Yes on Strong Majority Date: Sat, 23 Dec 2000 02:34:17 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Dec 2000 02:34:17.0908 (UTC) FILETIME=[D90AA740:01C06C88] X-Evolution: 0000002f-0010 The strong majority approach seems best, as a compromise between an ordinary supermajority rule, and not having a supermajority rule. Of course it's a change in the supermajority rule, rather than just a way of applying the supermajority rule to rank ballotings. Why not have 2 separate recommendations: One, the more modest & minimal recommendation, for how to apply a supermajority rule to rank methods; and another for replacing "supermajority" with "strong majority" (or whatever else we call it) wherever "supermajority" appears. So I'm just suggesting dividing the supermajority issue into 2 separate recommendations. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sat Dec 23 02:43:05 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4432 invoked from network); 23 Dec 2000 02:43:05 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 02:43:05 -0000 Received: (qmail 6280 invoked by uid 1000); 23 Dec 2000 02:42:53 -0000 Date: Fri, 22 Dec 2000 21:42:53 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Yes on Strong Majority Message-ID: <977539328.d538d85a@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nkklrp@hotmail.com on Sat, Dec 23, 2000 at 02:34:17AM -0000 X-Evolution: 00000030-0010 On Sat, Dec 23, 2000 at 02:34:17AM -0000, MIKE OSSIPOFF wrote: > So I'm just suggesting dividing the supermajority issue into 2 > separate recommendations. Works for me. Note also that you've suggested the creation of a "voter's guide". I also find this suggestion appealing. Thanks, -- Raul From nkklrp@hotmail.com Sat Dec 23 02:52:21 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 13952 invoked from network); 23 Dec 2000 02:52:21 -0000 Received: from law-f64.hotmail.com (HELO hotmail.com) (209.185.131.127) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 02:52:21 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 18:52:19 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 23 Dec 2000 02:52:19 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, moth@debian.org, bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Report Schulze's Output Ranking to Debian? Date: Sat, 23 Dec 2000 02:52:19 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Dec 2000 02:52:19.0386 (UTC) FILETIME=[5DA719A0:01C06C8B] X-Evolution: 00000031-0010 For any one agenda issue, it's occurred to me that if an output ranking is reported to Debian, instead of just one recommendation, then the issue of controversialness wouldn't be as much of a deterrent for highly recommending something like Norm's rule d. By the way, Rob pointed out that leaving procedural decisions to a chairperson can greatly streamline small committees, and that seems to have worked perfectly well for the agenda-ordering poll. So, for instance, I'm just suggesting the possible desirability of, for any particular agenda issue, a recommendation in the form of an output ranking rather than a single winner. Norm would of course take people's comments into consideration, but, with the chair-decides-procedures way of operating, Norm would make the final decision about that and similar procedural matters. Back to my suggestion, then--Because of the special importance of the top recommendation in the output ranking for a particular issue, I suggest that Schulze would still be the best count rule. The way that Schulze makes an output ranking is: Do the 1st count, and the winner is the 1st finisher. Delete the 1st finisher from the rankings and repeat the count, and the winner is named the 2nd finisher. Delete the 2nd finisher from the rankings, and repeat the count, and the winner is named the 3rd finisher... etc. With the output rankings, I'd feel more free to vote based on proposals' actual merits, less influenced by which ones are more likely to be too controversial. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Dec 23 03:24:21 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11436 invoked from network); 23 Dec 2000 03:24:21 -0000 Received: from law-f48.hotmail.com (HELO hotmail.com) (209.185.130.36) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 03:24:21 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 19:24:19 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 23 Dec 2000 03:24:18 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au Cc: bmbuck@14850.com, npetry@accesscomm.ca, moth@debian.org, stevegr@debian.org, robla@eskimo.com Subject: Townes & Buck not equivalent? Date: Sat, 23 Dec 2000 03:24:18 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Dec 2000 03:24:19.0192 (UTC) FILETIME=[D5F23F80:01C06C8F] X-Evolution: 00000032-0010 Yes, when I said that Townes' procedure gives the same result as Buck's procedure, I was assuming that we delete the Nth finisher from the ballots and repeat the count in order to find the (N+1)th finisher. As Anthony pointed out, if Townes' procedure is applied to an output ranking that isn't made in that way, then his procedure can give a different result from Buck's procedure. A general rule for making the output ranking would of course have to be part of the specification of Towne's procedure. The way that I described in the 1st paragraph of this message, for making an output ranking, is a completely general way to do it, for any voting system. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Dec 23 03:45:44 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1654 invoked from network); 23 Dec 2000 03:45:44 -0000 Received: from law-f18.hotmail.com (HELO hotmail.com) (209.185.131.81) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 03:45:44 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 19:45:42 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 23 Dec 2000 03:45:41 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Slight mis-statement by me re: Townes' procedure. Date: Sat, 23 Dec 2000 03:45:41 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Dec 2000 03:45:42.0203 (UTC) FILETIME=[D2AE30B0:01C06C92] X-Evolution: 00000033-0010 When I said that Towne's procedure has to specify a way of making an output ranking, that isn't necessarily so, if we regard the output ranking as the output of the count rule itself. Obviously it could be looked at either way: The count rule outputs a winner, and we apply some output-ranking-making procedure; or the count rule is regarded as outputing an output ranking. So, since Towne's procedure has been defined with the output ranking as part of its input, then it isn't true that Townes' procedure has to specify how to make an output ranking. So then, it's true that Towne's procedure and Buck's procedure can give different results, depending on how an output ranking is made. Still, if Towne's procedure is going to be among the candidate proposals, I suggest defining it so that it includes the making of the output ranking, so that it can be used with purely single-winner method definitions. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sat Dec 23 04:05:08 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 19873 invoked from network); 23 Dec 2000 04:05:08 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 04:05:08 -0000 Received: (qmail 7374 invoked by uid 1000); 23 Dec 2000 04:04:57 -0000 Date: Fri, 22 Dec 2000 23:04:57 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Report Schulze's Output Ranking to Debian? Message-ID: <977544285.20791955@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nkklrp@hotmail.com on Sat, Dec 23, 2000 at 02:52:19AM -0000 X-Evolution: 00000034-0010 On Sat, Dec 23, 2000 at 02:52:19AM -0000, MIKE OSSIPOFF wrote: > For any one agenda issue, > it's occurred to me that if an output ranking is reported to Debian, > instead of just one recommendation, then the issue of controversialness > wouldn't be as much of a deterrent for highly recommending something > like Norm's rule d. Note that until Debian adopts some alternative procedure(s), it's not going to be equipped to properly handle a controversial vote with a lot of options. Thanks, -- Raul From nkklrp@hotmail.com Sat Dec 23 04:40:08 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 18255 invoked from network); 23 Dec 2000 04:40:08 -0000 Received: from law-f56.hotmail.com (HELO hotmail.com) (209.185.131.119) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 04:40:08 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Dec 2000 20:40:05 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 23 Dec 2000 04:40:05 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, bmbuck@14850.com, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Report Schulze's Output Ranking to Debian? Date: Sat, 23 Dec 2000 04:40:05 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Dec 2000 04:40:05.0399 (UTC) FILETIME=[6BB26270:01C06C9A] X-Evolution: 00000035-0010 >> Dec 23, 2000 at 02:52:19AM -0000, MIKE OSSIPOFF wrote: >> For any one agenda issue, >> it's occurred to me that if an output ranking is reported to Debian, >> instead of just one recommendation, then the issue of >> controversialness >> wouldn't be as much of a deterrent for highly recommending something >> like Norm's rule d. >Note that until Debian adopts some alternative procedure(s), it's >not going to be equipped to properly handle a controversial vote >with a lot of options. True, and so, for a particular agenda issue, the reporting of an output ranking, instead of a single recommendation, would create a choice problem that Debian isn't now set up to deal with. That hadn't occurred to me, but it suggests that it's best to stick with a single recommendation for each agenda issue. So I withdraw my suggestion for reporting an output ranking to Debian. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From npetry@accesscomm.ca Sat Dec 23 05:26:45 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25206 invoked from network); 23 Dec 2000 05:26:45 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 05:26:45 -0000 Message-ID: <008101c06ca0$e4025860$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Raul Miller" , "'Buddha Buck'" , , , , , "Norman Petry" Subject: Re: Status/Summary of proposals so far... Date: Fri, 22 Dec 2000 23:26:23 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000036-0010 Raul Miller wrote: >> > That looks about right, with a minor arithmetic quibble (301 developers >> > constitutes a majority if there are 600). > >On Fri, Dec 22, 2000 at 01:52:22PM -0600, Norman Petry wrote: >> If you get to quibble, then so do I :-) You forgot to cancel the 1's (also, >> that's integer division I'm using in the above formulas). > >Mind walking me through this slowly? I feel like I'm missing something > >d: 600 >m1: 301 >pd: 450 >m: 3 >n: 1 >m2: 338.5 > >You had said: > >However, if 450 voters participate, then only 300/450 = 67% must support >the change for it to be accepted. > >My quibble was that 301/450 must support the change for it to be accepted >if there are 600 developers and a 3:1 "supermajority" is required. Sorry, my mistake. I thought you were referring to my formulas for m1 and m2 (which do contain the term but it cancels for the purposes of calculating the breakpoint between the two rules). I hadn't noticed my error in the description that you were referring to. > >[Also, while I'm in quibble mode -- I'd say that the supermajority >constraint is superceeded when m1supermajority constraint is lifted when m1=m2.] Sure, OK. > >Finally, and this isn't exactly a quibble -- more of a question -- debian >doesn't use integer arithmetic in vote tallying, and I hope we're not >suggesting that this is wrong. > Vote sums are always whole numbers in a pairwise method. It's helpful therefore to determine the required number of votes that an option must equal or exceed to be elected. The required number of votes must satisfy the constraint that it is the smallest whole number that, when divided by a vote total exceeds the passing threshold (expressed as a real number). Given: supermajority ratio, m:n passing threshold, h total of votes in a particular pairwise contest, t required votes, r Then h = m/(m+n), r = int(ht)+1 = int(mt/(m+n))+1, and r > ht always. This is why I suggested using integer arithmetic. I know that Mike has suggested that if a candidate *meets* the supermajority ratio that it should win. That is, if we have a 3:1 supermajority, and A>SQ 300:100, that A should win (or be eligible, at least). However, I would prefer to use the same rules for supermajorities as simple majorities (the special case where m:n = 1:1) which will require that the m:n ratio be exceeded to guarantee (pairwise) majority rule. -- Norm Petry From robla@eskimo.com Sat Dec 23 10:24:32 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31873 invoked from network); 23 Dec 2000 10:24:32 -0000 Received: from mx1.eskimo.com (204.122.16.48) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 10:24:32 -0000 Received: from eskimo.com (robla@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id CAA23315; Sat, 23 Dec 2000 02:24:04 -0800 Received: from localhost (robla@localhost) by eskimo.com (8.9.1a/8.9.1) with SMTP id CAA14820; Sat, 23 Dec 2000 02:24:04 -0800 (PST) X-Authentication-Warning: eskimo.com: robla owned process doing -bs Date: Sat, 23 Dec 2000 02:24:03 -0800 (PST) From: Rob Lanphier To: Norman Petry cc: "'Raul Miller'" , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Two Proposals for the Supermajority Requirement In-Reply-To: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Evolution: 00000037-0010 Hi all, As you might have guessed from my spotty participation, I've been pretty wrapped up in other things, and haven't had as much time to really deeply think about these issues (and will soon be out of reliable email contact through the holidays). I'm very happy with how things are going in general, and the final ranking of issues to tackle seems like a fine one. The depth and insight in this discussion is truly impressive, and Norman is doing an outstanding job of organizing. I only wish I had more time to contribute. I didn't notice any questions addressed specifically to me in this that I haven't answered, but if I missed something, let me know. Norman, per your request for input on your two proposals, I did want to comment on the first one...I'm still not convinced that supermajorities should be abolished. For every one example (slavery) where the U.S. Constitution needed changing and didn't allegedly because of supermajority requirements, there were many examples where it where it was probably a good thing (many items in the bill of rights have had spotty support through the years....and would have been hard to get back once taken away). Note also that slavery did indeed get abolished through constitutional amendment. Yeah, it took a war and the temporary disenfranchisement of the south, but it got done. Furthermore, the passage of a constitutional amendment abolishing slavery prior to the US Civil War would have likely triggered the Civil War anyway. In general, I think Debian has the very real danger of growing at a pace that dilutes the core values of the project. It seems like there need to be some way of protecting the time-tested institutional mechanisms of the project (which should be the only things that are in the constitution) from tampering from new members (who have the same vote as older members who've cumulatively contributed more). One could come up with something more sophisticated, but supermajorities are one good way. Anyway...I realize that this isn't the topic at the top of the list (heck, it's at the bottom), but it was about the only issue I've got a strong opinion on, so I figured I'd write it up. I'll do a point-by-point response when the time comes to discuss this. Rob On Thu, 21 Dec 2000, Norman Petry wrote: > Date: Thu, 21 Dec 2000 14:30:38 -0600 > From: Norman Petry > To: 'Raul Miller' , nkklrp@hotmail.com, > stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, > aj@azure.humbug.org.au, npetry@accesscomm.ca > Subject: Two Proposals for the Supermajority Requirement > > I have two proposals to make for resolving the current problems with the way > supermajorities are handled in the Debian constitution. They are listed in > order of preference, but I expect that Proposal #1 might be considered too > 'radical' for Debian, so I am also suggesting a second-choice alternative. > > Please let me know your opinions of these proposals. > > ***** > > PROPOSAL #1 - ABOLISH SUPERMAJORITY REQUIREMENTS > > In my opinion, the best way to deal with the problem of supermajorities is > to eliminate the rules requiring them. I don't want to get into a long > debate on this issue, since I do not think this proposal will be acceptable > to the committee or Debian as a whole, and we don't have that much time to > consider these issues. Still, I needed to make these points... > > It has been suggested that supermajorities are required to make it difficult > to amend the founding documents of an organisation, since these define the > core objectives of the group. In some sense, it ceases to be that > organisation if the underlying principles are modified. However, in > practice it is impossible and undesireable to keep organisations from > evolving -- mere rules cannot do this. If for example, Debian's developers > abandon their commitment to creating a Free Software OS distribution, their > rules won't save them. The solution to this potential problem is education > of new members about the ethics of Free Software, not rigid rules. > > Also, changed circumstances, unforseen by those preparing the founding > documents, require changes in response. Only the current members of an > organisation have the information needed to make these decisions. It is > irrational to suppose that the founders, lacking knowledge of future events > and conditions, would know better than the current members what needs to be > done. Why suppose that current members are less wise, committed, and > well-intentioned than the founders? This argument is a variation on the > 'argument from tradition' fallacy -- the idea that because something has > always been done in a particular way, there must be some good reason why > that course of action should continue to be followed. It is simply used as > a substitute for a rational argument when current practice can no longer be > justfied any other way ("We've always had slaves, therefore we should always > have slaves..."?). Supermajority requirements allow the small minority > faction which benefits from the existing rules to have more power than those > wanting change. This political inequality is neither fair to the members of > the group, nor is it in the interests of the organisation, since it limits > its ability to adapt. > > Another argument that has been made in support of supermajority requirements > is this one, made by Anthony Towns on November 22: > > "I'm not sure this is an ideal way of looking at things from Debian's > perspective. The usual decision making process in Debian is (supposed > to be) one of reaching consensus on an issue, not one of democracy, > per se. I tend to look at consensus as an attempt to disenfrachise > (by ignoring their objections) no one, and voting as an attempt to > disenfranchise up to 50% of the people concerned (and dictatorship > as an attempt to disenfranchise everyone else but one). If consensus > building is successful, then there's no need for a vote, because it's > clear everyone will vote the same way, and all is well. > > But even if we've given up on satisfying everyone, it still seems > appropriate to try satisfying 75% or 66% of people rather than 50% > of people for some issues." -- > http://lists.debian.org/debian-vote-0011/msg00159.html > > The idea is that it is better to require more than merely half the members > to support an action if something is to be done. Sure, I agree it's > desireable to have as much support as possible for a given course of action, > and if you have a group of people who are choosing between doing X and doing > nothing, it may be desireable to do nothing, rather than take an important > or risky step without overwhelming support. However, this is not the choice > that most organisations are faced with. In general, organisations adopt > policies which govern their day to day operations. Therefore, the group is > always doing *something* according to whatever standing rules are in place. > It then becomes a matter of deciding whether the group will do what the > minority wants, or what the majority wants. With a supermajority > requirement of 3:1, it can happen that 74% of the group is forced (under > existing rules) to do what the remaining 26% want, which is more unfair than > if the majority gets to choose where the organisation should be headed > (thereby limiting dissatisfaction to 49%, rather than 74% of members). > > I do think that there is one valid use of a supermajority rule, and that is > when it used to make it difficult for a faction within an organisation to > make surprise changes to important governing documents. If meetings of the > organisation are generally poorly attended, it can be quite easy for a small > and well-organised group to stack a meeting and push through important > changes that would not be supported by a majority of the membership. Many > organisations have rules requiring either prior notice, or else a > supermajority as a way of minimising this form of 'hijacking'. However > Debian's rules, together with the fact that meetings are conducted online, > make it impossible for changes to be made without a full and open discussion > period. Therefore, any developer who cares about an issue will know in > advance of the vote, and can participate in the decision, so there is no > risk of a 'false majority' changing the rules. > > ***** > > PROPOSAL #2 - DETERMINE AN "ELIGIBLE" SET OF CANDIDATES > > Here is a more modest proposal which the committee might want to adopt, if > supermajority requirements are to be retained. Rather than just describing > the concept, I've tried to write the proposal as I think it should appear as > part of an actual voting method within the constitution. Some of the > underlying definitions are not specified in this description ('beats', for > example would either be defined here or added to a glossary), but their > meaning is probably obvious to those of us on the committee. I'll describe > some of the advantages of this system following the description. > > *** > > Definitions: > > A "restricted option" is an option which would require a supermajority to be > adopted. > > A "regular option" is an option which would require a simple majority to be > adopted > > Restricted options and regular options may be combined on a single ballot. > However, all the restricted options appearing on the ballot must have the > same supermajority requirement. > > To determine a winner, the following sequence of steps will be carried out, > in order and without exception unless explicitly stated otherwise: > > 1. An initial set of "eligible" options is determined according to the > following rules: > > a) The default option is always eligible*. > b) All regular options are eligible. > c) A restricted option which beats the default option by a supermajority is > eligible. > d) A restricted option which beats another eligible, restricted option by a > supermajority is eligible. > > 2. All options not satisfying at least one of the conditions for eligibility > specified in (1) are "ineligible", and are eliminated from consideration in > the remaining steps. Any references to these options on either the ballots > or in the pairwise matrix are ignored. > > ... > > [continue with definition of a pairwise method used to choose a winner from > among those 'eligible'] > > (* note that we would need to change this part if the Secretary/DPL are > given the authority to eliminate the default option under some > circumstances) > > *** > > The advantages of this system are as follows: > > 1) It is written in the form of constraints which reduce the set of options > that may be chosen at a later stage in the process. By doing it this way, > it is possible to keep the supermajority requirements independent of the > count rule used. For example, it is easy to use this same definition with > any pairwise method we might later adopt. Alternate approaches may entangle > the supermajority rules with the pairwise count rules, making them difficult > to amend and forcing us to reconsider the question of how supermajorities > would be implemented with each count rule under discussion. > > 2) The method allows options which require a supermajority to be combined > with options that don't on the same ballot. This might be useful if it > would be possible for the organisation to achieve a particular goal either > by modifying the constitution (supermajority), or simply adopting a general > resolution. Provided the restricted option meets its supermajority > requirement, a simple majority will decide between the constitutional > amendment and the general resolution. Normally, this shouldn't happen; > different categories of policy, having different supermajority requirements, > will be categorised in that way precisely because they deal with different > issues (the Constitution explicitly states that its goal is to define > decisionmaking processes, for example). Therefore it is unlikely that > regular and restricted options on the same ballot would both be germane to > the same issue. However, it is at least possible that developers may wish > to do this, and by allowing both on one ballot, it is possible to avoid > serialising the decisionmaking, which is always undesireable, imho. > > 3) The method includes a recursive definition (1.(d)) that allows an option > which beats another option by a supermajority, but does not beat the current > default (status quo) option by a supermajority, to be eligible. This is > useful, because without this rule it is possible that an option which loses > under the current status quo would be a winner under the *new* status quo, > and this would prompt the supporters of that option to push for reballoting. > This would be undesireable -- it is always better to settle matters once and > for all, rather than have a new discussion period and re-vote just to > overcome the flaws in the voting system. Consider this example: > > Options: {A,B,SQ} (A,B = restricted options; SQ = status quo option) > Supermajority Requirement: 2:1 > > Pairwise totals: > > A>B 50:20 > A>SQ 35:20 > B>SQ 45:20 > > Without 1.(d), the winner is B, since A doesn't directly satisfy the > supermajority requirement, but B does. However, if B is elected, then > reballoting would result in the election of A, since it beats the new status > quo option by 2.5:1. It is better to just save time and treat all these > candidates as eligible, and then choose the Condorcet winner (A) on a single > ballot. Note that this proposal is not mine -- it was suggested by Markus > Schulze to debian-vote on November 21. See > http://lists.debian.org/debian-vote-0011/msg00156.html for more details. > Markus uses the term 'available' rather than 'eligible' to describe this set > of candidates. However, the set I am proposing is enlarged to include any > regular (simple majority) options that may be germane to the issue under > consideration. > > Please check out this method and let me know if you find scenarios where you > believe it would give the 'wrong' result, assuming that a pairwise method is > used to choose a winner from among the eligible candidates. Perhaps Buddha > and Anthony could check it against the supermajority criteria they have > proposed. > > I await your comments. > > -- > Norm Petry > Rob Lanphier robla@eskimo.com http://www.eskimo.com/~robla From npetry@accesscomm.ca Sat Dec 23 15:53:40 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5145 invoked from network); 23 Dec 2000 15:53:40 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 15:53:40 -0000 Message-ID: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Call for Votes on Supermajority Issue Date: Sat, 23 Dec 2000 09:53:15 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000038-0010 Greetings, So far, I have counted a total of seven proposals for defining the supermajority rules to be used in the Debian constitution. I have three recommendations as to how we should proceed now: 1) We should allow one more day or two to present arguments in support of, or in opposition to, the supermajority proposals under consideration. Ranked ballots for these 7 methods can then be submitted on or before the 26th, and the Schulze results will be announced on the 27th. 2) As a separate question, we should vote on whether we would want to recommend the 'strong majority' alternative that has been proposed (don't worry about the name for now). The options on this ballot would be: A) Submit 'supermajority' as our only proposal. B) Submit 'strong majority' as our only proposal. C) Submit 'supermajority' as our primary proposal, and 'strong majority' as part of an alternate proposal. D) Submit 'strong majority' as our primary proposal, and 'supermajority' as part of an alternate proposal. The idea I have in mind is that the alternate proposal would be the same as the primary proposal, except that it would include some of the more controversial (but arguably better) ideas that might be less winnable. These would be things that a majority of the committee members believe would be a good idea, but that we suspect developers might express doubts about. Under Debian's existing rules, the 'final form' of the ballot would be decided by developers from these two proposals using the Concorde pairwise rule (simple majority), and then that final resolution would be subject to ratification. We do not want to offer too many alternatives, or it will create too much confusion. Therefore, submitting exactly two complete proposals -- a 'conservative' one, that should be easy to adopt, plus a 'radical' one that has some worthwhile improvements, will give the developers all the information they need to create hybrid proposals containing some elements of each, if they so desire. 3) Aside from tomorrow's discussion, I recommend that we adjourn briefly over Christmas, and resume work on Agenda Item #2 the 28th. Anyone wishing to continue work should begin developing proposals for the upcoming items on our agenda. I will be away on holidays until January 7th, so my ability to participate between now and then will be limited. However, I hope to have intermittent e-mail access between now and then, and will try to keep in touch. I won't be able to contribute anything further for the next few days, however, so this is my final post until I send the results of balloting on the supermajority issue on the 27th. I realise that some participants would prefer to discuss pairwise rules, to see how they interact with the supermajority rules before deciding on which system to use for supermajorities. However, our time is limited, so I think we need to make a decision on this. Those who think the supermajority rule that is chosen interacts badly with certain pairwise proposals can make the arguments then, and we can revisit the issue later (ie: I will accept a proposal to reconsider the question of supermajority once our pairwise deliberations are complete). Merry Christmas! -- Norm Petry ***** Here is a restatement of all the supermajority proposals (Buddha's descriptions, suplemented with those supplied by Raul and Anthony): Definitions: An option is ADOPTED if it is the final outcome of the vote count process. An option is an AMENDMENT if it requires a supermajority to be adopted. An option is a RESOLUTION if it has no special majority or supermajority requirements. (Note: the status quo, if an option on the ballot, is considered a resolution) An option is the BEST option if it wins the "normal" vote count (i.e., Smith-Condorcet, STV-Condorcet, Tideman, SSD, whatever we adopt that doesn't handle supermajorities). An amendment is INELIGIBLE if it does not defeat the status quo by a supermajority. An amendment is PLAUSIBLE if it defeats the status quo by a supermajority, or if it defeats an PLAUSIBLE amendment by a supermajority. Ossipoff: Find the best option. If the best option is an ineligible amendment, adopt the Status Quo; otherwise, adopt the best option. Buck: Find the best option. If the best option is an ineligible amendment, discard it and find the next best option. Adopt the first best option that isn't an ineligible amendment. Miller-1: Discard all ineligible amendments. Adopt the best option remaining. (Note: may not have been formally proposed, claimed to be equivilant to Buck). Miller-2: Use supermajority criteria in the pairwise ranking by scaling down the vote counts in favor of supermajority options. [That is, if an option must have 3/4 of all cast votes, to win, when considering pairwise rankings, multiply number of votes in favor of this option by 1/3.] Petry-1: Discard all amendments that are not plausible. Adopt the best option remaining. Petry-2: Drop supermajority requirements all-together. Towns: form complete ranking, choose highest ranked eligible option. ("Another way of handling this would be to choose a method that ranks the entire list of options, rather than just chooses a winner. Once the options are ranked, choose the highest ranked eligible option.") ***** BALLOTS: Here is a set of 3 blank ballots you can use for voting on the supermajority question, and the 'stronger majority' question. Please provide rankings for both the 'primary' and 'alternate' proposals, as well as your vote on the question of strong majorities. Please do not reorder the items when submitting your ballot, as it makes counting harder. Rank 1-n (best to worst). If you have no opinion between 2 or more options, you CAN assign them equal rankings. Please do not truncate ballots -- if you want to truncate, just rank the unacceptable options equally last, so your intent is clear. If the Primary and Alternate proposals for supermajority end up with the same winner, then of course there will be no 'alternate' proposal for this issue. PRIMARY SUPERMAJORITY PROPOSAL [ ] OSSIPOFF [ ] BUCK [ ] MILLER-1 [ ] MILLER-2 [ ] PETRY-1 [ ] PETRY-2 [ ] TOWNS ALTERNATE SUPERMAJORITY PROPOSAL [ ] OSSIPOFF [ ] BUCK [ ] MILLER-1 [ ] MILLER-2 [ ] PETRY-1 [ ] PETRY-2 [ ] TOWNS SUPERMAJORITY vs. STRONG MAJORITY The supermajority and strong majority proposals should appear in the primary/alternate proposals as follows: [ ] SUPERMAJORITY/SUPERMAJORITY [ ] STRONG MAJORITY/STRONG MAJORITY [ ] SUPERMAJORITY/STRONG MAJORITY [ ] STRONG MAJORITY/SUPERMAJORITY ***** Here are my final arguments for and against each supermajority proposal: Ossipoff: Find the best option. If the best option is an ineligible amendment, adopt the Status Quo; otherwise, adopt the best option. Simple to define and understand. Independent of pairwise method chosen. Does not allow eligible resolutions to be adopted if the best option is an ineligible amendment, however. Buck: Find the best option. If the best option is an ineligible amendment, discard it and find the next best option. Adopt the first best option that isn't an ineligible amendment. Intuitive and easily defined. Independent of pairwise count rule. Can violate goals of monotonicity and independence from irrelevant alternatives, however. Miller-1: Discard all ineligible amendments. Adopt the best option remaining. Intuitive and easily defined. Independent of pairwise count rule. Results are independent of the effects of unwinnable proposals. Should be monotonic, unlike Buck. Allows winnable resolutions to be adopted if the best option is an ineligible amendment. Flexibile, because it allows a different supermajority ratio to be used for each option on the ballot. The best 'simple' proposal. Miller-2: "Use supermajority criteria in the pairwise ranking by scaling down the vote counts in favor of supermajority options. [That is, if an option must have 3/4 of all cast votes, to win, when considering pairwise rankings, multiply number of votes in favor of this option by 1/3.]". Similar to procedure described in the Concorde method. Unintuitive. Difficult to define and understand. Modifications to totals in the pairwise matrix will cause weird and unpredictable affects on outcomes. Not independent of pairwise count rule -- entangles supermajority requirements and pairwise counting in an undesireable way. No advantages have been cited for this method. The worst proposal. Petry-1: Discard all amendments that are not plausible. Adopt the best option remaining. Similar to Miller-1, but allows proposals that would not be eligible under Miller-1 to be eligible if they would be able to beat the new status quo. Fairer than Miller under these conditions, and minimises reballoting. Should be monotonic. I do not consider this a radical proposal -- it seems like a straightforward extension of the concept of pairwise-relative supermajority used in other methods. More complex than Miller-1, but complexity/quality tradoff is good, since the additional recursive rule can be defined in one sentence. In theory, less flexible than Miller-1, since only simple majority and a single supermajority ratio can be used on one ballot. This should not be a drawback in practice, however (scenarios where this could conceivably happen are implausible). The best method on technical grounds. Petry-2: Drop supermajority requirements all-together. The simplest solution, yielding the fairest results. Probably unwinnable, however -- doesn't contain safeguards against low participation rates. The 'strong majority' concept is probably a better way to overcome the potential problems with supermajorities, and that proposal should be winnable. Towns: form complete ranking, choose highest ranked eligible option. ("Another way of handling this would be to choose a method that ranks the entire list of options, rather than just chooses a winner. Once the options are ranked, choose the highest ranked eligible option.") Fairly intuitive and easily defined. NOT Independent of pairwise count rule -- requires a method yielding a social ranking, rather than a winner, to be used, which is contrary to the basic goal of pairwise voting (finding a winner, rather than a ranking). Greatly limits the choice of pairwise methods that could be used (in practice, only Tideman would be reasonable). Probably not independent of the effects of unwinnable proposals (see Buck), but it *will* be monotonic if the rank method is monotonic (satisfied by Tideman). No advantages have been cited for this method. ***** Here are MY ballots, based on the above arguments: PRIMARY SUPERMAJORITY PROPOSAL [4] OSSIPOFF [3] BUCK [2] MILLER-1 [7] MILLER-2 [1] PETRY-1 [5] PETRY-2 [6] TOWNS ALTERNATE SUPERMAJORITY PROPOSAL [5] OSSIPOFF [4] BUCK [3] MILLER-1 [7] MILLER-2 [1] PETRY-1 [2] PETRY-2 [6] TOWNS SUPERMAJORITY vs. STRONG MAJORITY The supermajority and strong majority proposals should appear in the primary/alternate proposals as follows: [3] SUPERMAJORITY/SUPERMAJORITY [1] STRONG MAJORITY/STRONG MAJORITY [2] SUPERMAJORITY/STRONG MAJORITY [4] STRONG MAJORITY/SUPERMAJORITY From moth@debian.org Sat Dec 23 16:23:06 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 750 invoked from network); 23 Dec 2000 16:23:06 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 16:23:06 -0000 Received: (qmail 16248 invoked by uid 1000); 23 Dec 2000 16:22:55 -0000 Date: Sat, 23 Dec 2000 11:22:55 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns , Raul Miller Subject: Re: Call for Votes on Supermajority Issue Message-ID: <20001223112255.A15756@usatoday.com> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 00000039-0010 On Sat, Dec 23, 2000 at 09:53:15AM -0600, Norman Petry wrote: > Under Debian's existing rules, the 'final form' of the ballot would be > decided by developers from these two proposals using the Concorde pairwise > rule (simple majority), and then that final resolution would be subject to > ratification. We do not want to offer too many alternatives, or it will > create too much confusion. Therefore, submitting exactly two complete > proposals -- a 'conservative' one, that should be easy to adopt, plus a > 'radical' one that has some worthwhile improvements, will give the > developers all the information they need to create hybrid proposals > containing some elements of each, if they so desire. This approach would delay the adoption of all of the proposals. Minimum added time: two weeks for a single amendment vote. However, when you include the likely discussion time spent sorting out the issues and possible multiple amendments and maybe multiple amendment votes, we could be talking months, or longer (beyond the 2 months it will require if we create a set of recommendations in one month). Or original ratification of the constitution took almost a year. I strongly prefer a two-stage release process, where we first amend the constitution to fix the problems interfering with Debian's being able to confront controversial issues, and then a later set of revisions where various philosophical points are addressed. If we're not prepared to resolve those philosophical points in a timely fashion, I don't think we should expect Debian to be better equipped. And, in the meantime, Debian has some very real flaws in the voting system, which need to be addressed. If we're going to propose a spectrum of choices, I'd prefer that they be split into "minimal" and "maximal" changes, with the advice that the "minimal" set be adopted in one vote, and that voting system used to decide about the spectrum offered in the "maximal" set. [I also have some more comments about supermajority, but those will go in a second letter.] Thanks, -- Raul From moth@debian.org Sat Dec 23 16:40:51 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 19110 invoked from network); 23 Dec 2000 16:40:51 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 16:40:51 -0000 Received: (qmail 16481 invoked by uid 1000); 23 Dec 2000 16:40:41 -0000 Date: Sat, 23 Dec 2000 11:40:41 -0500 From: Raul Miller To: Rob Lanphier Cc: Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <20001223114041.B15756@usatoday.com> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from robla@eskimo.com on Sat, Dec 23, 2000 at 02:24:03AM -0800 eval: msgid debian X-Evolution: 0000003a-0010 On Sat, Dec 23, 2000 at 02:24:03AM -0800, Rob Lanphier wrote: > In general, I think Debian has the very real danger of growing at a pace > that dilutes the core values of the project. It seems like there need to > be some way of protecting the time-tested institutional mechanisms of the > project (which should be the only things that are in the constitution) > from tampering from new members (who have the same vote as older members > who've cumulatively contributed more). One could come up with something > more sophisticated, but supermajorities are one good way. That rings a bell. I'm remembering discusions along similar lines, and I think this is exactly the reason that supermajority requirements were adopted. So now I'm rethinking what we're doing to supermajority, and why. I have some unanswered questions, I've presented to this committee, on "vote scaling". I'd be very interested in seeing answers to them in this context. I'm aware that vote scaling "thwarts the will of the majority", but that's only an issue if there is no underlying "correct answer". That is: is the only thing that makes a decision right that most people agree with it? I think we can agree that certain kinds of voting systems are to be preferred over others -- that, for example, if the majority of Debian wanted to adopt a "first announced, first adopted" strategy, in place of voting, that this would introduce problems -- even if the majority approved of this change at some point in time. Likewise, I believe it would completely destroy Debian, as it currently exists, if some majority of developers decided that while free software was an interesting exercise, supporting commercial software was essential to our continued existence and should be given priority. What I'd like to see is some reasoning about why simple majority is a better decision making process for foundational issues than "before you change foundational issues, make sure that almost everybody doesn't think there's a better way". In other words, I think that certain kinds of decisions extend across time, and that the people present at one point in time shouldn't be making them for people at another point in time, unless agreement is "nearly unanimous". I'm not really looking for math here -- I believe there's too many different kinds of possibilities to consider for math to be useful. I'm looking for rationale. Comments? Philosophy? Reasons? Thanks, -- Raul From bmbuck@14850.com Sat Dec 23 17:01:49 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8402 invoked from network); 23 Dec 2000 17:01:49 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 17:01:49 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 4B89915956; Sat, 23 Dec 2000 12:01:46 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: "Norman Petry" Cc: "Steve Greenland" , "Rob Lanphier" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" , bmbuck@zaphod.datahold.home Subject: Re: Call for Votes on Supermajority Issue In-Reply-To: Message from "Norman Petry" of "Sat, 23 Dec 2000 09:53:15 CST." <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Dec 2000 12:01:45 -0500 From: Buddha Buck Message-Id: <20001223170146.4B89915956@zaphod> X-Evolution: 0000003b-0010 I will give due consideration to my vote and deliver it soon. A couple of comments, though... > Miller-1: Discard all ineligible amendments. Adopt the best option > remaining. > > Intuitive and easily defined. Independent of pairwise count rule. Results > are independent of the effects of unwinnable proposals. Should be > monotonic, unlike Buck. Allows winnable resolutions to be adopted if the > best option is an ineligible amendment. Flexibile, because it allows a > different supermajority ratio to be used for each option on the ballot. The > best 'simple' proposal. > > Petry-1: Discard all amendments that are not plausible. Adopt the best > option remaining. > > Similar to Miller-1, but allows proposals that would not be eligible under > Miller-1 to be eligible if they would be able to beat the new status quo. > Fairer than Miller under these conditions, and minimises reballoting. > Should be monotonic. I do not consider this a radical proposal -- it seems > like a straightforward extension of the concept of pairwise-relative > supermajority used in other methods. More complex than Miller-1, but > complexity/quality tradoff is good, since the additional recursive rule can > be defined in one sentence. In theory, less flexible than Miller-1, since > only simple majority and a single supermajority ratio can be used on one > ballot. This should not be a drawback in practice, however (scenarios where > this could conceivably happen are implausible). The best method on > technical grounds. I don't see why multiple supermajority ratios can't be used on one ballot. By your reasoning and explanation of the method, it should be possible. Scenario: Among several ballot options, A requires a 3:1 supermajority over SQ, and has it. B requires a 3:2 supermajority over SQ, and doesn't have it, but has a 3:2 supermajority over A. Since B -would- be plausible if A was the Status Quo, by your reasoning, I see no reason why it shouldn't be plausible in Petry-1. But I'm not even certain that the plausibility rule is consistent or needed. Take this example: Scenario: Among several ballot options, resolution A has a pairwise majority over resolution B, yet B wins the vote count (a situation which will happen whenever there isn't a Condorcet winner). By the same logic promoting Petry-1 over Miller-1, this would induce supporters of A to resubmit a A, confident that A can win this time. Obviously, this isn't considered a serious issue -- or perhaps we should suggest a rule limiting proposals to things which haven't been voted on in a while? Why is it more of an issue that needs to be dealt with when A and B are amendments, not resolutions? -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From moth@debian.org Sat Dec 23 19:48:45 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 19680 invoked from network); 23 Dec 2000 19:48:45 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 19:48:45 -0000 Received: (qmail 20046 invoked by uid 1000); 23 Dec 2000 19:48:34 -0000 Date: Sat, 23 Dec 2000 14:48:33 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <20001223144833.A19352@usatoday.com> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 0000003c-0010 On Sat, Dec 23, 2000 at 09:53:15AM -0600, Norman Petry wrote: > Ossipoff: Find the best option. If the best option is an ineligible > amendment, adopt the Status Quo; otherwise, adopt the best option. Why should a voting system be designed, where the best option is ineligible? I have a philosophical problem with this. I think there's something fundamentally wrong with a system which classifies an option as "best" or "highest ranked" in preference to the winning option. > Buck: Find the best option. If the best option is an ineligible > amendment, discard it and find the next best option. Adopt the first > best option that isn't an ineligible amendment. Same objections as for Ossipoff. > Miller-1: Discard all ineligible amendments. Adopt the best option > remaining. (Note: may not have been formally proposed, claimed to be > equivilant to Buck). I formally propose this. Philosophically, I'm less opposed to this phrasing than, than I am to Ossipoff, Buck, and Towns -- it doesn't support an inconsistent idea of 'best". I uncomfortable that we've not established a philosophical basis for choosing between Miller-1 and Miller-2, yet we're treating them as competing proposals. > Miller-2: Use supermajority criteria in the pairwise ranking by > scaling down the vote counts in favor of supermajority options. > [That is, if an option must have 3/4 of all cast votes, to win, when > considering pairwise rankings, multiply number of votes in favor of > this option by 1/3.] This is based on the idea that it's possible to rank various ideas roughly, based on the amount of agreement the ideas attract. Voting, and Consensus are two examples of this principle in action. Supermajority is an attempt to rank certain ideas as "more significant" than others. That is: some ideas are classified as "particularly significant", and "near unanimous" agreement must be achieved before those ideas can be instantiated, or changed. I am most comfortable with this proposal, because "eligibility" is determined in the same fashion as "best". > Petry-1: Discard all amendments that are not plausible. Adopt the best > option remaining. Same objection as for Miller-1 -- we've not established a philosophical basis for making this kind of choice. Also, this seems to exaggerate any defects in the voting system: If the voting system would allow the presence of a non-winning option to influence the winner. > Petry-2: Drop supermajority requirements all-together. I'm uncomfortable with this because it doesn't respect consensus opinion as being more important than majority opinion. > Towns: form complete ranking, choose highest ranked eligible option. > ("Another way of handling this would be to choose a method that ranks > the entire list of options, rather than just chooses a winner. Once > the options are ranked, choose the highest ranked eligible option.") Same objections as for Ossipoff. Thanks, -- Raul From moth@debian.org Sat Dec 23 20:04:06 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3226 invoked from network); 23 Dec 2000 20:04:06 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 20:04:06 -0000 Received: (qmail 20385 invoked by uid 1000); 23 Dec 2000 20:03:55 -0000 Date: Sat, 23 Dec 2000 15:03:55 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977601542.8ade7a6b@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 0000003d-0010 On Sat, Dec 23, 2000 at 09:53:15AM -0600, Norman Petry wrote: > 2) As a separate question, we should vote on whether we would want to > recommend the 'strong majority' alternative that has been proposed (don't > worry about the name for now). The options on this ballot would be: I should note that this idea of "strong majority" is incompatible with "miller-2" -- combining them would introduce severe voting artifacts. I don't think it's meaningful to vote on "strong majority" while "miller-2" is a candidate. [I'll add that, considering the lack of vocal support for miller-2, I wish that there'd be a bit more rationale about why it's philosophically bad. The way I look at it, it's the only proposal which best represents the supermajority rule as an approximation of consensus.] Thanks, -- Raul From moth@debian.org Sat Dec 23 21:29:23 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25979 invoked from network); 23 Dec 2000 21:29:23 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 23 Dec 2000 21:29:23 -0000 Received: (qmail 21223 invoked by uid 1000); 23 Dec 2000 21:29:11 -0000 Date: Sat, 23 Dec 2000 16:29:11 -0500 From: Raul Miller To: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977606703.7ab61894@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <20001223144833.A19352@usatoday.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001223144833.A19352@usatoday.com>; from moth@debian.org on Sat, Dec 23, 2000 at 02:48:33PM -0500 X-Evolution: 0000003e-0010 Anthony Towns has told me (repeatedly :) that the current debian constitution eliminates all options if there's a smith set with more than one member -- resulting in the default option winning. It occurs to me that [if the constitution is aimed at a rough consensus] this would be in line with the design intent -- and in line with existing debian practice (going back to long before the constitution was adopted). In other words: where there's no clear choice, we discuss things further. This feels right (and if I think I owe Anthony an apology). And, unless people in this group object, I'll withdraw my [unsponsored] proposal from debian-vote on this basis. [I'll wait till after Christmas to give people a chance to object.] Merry Christmas, -- Raul From nkklrp@hotmail.com Sun Dec 24 04:47:25 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20516 invoked from network); 24 Dec 2000 04:47:25 -0000 Received: from law-f40.hotmail.com (HELO hotmail.com) (209.185.131.103) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 04:47:25 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Dec 2000 20:47:22 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sun, 24 Dec 2000 04:47:22 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Call for Votes on Supermajority Issue Date: Sun, 24 Dec 2000 04:47:22 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Dec 2000 04:47:22.0450 (UTC) FILETIME=[9A9CD320:01C06D64] X-Evolution: 0000003f-0010 >From: Raul Miller >To: Norman Petry Raul wrote [referring to the 2-proposals approach]: >This approach would delay the adoption of all of the proposals. That concerned me too. The 2-stage release sounds good. First we release recommendations for the actual voting system & a simple form of supermajority procedure (preferably Miller-1). If there are felt to be other essentials, then they too, in their simplest form, would be part of this 1st release. Then, after these proposals are enacted by Debian, we release a 2nd batch of proposals, including more optional proposals, and more complicated or controversial supermajority proposals. Maybe when I hear Norm's arguments for the 2-proposal approach that will convince me. Right now the 2-stage release sounds better, because it avoids the crucial, necessary reforms being delayed while optional or controversial proposals are being debated and combined in amended proposals. Also, Debian could better deal with several competing options of varying controversialness after the new voting system is in place. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sun Dec 24 04:58:37 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31191 invoked from network); 24 Dec 2000 04:58:37 -0000 Received: from law-f12.hotmail.com (HELO hotmail.com) (209.185.131.75) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 04:58:37 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 23 Dec 2000 20:58:34 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sun, 24 Dec 2000 04:58:34 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Call for Votes on Supermajority Issue Date: Sun, 24 Dec 2000 04:58:34 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Dec 2000 04:58:34.0914 (UTC) FILETIME=[2B6EB020:01C06D66] X-Evolution: 00000040-0010 >I should note that this idea of "strong majority" is incompatible with >"miller-2" -- combining them would introduce severe voting artifacts. >I don't think it's meaningful to vote on "strong majority" while >"miller-2" is a candidate. If strong majority & Miller-2 both win, then we can hold an additional balloting between them. A 2-alternative choice in which people are asked to vote which of those 2 incompatible things should be kept instead of the other. If strong majority wins, then we simply delete Miller-2 from the supermajority ballots and recount them. > >[I'll add that, considering the lack of vocal support for miller-2, I wish >that there'd be a bit more rationale about why it's philosophically bad. There are other kinds of arguments against it, such as complicatedness and nonintuitiveness & nonobviousness. Also, applying supermajority rules only to the comparison between an alternative and the Status-Quo is more in keeping with the usual intent of supermajority rules: Nothing should replace Status Quo unless a supermajority vote it over the Status-Quo. So just look at an alternative's pairing with the Status-Quo to find out if it's eligible to replace the status quo in the event that it wins the count. Miller-2 would involve the supermajority rule in the count itself, in pairings between non-status-quo alternatives. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sun Dec 24 17:54:18 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26449 invoked from network); 24 Dec 2000 17:54:18 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 17:54:18 -0000 Received: (qmail 23720 invoked by uid 1000); 24 Dec 2000 17:54:07 -0000 Date: Sun, 24 Dec 2000 12:54:07 -0500 From: Raul Miller To: Buddha Buck Cc: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Anthony Towns , bmbuck@zaphod.datahold.home Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977680079.ea0ed124@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <20001223144833.A19352@usatoday.com> <977606703.7ab61894@debian.org> <20001224020408.51AA415956@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001224020408.51AA415956@zaphod>; from bmbuck@14850.com on Sat, Dec 23, 2000 at 09:04:08PM -0500 X-Evolution: 00000041-0010 > > It occurs to me that [if the constitution is aimed at a rough consensus] > > this would be in line with the design intent -- and in line with existing > > debian practice (going back to long before the constitution was adopted). > > In other words: where there's no clear choice, we discuss things further. On Sat, Dec 23, 2000 at 09:04:08PM -0500, Buddha Buck wrote: > It -feels- like a bug, and here's why. ... > However, A.6(5) (Use STV in case ore than one option remains) implies > that there was thought given to the idea that there may be more than > one option -- there was not a single Condorcet winner. You've got a point, but I'm now thinking that STV is the bug. I suppose the implication is that the current behavior of the constitutional voting system is more serendipitous than intentional, and there may be some justice to that. And, serendipity or not, this behavior rather neatly circumvents Arrow's theorem. The cost is that controversial issues must be discussed more thoroughly, in order to reach a rough consensus. The benefits are: [1] intuition behaves reasonably, and [2] this is pretty much how Debian has always approached such issues. Merry Christmas, -- Raul From moth@debian.org Sun Dec 24 17:59:37 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 30688 invoked from network); 24 Dec 2000 17:59:37 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 17:59:37 -0000 Received: (qmail 23817 invoked by uid 1000); 24 Dec 2000 17:59:26 -0000 Date: Sun, 24 Dec 2000 12:59:26 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977680482.c537aed0@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Dec 24, 2000 at 04:58:34AM -0000 X-Evolution: 00000042-0010 On Sun, Dec 24, 2000 at 04:58:34AM -0000, MIKE OSSIPOFF wrote: > >[I'll add that, considering the lack of vocal support for miller-2, I wish > >that there'd be a bit more rationale about why it's philosophically bad. > > There are other kinds of arguments against it, such as complicatedness > and nonintuitiveness & nonobviousness. Oh? > Also, applying supermajority rules only to the comparison between > an alternative and the Status-Quo is more in keeping with the usual > intent of supermajority rules: Nothing should replace Status Quo > unless a supermajority vote it over the Status-Quo. So just look at an > alternative's pairing with the Status-Quo to find out if it's eligible > to replace the status quo in the event that it wins the count. This comes down to the definition of "Status-Quo". The question here is: does the supermajority rule care about non-supermajority issues, when judging status quo? If so, why? > Miller-2 would involve the supermajority rule in the count itself, in > pairings between non-status-quo alternatives. If you accept that the concept of status-quo is blind to non-supermajority issues, this only becomes an issue when options with two different supermajorities are being compared. Thanks, -- Raul From bmbuck@14850.com Sun Dec 24 21:34:38 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8850 invoked from network); 24 Dec 2000 21:34:38 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 21:34:38 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 6AA4315957; Sun, 24 Dec 2000 16:34:35 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: Raul Miller Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Classification of Supermajority Options Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Dec 2000 16:34:35 -0500 From: Buddha Buck Message-Id: <20001224213435.6AA4315957@zaphod> X-Evolution: 00000043-0010 We have 7 options presented for the Supermajority issue. One of the 7, Petry-2, gets rid of the Supermajority requirement, the other 6 keep it. Five of the remaining 6 (Ossipoff, Buck, Miller-1, Petry-1, Towns) determine if an option received supermajority support separately from the main vote count. Miller-2 combines supermajority resolution and the main vote count. Of the five "separatist" proposals, three are "post-elimination", determining supermajority qualification after the vote count (Ossipoff, Buck, Towns), and two are "pre-elimination", determing supermajority qualifications before the vote count (Petry-1, Miller-1). Buck and Towns try to accomplish the same goal (elect the highest ranked possible winner), but use different means of determining ranking. Ossipoff gives up if the highest ranked option cannot win. Petry-1 includes more potential winners than Miller-1, to avoid re-campaigning and re-voting, but is otherwise identical. Towns requires a vote-count method that provides a social order, not just a single-winner. Buck requires iterating the vote-count procedure. Miller-2 requires pre-scaling the tally before the vote count. All of these are complications that make it harder to analyze. To answer Raul's question... Miller-2 is hard to analyze, and isn't as obvious that it has good properties. Most of the other methods don't modify the existing heavily-analyzed basic vote count, and their analysis can easily be extrapolated from previously analyzed results. It has been claimed that it better represents consensus without a real demonstration of that, or even a suggestion of how to measure it. That makes it hard to comment on in the short time remaining. -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From moth@debian.org Sun Dec 24 22:08:20 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2945 invoked from network); 24 Dec 2000 22:08:20 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 22:08:20 -0000 Received: (qmail 27010 invoked by uid 1000); 24 Dec 2000 22:08:09 -0000 Date: Sun, 24 Dec 2000 17:08:09 -0500 From: Raul Miller To: Buddha Buck Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, aj@azure.humbug.org.au Subject: Re: Classification of Supermajority Options Message-ID: <977694195.8406b458@debian.org> References: <20001224213435.6AA4315957@zaphod> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001224213435.6AA4315957@zaphod>; from bmbuck@14850.com on Sun, Dec 24, 2000 at 04:34:35PM -0500 X-Evolution: 00000044-0010 On Sun, Dec 24, 2000 at 04:34:35PM -0500, Buddha Buck wrote: > To answer Raul's question... Miller-2 is hard to analyze, and isn't > as obvious that it has good properties. Most of the other methods > don't modify the existing heavily-analyzed basic vote count, and their > analysis can easily be extrapolated from previously analyzed results. > It has been claimed that it better represents consensus without a real > demonstration of that, or even a suggestion of how to measure it. That > makes it hard to comment on in the short time remaining. My claim is that miller-2 is less likely (than the other options) to pick a supermajority option, if there's no consensus that that supermajority option is the best option. This claim is easy to check. I'm going to call this kind of agreement "rough consensus" for the remainder of this message. My thesis is that supermajority options should be options which would change something which was agreed on in a prior "rough consensus". And, note that I'm talking about issues which give Debian its group identity. If nearly unanimous agreement is obtained, at time t1, that some definition of group identity is a good idea, why should it be possible at time t2, for some significantly smaller fraction of voters to change that identity? If the consensus of this group is that miller-2 has unknown properties, because it's not been studied, and it should not be accepted for that reason, I guess I can accept that. However, I'd prefer that the decision be made on grounds more concrete than "we don't have enough time to think about this". [It's not as if miller-2 should be a suprise to anyone in this group -- after all, it's a direct restatement of the supermajority mechanism described in the current debian constitution. [I understand that the exact implications of miller-2 depend on the vote ranking system we pick, and on how that system deals with the issues characterized by Arrow's theorem. I wish that we were considering supermajority after we picked the vote ranking system. I've proposed that we defer consideration of supermajority until after vote ranking is decided -- perhaps we could make that a formal proposal, "miller-3"?]] Thanks, -- Raul From moth@debian.org Sun Dec 24 23:22:13 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27207 invoked from network); 24 Dec 2000 23:22:13 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 24 Dec 2000 23:22:13 -0000 Received: (qmail 27940 invoked by uid 1000); 24 Dec 2000 23:22:01 -0000 Date: Sun, 24 Dec 2000 18:22:01 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977698802.f8cd771d@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 00000045-0010 Problems I see: Ossipoff, Buck, Miller-1, Petry-1, and Towns all seem to implicitly declare that "status quo" in the context of supermajority, is something other than "that which does not trigger the supermajority requirement". I'm told that this is "tradition" -- but this seems logically inconsistent to me. It's interesting, however, that none of these options include this definition of status quo, and any of them could be used with the definition of status quo which is implicit in Miller-2. Maybe tomorrow I can present some examples of what this would mean. Buck and Towns try to force an instant winner by first declaring one option the winner, then going for another option when it's declared ineligible. This seems logically inconsistent and less than ideal. Towns rests on the idea that a complete order is meaningful, in the context of a multi-option vote. I believe that a complete order is not meaningful where Arrow's theorem is applicable. Also, if we use the idea of further discussion to resolve cases where Arrow's theorem applies, then Towns proposal would result in unnecessary discussion (to resolve irrelevant issues). Petry-1 has the interesting feature that it uses supermajority comparison in contexts other than between the supermajority option and the status quo. This seems logically inconsistent, and less than ideal. Ossipoff defaults the election if an option which has a supermajority requirement would win, but doesn't have enough votes to win. This idea appeals to me [though I'm uncomfortable with the underlying contraditions in the way that "winning" and "status quo" are defined.] Petry-2 is likely to erode debian's identity, by failing to allow a distinction between long-term and short-term decisions. Miller-3 isn't a formal proposal, but is a declaration that we don't yet have a good reason to pick any of these. Thanks, -- Raul From aj@azure.humbug.org.au Mon Dec 25 07:18:38 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3467 invoked from network); 25 Dec 2000 07:18:38 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 07:18:38 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14ARt2-0004W2-00; Mon, 25 Dec 2000 17:17:36 +1000 Date: Mon, 25 Dec 2000 17:17:36 +1000 From: Anthony Towns To: Raul Miller Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <20001225171735.A16826@azure.humbug.org.au> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001223114041.B15756@usatoday.com>; from moth@debian.org on Sat, Dec 23, 2000 at 11:40:41AM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000046-0030 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 23, 2000 at 11:40:41AM -0500, Raul Miller wrote: > I'm aware that vote scaling "thwarts the will of the majority", but that'= s > only an issue if there is no underlying "correct answer". That is: is > the only thing that makes a decision right that most people agree with it= ? There are a few possibilities: there may be a right answer that works, and a bunch of wrong answers that have subtle flaws that the proposer didn't think of in time; there may be a bunch of answers that are all workable, but some require more effort than others to get done, or introduce more problems over the longer term, in which case one may stand out as being clearly the least problematic, or all of them may be unworkable, or there might be two or three or more that could be done, with just minor differences amongst them. In the first case, we probably don't need a vote: it's relatively easy to discuss it, and get a consensus on it; in the latter case, if we can't find any solution that's satisfactory we tend to let the matter drop and bring it up again later (or so it seems to me), if we find one solution that's more workable, we eventually do it (/usr/doc links, eg), and if there's two or three workable ideas, then it's not going to kill us whichever one gets picked, although it'll probably make some people unhappy (the logo vote, or the elections, eg). If you look at the non-free issue, eg, you'll note it's been raised at least twice (once by Wichert, and once by John), and both times it's essentially managed to die before it gets voted on. It might not be too inaccurate to divide voting issues into two lots: ones where we want to pick amongst a bunch of random options, and don't really care too much which one wins (logo vote, logo swap, elections); and those where we want to make sure we've gone through an appropriate process to make sure we've got a consensus and that any dissenters haven't been lost in the noise of the applicable flamewar and so on (constitution, logo license, non-free, social contract can be modified). Supermajorities are obviously a part of the latter: making sure we really have gone through the process of establishing a consensus, and making sure we're not doing anything stupid. Quorum and minimum discussion times are also part of this. OTOH, whether to use first-past-the-post, or STV, or Smith, or Tideman, and what tie-breaker, or whatever to use, is part of the other half of the equation: "randomly" choosing one of many options that all seem reasonable. > What I'd like to see is some reasoning about why simple majority is > a better decision making process for foundational issues than "before > you change foundational issues, make sure that almost everybody doesn't > think there's a better way". There's two ways of looking at the latter statement: not (there exists a better way, that almost everyone prefers) for almost everybody (there exists a different way they'd prefer) The first case will be handled by just about every voting system you can come up with anyway. The latter case probably isn't avoidable: there're always issues that will require compromise of some sort to resolve. > I'm not really looking for math here -- I believe there's too many > different kinds of possibilities to consider for math to be useful. Maths is a good way of seeing if your proposed implementation actually corresponds with your philosophy, and sometimes to see if your philosophy is self-contradictory, or what implications it might have. It's perfectly useful, no matter how many possibilities you have, but it's not a replacement for a rationale. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --J2SCkAp4GZ/dPZZf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkb0j+RRvX9xctrtAQGLVAP9EJ9GF0FRVfA4BfOEC0+e53qLP8KDiPs3 z2RD1CQQDNV1Lou16JEttAW9ggSTurzV7yYZa6AgzxlMTlbmmcTEyjw5O96vIJd2 PkzekIhjH86WjcVTkJU71/9DGZINDETaNfzfbp5AtLWrwI8DVDFGtkJ6rC+yCMe2 bvRLyV4k8P4= =ZJE0 -----END PGP SIGNATURE----- --J2SCkAp4GZ/dPZZf-- From moth@debian.org Mon Dec 25 12:09:45 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26308 invoked from network); 25 Dec 2000 12:09:45 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 12:09:45 -0000 Received: (qmail 4259 invoked by uid 1000); 25 Dec 2000 12:09:35 -0000 Date: Mon, 25 Dec 2000 07:09:35 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977745166.2c8a877b@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 00000047-0010 I'd compare the various supermajority proposals, by looking at how they behave with the "current" debian vote tallying system. [I'm talking about the interpretation where a smith set which contains more than one member implies a revote.] I'm going to call this system "intuitive". In this context, I'm calling a vote controversial if the smith set contains more than one member. > Ossipoff: Find the best option. If the best option is an ineligible > amendment, adopt the Status Quo; otherwise, adopt the best option. This subverts intuitive, because it calls for revotes on noncontroversial votes. > Buck: Find the best option. If the best option is an ineligible > amendment, discard it and find the next best option. Adopt the first > best option that isn't an ineligible amendment. This subverts intuitive, because it picks a particular option in a controversial vote. > Miller-1: Discard all ineligible amendments. Adopt the best option > remaining. (Note: may not have been formally proposed, claimed to be > equivilant to Buck). This subverts intuitive, because it can hide controversy. > Miller-2: Use supermajority criteria in the pairwise ranking by > scaling down the vote counts in favor of supermajority options. > [That is, if an option must have 3/4 of all cast votes, to win, when > considering pairwise rankings, multiply number of votes in favor of > this option by 1/3.] This could be more simply phrased: scale the vote tallies so that supermajority results are comparable to non-supermajority results. This redefines controversy. It doesn't seem to have any other effects (a condorcet winner is still a condorcet winner, even with scaled vote tallies). > Petry-1: Discard all amendments that are not plausible. Adopt the best > option remaining. This subverts intuitive, because it can hide controversy. > Petry-2: Drop supermajority requirements all-together. The voting system is ok, but fragile [subject to change]. > Towns: form complete ranking, choose highest ranked eligible option. > ("Another way of handling this would be to choose a method that ranks > the entire list of options, rather than just chooses a winner. Once > the options are ranked, choose the highest ranked eligible option.") This is undecidable, in the general case, with intuitive. Thanks, -- Raul From moth@debian.org Mon Dec 25 12:20:49 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31856 invoked from network); 25 Dec 2000 12:20:49 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 12:20:49 -0000 Received: (qmail 4438 invoked by uid 1000); 25 Dec 2000 12:20:39 -0000 Date: Mon, 25 Dec 2000 07:20:39 -0500 From: Raul Miller To: Anthony Towns Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <977746190.a131275b@debian.org> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001225171735.A16826@azure.humbug.org.au>; from aj@azure.humbug.org.au on Mon, Dec 25, 2000 at 05:17:36PM +1000 X-Evolution: 00000048-0010 On Sat, Dec 23, 2000 at 11:40:41AM -0500, Raul Miller wrote: > > I'm aware that vote scaling "thwarts the will of the majority", but > > that's only an issue if there is no underlying "correct answer". > > That is: is the only thing that makes a decision right that most > > people agree with it? On Mon, Dec 25, 2000 at 05:17:36PM +1000, Anthony Towns wrote: > There are a few possibilities: there may be a right answer that works, ... > In the first case, we probably don't need a vote: it's relatively > easy to discuss it, and get a consensus on it; in the latter case, > if we can't find any solution that's satisfactory we tend to let the > matter drop and bring it up again later (or so it seems to me), if we > find one solution that's more workable, we eventually do it (/usr/doc > links, eg), and if there's two or three workable ideas, then it's not > going to kill us whichever one gets picked, although it'll probably > make some people unhappy (the logo vote, or the elections, eg). Ok. But note that none of these are likely to result in a smith set. [Ok, there's a slight chance that "bored and random" will result in a smith set, but that's not likely to recur on a revote.] > It might not be too inaccurate to divide voting issues into two lots: > ones where we want to pick amongst a bunch of random options, and > don't really care too much which one wins (logo vote, logo swap, > elections); and those where we want to make sure we've gone through an > appropriate process to make sure we've got a consensus and that any > dissenters haven't been lost in the noise of the applicable flamewar > and so on (constitution, logo license, non-free, social contract can > be modified). > > Supermajorities are obviously a part of the latter: making sure we really > have gone through the process of establishing a consensus, and making > sure we're not doing anything stupid. Quorum and minimum discussion > times are also part of this. I can mostly go along with this. I wouldn't say that non-supermajority votes are "random", however. > OTOH, whether to use first-past-the-post, or STV, or Smith, or Tideman, > and what tie-breaker, or whatever to use, is part of the other half > of the equation: "randomly" choosing one of many options that all seem > reasonable. If we really wanted random, we'd have a lottery process. > > What I'd like to see is some reasoning about why simple majority is > > a better decision making process for foundational issues than "before > > you change foundational issues, make sure that almost everybody doesn't > > think there's a better way". > > There's two ways of looking at the latter statement: > > not (there exists a better way, that almost everyone prefers) > for almost everybody (there exists a different way they'd prefer) > > The first case will be handled by just about every voting system you can > come up with anyway. The latter case probably isn't avoidable: there're > always issues that will require compromise of some sort to resolve. It seems to me that the latter case should be avoidable -- by talking through whatever the controversy is. If it's really not avoidable, I'm not sure why we should declare a particular answer as representative of the group. > > I'm not really looking for math here -- I believe there's too many > > different kinds of possibilities to consider for math to be useful. > > Maths is a good way of seeing if your proposed implementation actually > corresponds with your philosophy, and sometimes to see if your philosophy > is self-contradictory, or what implications it might have. It's perfectly > useful, no matter how many possibilities you have, but it's not a > replacement for a rationale. Er.. my impression is that supermajority handling is "good" or "bad" based on how well it integrates with the normal vote deciding system. If you can come up with relevant and interesting mathematical statements which are independent of that vote system, well, good for you -- I'm interested in seeing them. Thanks, -- Raul From aj@azure.humbug.org.au Mon Dec 25 13:36:50 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 6237 invoked from network); 25 Dec 2000 13:36:50 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 13:36:50 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14AXnl-0005S4-00; Mon, 25 Dec 2000 23:36:33 +1000 Date: Mon, 25 Dec 2000 23:36:33 +1000 From: Anthony Towns To: Raul Miller Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <20001225233632.A20423@azure.humbug.org.au> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> <977746190.a131275b@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <977746190.a131275b@debian.org>; from moth@debian.org on Mon, Dec 25, 2000 at 07:20:39AM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000049-0030 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 25, 2000 at 07:20:39AM -0500, Raul Miller wrote: > On Mon, Dec 25, 2000 at 05:17:36PM +1000, Anthony Towns wrote: > > There are a few possibilities: there may be a right answer that works, > > In the first case, we probably don't need a vote: it's relatively > > easy to discuss it, and get a consensus on it; in the latter case, > > if we can't find any solution that's satisfactory we tend to let the > > matter drop and bring it up again later (or so it seems to me), if we > > find one solution that's more workable, we eventually do it (/usr/doc > > links, eg), and if there's two or three workable ideas, then it's not > > going to kill us whichever one gets picked, although it'll probably > > make some people unhappy (the logo vote, or the elections, eg). > Ok. But note that none of these are likely to result in a smith set. Consider the logo vote for example: did it matter at all as far as any of Debian's goals go, or it's continued existance is concerned, or any of those things which option was chosen? OTOH, there was a vote taken, the rankings were counted, and there was not only a Smith set, but a Condorcet winner too. (A Smith set always exists anyway; if the voters aren't trying to be educated and sincere that might be meaningless, but it's impossible to conduct a vote with ballots like Debian's and *not* have a Smith set) And the logo chosen (which was, eg, my 5th or 6th preference) looks like it's worked out quite well, even though it probably wouldn't have mattered if we'd chosen a different one. > > It might not be too inaccurate to divide voting issues into two lots: > > ones where we want to pick amongst a bunch of random options, and > > don't really care too much which one wins (logo vote, logo swap, > > elections); and those where we want to make sure we've gone through an > > appropriate process to make sure we've got a consensus and that any > > dissenters haven't been lost in the noise of the applicable flamewar > > and so on (constitution, logo license, non-free, social contract can > > be modified). > > > > Supermajorities are obviously a part of the latter: making sure we real= ly > > have gone through the process of establishing a consensus, and making > > sure we're not doing anything stupid. Quorum and minimum discussion > > times are also part of this. > I can mostly go along with this. I wouldn't say that non-supermajority > votes are "random", however. Taking this view would make Manoj's and Branden's current proposals be two aspects of the issue: 1) That we should amend the consitution to make it clear whether we can modify the social contract 2) How we should amend it Everyone's agreed on (1), and there's only a minor variation in (2), and, really, it's not likely to be the end of the world whichever option is chosen. > > OTOH, whether to use first-past-the-post, or STV, or Smith, or Tideman, > > and what tie-breaker, or whatever to use, is part of the other half > > of the equation: "randomly" choosing one of many options that all seem > > reasonable. > If we really wanted random, we'd have a lottery process. Right. That's why it's in scare-quotes: we don't want completely random, we want the most popular solution, on the basis that since if there is a clear objective technical reason for it, we're all educated and sensible enough to choose that option; and if there's not, there's a good chance that the majority selection will be a good one. > > > What I'd like to see is some reasoning about why simple majority is > > > a better decision making process for foundational issues than "before > > > you change foundational issues, make sure that almost everybody doesn= 't > > > think there's a better way". > > There's two ways of looking at the latter statement: > > not (there exists a better way, that almost everyone prefers) > > for almost everybody (there exists a different way they'd prefer) > > The first case will be handled by just about every voting system you ca= n > > come up with anyway. The latter case probably isn't avoidable: there're > > always issues that will require compromise of some sort to resolve. > It seems to me that the latter case should be avoidable -- by talking > through whatever the controversy is. If it's really not avoidable, I'm > not sure why we should declare a particular answer as representative of > the group. Just because they talk about it doesn't necessarily change their preferences as to what they'd like. Consider a bunch of selfish people with $150,000 to distribute amongst themselves. Their ballots are likely to go something like: A: [1] Distribute $150k to A [ ] Distribute $150k to B [ ] Distribute $150k to C [ ] Distribute $150k to D [ ] Distribute $150k to E [2] Distribute $30k to each of A,B,C,D,E [3] Further discussion B: [ ] Distribute $150k to A [1] Distribute $150k to B [ ] Distribute $150k to C [ ] Distribute $150k to D [ ] Distribute $150k to E [2] Distribute $30k to each of A,B,C,D,E [3] Further discussion ...and so on. A Condorcet system will immediately look at this and say `Okay, the best compromise is distributing $10k to each person'. A first-past-the-post system, or a STV system would fail. [0] Which is to say: sure, voting systems aren't all intelligent, you can't take uninformed opinions, or actively malicious majorities, and just shove them into a Condorcet system and have the fair and just result pop out, but it is possible that the best compromise may not be anyone's first preference, and at least a few of these cases can be handled by careful thought in advance. But that's getting a bit of track: sometimes it just not possible to choose the best compromise by any amount of talk. Choosing logos, leaders, and probably choosing between Manoj's and Branden's preferred form of how the social contract can be modified are probably all like this. In this case, the easiest way to do things is just to have a vote, and let that decide. And that's what we do right now (ignoring A.3(3)): we have an initial vote to see what the most popular way of proceeding is (Condorcet winner, no quorum or supermajority), then we have a second vote to make sure we're really happy to go that way. > > > I'm not really looking for math here -- I believe there's too many > > > different kinds of possibilities to consider for math to be useful. > > Maths is a good way of seeing if your proposed implementation actually > > corresponds with your philosophy, and sometimes to see if your philosop= hy > > is self-contradictory, or what implications it might have. It's perfect= ly > > useful, no matter how many possibilities you have, but it's not a > > replacement for a rationale. > Er.. my impression is that supermajority handling is "good" or "bad" > based on how well it integrates with the normal vote deciding system. That seems completely irrelevant to me. Whether supermajority handling is "good" or "bad" is simply whether it accurately reflects the will of the developers or not. If that involves kludges and hacks, or eloquent simplicity, well, that might make a difference, but not a particularly important one. > If you can come up with relevant and interesting mathematical statements > which are independent of that vote system, well, good for you -- I'm > interested in seeing them. There are two reasons to vote: one is to select among options that are essentially equally acceptable (Manoj v Branden, leadership, logos); one is to make sure we've gone through the appropriate procedure and haven't accidently or deliberately ignored a significant body of objectors (ie, we've gone through due process). The best way to choose amongst options that are equally acceptable is working out which option is preferred by the majority of developers interested enough to vote amongst any two, and using the Condorcet winner if there is one, or choosing a reasonable winner if there isn't (Smith Set, STV, Tideman, Schulze, whatever). The best way to ensure we haven't ignored a significant body of objectors is to give all developers a fair chance to vote (clear announcements, enough time to consider what's going on, and enough time to vote) and an opportunity to veto an option; if enough objectors try to veto an option (50% for most options, 33% for tech ctte overrides, 25% for constitutional amendments [1]), then it should not be done. Using comparison with the status-quo (ie, doing absolutely **nothing** as a result of the vote) for the latter, and a standard Condorcet method for the former satisfies both, in a fairly obvious manner, and doesn't introduce any other subtleties, as far as it goes. The question of what to do if the preferred option is vetoed remains: Ossipoff (or at least his method) says "give up, and talk some more you twits", which isn't unreasonable. Buck, Miller-1 and Towns all say "go to the next best option" [2], which probably isn't unreasonable either. Cheers, aj [0] If you have any options which a majority would see as preferable, say "Give A,B,C $50k each", then that option'll be chosen over the "fairer" compromise; if multiple such options are proposed, then the Smith criterion will let you choose any of them, but not the "fairer" compromise. [1] Or possibly 50%+1, or similar. [2] And differ primarily in how they work out what the "next best" option is in the case of cycles. Buck, in a sense, is a subset of Towns in that one easy way to get a "ranking" from a Condorcet system that only chooses winners is to just remove the winner each time, and work it out again. Personally, I don't think there's a signficant difference between any of these three methods: in the event of a "Condorcet ranking" (A beats all options; B beats all options but A; C beats all options but A,B; etc), I'm fairly sure they'll have the same result; in the event of not having a Condorcet ranking, there are probably good arguments for either way of doing things anyway. All of which would incline me towards using Miller-1 since it seems to have the nicest properties; even though I think Towns/Buck is more straightforwardly justified. --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkdNYORRvX9xctrtAQED7wP9GR+GSBEXD8j8kifrpJGPOipJz8Aidi7l 4RcpaIdlhOziTLYDOE3HdmOCc//CkAyR55QR2mMpw1TPyJRxP8WY0eLWchfIQAqI ZYCHh+UZJROl/qFWgFT6p0JAKLc+FkP9l90Ll7PPJQTOFVFv74meTTa/DNk6Iv6S 4eGGVt8KNX8= =goAx -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From aj@azure.humbug.org.au Mon Dec 25 13:43:55 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 10341 invoked from network); 25 Dec 2000 13:43:55 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 13:43:55 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14AXui-0005UC-00; Mon, 25 Dec 2000 23:43:44 +1000 Date: Mon, 25 Dec 2000 23:43:44 +1000 From: Anthony Towns To: Raul Miller Cc: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck Subject: Re: Call for Votes on Supermajority Issue Message-ID: <20001225234344.B20423@azure.humbug.org.au> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <977745166.2c8a877b@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <977745166.2c8a877b@debian.org>; from moth@debian.org on Mon, Dec 25, 2000 at 07:09:35AM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000004a-0030 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 25, 2000 at 07:09:35AM -0500, Raul Miller wrote: > > Ossipoff: Find the best option. If the best option is an ineligible > > amendment, adopt the Status Quo; otherwise, adopt the best option. > This subverts intuitive, because it calls for revotes on noncontroversial > votes. If a situation is such that what the majority want is completely unacceptable to an appropriately sized groud (which in normal situations is a majority itself, but can be 33% or 25%), then I'd be inclined to suspect controversy abounds. "subverts intuitive" doesn't strike me as good grammar and don't seem particularly meaningful even accounting for that. You defined "intuitive" as what the current system is: none of these "subvert" that, they outright replace it. Given the sorts of thing you've said "subvert intuitive", I'm not sure it's necessarily a bad thing either. One of the whole points of all this was to choose a reasonable winner even in controversial issues, eg. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkdPEORRvX9xctrtAQEC3QP+IeHw1AIwUNK4l9ebc29EJY+f6bv/nz7K O2CS2Wj3sAueOSBpd5hLoxTP9Hg9KyhGa3wy3Jtyn5NXJBTzTyk0GkDnXrcBAdAN PMyZxTrpMzRb1WjTk8sn5f0Sh6OAhJaxwgXT3crcnpuX1MOTyRg6yMeE1hQVKcYz TzxYmC8T4Zw= =pV1i -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From moth@debian.org Mon Dec 25 14:28:07 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2439 invoked from network); 25 Dec 2000 14:28:07 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 14:28:07 -0000 Received: (qmail 5592 invoked by uid 1000); 25 Dec 2000 14:27:56 -0000 Date: Mon, 25 Dec 2000 09:27:56 -0500 From: Raul Miller To: Anthony Towns Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <977754238.66568485@debian.org> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> <977746190.a131275b@debian.org> <20001225233632.A20423@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001225233632.A20423@azure.humbug.org.au>; from aj@azure.humbug.org.au on Mon, Dec 25, 2000 at 11:36:33PM +1000 X-Evolution: 0000004b-0010 > > Ok. But note that none of these are likely to result in a smith set. Sorry, I meant to say "none of these are likely to result in a smith set with more than one member". > Which is to say: sure, voting systems aren't all intelligent, you can't > take uninformed opinions, or actively malicious majorities, and just shove > them into a Condorcet system and have the fair and just result pop out, > but it is possible that the best compromise may not be anyone's first > preference, and at least a few of these cases can be handled by careful > thought in advance. Agreed. > > Er.. my impression is that supermajority handling is "good" or "bad" > > based on how well it integrates with the normal vote deciding system. > > That seems completely irrelevant to me. Whether supermajority handling is > "good" or "bad" is simply whether it accurately reflects the will of the > developers or not. I think we're talking past each other. You seem to be addressing the validity of supermajorities. I'm trying to talk about whether the handling of supermajorities is inconsistent with how the rest of the vote is handled. > Using comparison with the status-quo (ie, doing absolutely **nothing** > as a result of the vote) for the latter, and a standard Condorcet method > for the former satisfies both, in a fairly obvious manner, and doesn't > introduce any other subtleties, as far as it goes. I do see this. I'm just not comfortable with it. Thanks, -- Raul From moth@debian.org Mon Dec 25 14:32:05 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4729 invoked from network); 25 Dec 2000 14:32:05 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 14:32:05 -0000 Received: (qmail 5681 invoked by uid 1000); 25 Dec 2000 14:31:54 -0000 Date: Mon, 25 Dec 2000 09:31:54 -0500 From: Raul Miller To: Anthony Towns Cc: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977754490.13acf0c4@debian.org> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <977745166.2c8a877b@debian.org> <20001225234344.B20423@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001225234344.B20423@azure.humbug.org.au>; from aj@azure.humbug.org.au on Mon, Dec 25, 2000 at 11:43:44PM +1000 X-Evolution: 0000004c-0010 > On Mon, Dec 25, 2000 at 07:09:35AM -0500, Raul Miller wrote: > > > Ossipoff: Find the best option. If the best option is an ineligible > > > amendment, adopt the Status Quo; otherwise, adopt the best option. > > This subverts intuitive, because it calls for revotes on noncontroversial > > votes. On Mon, Dec 25, 2000 at 11:43:44PM +1000, Anthony Towns wrote: > If a situation is such that what the majority want is completely > unacceptable to an appropriately sized groud (which in normal > situations is a majority itself, but can be 33% or 25%), then I'd be > inclined to suspect controversy abounds. That's a reasonable point. > "subverts intuitive" doesn't strike me as good grammar and don't > seem particularly meaningful even accounting for that. You defined > "intuitive" as what the current system is: none of these "subvert" > that, they outright replace it. Sorry. I meant "this conflicts with the idea that if there's a clear condorcet winner then that should be picked, otherwise further discussion is in order". > Given the sorts of thing you've said "subvert intuitive", I'm not sure > it's necessarily a bad thing either. One of the whole points of all > this was to choose a reasonable winner even in controversial issues, > eg. But should this be given precedence over talking out unresolved issues? Any real life examples where a smith set was about an issue where further discussion wouldn't have achieved anything? Thanks, -- Raul From aj@azure.humbug.org.au Mon Dec 25 15:02:49 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 23546 invoked from network); 25 Dec 2000 15:02:49 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 25 Dec 2000 15:02:49 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14AZ96-0006Qs-00; Tue, 26 Dec 2000 01:02:40 +1000 Date: Tue, 26 Dec 2000 01:02:40 +1000 From: Anthony Towns To: Raul Miller Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <20001226010240.B24392@azure.humbug.org.au> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> <977746190.a131275b@debian.org> <20001225233632.A20423@azure.humbug.org.au> <977754238.66568485@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <977754238.66568485@debian.org>; from moth@debian.org on Mon, Dec 25, 2000 at 09:27:56AM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000004d-0030 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 25, 2000 at 09:27:56AM -0500, Raul Miller wrote: > > > Ok. But note that none of these are likely to result in a smith set. > Sorry, I meant to say "none of these are likely to result in a smith > set with more than one member". Eh? Ballots where it doesn't really matter which option's picked seem more likely to not have a Condorcet winner, to me. Got any justification for that assertion? > > > Er.. my impression is that supermajority handling is "good" or "bad" > > > based on how well it integrates with the normal vote deciding system. > > That seems completely irrelevant to me. Whether supermajority handling = is > > "good" or "bad" is simply whether it accurately reflects the will of th= e > > developers or not. > I think we're talking past each other. You seem to be addressing > the validity of supermajorities. I'm trying to talk about whether > the handling of supermajorities is inconsistent with how the rest > of the vote is handled. If an inconsistency in the process matters, it's only because it ends up producing an outcome that doesn't match the developers want. > > Using comparison with the status-quo (ie, doing absolutely **nothing** > > as a result of the vote) for the latter, and a standard Condorcet metho= d > > for the former satisfies both, in a fairly obvious manner, and doesn't > > introduce any other subtleties, as far as it goes. > I do see this. I'm just not comfortable with it. I'm tempted to spend half an hour trying to make up some clever reference to the "princess and the pea" fable, but I think I'd rather go to sleep. It's too hot. At any rate, it doesn't much matter if you're not comfortable if you can't explain why you're not comfortable with it. I think my explanation of vetoing and majority rule, and why they're appropriate for Debian votes, and how any of Ossipoff/Buck/Miller-1/Towns achieves those hangs together reasonably from first principles; I'd be very interested to see one of Miller-2 that does likewise. Of course, I suspect you don't know yourself why you're more comfortable with it, so... [0] Cheers, aj [0] FWIW, whenever I'm like that, I just start wildly making up reasons, until I find one that seems to hang together. I tried that with Miller-2 on -vote, and couldn't think of anything, but then, I'm not comfortable with it, so that's not overly surprising. :) --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOkdhj+RRvX9xctrtAQHVaQP/QFZoavnlLcpHhdJx7DMqH+I9MakkbXfn ovuUVA3rKzD07Sbtgkvt4/jdYPvElkq/J4fDW5/fXdeWjm2bWSw2AFJu7gulL7VJ PPHg5fazGNwX/uhfy+96tfu5//ZmPrRQe3pfkB6U8DNt9YrDfW3n04nLgYagWgLz EY6zLzdqte0= =dvKW -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From moth@debian.org Tue Dec 26 10:39:30 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 15273 invoked from network); 26 Dec 2000 10:39:30 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 10:39:30 -0000 Received: (qmail 29300 invoked by uid 1000); 26 Dec 2000 10:39:19 -0000 Date: Tue, 26 Dec 2000 05:39:19 -0500 From: Raul Miller To: Anthony Towns Cc: Rob Lanphier , Norman Petry , nkklrp@hotmail.com, stevegr@debian.org, bmbuck@14850.com Subject: Re: Two Proposals for the Supermajority Requirement Message-ID: <977825870.d951dcef@debian.org> References: <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> <977746190.a131275b@debian.org> <20001225233632.A20423@azure.humbug.org.au> <000401c06b8c$e1db1a00$4d01a8c0@archives.gov.sk.ca> <20001223114041.B15756@usatoday.com> <20001225171735.A16826@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001225171735.A16826@azure.humbug.org.au>; from aj@azure.humbug.org.au on Mon, Dec 25, 2000 at 05:17:36PM +1000 X-Evolution: 0000004e-0010 > > Sorry, I meant to say "none of these are likely to result in a smith > > set with more than one member". On Tue, Dec 26, 2000 at 01:02:40AM +1000, Anthony Towns wrote: > Eh? Ballots where it doesn't really matter which option's picked > seem more likely to not have a Condorcet winner, to me. Got any > justification for that assertion? It's correct to say that a ballot with several workable ideas is more likely to not have a condorcet winner than a ballot with only one. That's not the same thing as saying that such a ballot is likely to not have a condorcet winner. However, for there to not be a condorcet winner you have to have a tie of some sort -- either a strict tie (two or more options preferred equally by the ballots) or a circular tie (three or more options with no strict preference between them). My assertion is that even when there are several workable ideas, these ideas are not equivalent -- there's issues of simplicity, philosophy, implementation effort, etc. which would tend to bias opinion towards these ideas. Of course, I'll also assert that when one idea is a particularly *good* idea, that opinion in favor of that idea is nearly unanimous. And, also, I'll note that if an option with a supermajority requirement is a particularly good idea, and if it just barely loses out to some option which doesn't have supermajority requirement in a specific case, that the developers are likely to call for another election focussing on just that supermajority idea. > > I think we're talking past each other. You seem to be addressing > > the validity of supermajorities. I'm trying to talk about whether > > the handling of supermajorities is inconsistent with how the rest > > of the vote is handled. > > If an inconsistency in the process matters, it's only because it ends > up producing an outcome that doesn't match the developers want. I'd phrase replace "the developers want" with "Debian's goals". Debian is considerably larger than the developers. The developers make most of the decisions, but they're only a tiny fraction of Debian as a whole. -- Raul From npetry@accesscomm.ca Tue Dec 26 16:16:49 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7530 invoked from network); 26 Dec 2000 16:16:49 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 16:16:49 -0000 Message-ID: <006601c06f57$2e9c3180$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Re: Call for Votes on Supermajority Issue Date: Tue, 26 Dec 2000 10:16:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 0000004f-0010 On December 23, Buddha Buck wrote: >> Petry-1: Discard all amendments that are not plausible. Adopt the best >> option remaining. >> >> Similar to Miller-1, but allows proposals that would not be eligible under >> Miller-1 to be eligible if they would be able to beat the new status quo. >> Fairer than Miller under these conditions, and minimises reballoting. >> Should be monotonic. I do not consider this a radical proposal -- it seems >> like a straightforward extension of the concept of pairwise-relative >> supermajority used in other methods. More complex than Miller-1, but >> complexity/quality tradoff is good, since the additional recursive rule can >> be defined in one sentence. In theory, less flexible than Miller-1, since >> only simple majority and a single supermajority ratio can be used on one >> ballot. This should not be a drawback in practice, however (scenarios where >> this could conceivably happen are implausible). The best method on >> technical grounds. > >I don't see why multiple supermajority ratios can't be used on one >ballot. By your reasoning and explanation of the method, it should be >possible. I've thought some more about this, and it occurs to me that you are probably right. As long as an option beats another 'plausible' option by its *own* supermajority requirement (pretend the beaten option is the status-quo), it should also be plausible. I had thought that this would result in problems, so I wanted to constrain the system to a single supermajority requirement to reduce the possibility of unanticipated results, but I can't come up with an example where this would be a problem. Particularly so since we are (in this step) only determining eligibility, not a single winner. As long as a good single-winner method is used, the winner will be a good choice regardless. However, this is all academic anyway -- a single vote combining a tech ctte decision (2:1), a constitutional amendment (3:1) and a general resolution (1:1) on a single ballot would be an absurd, confused mess. Who knows what might result from such a vote? Assuming Debian developers aren't complete lunatics, this will never happen anyway, so the additional flexibility is unimportant, imho. > >Scenario: Among several ballot options, A requires a 3:1 >supermajority over SQ, and has it. B requires a 3:2 supermajority over >SQ, and doesn't have it, but has a 3:2 supermajority over A. Since B >-would- be plausible if A was the Status Quo, by your reasoning, I see >no reason why it shouldn't be plausible in Petry-1. > >But I'm not even certain that the plausibility rule is consistent or >needed. Take this example: > >Scenario: Among several ballot options, resolution A has a pairwise >majority over resolution B, yet B wins the vote count (a situation >which will happen whenever there isn't a Condorcet winner). By the >same logic promoting Petry-1 over Miller-1, this would induce >supporters of A to resubmit a A, confident that A can win this time. >Obviously, this isn't considered a serious issue -- or perhaps we >should suggest a rule limiting proposals to things which haven't been >voted on in a while? > >Why is it more of an issue that needs to be dealt with when A and B are >amendments, not resolutions? This is an interesting point. I guess the difference between the two cases is that once an option becomes the status quo, its supermajority passage requirement changes into a simple majority, whereas there is no change in the simple majority case. This has an affect on stability. If we have 3 options {A,B,C} involved in a circular tie (A>B>C>A>B...), and no supermajority requirement, then as you point out, if C is the chosen winner, a reballoting with only B and C would result in the election of B. However, there is no basis for the elimination of A. That is, in the simple majority case, for a simple pairwinner to be able to win, we would need to change the field of available candidates. Supporters of B will not call for a reballoting, because A will still be a contender, and will prevent the election of B. In contrast, with the *same set* of candidates and a status quo option that could be any of them, there is only one stable possible outcome where a candidate is both the single winner choice and also the status quo option using the Petry-1 supermajority rule. Therefore, I think these situations are different, and this is not a reasonable objection to Petry-1. -- Norm Petry From bmbuck@14850.com Tue Dec 26 16:40:18 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24410 invoked from network); 26 Dec 2000 16:40:18 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 16:40:18 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Tue, 26 Dec 2000 11:40:08 -0500 Message-Id: <5.0.0.25.0.20001226112135.02b98520@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 26 Dec 2000 16:40:08 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 26 Dec 2000 11:38:43 -0500 To: "Steve Greenland" , "Rob Lanphier" ,"Norman Petry" , "Mike Ossipoff" , "Anthony Towns" ,"Raul Miller" From: Buddha Buck Subject: What is the Status Quo? In-Reply-To: <006601c06f57$2e9c3180$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Evolution: 00000050-0010 Raul Miller has brought up the issue of what the Ossipoff, Buck, Towns, Petry-1, and Miller-1 options mean by "status quo". All of those methods use an definition of supermajority of "defeats the status quo by N:M pairwise". I'd like to put forth the idea that on any ballot decided by those methods, there be an explicit "Status Quo" option, who's selection would result in the dismissal without prejudice of all the other options. No resolutions passed, no amendments made, and the resolutions/amendments/etc can be re-proposed if desired. The situation would be restored to how it was before the options were proposed in the first place. An explicit option is necessary, so that there is no ambiguity in the interpretation of "defeats the status quo by a supermajority". In the recent Goerzen/Towns situation, it was argued at one point that Towns' resolution would have been a "status quo" option, since it didn't change the nature of Debian Operations (the resolution essentially reaffirmed Debian's commitments to the disputed portions of the Social Contract, claiming that our behavior was consistant with the SC). Even without such potential "status quo equivalent" resolutions, the simple single-amendment "amend/don't amend/further discussion" ballot is ambiguous. Is "Don't Amend" or "Further Discussion" the "status quo" option? Better to have an explicit option, so that the ballot would be "amend/status quo", or "amendment A/amendment B/resolution C/status quo", and we can tell immediately which option should be considered the status quo. From npetry@accesscomm.ca Tue Dec 26 16:58:23 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7387 invoked from network); 26 Dec 2000 16:58:23 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 16:58:23 -0000 Message-ID: <008401c06f5c$fd944180$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Re: Call for Votes on Supermajority Issue Date: Tue, 26 Dec 2000 10:57:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000051-0010 Mike wrote: > >Raul wrote [referring to the 2-proposals approach]: > >>This approach would delay the adoption of all of the proposals. > >That concerned me too. > >The 2-stage release sounds good. First we release recommendations >for the actual voting system & a simple form of supermajority >procedure (preferably Miller-1). If there are felt to be other >essentials, then they too, in their simplest form, would be >part of this 1st release. > >Then, after these proposals are enacted by Debian, we release >a 2nd batch of proposals, including more optional proposals, >and more complicated or controversial supermajority proposals. > >Maybe when I hear Norm's arguments for the 2-proposal approach that >will convince me. Right now the 2-stage release sounds better, because >it avoids the crucial, necessary reforms being delayed while >optional or controversial proposals are being debated and combined >in amended proposals. > I agree that submitting two proposals simultaneously will result in internal debate that may delay the adoption of one proposal or the other. This is a problem if decisions about important internal matters are held up as a result. I have repeatedly argued though that those delays are unnecessary -- I see no reason why other matters cannot be decided under Debian's existing rules. Rather than reiterate my arguments on that subject, I guess Raul and I will just have to agree to disagree. It then becomes a question of whether or not debian developers will insist on resolving these issues now, or are prepared to wait until the constitutional issues are settled. However, isn't informed internal debate about the constitutional questions desireable? If the developers have two proposals, and can compare and contrast at least two good approaches, I think it is more likely that they will get the constitution they are looking for. A single proposal would be easier to ram through, but might not be the best choice for Debian. >Also, Debian could better deal with several competing options of >varying controversialness after the new voting system is in place. > This is a good point. However, I don't think the developers will have any interest in considering an 'improved' version of their constitution once they've already made changes that fix most of the serious problems. Right now, the rules have enough flaws that there is an impetus to make changes, and developers will of course want to adopt the best fixes that are suggested (and what is 'best' is debatable). Once the rules are no longer broken though, developers will probably take the view that 'yeah, this is an improvement, but our current system works', and the 'alternate' proposal won't even get enough sponsors for consideration. As I understand it, Debian's rules require a proposal to receive sponsorship from X number of developers in order to appear on the ballot. If we submitted two proposals simultaneously and there is genuinely little or no support for the alternate proposal, it probably wouldn't meet the sponsorship requirement and would die without delaying the internal decision at all. We won't know that, however unless we make the proposal. For now, I suggest we continue working on an alternate, and then when we have nearly finished our committee's work, we can decide on the best strategy for what to do with it: a) Discard it b) Release simultaneously c) Release later d) Release it instead of primary proposal I think reasonable arguments can be made for all these positions, and despite my arguments in support of (b), I am not certain that this is the best choice. I think it would be best if the developers on the committee make this final decision, rather than those of us from EM. Please let me know your thoughts on this matter. -- Norm Petry From moth@debian.org Tue Dec 26 17:06:30 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14593 invoked from network); 26 Dec 2000 17:06:30 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 17:06:30 -0000 Received: (qmail 2096 invoked by uid 1000); 26 Dec 2000 17:06:19 -0000 Date: Tue, 26 Dec 2000 12:06:19 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977849035.23e70c6f@debian.org> References: <006601c06f57$2e9c3180$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <006601c06f57$2e9c3180$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Tue, Dec 26, 2000 at 10:16:19AM -0600 X-Evolution: 00000052-0010 On Tue, Dec 26, 2000 at 10:16:19AM -0600, Norman Petry wrote: > regardless. However, this is all academic anyway -- a single vote > combining a tech ctte decision (2:1), a constitutional amendment (3:1) > and a general resolution (1:1) on a single ballot would be an absurd, > confused mess. Who knows what might result from such a vote? Assuming > Debian developers aren't complete lunatics, this will never happen > anyway, so the additional flexibility is unimportant, imho. I could see something like this eventually happening, for example if Debian were subject to significant legal pressure. Let's imagine that some u.s. law or trade agreement was ratified, requiring all computers above a certain complexity to have some kind of copyright-protection code installed in all text manipulation programs, and one option for solution violates the DFSG (let's say we've ratified that so that 3:1 supermajority is allowed for changes), and another violates some tech committee ruling (maybe something about not breaking previous releases), and one option involves a more gradual phase in, and doesn't require non-free software, but risks legal trouble. Anyways, the details don't matter, we're not trying to decide the outcome of future votes. We're trying to decide the methedology used to resolve the ballots. [And, we mostly seem to care about "reasonably handling" of the improbable cases.] -- Raul From bmbuck@14850.com Thu Dec 21 22:54:38 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25422 invoked from network); 21 Dec 2000 22:54:38 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 21 Dec 2000 22:54:37 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 866AC15970; Thu, 21 Dec 2000 17:54:35 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: "Norman Petry" Cc: "'Raul Miller'" , nkklrp@hotmail.com, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Status/Summary of proposals so far... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Dec 2000 17:54:35 -0500 From: Buddha Buck Message-Id: <20001221225435.866AC15970@zaphod> X-Evolution: 00000053-0010 This is not meant to be definitive, but rather states in one place what I think I've seen so far. To the question "What does 'supermajority' mean in a ranked-ballot situation" the only answer I've seen was from Mike Ossipoff, that being that an amendment can be adopted only if it defeats the status quo by a supermajority. I've seen no other suggestion, nor any opposition to that suggestion. I think we may have achieved consensus on that point. I think we can also agree that if there is an option that has a supermajority requirement, there must be a "Status Quo" option. I'd go further and suggest that except for elections, there must be a "Status Quo" option, even without supermajority requirements. As far as the vote count itself, I've seen 5 proposals to date, which I will summarize below. First, some definitions: An option is ADOPTED if it is the final outcome of the vote count process. An option is an AMENDMENT if it requires a supermajority to be adopted. An option is a RESOLUTION if it has no special majority or supermajority requirements. (Note: the status quo, if an option on the ballot, is considered a resolution) An option is the BEST option if it wins the "normal" vote count (i.e., Smith-Condorcet, STV-Condorcet, Tideman, SSD, whatever we adopt that doesn't handle supermajorities). An amendment is INELIGIBLE if it does not defeat the status quo by a supermajority. An amendment is PLAUSIBLE if it defeats the status quo by a supermajority, or if it defeats an PLAUSIBLE amendment by a supermajority. So, here are the proposals, summarized by me: Ossipoff: Find the best option. If the best option is an ineligible amendment, adopt the Status Quo; otherwise, adopt the best option. Buck: Find the best option. If the best option is an ineligible amendment, discard it and find the next best option. Adopt the first best option that isn't an ineligible amendment. Miller: Discard all ineligible amendments. Adopt the best option remaining. (Note: may not have been formally proposed, claimed to be equivilant to Buck). Petry-1: Discard all amendments that are not plausible. Adopt the best option remaining. Petry-2: Drop supermajority requirements all-together. Have I missed anything, or mischaracterized anything or anyone? -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From nkklrp@hotmail.com Tue Dec 26 20:31:13 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 29859 invoked from network); 26 Dec 2000 20:31:13 -0000 Received: from law-f47.hotmail.com (HELO hotmail.com) (209.185.130.35) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 20:31:13 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Dec 2000 12:31:11 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Tue, 26 Dec 2000 20:31:11 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, moth@debian.org Subject: Re: Call for Votes on Supermajority Issue Date: Tue, 26 Dec 2000 20:31:11 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Dec 2000 20:31:11.0474 (UTC) FILETIME=[C8F7A520:01C06F7A] X-Evolution: 00000054-0010 Before I go on, let me state my proposal at the beginning of this' letter: I suggest that we proceed with the agenda as planned, without debate now on the matter of the reporting mode. Then, when we've covered the items that Raul judges to be the essential minimal recommendations, then I urge Raul to, at that time, make a motion that the 3 developers vote on 2-proposals vs 2-stage-release. As I say later in this letter, that seems the simplest & most natural & most easily justified procedural solution. Now, a few comments on the reporting mode issue itself: >I agree that submitting two proposals simultaneously will result in >internal >debate that may delay the adoption of one proposal or the other. This is a >problem if decisions about important internal matters are held up as a >result. I have repeatedly argued though that those delays are >unnecessary Yes, but the reforms that we recommend could be endlessly delayed by all the many possible amendments with all sorts of combinations of the items in the proposals. It could go on so long that people just give up, and the more crucial reforms never get enacted. And many might be bothered by a long delay before a decent voting system is in place. And maybe the voting system reform, buried in a hopeless mass of debated amendments on many items, will never be enacted. >- I see no reason why other matters cannot be decided under >Debian's existing rules. But Raul said that they're expecting a recommended solution from us for the voting system. If we give them the 2 proposals, which invite long debate on all the issues, and many amendments consisting of various combinations of items from the 2 proposals, then we're not helping with the voting system in a timely fashion. >However, isn't informed internal debate about the constitutional questions >desireable? If the developers have two proposals, and can compare and >contrast at least two good approaches, I think it is more likely that they >will get the constitution they are looking for. Sure, but right after they enact the minimal crucial fixes, they could be offered the refinements and more optional & complicated things--and they'd then be in a position to vote among sets of alternatives in an improved way. You're concerned that after voting to enact the simple & brief initial recommendations, they'd be tired of the whole thing and wouldn't want to deal with the refinements, optional reforms, & complicated reforms. But if so, then why would you expect them to not get tired of the whole thing long before they come to any agreement about the big task posed by the 2 proposals? I think that would be more discouraging. Equipped with a new & better voting system, enacted without complicated debates on many issues, people] would be more encouraged to tackle the refinements. But if not, then there seems no reason to expect them to wade through them either way. So let's at least start with a brief, simple, recommendation about the most crucial reforms: Voting system & supermajority rule. And anything else felt to be essential, simple, & uncontroversial. > >Also, Debian could better deal with several competing options of > >varying controversialness after the new voting system is in place. > > > >This is a good point. However, I don't think the developers will have any >interest in considering an 'improved' version of their constitution once >they've already made changes that fix most of the serious problems. Right >now, the rules have enough flaws that there is an impetus to make changes, >and developers will of course want to adopt the best fixes that are >suggested (and what is 'best' is debatable). Once the rules are no longer >broken though, developers will probably take the view that 'yeah, this is >an >improvement, but our current system works', and the 'alternate' proposal >won't even get enough sponsors for consideration. It's an issue of a bird in the hand versus two in the bog. Well I don't claim to know how things are likely to happen at Debian. So let me restate my suggestion: After we've finished the Supermajority vote, and after we have a voting system recommendation (Schulze, SSD, etc), and we've covered the minimal things that Raul would include in the 1st release, then,at that time, let's have Raul, Anthony & Buddha vote between the 2-stage-release vs the 2-proposals. Or rather, let Raul, at that time, make a motion that the 3 developers vote on that issue at that time. That recommendation-mode vote shouldn't add more than a day or 2 of delay. How's that for a compromise? >For now, I suggest we continue working on an alternate, and then when we >have nearly finished our committee's work, we can decide on the best >strategy for what to do with it: Either that, or the 3 developers could decide the reporting-mode after Raul's essential minimal recommendations are ready. Raul could move for a vote among the 3 developers on that question at that time. I urge Raul to make that motion at that time if he favors that approach. In the meantime, we need only proceed with the agenda as previously planned. This seems like the simplest, most easily justified, procedural solution. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Tue Dec 26 21:19:24 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3349 invoked from network); 26 Dec 2000 21:19:24 -0000 Received: from law-f100.hotmail.com (HELO hotmail.com) (209.185.131.163) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 21:19:24 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 26 Dec 2000 13:19:22 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Tue, 26 Dec 2000 21:19:22 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, moth@debian.org Subject: My Supermajority Ballot, due today. Date: Tue, 26 Dec 2000 21:19:22 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Dec 2000 21:19:22.0371 (UTC) FILETIME=[84138530:01C06F81] X-Evolution: 00000055-0010 PRIMARY SUPERMAJORITY PROPOSAL [4] OSSIPOFF [2] BUCK [1] MILLER-1 [7] MILLER-2 [3] PETRY-1 [5] PETRY-2 [6] TOWNS ALTERNATE SUPERMAJORITY PROPOSAL [4] OSSIPOFF [3] BUCK [2] MILLER-1 [7] MILLER-2 [1] PETRY-1 [5] PETRY-2 [6] TOWNS SUPERMAJORITY vs. STRONG MAJORITY The supermajority and strong majority proposals should appear in the primary/alternate proposals as follows: [2] SUPERMAJORITY/SUPERMAJORITY [3] STRONG MAJORITY/STRONG MAJORITY [1] SUPERMAJORITY/STRONG MAJORITY [4] STRONG MAJORITY/SUPERMAJORITY _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Tue Dec 26 21:41:58 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 23786 invoked from network); 26 Dec 2000 21:41:58 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 21:41:58 -0000 Received: (qmail 5396 invoked by uid 1000); 26 Dec 2000 21:41:46 -0000 Date: Tue, 26 Dec 2000 16:41:46 -0500 From: Raul Miller To: Anthony Towns Cc: Norman Petry , Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck Subject: Re: Call for Votes on Supermajority Issue Message-ID: <20001226164146.A4603@usatoday.com> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> <977745166.2c8a877b@debian.org> <20001225234344.B20423@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <20001225234344.B20423@azure.humbug.org.au>; from aj@azure.humbug.org.au on Mon, Dec 25, 2000 at 11:43:44PM +1000 X-Evolution: 00000057-0010 On Mon, Dec 25, 2000 at 11:43:44PM +1000, Anthony Towns wrote: > "subverts intuitive" doesn't strike me as good grammar and don't seem > particularly meaningful even accounting for that. You defined "intuitive" > as what the current system is: none of these "subvert" that, they outright > replace it. I'm going to give this another go. The current debian system has some flaws. The worst flaw, in my opinion, is that to some people it seems to disallow multiple-option "final" ballots. There are also theoretical and presentation flaws. One of these flaws may be expressed as: If there's no condorcet winner, Debian's constitution appears to specify that the default option wins -- and, it has some verbiage about "single transferrable vote" which appears to be almost completely pointless. But (other than the unnecessary verbiage) is this a real flaw? I'm calling this system "intuitive" both because I feel its current properties are the result of an intuitive description of the voting process, and because the system has the following properties: [1] If there's a winner, it's the option which beats all other options. [2] If there's no option which beats [nor ties] all other options, there's no winner, and further discussion is in order. [That further discussion might sway people from their positions, or may result in the synthesis of a new option. I'm asserting that "no winner", with the current constitution, represents a rather unstable state of affairs, and is unlikely to last through very many votes.] In other words, Arrow's theorem doesn't seem to apply to the current debian system, except that introduction of an additional option may require additional discussion and the outcome of that discussion may be a different winner. I think this is intuitive. Now, we've got some proposed mechanisms: OSSIPOFF This mechanism creates a stable state of affairs where there's likely to be "no winner". For the case of a ballot where there's an option with a 3:1 supermajority requirement and an option with no supermajority requirement, there's no winner when the preference for the supermajority option is greater than 50% but less than 75%. I consider this a severe flaw. TOWNS This mechanism requires that the balloting system completely order the options. But, the current system is incapable of doing so. I consider this evidence of a severe flaw. BUCK, MILLER-1, PETRY-1 These options deal with supermajority by saying that supermajority options which don't beat the "solve nothing" option by some percent are not comparable with any other options on the ballot. They share the same flaw: If adding a few votes to option A would make A beat B, adding a comparable number of votes on B's side wouldn't recover B's victory. This strikes me as inconsistent. Buck also bothers me, because it allows "no winner" conditions involving options with only a small fraction of the votes they'd need to win. Petry-1 shares this flaw, to a lesser extent -- it allows for A>>B>>C>>D>>E>>A circular ties, while eliminating A>B>C>D>E>A circular ties. PETRY-2 This option says that "supermajority" doesn't solve any real needs. But that determination appears to be beyond the scope of this group. I consider this a severe flaw. MILLER-2 This option says that "supermajority" options may be made comparable to other options by scaling such votes. Thus, if adding a few votes to A causes A to win over B, adding a comparable number of votes to B would recover B's victory. [Miller-2 option, as stated, may have other effects on a particular system, but that needn't be true for otherwise equivalent phrasings. I've also proposed that we defer voting on supermajority until the other properties of the voting system have been fixed -- in part because of this.] Thanks, -- Raul From moth@debian.org Tue Dec 26 21:47:06 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28035 invoked from network); 26 Dec 2000 21:47:06 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 21:47:06 -0000 Received: (qmail 5490 invoked by uid 1000); 26 Dec 2000 21:46:54 -0000 Date: Tue, 26 Dec 2000 16:46:54 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <977866929.eab10814@debian.org> References: <008401c06f5c$fd944180$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <008401c06f5c$fd944180$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Tue, Dec 26, 2000 at 10:57:54AM -0600 X-Evolution: 00000058-0010 On Tue, Dec 26, 2000 at 10:57:54AM -0600, Norman Petry wrote: > I agree that submitting two proposals simultaneously will result in > internal debate that may delay the adoption of one proposal or the > other. This is a problem if decisions about important internal matters > are held up as a result. I have repeatedly argued though that those > delays are unnecessary -- I see no reason why other matters cannot be > decided under Debian's existing rules. Would you consider those results flawed? > However, isn't informed internal debate about the constitutional questions > desireable? If the developers have two proposals, and can compare and > contrast at least two good approaches, I think it is more likely that they > will get the constitution they are looking for. A single proposal would be > easier to ram through, but might not be the best choice for Debian. If this is to be the case, then what this group needs to produce is not just a list of recommendations, but a corresponding list of reasons why these are good recommendations. I don't see that we're approaching the discussion in that fashion. > For now, I suggest we continue working on an alternate, and then when we > have nearly finished our committee's work, we can decide on the best > strategy for what to do with it: > > a) Discard it > b) Release simultaneously > c) Release later > d) Release it instead of primary proposal I must say, I don't understand why I would want to vote any differently on the alternate ballot than I would on the primary ballot. Then again, I don't see that we're coming up with reasons to go along with the proposals, so I guess I don't really understand on what basis you expect Debian to carry out an informed discussion on these matters. -- Raul From moth@debian.org Tue Dec 26 22:00:56 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4899 invoked from network); 26 Dec 2000 22:00:56 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 22:00:56 -0000 Received: (qmail 5840 invoked by uid 1000); 26 Dec 2000 22:00:44 -0000 Date: Tue, 26 Dec 2000 17:00:44 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Call for Votes on Supermajority Issue Message-ID: <20001226170044.A5618@usatoday.com> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 00000059-0010 I'm abstaining from this vote, on the grounds that I don't know enough about how circular ties will be handled: I feel that the mechanism for supermajority handling should be consistent with the mechanism used to handle circular ties. [On the subject of alternates: I also feel that we should come up with a rationale for our recommendations. I don't think that Debian can engage in an informed discussion without such rationale.] Thanks, -- Raul From bmbuck@14850.com Tue Dec 26 23:19:50 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9088 invoked from network); 26 Dec 2000 23:19:50 -0000 Received: from nsh1-1685c.twcny.rr.com (HELO zaphod) (24.95.168.92) by qmail.accesscomm.ca with SMTP; 26 Dec 2000 23:19:50 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id 4BEA81570B; Tue, 26 Dec 2000 18:19:48 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: "Norman Petry" Cc: "Steve Greenland" , "Rob Lanphier" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" , bmbuck@zaphod.datahold.home Subject: Re: Call for Votes on Supermajority Issue In-Reply-To: Message from "Norman Petry" of "Sat, 23 Dec 2000 09:53:15 CST." <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Dec 2000 18:19:48 -0500 From: Buddha Buck Message-Id: <20001226231948.4BEA81570B@zaphod> X-Evolution: 0000005a-0010 My ballots... > > PRIMARY SUPERMAJORITY PROPOSAL > > [5] OSSIPOFF > [4] BUCK > [1] MILLER-1 > [6] MILLER-2 > [2] PETRY-1 > [7] PETRY-2 > [3] TOWNS > I ranked pre-elimination candidates first, post-elimination candidates second, then the two others. > > ALTERNATE SUPERMAJORITY PROPOSAL > > [3] OSSIPOFF > [2] BUCK > [4] MILLER-1 > [6] MILLER-2 > [5] PETRY-1 > [7] PETRY-2 > [1] TOWNS > I switched the order of pre-elimination/post-elimination candidates en bloc, since I feel that one block is the natural alternative to the other. > > SUPERMAJORITY vs. STRONG MAJORITY > > The supermajority and strong majority proposals should appear in the > primary/alternate proposals as follows: > > [1] SUPERMAJORITY/SUPERMAJORITY > [3] STRONG MAJORITY/STRONG MAJORITY > [2] SUPERMAJORITY/STRONG MAJORITY > [4] STRONG MAJORITY/SUPERMAJORITY > -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From robla@eskimo.com Wed Dec 13 00:25:50 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20649 invoked from network); 13 Dec 2000 00:25:50 -0000 Received: from mx1.eskimo.com (204.122.16.48) by qmail.accesscomm.ca with SMTP; 13 Dec 2000 00:25:50 -0000 Received: from eskimo.com (root@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id QAA27192; Tue, 12 Dec 2000 16:25:05 -0800 Received: from localhost (robla@localhost) by eskimo.com (8.9.1a/8.9.1) with SMTP id QAA09891; Tue, 12 Dec 2000 16:24:47 -0800 (PST) X-Authentication-Warning: eskimo.com: robla owned process doing -bs Date: Tue, 12 Dec 2000 16:24:46 -0800 (PST) From: Rob Lanphier To: Norman Petry cc: "'Anthony Towns'" , "'Buddha Buck'" , "'Mike Ossipoff'" , "'Steve Greenland'" Subject: Re: Debian-EM Constitution Committee -- First Steps In-Reply-To: <000001c06161$081cc8c0$4d01a8c0@archives.gov.sk.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Evolution: 00000062-0010 This looks good, although I'd suggest not getting too concerned about a voting method for a self-selected committee like this. I'd be happy naming Norman the chairman of the committee, and give Norman the latitude of measuring consensus however he sees fit (making unilateral decisions if he thinks it's safe). Since this isn't a permanent committee, and doesn't have any official standing or exclusive control of any shared resources, it's pretty safe. Having been on a lot of spec writing committees in IETF and W3C, this model seems to work fairly well when there's a motivated chair. I've also seen groups that rely on voting too heavily get a bad case of votitus. It may be good to vet rough drafts of the proposed amendment on EM as a balance to having a limited committee. We'll probably get feedback we don't like, but I think it's important to be confident amongst ourselves that we have the right solution by seeing how well it stands up. Rob On Fri, 8 Dec 2000, Norman Petry wrote: > Date: Fri, 8 Dec 2000 15:51:32 -0600 > From: Norman Petry > To: 'Anthony Towns' , > 'Buddha Buck' , > 'Mike Ossipoff' , > 'Norman Petry' , > 'Rob Lanphier' , > 'Steve Greenland' > Subject: Debian-EM Constitution Committee -- First Steps > > Hi, > > I've now received positive feedback from everyone I wrote to initially about > setting up a committee to develop an amendment to fix the problems with > Debian's voting procedure. Therefore, I think we can proceed. Initially, > the committee will consist of: > > Anthony Towns, aj@azure.humbug.org.au > Buddha Buck, bmbuck@14850.com > Mike Ossipoff, nkklrp@hotmail.com > Norman Petry, npetry@accesscomm.ca > Rob Lanphier, robla@eskimo.com > Steve Greenland, stevegr@debian.org > > We can invite other developers and/or EM members to join the committee as > well, although smaller committees are generally more productive, so we > shouldn't try to expand the committee *too* much. One idea would be to send > an invitation to both debian-vote and the EM list asking for volunteers. If > we do this though, I think we should clearly define the goals of the > committee, so people know whether or not to join. For example, I have no > interest in debating the merits of pairwise methods vs. all the other > systems of voting in the universe -- that's what the EM list is for, imho. > We have to assume a certain amount of common ground to have any hope of > jointly drafting an amendment. As I see it, our goals should be to: > > 1) Develop a comprehensive, well thought-out solution to all the problems in > Debian's constitution that are related to voting. This is not intended to > be a quick-fix. It is important that we be systematic and thorough, because > it is difficult to amend the constitution (a 3:1 supermajority is required). > We'll need a really good proposal to interest enough developers to support a > change. For the same reason, it seems better to fix as much as possible at > once, rather than dealing only with the most serious problems. > > 2) Use a pairwise method as the core of the proposed amendment. I think > everyone listed above already understands why this is a good idea, so we > shouldn't need to spend too much time going over the most basic issues. > > I've thought a bit about how we might proceed, and suggest the following > groundrules and procedures for the new committee: > > 1) Every member of the committee should individually review the Debian > constitution, and create a list of all the problems they find -- anything > related to voting that is sub-optimal, confusing, or could be simplified. > If we all do this, it is unlikely we'll miss anything when we combine our > results. We all need to be familiar with the existing constitution anyway > if we are going to sensibly discuss changes to it. > > 2) We can collate these lists in about a week's time, to create an agenda of > issues that need to be discussed by the committee. If it's a long list, and > we may not have time to deal with every issue, we can prioritise the issues > on the agenda (I've now got an implementation of the 'Ranked STV' method > that > Mike and I developed a while ago, which is ideal for ordering agendas. It > might be fun to try it out on this). > > 3) Once we have the agenda of issues, we can go through it, one item at a > time, and devise the best possible solution and suitable constitutional > wording. By dealing with issues one at a time, we should be able to keep > the discussion manageable and focused, and arrive at quick decisions. This > might not always work (some issues are unavoidably interrelated), but as a > general approach it should be ok. > > 4) Since we are unlikely to achieve consensus on every issue, I suggest that > we use a pairwise voting method to decide the questions that arise. Because > of the high probability of pairties within a small group, I think we should > use a Schwartz-set based method, like SSD or Schulze to decide any > contentious issues. > > 5) The Debian developers on the committee must of course be satisfied with > the final proposal, since they will need to justify it to other members of > Debian. Therefore, I think it would be appropriate for a majority of the > Debian developers on the committee to be able to veto any proposal they > disagree with. I think it's still a good idea to vote sometimes to see what > the preferred compromise of the entire group is, but ultimately, the role of > non-developers can only be advisory. If the developers on the _committee_ > are only lukewarm about the results, there's really no chance of getting > Debian as a whole to adopt it anyway. > > 6) Following a suggestion from Anthony, we should maintain an archive of all > the committee discussion, and supply it to Debian along with our finished > proposal. That way, anyone interested in the detailed arguments that led to > the final proposal will be able to find them. > > That's all I can think of at the moment. If you think of any improvements > or changes in how we should organise ourselves, be sure to share it with > everyone. From now on, we should be sure to send copies of all > correspondence to every member of the committee. You'll probably want to > create a distribution list to make this easy. > > I'll start reviewing the Constitution tomorrow, and will circulate my list > of problems on or before December 16th, unless we decide to proceed in some > other way before then. > > -- > Norm Petry > Rob Lanphier robla@eskimo.com http://www.eskimo.com/~robla From npetry@accesscomm.ca Thu Jan 4 21:21:35 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 23509 invoked from network); 4 Jan 2001 21:21:35 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 4 Jan 2001 21:21:35 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010104212132.BIDA21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 13:21:32 -0800 Message-ID: <009a01c07693$d8e61000$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Back Again... Date: Thu, 4 Jan 2001 13:18:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 00000063-0010 Hi Everyone, I'm sorry I've been unable to participate in recent discussions of the committee -- I've been away on vacation, and didn't have e-mail access as I had expected. I should be able to keep up with things now. Anyway, I've tabulated the results from the supermajority vote, and I will send these out in 3 separate e-mails following this message. I realise that Raul has some concerns about deciding this issue without first discussing the pairwise voting method. Therefore, I suggest that we proceed now with discussion of the second item on our agenda (RESOLVE CIRCULAR TIE PROBLEM), and when we are ready to vote on that issue, I will *also* redistribute ballots for the supermajority question. Those final ballots will decide what supermajority rule we will be recommending. Another advantage of doing it that way is that hopefully we will have better participation in the final decision than we did in the preliminary voting -- only 3 ballots were submitted, and if the issue is controversial, I would prefer to have more members of the committee expressing an opinion before we make the final decision. Please present any arguments you have in support of particular supermajority rules along with the discussion of pairwise voting methods that will commence now. As part of the discussion of pairwise voting rules, I would like to distribute some graphs and data I have derived from simulations of the various voting methods we will be discussing. Right now, I have these in the form of Excel spreadsheets. If everyone has Excel, I would like to circulate this information to the committee in this format, to save time. However, I realise that not everyone may have Excel or a compatible spreadsheet (does Gnumeric support excel graphs yet?), so please let me know if you don't have a way of reading this format. I can probably just supply the raw data as text, and the graphs as .jpg images, if necessary. -- Norm Petry From npetry@accesscomm.ca Thu Jan 4 21:33:47 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20716 invoked from network); 4 Jan 2001 21:33:47 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 4 Jan 2001 21:33:47 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010104213345.BKSU21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 13:33:45 -0800 Message-ID: <00c101c07695$8db92660$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Vote #1 Results - Agenda Poll Date: Thu, 4 Jan 2001 13:30:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 00000064-0010 I've written a routine to print and tabulate the ballots and the results from the votes our committee will be conducting as we develop our proposal. This should allow me to get our decisions to you more quickly. For the sake of completeness, I decided to distribute the results from our agenda poll in this new format. For this particular vote, the Tideman Social Ranking was the result we were interested in. However, if you're curious, you'll also find the Smith Set, Schwartz Set, and Schulze winner results shown below. -- Norman Petry ***** AGENDA BALLOT Ballots: Norman Petry: RESOLVE SUPERMAJORITY PROBLEMS > RESOLVE CIRCULAR TIE PROBLEM > SIMPLIFY AND IMPROVE TIEBREAKER > CONSIDER FINAL TIEBREAKER > DISCUSS QUORUM REQUIREMENTS > EXPLICITLY ALLOW EQUAL RANKINGS > STATE INTERPRETATION OF TRUNCATED BALLOTS > CHOOSE NAME OF NEW VOTING METHOD > CREATE GLOSSARY OF VOTING TERMS > ELIMINATE TWO-STAGE VOTING > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > REQUIRE SIMULTANEOUS DECISIONS > CLARIFY REPORTING REQUIREMENTS > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > 3:1 SUPERMAJORITY EXCESSIVELY HIGH > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY Raul Miller: ELIMINATE TWO-STAGE VOTING > REQUIRE SIMULTANEOUS DECISIONS > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > STATE INTERPRETATION OF TRUNCATED BALLOTS > CLARIFY REPORTING REQUIREMENTS > RESOLVE CIRCULAR TIE PROBLEM > SIMPLIFY AND IMPROVE TIEBREAKER > CONSIDER FINAL TIEBREAKER > RESOLVE SUPERMAJORITY PROBLEMS > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > CHOOSE NAME OF NEW VOTING METHOD > CREATE GLOSSARY OF VOTING TERMS > EXPLICITLY ALLOW EQUAL RANKINGS > PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY > DISCUSS QUORUM REQUIREMENTS > 3:1 SUPERMAJORITY EXCESSIVELY HIGH Mike Ossipoff: RESOLVE CIRCULAR TIE PROBLEM > SIMPLIFY AND IMPROVE TIEBREAKER > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > REQUIRE SIMULTANEOUS DECISIONS > RESOLVE SUPERMAJORITY PROBLEMS > STATE INTERPRETATION OF TRUNCATED BALLOTS > EXPLICITLY ALLOW EQUAL RANKINGS > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > ELIMINATE TWO-STAGE VOTING > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > CLARIFY REPORTING REQUIREMENTS > 3:1 SUPERMAJORITY EXCESSIVELY HIGH > PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY > CHOOSE NAME OF NEW VOTING METHOD > CREATE GLOSSARY OF VOTING TERMS > CONSIDER FINAL TIEBREAKER > DISCUSS QUORUM REQUIREMENTS Buddha Buck: PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY > RESOLVE SUPERMAJORITY PROBLEMS > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > RESOLVE CIRCULAR TIE PROBLEM > DISCUSS QUORUM REQUIREMENTS > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > ELIMINATE TWO-STAGE VOTING > CLARIFY REPORTING REQUIREMENTS > CREATE GLOSSARY OF VOTING TERMS > SIMPLIFY AND IMPROVE TIEBREAKER > CONSIDER FINAL TIEBREAKER > EXPLICITLY ALLOW EQUAL RANKINGS > STATE INTERPRETATION OF TRUNCATED BALLOTS > REQUIRE SIMULTANEOUS DECISIONS > CHOOSE NAME OF NEW VOTING METHOD > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > 3:1 SUPERMAJORITY EXCESSIVELY HIGH Anthony Towns: ELIMINATE TWO-STAGE VOTING > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > REQUIRE SIMULTANEOUS DECISIONS > RESOLVE SUPERMAJORITY PROBLEMS > RESOLVE CIRCULAR TIE PROBLEM > SIMPLIFY AND IMPROVE TIEBREAKER > DISCUSS QUORUM REQUIREMENTS > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > 3:1 SUPERMAJORITY EXCESSIVELY HIGH > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > CONSIDER FINAL TIEBREAKER > PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY > EXPLICITLY ALLOW EQUAL RANKINGS > STATE INTERPRETATION OF TRUNCATED BALLOTS > CLARIFY REPORTING REQUIREMENTS > CHOOSE NAME OF NEW VOTING METHOD > CREATE GLOSSARY OF VOTING TERMS Tiebreaker: RESOLVE SUPERMAJORITY PROBLEMS > RESOLVE CIRCULAR TIE PROBLEM > SIMPLIFY AND IMPROVE TIEBREAKER > CONSIDER FINAL TIEBREAKER > DISCUSS QUORUM REQUIREMENTS > EXPLICITLY ALLOW EQUAL RANKINGS > STATE INTERPRETATION OF TRUNCATED BALLOTS > CHOOSE NAME OF NEW VOTING METHOD > CREATE GLOSSARY OF VOTING TERMS > ELIMINATE TWO-STAGE VOTING > TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS > REQUIRE SIMULTANEOUS DECISIONS > CLARIFY REPORTING REQUIREMENTS > SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY > 3:1 SUPERMAJORITY EXCESSIVELY HIGH > ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY > PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY Pairwise Comparisons: Option RESOLVE SUPERMAJORITY PROBLEMS: beats option RESOLVE CIRCULAR TIE PROBLEM [3 - 2] beats option ELIMINATE TWO-STAGE VOTING [3 - 2] loses to option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [2 - 3] beats option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 2] loses to option REQUIRE SIMULTANEOUS DECISIONS [2 - 3] beats option CONSIDER FINAL TIEBREAKER [4 - 1] beats option DISCUSS QUORUM REQUIREMENTS [5 - 0] beats option EXPLICITLY ALLOW EQUAL RANKINGS [5 - 0] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [4 - 1] beats option CLARIFY REPORTING REQUIREMENTS [4 - 1] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [5 - 0] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [5 - 0] beats option CHOOSE NAME OF NEW VOTING METHOD [5 - 0] beats option CREATE GLOSSARY OF VOTING TERMS [5 - 0] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option RESOLVE CIRCULAR TIE PROBLEM: beats option ELIMINATE TWO-STAGE VOTING [3 - 2] loses to option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [2 - 3] beats option SIMPLIFY AND IMPROVE TIEBREAKER [5 - 0] beats option REQUIRE SIMULTANEOUS DECISIONS [3 - 2] beats option CONSIDER FINAL TIEBREAKER [5 - 0] beats option DISCUSS QUORUM REQUIREMENTS [5 - 0] beats option EXPLICITLY ALLOW EQUAL RANKINGS [5 - 0] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [4 - 1] beats option CLARIFY REPORTING REQUIREMENTS [4 - 1] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [5 - 0] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [5 - 0] beats option CHOOSE NAME OF NEW VOTING METHOD [5 - 0] beats option CREATE GLOSSARY OF VOTING TERMS [5 - 0] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option ELIMINATE TWO-STAGE VOTING: beats option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 2] beats option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 2] beats option REQUIRE SIMULTANEOUS DECISIONS [4 - 1] beats option CONSIDER FINAL TIEBREAKER [4 - 1] beats option DISCUSS QUORUM REQUIREMENTS [3 - 2] beats option EXPLICITLY ALLOW EQUAL RANKINGS [3 - 2] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [3 - 2] beats option CLARIFY REPORTING REQUIREMENTS [5 - 0] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [4 - 1] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [4 - 1] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS: beats option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 2] beats option REQUIRE SIMULTANEOUS DECISIONS [4 - 1] beats option CONSIDER FINAL TIEBREAKER [4 - 1] beats option DISCUSS QUORUM REQUIREMENTS [4 - 1] beats option EXPLICITLY ALLOW EQUAL RANKINGS [4 - 1] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [4 - 1] beats option CLARIFY REPORTING REQUIREMENTS [5 - 0] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [5 - 0] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [5 - 0] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option SIMPLIFY AND IMPROVE TIEBREAKER: beats option REQUIRE SIMULTANEOUS DECISIONS [3 - 2] beats option CONSIDER FINAL TIEBREAKER [5 - 0] beats option DISCUSS QUORUM REQUIREMENTS [4 - 1] beats option EXPLICITLY ALLOW EQUAL RANKINGS [5 - 0] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [4 - 1] beats option CLARIFY REPORTING REQUIREMENTS [3 - 2] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [5 - 0] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [4 - 1] beats option CHOOSE NAME OF NEW VOTING METHOD [5 - 0] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option REQUIRE SIMULTANEOUS DECISIONS: beats option CONSIDER FINAL TIEBREAKER [3 - 2] beats option DISCUSS QUORUM REQUIREMENTS [3 - 2] beats option EXPLICITLY ALLOW EQUAL RANKINGS [3 - 2] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [3 - 2] beats option CLARIFY REPORTING REQUIREMENTS [4 - 1] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [5 - 0] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [4 - 1] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [3 - 2] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [5 - 0] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option CONSIDER FINAL TIEBREAKER: beats option DISCUSS QUORUM REQUIREMENTS [3 - 2] beats option EXPLICITLY ALLOW EQUAL RANKINGS [4 - 1] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [3 - 2] loses to option CLARIFY REPORTING REQUIREMENTS [2 - 3] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [3 - 2] loses to option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [2 - 3] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [3 - 2] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [3 - 2] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [3 - 2] Option DISCUSS QUORUM REQUIREMENTS: beats option EXPLICITLY ALLOW EQUAL RANKINGS [3 - 2] beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [3 - 2] beats option CLARIFY REPORTING REQUIREMENTS [3 - 2] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [3 - 2] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [3 - 2] beats option CHOOSE NAME OF NEW VOTING METHOD [3 - 2] beats option CREATE GLOSSARY OF VOTING TERMS [3 - 2] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] loses to option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [2 - 3] Option EXPLICITLY ALLOW EQUAL RANKINGS: beats option STATE INTERPRETATION OF TRUNCATED BALLOTS [3 - 2] beats option CLARIFY REPORTING REQUIREMENTS [3 - 2] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [3 - 2] loses to option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [2 - 3] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [3 - 2] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [3 - 2] Option STATE INTERPRETATION OF TRUNCATED BALLOTS: beats option CLARIFY REPORTING REQUIREMENTS [4 - 1] beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [4 - 1] beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [3 - 2] beats option CHOOSE NAME OF NEW VOTING METHOD [5 - 0] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [3 - 2] Option CLARIFY REPORTING REQUIREMENTS: beats option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY [3 - 2] loses to option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [2 - 3] beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [3 - 2] Option SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY: beats option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY [3 - 2] beats option CHOOSE NAME OF NEW VOTING METHOD [3 - 2] beats option CREATE GLOSSARY OF VOTING TERMS [3 - 2] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY: beats option CHOOSE NAME OF NEW VOTING METHOD [4 - 1] beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [4 - 1] beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [4 - 1] Option CHOOSE NAME OF NEW VOTING METHOD: beats option CREATE GLOSSARY OF VOTING TERMS [4 - 1] beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [3 - 2] loses to option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [2 - 3] Option CREATE GLOSSARY OF VOTING TERMS: beats option 3:1 SUPERMAJORITY EXCESSIVELY HIGH [3 - 2] loses to option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [2 - 3] Option 3:1 SUPERMAJORITY EXCESSIVELY HIGH: beats option PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY [3 - 2] Social Ranking (Tideman): 1. RESOLVE SUPERMAJORITY PROBLEMS 2. RESOLVE CIRCULAR TIE PROBLEM 3. ELIMINATE TWO-STAGE VOTING 4. TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS 5. SIMPLIFY AND IMPROVE TIEBREAKER 6. REQUIRE SIMULTANEOUS DECISIONS 7. CONSIDER FINAL TIEBREAKER 8. DISCUSS QUORUM REQUIREMENTS 9. EXPLICITLY ALLOW EQUAL RANKINGS 10. STATE INTERPRETATION OF TRUNCATED BALLOTS 11. CLARIFY REPORTING REQUIREMENTS 12. SIMPLE MAJORITIES SHOULD RESOLVE CONSTITUTIONAL AMBIGUITY 13. ELIMINATE PREMATURE TERMINATION OF VOTING BY SECRETARY 14. CHOOSE NAME OF NEW VOTING METHOD 15. CREATE GLOSSARY OF VOTING TERMS 16. 3:1 SUPERMAJORITY EXCESSIVELY HIGH 17. PREVENT EXPIRY OF MOTIONS DUE TO INACTION BY SECRETARY The Smith Set is: {ELIMINATE TWO-STAGE VOTING, TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS, REQUIRE SIMULTANEOUS DECISIONS, RESOLVE CIRCULAR TIE PROBLEM, SIMPLIFY AND IMPROVE TIEBREAKER, RESOLVE SUPERMAJORITY PROBLEMS}. The Schwartz Set is the same as the Smith Set. Beatpath Comparisons - Stage 1: Option RESOLVE SUPERMAJORITY PROBLEMS: beatpath ties option RESOLVE CIRCULAR TIE PROBLEM [3 - 3] beatpath ties option ELIMINATE TWO-STAGE VOTING [3 - 3] beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] beatpath ties option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 3] beatpath ties option REQUIRE SIMULTANEOUS DECISIONS [3 - 3] Option RESOLVE CIRCULAR TIE PROBLEM: beatpath ties option ELIMINATE TWO-STAGE VOTING [3 - 3] beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] defeats option SIMPLIFY AND IMPROVE TIEBREAKER [5 - 3] beatpath ties option REQUIRE SIMULTANEOUS DECISIONS [3 - 3] Option ELIMINATE TWO-STAGE VOTING: beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] beatpath ties option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 3] defeats option REQUIRE SIMULTANEOUS DECISIONS [4 - 3] Option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS: beatpath ties option SIMPLIFY AND IMPROVE TIEBREAKER [3 - 3] defeats option REQUIRE SIMULTANEOUS DECISIONS [4 - 3] Option SIMPLIFY AND IMPROVE TIEBREAKER: beatpath ties option REQUIRE SIMULTANEOUS DECISIONS [3 - 3] The Stage 1 Schulze Winners are: {RESOLVE SUPERMAJORITY PROBLEMS, RESOLVE CIRCULAR TIE PROBLEM, ELIMINATE TWO-STAGE VOTING, TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS}. Beatpath Comparisons - Stage 2: Option RESOLVE SUPERMAJORITY PROBLEMS: beatpath ties option RESOLVE CIRCULAR TIE PROBLEM [3 - 3] beatpath ties option ELIMINATE TWO-STAGE VOTING [3 - 3] beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] Option RESOLVE CIRCULAR TIE PROBLEM: beatpath ties option ELIMINATE TWO-STAGE VOTING [3 - 3] beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] Option ELIMINATE TWO-STAGE VOTING: beatpath ties option TREAT ALL AMENDMENTS AS INDEPENDENT PROPOSALS [3 - 3] The Stage 2 Schulze Winners are the same as the winners from Stage 1. The tiebreak winner is RESOLVE SUPERMAJORITY PROBLEMS. The Schulze Winner is RESOLVE SUPERMAJORITY PROBLEMS. From npetry@accesscomm.ca Thu Jan 4 21:38:35 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 32237 invoked from network); 4 Jan 2001 21:38:35 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 4 Jan 2001 21:38:35 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010104213832.BLYC21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 13:38:32 -0800 Message-ID: <00c701c07696$3923e6c0$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Vote #2 Results - Primary Supermajority Proposal (preliminary) Date: Thu, 4 Jan 2001 13:35:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 00000065-0010 Here's the preliminary results for our main supermajority proposal. Right now, the preferred option is Miller-1, but we will be reballotting on this question once the circular tie problem has been resolved. -- Norm Petry ***** PRIMARY SUPERMAJORITY PROPOSAL Ballots: Norman Petry: PETRY-1 > MILLER-1 > BUCK > OSSIPOFF > PETRY-2 > TOWNS > MILLER-2 Mike Ossipoff: MILLER-1 > BUCK > PETRY-1 > OSSIPOFF > PETRY-2 > TOWNS > MILLER-2 Buddha Buck: MILLER-1 > PETRY-1 > TOWNS > BUCK > OSSIPOFF > MILLER-2 > PETRY-2 Tiebreaker: PETRY-1 > MILLER-1 > BUCK > OSSIPOFF > PETRY-2 > TOWNS > MILLER-2 Pairwise Comparisons: Option MILLER-1: beats option PETRY-1 [2 - 1] beats option BUCK [3 - 0] beats option OSSIPOFF [3 - 0] beats option PETRY-2 [3 - 0] beats option TOWNS [3 - 0] beats option MILLER-2 [3 - 0] Option PETRY-1: beats option BUCK [2 - 1] beats option OSSIPOFF [3 - 0] beats option PETRY-2 [3 - 0] beats option TOWNS [3 - 0] beats option MILLER-2 [3 - 0] Option BUCK: beats option OSSIPOFF [3 - 0] beats option PETRY-2 [3 - 0] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option OSSIPOFF: beats option PETRY-2 [3 - 0] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option PETRY-2: beats option TOWNS [2 - 1] beats option MILLER-2 [2 - 1] Option TOWNS: beats option MILLER-2 [3 - 0] Social Ranking (Tideman): 1. MILLER-1 2. PETRY-1 3. BUCK 4. OSSIPOFF 5. PETRY-2 6. TOWNS 7. MILLER-2 The Condorcet Winner is MILLER-1. From npetry@accesscomm.ca Thu Jan 4 21:42:58 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11288 invoked from network); 4 Jan 2001 21:42:58 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 4 Jan 2001 21:42:58 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010104214256.BMOK21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 13:42:56 -0800 Message-ID: <00cd01c07696$d62fc240$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Vote #3 Results - Alternate Supermajority Proposal (preliminary) Date: Thu, 4 Jan 2001 13:39:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 00000066-0010 The preferred supermajority rule for our alternate proposal (should we choose to offer one) was Petry-1. As before, this result is only tentative. -- Norm Petry ***** ALTERNATE SUPERMAJORITY PROPOSAL Ballots: Norman Petry: PETRY-1 > PETRY-2 > MILLER-1 > BUCK > OSSIPOFF > TOWNS > MILLER-2 Mike Ossipoff: PETRY-1 > MILLER-1 > BUCK > OSSIPOFF > PETRY-2 > TOWNS > MILLER-2 Buddha Buck: TOWNS > BUCK > OSSIPOFF > MILLER-1 > PETRY-1 > MILLER-2 > PETRY-2 Tiebreaker: PETRY-1 > PETRY-2 > MILLER-1 > BUCK > OSSIPOFF > TOWNS > MILLER-2 Pairwise Comparisons: Option PETRY-1: beats option MILLER-1 [2 - 1] beats option BUCK [2 - 1] beats option OSSIPOFF [2 - 1] beats option PETRY-2 [3 - 0] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option MILLER-1: beats option BUCK [2 - 1] beats option OSSIPOFF [2 - 1] beats option PETRY-2 [2 - 1] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option BUCK: beats option OSSIPOFF [3 - 0] beats option PETRY-2 [2 - 1] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option OSSIPOFF: beats option PETRY-2 [2 - 1] beats option TOWNS [2 - 1] beats option MILLER-2 [3 - 0] Option PETRY-2: beats option TOWNS [2 - 1] beats option MILLER-2 [2 - 1] Option TOWNS: beats option MILLER-2 [3 - 0] Social Ranking (Tideman): 1. PETRY-1 2. MILLER-1 3. BUCK 4. OSSIPOFF 5. PETRY-2 6. TOWNS 7. MILLER-2 The Condorcet Winner is PETRY-1. From npetry@accesscomm.ca Thu Jan 4 21:48:20 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25863 invoked from network); 4 Jan 2001 21:48:20 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 4 Jan 2001 21:48:20 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010104214818.BNJV21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 13:48:18 -0800 Message-ID: <00d701c07697$963a0d20$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Vote #4 Results - Supermajority vs. Strong Majority (preliminary) Date: Thu, 4 Jan 2001 13:44:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 00000067-0010 The provisional result from vote#4 suggests that we should continue to use the concept of pairwise relative Supermajority that is found in the existing constitution, and suggest the use of Strong Majority as part of an alternate proposal, should we choose to offer one (no surprises here). N. ***** SUPERMAJORITY vs. STRONG MAJORITY Ballots: Norman Petry: STRONG MAJORITY/STRONG MAJORITY > SUPERMAJORITY/STRONG MAJORITY > SUPERMAJORITY/SUPERMAJORITY > STRONG MAJORITY/SUPERMAJORITY Mike Ossipoff: SUPERMAJORITY/STRONG MAJORITY > SUPERMAJORITY/SUPERMAJORITY > STRONG MAJORITY/STRONG MAJORITY > STRONG MAJORITY/SUPERMAJORITY Buddha Buck: SUPERMAJORITY/SUPERMAJORITY > SUPERMAJORITY/STRONG MAJORITY > STRONG MAJORITY/STRONG MAJORITY > STRONG MAJORITY/SUPERMAJORITY Tiebreaker: STRONG MAJORITY/STRONG MAJORITY > SUPERMAJORITY/STRONG MAJORITY > SUPERMAJORITY/SUPERMAJORITY > STRONG MAJORITY/SUPERMAJORITY Pairwise Comparisons: Option SUPERMAJORITY/STRONG MAJORITY: beats option SUPERMAJORITY/SUPERMAJORITY [2 - 1] beats option STRONG MAJORITY/STRONG MAJORITY [2 - 1] beats option STRONG MAJORITY/SUPERMAJORITY [3 - 0] Option SUPERMAJORITY/SUPERMAJORITY: beats option STRONG MAJORITY/STRONG MAJORITY [2 - 1] beats option STRONG MAJORITY/SUPERMAJORITY [3 - 0] Option STRONG MAJORITY/STRONG MAJORITY: beats option STRONG MAJORITY/SUPERMAJORITY [3 - 0] Social Ranking (Tideman): 1. SUPERMAJORITY/STRONG MAJORITY 2. SUPERMAJORITY/SUPERMAJORITY 3. STRONG MAJORITY/STRONG MAJORITY 4. STRONG MAJORITY/SUPERMAJORITY The Condorcet Winner is SUPERMAJORITY/STRONG MAJORITY. From nkklrp@hotmail.com Fri Jan 5 01:49:41 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 10284 invoked from network); 5 Jan 2001 01:49:41 -0000 Received: from law-f50.hotmail.com (HELO hotmail.com) (209.185.131.113) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 01:49:41 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 4 Jan 2001 17:49:39 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 05 Jan 2001 01:49:38 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org, moth@debian.org Cc: nkklrp@hotmail.com Subject: Count rule, opening arguments Date: Fri, 05 Jan 2001 01:49:38 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jan 2001 01:49:39.0307 (UTC) FILETIME=[C3D753B0:01C076B9] X-Evolution: 00000069-0010 At the end of this message, I'll define the methods that I'm talking about. As I understand it, Schulze's method and several Condorcet versions are the methods that have been suggested so far for our count rule recommendation to Debian. There of course may be other proposals, and , if so, at that time it becomes important to compare them to the EM proposals. But, in the meantime, it seems more important to compare the EM proposals to eachother. I won't deny that, in terms of pure merit, Schulze's method is probably the best. In addition to the important properties shared by Schulze, Tideman, & SSD, Schulze never fails the Clone Criterion and always chooses from the Schwartz set. SSD can, under some conditions where the failure probably isn't important, fail the Clone Criterion. Tideman can choose outside the Schwartz set, but not when there are no pairwise ties or exactly equal defeats. The fact that Plurality meets the Clone Criterion seems to take away some of the meaning of passing it. Schulze's method is probably somewhat more convenient when it returns a tie, as compared to SSD & Tideman. But pure merit isn't everything. SSD & Tideman have natural & obvious motivation & justification. Schulze doesn't have that. Its rule sounds arbitrary. That may mean that it won't go over well with Debian. Additionally, the merit differences that we're talking about between those 3 methods are slight. Especially unless Norm shows a Clone Criterion failure by SSD that actually looks bad and fairly likely. So then, because Schulze & SSD are really practically just as good, maybe it's worthwhile to compare them by a different consideration: The larger social value of the precedent that Debian sets by adopting a better voting system. Adoption of a better voting system by a large & well-known international organization like Debian could have an important precedent effect for adoption of that method for public elections. That would benefit all of us, and so it's worth considering. As I said, SSD & Tideman have a natural & obvious motivation & justification that Schulze doesn't have. So, since these methods are essentially equal in merit, especially Schulze & SSD, I suggest that SSD would be a better recommendation than Schulze. Because of its better acceptability both to Debian and to the public, who could benefit tremendously from the voting system precedent that Debian could set. There are a few simpler Condorcet versions that I haven't mentioned yet, but in this message I just wanted to state why I consider SSD a better recommendation than Schulze. Later I'll compare the other Condorcet versions to SSD. Definitions: SSD: 1. An unbeaten set is a set of alternatives none of whom are beaten by anything outside the set. 2. An innermost unbeaten set is an unbeaten set that doesn't contain a smaller unbeaten set. 3. The Schwartz set is the set of alternatives that are in innermost unbeaten sets. 4. Drop the weakest defeat that's among members of the current Schwartz set. The current Schwartz set is the Schwartz set based only on undropped defeats. Repeat till there's an unbeaten alternative. It wins. (A beats B if more people rank A over B than vice-versa. The strength of B's defeat by A is measured by how many people rank A over B). [end of definition] SSD is an interpretation of one of Condorcet's proposals for solving circular ties. There's a simpler & more literal interpretation of Condorcet's words, but some have suggested that SSD is likely what Condorcet would have actually done. Condorcet's definitions weren't as precise as we'd have liked them to be. Schulze's method: 1. X has a beatpath to Y if either X beats Y, or if X beats something that has a beatpath to Y. 2. A sequence of defeats that, by themselves, would be enough to make it possible to say that X has a beatpath to Y, is called a beatpath that X has to Y. (#2 merely defines the noun "beatpath" in terms of the verb phrase "to have a beatpth to...") 3. The strength of a beatpath is measured by the strength of its weakest defeat. 4. If X has a stronger beatpath to Y than Y has to X, then X has a beatpath win over Y. 5. The alternative that has a beatpath win over each one of the others wins. [end of definition] It's been shown that, unless there are pairwise ties or exactly equal defeats, there will always be an altenative that has a beatpath win over each one of the other alternatives. SSD & Schulze give the same result when there are no pairwise ties or exactly equal defeats. In other words, when Schulze has a winner by the above rule, that winner is also the SSD winner. I don't know if it's necessary to define Tideman, since Norm & I agree that SSD is better, especially where the number of voters is small enough that Tideman could choose outside the Schwartz set. I'll define Tideman in a subsequent message, but I don't think anyone will be actually proposing it for the recommendation. I propose SSD for the recommendation, though I'll later be stating the case for some simpler Condorcet versions. Criteria met by SSD are described at the website: http://www.electionmethods.org under the Technical Evaluation menu heading. In the criteria compliance table that begins that article, "Condorcet" refers to SSD & Tideman. But Schulze shares those same criteria compliances with SSD & Tideman. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Fri Jan 5 02:32:21 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26259 invoked from network); 5 Jan 2001 02:32:21 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 02:32:21 -0000 Received: (qmail 31516 invoked by uid 1000); 5 Jan 2001 02:32:06 -0000 Date: Thu, 4 Jan 2001 21:32:06 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Message-ID: <978661570.82435e89@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Jan 05, 2001 at 01:49:38AM -0000 X-Evolution: 0000006a-0010 I think it's important to consider how each of these mechanisms handle a circular tie which also involves an exact tie. Thanks, -- Raul From npetry@accesscomm.ca Fri Jan 5 03:38:59 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8917 invoked from network); 5 Jan 2001 03:38:59 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 03:38:59 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010105033856.EAVN21777.mail2.rdc2.bc.home.com@rhiannon>; Thu, 4 Jan 2001 19:38:56 -0800 Message-ID: <007301c076c8$91cad5e0$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" References: Subject: Independence of Clones Criterion - Definitions Date: Thu, 4 Jan 2001 19:35:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 0000006b-0010 In Mike's opening arguments, he makes reference to the "Independence of Clones Criterion" (ICC), which is one of the criteria we use to evaluate voting methods on EM. For the benefit of the Debian folks on the committee, I thought I'd share a couple of definitions of this criterion that have been suggested, so you don't need to wade through the EM archives to know what this refers to. I'll follow this up with a subsequent e-mail giving some explanation of why satisfying this criterion might be considered important to Debian's voters. The first of these definitions is the one that Niklaus Tideman uses: Tideman's Independence of Clones Criterion: ""A proper subset of two or more candidates, S, is a set of clones if no voter ranks any candidate outside of S as either tied with any element of S or between any two elements of S." -- Tideman, "Independence of Clones", p. 186. Markus Schulze proposed a slightly different version of the clone criterion, which allows voters to rank two or more clone sets equally (or leave them unranked). This is a bit more general than the definition Tideman uses: Schulze's Independence of Clones Criterion: Definition ("clones"): A[1],...,A[m] are a set of m clones if & only if for each pair (A[i],A[j]) of two candidates of the set of m clones, for each voter V, and for each candidate C outside the set of m clones the following statements are valid: V prefers A[i] to C, if & only if V prefers A[j] to C. V prefers C to A[i], if & only if V prefers C to A[j]. Definition ("Generalized Independence of Clones Criterion"): A voting method meets the "Generalized Independence of Clones Criterion" if & only if additional clones cannot change the result of the elections. [If one clone is elected instead of another clone of the same set of clones, then this is not regarded as a change of the result.] ***** Note that both versions of this criterion are defined in terms of preferences/rankings, so ICC is really only applicable as a means of distinguishing between rank count methods where all the voter's preferences may be expressed. Tideman assumes that voters supply full rankings, so his version is less general than Schulze's, but in practice I have found that the methods which satisfy one version of this criterion will also satisfy the other. Therefore the distinction between the two definitions is not particularly important for the purposes of comparing the methods that we will probably be discussing. N. From moth@debian.org Fri Jan 5 04:53:13 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14031 invoked from network); 5 Jan 2001 04:53:13 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 04:53:13 -0000 Received: (qmail 350 invoked by uid 1000); 5 Jan 2001 04:52:58 -0000 Date: Thu, 4 Jan 2001 23:52:58 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Message-ID: <20010104235258.A32416@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Jan 05, 2001 at 01:49:38AM -0000 X-Evolution: 0000006c-0010 On Fri, Jan 05, 2001 at 01:49:38AM -0000, MIKE OSSIPOFF wrote: > But pure merit isn't everything. SSD & Tideman have natural & obvious > motivation & justification. Schulze doesn't have that. Its rule sounds > arbitrary. That may mean that it won't go over well with Debian. Maybe this is just displaying my lack of refined taste, but I don't see why Schulze is thought to "sound arbitrary". If I were to pick one of the three which sounds most arbitrary, I'd pick Tideman. Tideman is definitely a tie breaker, but it seems to toss some of the more significant preferences which are causing the circular tie. Schulze and SSD make an effort to toss the least significant information, though they have different mechanisms for determining what's least significant: SSD ignores the mechanics of the circular tie when picking the least significant. Schulze is sensitive to the mechanics of the circular tie when picking the least significant. Of the three, my impression is that Schulze sounds the least arbitrary. Thanks, -- Raul From aj@azure.humbug.org.au Fri Jan 5 09:06:17 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4489 invoked from network); 5 Jan 2001 09:06:17 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 09:06:17 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14ESp1-0006yO-00; Fri, 05 Jan 2001 19:06:03 +1000 Date: Fri, 5 Jan 2001 19:06:03 +1000 From: Anthony Towns To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Message-ID: <20010105190602.B23857@azure.humbug.org.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Jan 05, 2001 at 01:49:38AM -0000 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000006d-0010 On Fri, Jan 05, 2001 at 01:49:38AM -0000, MIKE OSSIPOFF wrote: > The fact that Plurality meets the Clone Criterion seems to take away > some of the meaning of passing it. Huh? Plurality is the same as first-past-the-post, isn't it? In which case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, 30 votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't independent from clones. Have I missed something? Cheers, aj -- Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 From moth@debian.org Fri Jan 5 18:34:26 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 12398 invoked from network); 5 Jan 2001 18:34:26 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 18:34:26 -0000 Received: (qmail 24242 invoked by uid 1000); 5 Jan 2001 18:34:12 -0000 Date: Fri, 5 Jan 2001 13:34:12 -0500 From: Raul Miller To: Anthony Towns Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org Subject: Re: Count rule, opening arguments Message-ID: <978718269.734d317c@debian.org> References: <20010105190602.B23857@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010105190602.B23857@azure.humbug.org.au>; from aj@azure.humbug.org.au on Fri, Jan 05, 2001 at 07:06:03PM +1000 X-Evolution: 0000006e-0010 On Fri, Jan 05, 2001 at 07:06:03PM +1000, Anthony Towns wrote: > Huh? Plurality is the same as first-past-the-post, isn't it? In which > case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, > 30 votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't > independent from clones. > > Have I missed something? In your example, B is in the clone set. -- Raul From bmbuck@14850.com Fri Jan 5 18:55:49 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9793 invoked from network); 5 Jan 2001 18:55:49 -0000 Received: from www.14850.com (HELO mail.14850.com) (209.150.235.34) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 18:55:49 -0000 Received: from [12.33.64.34] by mail.14850.com with SMTP (Eudora Internet Mail Server 1.3.1); Fri, 5 Jan 2001 13:55:42 -0500 Message-Id: <5.0.0.25.0.20010105133851.032c4900@armstrong.cse.buffalo.edu> Received: from emp1220.cbord.com by [12.33.64.34] via smtpd (for www.14850.com [209.150.235.34]) with SMTP; 5 Jan 2001 18:55:40 UT X-Sender: bmbuck@armstrong.cse.buffalo.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 05 Jan 2001 13:53:55 -0500 To: Raul Miller ,Anthony Towns From: Buddha Buck Subject: Re: Count rule, opening arguments Cc: MIKE OSSIPOFF ,npetry@accesscomm.ca, robla@eskimo.com,stevegr@debian.org In-Reply-To: <978718269.734d317c@debian.org> References: <20010105190602.B23857@azure.humbug.org.au> <20010105190602.B23857@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Evolution: 0000006f-0010 At 01:34 PM 01-05-2001 -0500, Raul Miller wrote: >On Fri, Jan 05, 2001 at 07:06:03PM +1000, Anthony Towns wrote: > > Huh? Plurality is the same as first-past-the-post, isn't it? In which > > case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, > > 30 votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't > > independent from clones. > > > > Have I missed something? > >In your example, B is in the clone set. Er, I think both {B} and {A,a} are clone sets. Actually, based on the definition at http://www.fortunecity.com/meltingpot/harrow/124/defn.html#clones only {A,a} is a clone set: Every other option Z is either higher than both A and a, or lower than both A and a on all ballots. {B} matches that two, but that definition excludes singleton sets. >-- >Raul From moth@debian.org Fri Jan 5 20:09:30 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 29577 invoked from network); 5 Jan 2001 20:09:30 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 20:09:30 -0000 Received: (qmail 25563 invoked by uid 1000); 5 Jan 2001 20:09:15 -0000 Date: Fri, 5 Jan 2001 15:09:15 -0500 From: Raul Miller To: Buddha Buck Cc: Anthony Towns , MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, stevegr@debian.org Subject: Re: Count rule, opening arguments Message-ID: <978724980.1e3ae4cf@debian.org> References: <20010105190602.B23857@azure.humbug.org.au> <20010105190602.B23857@azure.humbug.org.au> <978718269.734d317c@debian.org> <5.0.0.25.0.20010105133851.032c4900@armstrong.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20010105133851.032c4900@armstrong.cse.buffalo.edu>; from bmbuck@14850.com on Fri, Jan 05, 2001 at 01:53:55PM -0500 X-Evolution: 00000070-0010 On Fri, Jan 05, 2001 at 07:06:03PM +1000, Anthony Towns wrote: > > > Huh? Plurality is the same as first-past-the-post, isn't it? In which > > > case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, > > > 30 votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't > > > independent from clones. > > > > > > Have I missed something? At 01:34 PM 01-05-2001 -0500, Raul Miller wrote: > >In your example, B is in the clone set. On Fri, Jan 05, 2001 at 01:53:55PM -0500, Buddha Buck wrote: > Er, I think both {B} and {A,a} are clone sets. Actually, based on the > definition at http://www.fortunecity.com/meltingpot/harrow/124/defn.html#clones > only {A,a} is a clone set: Every other option Z is either higher than both > A and a, or lower than both A and a on all ballots. {B} matches that two, > but that definition excludes singleton sets. FPP ballots only allow mention of a single choice. So a ballot representing AaB would be: A a ballot representing aAB would be: a a ballot representing BAa would be: B Refering back to Anthony's notation: AaB ranks "a" the same as "B", and aAB ranks "A" the same as "B". Thus, "B" is in the clone set. Thanks, -- Raul From nkklrp@hotmail.com Fri Jan 5 23:19:10 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 12406 invoked from network); 5 Jan 2001 23:19:10 -0000 Received: from law-f67.hotmail.com (HELO hotmail.com) (209.185.131.130) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 23:19:10 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Jan 2001 15:19:07 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 05 Jan 2001 23:19:07 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org, moth@debian.org Subject: Re: Independence of Clones Criterion - Definitions Date: Fri, 05 Jan 2001 23:19:07 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jan 2001 23:19:07.0748 (UTC) FILETIME=[E7068A40:01C0776D] X-Evolution: 00000071-0010 >Definition ("Generalized Independence of Clones Criterion"): > > A voting method meets the "Generalized Independence > of Clones Criterion" if & only if additional > clones cannot change the result of the elections. > [If one clone is elected instead of another clone of the > same set of clones, then this is not regarded as a change > of the result.] Schulze's definition, quoted above, is rather vague. An additional clone cannot change the result of the election even if its addition causes people to vote differently? How about this: Deleting from the ballots a member of a clone set shouldn't change the matter of whether the winner comes from that clone set. (If desired, we could add the words: "...or what alternative outside the clone set wins"). [end of definition] This definition seems more definite in its meaning than Schulze's. > >***** > >Note that both versions of this criterion are defined in terms of >preferences/rankings, so ICC is really only applicable as a means of >distinguishing between rank count methods where all the voter's preferences >may be expressed. Isn't it true that, when applying a definition that speaks of ranking A over B, to Plurality, it's reasonable to say that Plurality can fairly be regarded as a two-tier rank method? When you vote for an alternative, you're ranking it over all the other alternatives, and are ranking all the other alternatives equal. If those definitions don't specifically say that they apply only to rank methods, then I don't know if we can infer that from their wording. In any case, if we interpret the definitions as saying that they apply only to rank methods, then I have to remark that that just happens to save us from the criterion's unexpected results with Plurality. Doesn't it seem that something is wrong with a criterion when we don't want to apply it to a certain method, because we don't like what it will say about that method? The Clone Criterion is intended to measure for the problem where some identical candidates can act as spoilers for eachother. Plurality is notorious for that problem. And yet Plurality passes, and some Condorcet versions fail the criterion, which means that the criterion is saying that those Condorcet versions have more of a spoiler problem under those conditions than Plurality does. When a criterion rates 2 methods with respect to eachother in a way that's contrary to what we believe to be their actual relation, that says that there's something wrong with that criterion. The fact that the criterion can be saved from that embarrassment because its definition can be interpreted as not applying to nonrank methods doesn't seem to me to avoid the problem. Here's my concern: Say we wrote a new version of the Clone Criterion that, when applied to all methods, would rate them in a way that isn't contrary to how we believe they should be rated. The question is, will Schulze still pass that new version? Who knows--it that version of the criterion hasn't been written yet. If we don't know that Schulze would pass that as-yet unwritten criterion, then how much does it really mean to show that Schulze passes the existing version and some other method doesn't? When we have a verion of the Clone Criterion that we can usefully apply to all methods, then would be a better time to use the Clone Criterion to compare methods. Most criteria apply to all methods in a way that seems right to us. A Clone Criterion like that could be written too. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Fri Jan 5 23:38:36 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4702 invoked from network); 5 Jan 2001 23:38:36 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 23:38:36 -0000 Received: (qmail 28996 invoked by uid 1000); 5 Jan 2001 23:38:21 -0000 Date: Fri, 5 Jan 2001 18:38:21 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Definitions Message-ID: <978737113.a720fafa@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Jan 05, 2001 at 11:19:07PM -0000 X-Evolution: 00000072-0010 > >Note that both versions of this criterion are defined in terms of > >preferences/rankings, so ICC is really only applicable as a means of > >distinguishing between rank count methods where all the voter's preferences > >may be expressed. On Fri, Jan 05, 2001 at 11:19:07PM -0000, MIKE OSSIPOFF wrote: > Isn't it true that, when applying a definition that speaks of ranking > A over B, to Plurality, it's reasonable to say that Plurality can > fairly be regarded as a two-tier rank method? When you vote for an > alternative, you're ranking it over all the other alternatives, and > are ranking all the other alternatives equal. Sure: Either the clone set includes votes in both ranks [in which case everything is in the clone set], or it includes votes in only the second rank [in which case no one is voting for anything in the clone set] or it includes votes in only the first rank [in which case the clone set contains only the single winning option, which everyone has voted for]. Plurality has a lot of flaws, but it's a very simple mechanism -- I don't think it's either surprising or disappointing that this simplicity has some benefit. Thanks, -- Raul From nkklrp@hotmail.com Fri Jan 5 23:41:42 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14139 invoked from network); 5 Jan 2001 23:41:42 -0000 Received: from law-f4.hotmail.com (HELO hotmail.com) (209.185.131.67) by qmail.accesscomm.ca with SMTP; 5 Jan 2001 23:41:42 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Jan 2001 15:41:39 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Fri, 05 Jan 2001 23:41:39 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Date: Fri, 05 Jan 2001 23:41:39 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jan 2001 23:41:39.0967 (UTC) FILETIME=[0D02C8F0:01C07771] X-Evolution: 00000073-0010 Anthony Townes wrote: >Huh? Plurality is the same as first-past-the-post, isn't it? In which >case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, 30 >votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't independent >from clones. I'd like there to be a precise Clone Criterion of the type that you imply. A Clone Criterion that allows for people changing their vote strategically after the addition of a new clone. That definition, of course, would have to specify some sort of constraints about how voters may change their votes strategically, otherwise any method fails because I can make everyone radically & inexplicably change their votes. Maybe we'd say that voters, before and after the addition of the new clone, must vote in a way that isn't dominated by another way of voting. Maybe we'd add to that a requirement that voters may not change their vote unless their old way of voting has become dominated when the clone is added. Or maybe we should instead say that every voter votes so as to maximize his utility expectation. Whichever of those 2 solutions we use, it really is necessary to specify what kind of strategic vote-changes are allowed. Otherwise, as I said, I could arbitrarily change everyone's votes inexplicably and make a Clone Criterion failure example for any method you can name. So wording for the requirements in those 2 paragraphs would have to be part of that new Clone Criterion. And, if we use the dominated voting solution, then any example must specify the information needed to determine dominated & undominated voting, meaning that it would have to specify the voters' sincere rankings or ratings. If we use the utililty expectation maximization approach, then the voters' sincere ratings of the alterantives would be needed. So, though I too would prefer the kind of Clone Criterion that you've implied above, such a Clone Criterion doesn't exist yet. The only complete & precise Clone Criterion definition I know of so far is: Deleting from the ballots a member of a clone set, and recounting those ballots, shouldn't change the matter of whether or not the winner comes from that clone set [and maybe shouldn't change which nonmember of that clone set wins]. (If the part in brackets should be included, then delete the brackets and the word "maybe"). [end of definition] If we want a better definition, one that works the way you implied, then it will have to be a much more complicated definition. So far as I'm aware, no such Clone Criterion definition has been written so far. I'm not saying for sure that there isn't somewhere another complete & precise Clone Criterion definition, only that I don't know of one yet. Someone could say my definition is incomplete because it doesn't define "clone set", but we agree on what that term means. I left it out for brevity. If there's a precise & complete Clone Criterion definition that acts in the way that Anthony implied above, then I'd like someone to tell me of it. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From aj@azure.humbug.org.au Sat Jan 6 04:40:23 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24704 invoked from network); 6 Jan 2001 04:40:23 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 04:40:23 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14El9I-00033Y-00; Sat, 06 Jan 2001 14:40:12 +1000 Date: Sat, 6 Jan 2001 14:40:11 +1000 From: Anthony Towns To: Raul Miller Cc: Buddha Buck , MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, stevegr@debian.org Subject: Re: Count rule, opening arguments Message-ID: <20010106144011.E11143@azure.humbug.org.au> References: <20010105190602.B23857@azure.humbug.org.au> <20010105190602.B23857@azure.humbug.org.au> <978718269.734d317c@debian.org> <5.0.0.25.0.20010105133851.032c4900@armstrong.cse.buffalo.edu> <978724980.1e3ae4cf@debian.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DqhR8hV3EnoxUkKN" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <978724980.1e3ae4cf@debian.org>; from moth@debian.org on Fri, Jan 05, 2001 at 03:09:15PM -0500 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000074-0030 --DqhR8hV3EnoxUkKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2001 at 03:09:15PM -0500, Raul Miller wrote: > FPP ballots only allow mention of a single choice. > So a ballot representing AaB would be: A > a ballot representing aAB would be: a > a ballot representing BAa would be: B In which case there aren't really any clones at all. FPP as usually used is exactly equivalent to a method that allows ballots with fully expressed preferences but then goes ahead and ignores any but the first expressed preference on each vote (the strategies are the same, so the ballots should be the same, so the result should be the same). So I don't think the claim that FPP passes the clone criterion when justified that way is particularly illuminating of either FPP or the clone criterion. Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --DqhR8hV3EnoxUkKN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOlahq+RRvX9xctrtAQF6awQAhfbHbyzzwEpEOweUQ+pSq2e197vuJcYQ Qef5hSdvAvhqyb6KIkujeMPymi5quOWpC1Gid44xmq6Vfih9jXvkLYWS0JCQAipm wlxYqXrZg2FlLHt4EpKv8x2ogBCxRZHw9xJgKjqS4f8QzvVjwilszyv4pocZ+u2Y f+SQ6nuuPus= =LYXS -----END PGP SIGNATURE----- --DqhR8hV3EnoxUkKN-- From aj@azure.humbug.org.au Sat Jan 6 04:51:14 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26919 invoked from network); 6 Jan 2001 04:51:14 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 04:51:14 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14ElJl-00035X-00; Sat, 06 Jan 2001 14:51:01 +1000 Date: Sat, 6 Jan 2001 14:51:01 +1000 From: Anthony Towns To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Message-ID: <20010106145101.F11143@azure.humbug.org.au> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ni93GHxFvA+th69W" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Fri, Jan 05, 2001 at 11:41:39PM -0000 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 00000075-0030 --ni93GHxFvA+th69W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2001 at 11:41:39PM -0000, MIKE OSSIPOFF wrote: > >Huh? Plurality is the same as first-past-the-post, isn't it? In which > >case, if you have 60 votes AB, 40 votes BA; A wins, clone A to a, 30 > >votes AaB, 30 votes aAB, 40 botes BAa; B wins. FPP thus isn't independen= t > >from clones. > I'd like there to be a precise Clone Criterion of the type that > you imply. Try something like: a clone set is a maximal proper subset of the set of options such that no vote ranks an option not in the set between two options in the set (or however you like to express). Given a set of votes in which there is a clone set X of two or more options, the clone criterion is failed if by eliminating any one of the options in X from all ballots the result of the vote is changed in such a way that the new winner is not in the same clone set as the old winner. Starting with: 40 votes BAa 30 votes AaB 30 votes aAB then the FPP winner is B, and the clone sets are {A,a} and {B}. Removing {a} from the first clone set changes the votes to: 40 votes BA 60 votes AB and the result of the vote is changed to have A win. So FPP fails the clone criterion. You could strengthen the above clone criterion to either: if the old winner was removed, the new winner should be a member of X, otherwise the new winner should be the same as the old winner or if the old winner was a member of X, the new winner should be a member of X also, otherwise the new winner should be the same as the old winner The backwards way of phrasing it (removing a clone rather than adding one) gives an obvious way of deciding what the new votes should look like, and doesn't allow strategy to come into play (since you're allowed to choose a non-strategic set of votes in the first place). Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 --ni93GHxFvA+th69W Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOlakNeRRvX9xctrtAQFJFAP5AfuOk607/609rZG1x1xlJQoGeMaM8UtS 89RlqurnAwUnzvrxy/vVXyvHTsXl5tSMmor3Sl9SpLKYs5BG0qumiOVpVkU4Fou7 ATTHuH5pkvy/t5Jkv82WqzWMNRJZrU3UncG9XUvjRtmzifr5PmnR6ItJG7OjsTIo CwDLrygHDAY= =yazC -----END PGP SIGNATURE----- --ni93GHxFvA+th69W-- From nkklrp@hotmail.com Sat Jan 6 06:33:37 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 16347 invoked from network); 6 Jan 2001 06:33:37 -0000 Received: from law-f9.hotmail.com (HELO hotmail.com) (209.185.131.72) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 06:33:37 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Jan 2001 22:33:34 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 06:33:34 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, bmbuck@14850.com Cc: aj@azure.humbug.org.au, npetry@accesscomm.ca, robla@eskimo.com, stevegr@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 06:33:34 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 06:33:34.0455 (UTC) FILETIME=[97FE6070:01C077AA] X-Evolution: 00000076-0010 > >FPP ballots only allow mention of a single choice. > >So a ballot representing AaB would be: A > a ballot representing aAB would be: a > a ballot representing BAa would be: B > >Refering back to Anthony's notation: AaB ranks "a" the same as "B", >and aAB ranks "A" the same as "B". Thus, "B" is in the clone set. But if we're going by the clone-set definition at the website that you referred to, a clone set must not include all of the candidates, and so if A & a are in a clone set, then B can't also be in that clone set. If some people voted for A, & some voted for a, & some voted for B, then there are no clone sets in that example. It can't be said that everyone who voted A over B voted a over B, because the only people who voted A over B didn't vote a over anyone. Likewise for every pair of candidates. So that example with some people voting for A, some voting for a, & some voting for B, has no clone sets. By the way, the Clone Criterion definition at that website that you referred to is the same as mine. Slightly different wording, but same meaning. But when I said that Plurality passes that version of the Clone Criterion (I've seen that criterion abbreviated "ICC"), I forgot that Plurality doesn't allow a voter to vote, or "rank" candidates equal. Approval passes that version, but it doesn't apply to Plurality, because when people voting for A are _only_ allowed to vote for A, it can't be possible to say that everyone who votes A over B votes a over B. So any Plurality example that we could write will violate the premise of ICC, and so ICC doesn't apply to Plurality. But that doesn't change my objection to ICC. ICC still fails to say that Schulze is better than Plurality in terms of what ICC measures for. ICC merely refuses to compare Plurality to Schulze or other methods. Do we want to use a criterion that doesn't say that Schulze is better than Plurality, when that criterion is supposed to be measuring for the problem of 2 identical candidates being spoilers for eachother-- a problem that Plurality is notorious for? Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Jan 6 07:25:54 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9653 invoked from network); 6 Jan 2001 07:25:54 -0000 Received: from law-f30.hotmail.com (HELO hotmail.com) (209.185.131.93) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 07:25:54 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Jan 2001 23:25:51 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 07:25:51 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Definitions Date: Sat, 06 Jan 2001 07:25:51 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 07:25:51.0422 (UTC) FILETIME=[E5C58DE0:01C077B1] X-Evolution: 00000077-0010 Before I wade farther into this clone definition mess, let me say this: If this all sounds like a mess, that's because there are different Clone Criterion definitions, some of which are only vaguely suggested rather than actually defined; and because there are different contradictory definitions of a clone set. My claim that you don't vote A & B equal by refusing to vote for either does not represent accepted opinion, and I only mentioned it because someone else might if I didn't. Anyway, one conclusion comes out of this mess: The Clone Criterion, as precisely & completely defined, by me & Cretney, whichever of the clone-set definitions is used, does not say that Schulze is better than Plurality even though the Clone Criterion is supposed to measure for a problem for which Plurality is notorious. Earlier I correctly said that Plurality doesn't allow any clone sets. That's if we are using Schulze's definition of a clone set, at least it is if that definition is written in terms of ballots rather than sincere preferences. Since the only precise & complete definition of the Clone Criterion is about ballots, not sincere preferences (The definition at Cretney's website, also written here by me) a clone set definition in terms of ballots is what is needed. I don't remember whether Schulze's clone set definitions are in terms of ballots, but when I referred to that definition, I was referring to what it would be if it were written in terms of ballots rather than sincere prefernces. But that remains true, for a different reason, if we use Cretney's definition. He says that nothing outside the clone set may be ranked equal to anything in the clone set. That again makes it impossible to have a clone set in Plurality. To make matters worse: Before someone calls me on contradicting myself, I want to add that, for my SDSC definition, I don't say you've voted 2 candidates equal unless you've actually voted for both of them. In that case, using that meaning for voting alternatives equal, & Tideman's definition of a clone set, Plurality _does_ allow clone sets, because , when I vote for A, I can add any number of the candidates I didn't vote for, as long as it's less than all of them, and say A & they are a clone set, because no one outside that set is ranked between them. Again, when I refer to Tideman's definition of a clone set, what I mean is what it would be if it were written in terms of ballots rather than sincere preferences. If this all sounds like a mess, that's because there are different Clone Criterion definitions, some of which are only vaguely suggested rather than actually defined; and because there are different contradictory definitions of a clone set. My claim that you don't vote A & B equal by refusing to vote for either does not represent accepted opinion, and I only mentioned it because someone else might if I didn't. Anyway, one conclusion comes out of this mess: The Clone Criterion, as precisely & completely defined, by me & Cretney, whichever of the clone-set definitions is used, does not say that Schulze is better than Plurality even though the Clone Criterion is supposed to measure for a problem for which Plurality is notorious. I'm going to paste those last 2 paragraphs to the beginning of this letter, so that the subject won't seem like a hopeless mess. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Jan 6 07:41:18 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20764 invoked from network); 6 Jan 2001 07:41:18 -0000 Received: from law-f40.hotmail.com (HELO hotmail.com) (209.185.131.103) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 07:41:18 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 5 Jan 2001 23:41:15 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 07:41:14 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au, moth@debian.org Cc: bmbuck@14850.com, npetry@accesscomm.ca, robla@eskimo.com, stevegr@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 07:41:14 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 07:41:15.0196 (UTC) FILETIME=[0C6247C0:01C077B4] X-Evolution: 00000078-0010 >So I don't think the claim that FPP passes the clone criterion when >justified that way is particularly illuminating of either FPP or the >clone criterion. That's true. I missed that at first. The Clone Criterion doesn't apply to FPP. But failure to apply to all methods is a fault that undermines a criterion's credibility. Having said that, it's also true, of course that if one rank method will change its choice into or out of a clone set when we delete one of the clones from the ballots & recount them, and another method doesn't guarantee that, then of course I admit that the 1st method is doing something somewhat less than desirable, that the 2nd method isn't doing. Because that's the same as saying that if we add a new member to the clone set, and if everyone inserts him in their ranking without changing the order of the other candidates, then with the 1st method that can change the victory into or out of the clone set, and with the 2nd method it won't. So I don't deny that the Clone Criterion means something. I just meant that there's something wrong with that criterion that should be fixed if the criterion is going to be used, even though it would greatly complicate the criterion. But I'm sorry if I got carried away with what I was saying, and almost took the position that the Clone Criterion means nothing at all. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Jan 6 08:18:12 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25778 invoked from network); 6 Jan 2001 08:18:12 -0000 Received: from law-f45.hotmail.com (HELO hotmail.com) (209.185.130.33) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 08:18:12 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 00:18:09 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 08:18:09 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 08:18:09 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 08:18:09.0635 (UTC) FILETIME=[344ADB30:01C077B9] X-Evolution: 00000079-0010 > > I'd like there to be a precise Clone Criterion of the type that > > you imply. > >Try something like: a clone set is a maximal proper subset of the set >of options such that no vote ranks an option not in the set between >two options in the set (or however you like to express). Given a set of >votes in which there is a clone set X of two or more options, the clone >criterion is failed if by eliminating any one of the options in X from >all ballots the result of the vote is changed in such a way that the >new winner is not in the same clone set as the old winner. That's in agreement with the definition written by Cretney & me. > >Starting with: > 40 votes BAa > 30 votes AaB > 30 votes aAB >then the FPP winner is B, and the clone sets are {A,a} and {B}. But the problem, which I admit that I didn't notice until just now, is that Cretney's definition of a clone set, and Tideman's & Schulze's definitions too, when written about ballots rathet than sincere preferences, don't allow Plurality to have clone sets. If a clone set must contain more than 1 candidate. Schulze's & Cretney's definition doesn't allow it because if you vote A over B, there can't be any "a" that you vote over anyone, including B. You aren't voting anyone but A over anyone. If we use Tideman's definition, keeping the requirement that nothing outside the clone set must be ranked equal to anything in the clone set, then there still can't be a Plurality clone set, because anything that we put with A (for whom we vote) to make a clone set has other un-voted-for alternatives that we've treated equally with it, contrary to the requirement that alternatives outside the clone set may not be ranked equal to alternatives in the clone set. Now, I don't remember for sure whether all of those requirements are present in all the definitions, and so maybe one of the definitions _does_ allow clone sets for Plurality, and therefore lets Plurality fail the clone criterion. But, either way, either the Clone Criterion lets Plurality pass, or it is inapplicable to Plurality. Either way, that seems to me to be something wrong with the Clone Criterion. As I was saying before, I'm not saying that it doesn't mean anything for one method to pass that criterion & another method not to. But it would mean more if the criterion had universal useful applicability. Mike Removing >{a} from the first clone set changes the votes to: > 40 votes BA > 60 votes AB >and the result of the vote is changed to have A win. So FPP fails the >clone criterion. > >You could strengthen the above clone criterion to either: > > if the old winner was removed, the new winner should be a member of X, > otherwise the new winner should be the same as the old winner >or > if the old winner was a member of X, the new winner should be a member > of X also, otherwise the new winner should be the same as the old > winner > >The backwards way of phrasing it (removing a clone rather than adding one) >gives an obvious way of deciding what the new votes should look like, >and doesn't allow strategy to come into play (since you're allowed to >choose a non-strategic set of votes in the first place). > >Cheers, >aj > >-- >Anthony Towns >I don't speak for anyone save myself. GPG signed mail preferred. > > ``Thanks to all avid pokers out there'' > -- linux.conf.au, 17-20 January 2001 ><< attach3 >> _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Jan 6 09:32:31 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1018 invoked from network); 6 Jan 2001 09:32:31 -0000 Received: from law-f5.hotmail.com (HELO hotmail.com) (209.185.131.68) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 09:32:31 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 01:32:31 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 09:32:30 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: aj@azure.humbug.org.au Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 09:32:30 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 09:32:31.0043 (UTC) FILETIME=[977FB130:01C077C3] X-Evolution: 0000007a-0010 Raul has pointed out that Plurality _does_ allow clone sets, and that the only kind of clone set that it allows can never contain a winner, meaning that Plurality passes the Clone Criterion. Say there are a few "bottom candidates" whom no one votes for. They satisfy the requirements for a clone set. That hadn't occurred to me. Of course such a bottom candidate can't win, and so deleting one of them from the ballots & recounting the ballots won't change the matter of whether the winner comes from that set--the winner will never come from a set of candidates for whom no one votes. I felt that that fact is relevant to the discussion of Plurality & the Clone Criterion, and so I've taken the liberty of writing to all about it. So that means that I can make this strong statement: The Clone Criterion says that Plurality is just as good as Schulze by what the criterion measures for, even though the spoiler effect among identical or similar candidates, for which ICC measures, is a problem for which Plurality is notorious. That's why I say that ICC says something that doesn't make any sense. That's why I say that there's something wrong with ICC. I'm not saying that it doesn't mean anything at all if one method passes ICC and another fails it. But what method(s) would pass ICC if we rewrote it in a way so that its results would make more sense? Who knows? That weakens the meaning of passing ICC. It's rather as if a witness testified in court that he saw the defendant commit the crime, and then stated that he sees a UFO land on the courthouse lawn every week. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sat Jan 6 09:51:19 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 17831 invoked from network); 6 Jan 2001 09:51:19 -0000 Received: from law-f100.hotmail.com (HELO hotmail.com) (209.185.131.163) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 09:51:19 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 01:51:18 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 09:51:18 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 09:51:18 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 09:51:18.0541 (UTC) FILETIME=[378A3BD0:01C077C6] X-Evolution: 0000007b-0010 Raul wrote: >I think it's important to consider how each of these mechanisms handle >a circular tie which also involves an exact tie. A pairwise tie isn't a problem of itself. In SSD it of course doesn't count as a defeat for either member of that pair, and of course having a pairwise tie between those 2 alternatives instead of a defeat affects the current Schwartz set. In Schulze, it just means that there's no beatpath through that pair. The problem would be, for instance, if there were a pairwise tie between 2 alternatives that are unbeaten by the others. There'd be 2 unbeaten candidates, and a special tiebreaker would be needed in SSD. Pairwise ties can make Schulze return a tie too, of course. In the example in the previous paragraph, for instance, neither of those 2 candidates has any beatpath to the other. Norm can tell you more about the convenience of solving ties that the various methods return. From what he's said, Schulze may be somewhat more convenient in that regard, though I'd like to have examples of that. The Clone Criterion and the convenience of tie-solving seem to be the 2 arguments that are used for Schulze vs SSD. I've already said why consider the Clone Criterion's meaning to be weakened by its equal rating of Schulze & Plurality. Aside from that, I'd like to have the worst looking examples of SSD failure of the Clone Criterion, and a few of the more likely examples. Plus examples of where Schulze ties can be solved more conveniently than SSD ties, with arguments for why that should typically be so. These seem to be the important issues in the matter of Schulze vs SSD. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sat Jan 6 09:53:53 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24303 invoked from network); 6 Jan 2001 09:53:53 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 09:53:53 -0000 Received: (qmail 9785 invoked by uid 1000); 6 Jan 2001 09:53:40 -0000 Date: Sat, 6 Jan 2001 04:53:40 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: aj@azure.humbug.org.au, npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, stevegr@debian.org, moth@debian.org Subject: Re: Count rule, opening arguments Message-ID: <978774669.56d48d48@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sat, Jan 06, 2001 at 09:32:30AM -0000 X-Evolution: 0000007c-0010 On Sat, Jan 06, 2001 at 09:32:30AM -0000, MIKE OSSIPOFF wrote: > Raul has pointed out that Plurality _does_ allow clone sets, and that > the only kind of clone set that it allows can never contain a winner, > meaning that Plurality passes the Clone Criterion. [To avoid needless further rebuttals on this issue]: another constraint here is that all votes must be cast for a single option, which is the option not in the clone set. -- Raul From nkklrp@hotmail.com Sat Jan 6 10:23:54 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5783 invoked from network); 6 Jan 2001 10:23:54 -0000 Received: from law-f12.hotmail.com (HELO hotmail.com) (209.185.131.75) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 10:23:54 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 02:23:50 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 06 Jan 2001 10:23:50 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Count rule, opening arguments Date: Sat, 06 Jan 2001 10:23:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jan 2001 10:23:50.0932 (UTC) FILETIME=[C3417540:01C077CA] X-Evolution: 0000007d-0010 I'd said: > > But pure merit isn't everything. SSD & Tideman have natural & obvious > > motivation & justification. Schulze doesn't have that. Its rule sounds > > arbitrary. That may mean that it won't go over well with Debian. > Raul commented: >SSD ignores the mechanics of the circular tie when picking the least >significant. Schulze is sensitive to the mechanics of the circular tie >when picking the least significant. > >Of the three, my impression is that Schulze sounds the least arbitrary. The circular tie, and the relative strength of its parts, is of course one way of looking at it. If A beats B beats C beats beats D beats A, then the people are saying that B is better than A and that C is better than B, and that therefore C is better than A. Similarly they're saying that A is better than C. (Say there's a pairwise tie between A & C). So it makes sense to ask which of those 2 statements is stronger. But what isn't so obvious is why we should measure the strength of a cycle-segment, a beatpath, by its weakest defeat. Why not add up the strengths of the defeats, or, better yet, multiply them? The analogy with a chain's weakest link isn't really solid. A chain breaks because one link breaks, the weakest link. But the validity of the infered indirect merit comparison that a beatpath makes could be argued to be affected by all of its links. The unbeaten sets are compelling in a more simple & concrete & obvious way. If none of the candidates in a set are beaten by anyone outside that set, but the others are beaten from that set, then the defeats from that set aren't contradicted or conflicted by any other defeats. The whole reason why the cycle is indecisive is that , as Condorcet worded it (translated of course), the propositions (pair-defeats) cannot all exist together. Well, the defeats from the unbeaten set can exist just fine and aren't contradicted. The only defeats that cannot all exist together are the ones among the unbeaten set candidates. Obviously the same thing can be said for a smaller unbeaten set inside that unbeaten set, and so it's really the innermost unbeaten set that we're interested in. To say it differently, there's just something obviously special and more democratically qualified about the candidates in an innermost unbeaten set. No one beats them, but they beat the others. The people have obviously chosen them. It's similar to the Smith Criterion. If you agree that the Smith Criterion is natural, and intuitive, then you'll agree that choosing only from the innermost unbeaten set is also natural & obvious. This is more concrete, it seems to me, than the arguments about why one beatpath is stronger than another, and the attempt to justify how we measure that strength. The unbeaten set approach has nothing difficult to explain or justify. I explained SSD, with a simple diagram, to someone completely unfamiliar with voting systems, and it was immediately obvious to her that SSD made sense. She liked it better than a more briefly-worded relative of Plain Condorcet, because the PC relative referred to cycles. Cycles may be natural & intuitive for people who like voting systems, but, believe me, they aren't natural for most people who haven't studied voting systems. The beauty of SSD is that it doesn't talk about cycles or beatpaths. The person I spoke to, when I told her that A beats B beats C beats A, said "No", as if to say "Oh come on". The two contradictory beatpaths of Schulze would probably be just as counterintuitive. So those seem to me to be the 3 issues for SSD vs Schulze: 1. Clone Criterion 2. Tie convenience & frequency 3. Natural & obvious motivation & justification I claim that SSD wins by #3, and it would have to be demonstrated that it looks bad by #1 & #2. And the Clone Criterion discredits itself by rating Schulze & Plurality equal. As for Tideman, no one here is proposing it for single-winner voting (as opposed to ordering a list). Norm & I agree that SSD & Schulze would be better for that than Tideman. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sat Jan 6 17:15:08 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 21693 invoked from network); 6 Jan 2001 17:15:08 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 17:15:08 -0000 Received: (qmail 13141 invoked by uid 1000); 6 Jan 2001 17:14:54 -0000 Date: Sat, 6 Jan 2001 12:14:54 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Count rule, opening arguments Message-ID: <20010106121454.A12005@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sat, Jan 06, 2001 at 10:23:50AM -0000 X-Evolution: 0000007e-0010 On Sat, Jan 06, 2001 at 10:23:50AM -0000, MIKE OSSIPOFF wrote: > It's similar to the Smith Criterion. If you agree that the Smith > Criterion is natural, and intuitive, then you'll agree that choosing > only from the innermost unbeaten set is also natural & obvious. I agree. However: both Schulze and SSD could be said to be choosing only from "the innermost unbeaten set". In Schulze, those set members are specific options [which is what set members are for Smith]. > Cycles may be natural & intuitive for people who like voting systems, > but, believe me, they aren't natural for most people who haven't > studied voting systems. The beauty of SSD is that it doesn't talk > about cycles or beatpaths. The person I spoke to, when I told her > that A beats B beats C beats A, said "No", as if to say "Oh come on". > The two contradictory beatpaths of Schulze would probably be just as > counterintuitive. This part of your argument seems unreasonable to me: How are we supposed to pick a good mechanism for breaking circular ties if we're not allowed to admit that circular ties exist? > So those seem to me to be the 3 issues for SSD vs Schulze: > > 1. Clone Criterion > 2. Tie convenience & frequency > 3. Natural & obvious motivation & justification I think you left out the Reversal Symmetry Criterion: If alternative X wins, and all rankings on all ballots are reversed, then X must lose. > I claim that SSD wins by #3, and it would have to be demonstrated that > it looks bad by #1 & #2. I claim that #3 isn't knowable unless we're working with specific explicitly written motivations and justifications, and a specific set of people [who are then polled about which of the two write ups they prefer]. > And the Clone Criterion discredits itself by rating Schulze & > Plurality equal. This would also discredit the Smith Criterion. Thanks, -- Raul From npetry@accesscomm.ca Sat Jan 6 19:23:38 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24818 invoked from network); 6 Jan 2001 19:23:38 -0000 Received: from mail2.rdc2.bc.home.com (24.2.10.85) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 19:23:38 -0000 Received: from rhiannon ([24.115.192.89]) by mail2.rdc2.bc.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010106192336.PBDA21777.mail2.rdc2.bc.home.com@rhiannon>; Sat, 6 Jan 2001 11:23:36 -0800 Message-ID: <00ba01c07815$b4e31080$59c07318@cdrva1.bc.wave.home.com> From: "Norman Petry" To: "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Steve Greenland" , "Raul Miller" Subject: Independence of Clones Criterion - Justification Date: Sat, 6 Jan 2001 11:20:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Evolution: 0000007f-0010 The definition of clone sets and the two clone independence criteria that I described are useful for evaluating how a voting method will respond to voting by an electorate containing parties or factions of various sizes. Voting methods which are not clone independent will suffer from one of two types of problems: 1) The so-called 'Rich Party Problem' occurs when a faction/party will benefit from running additional candidates. Even though these candidates will be seen as similar to the existing field of candidates by most voters, their faction's chances of electing a candidate increases if the voting method has this defect. Obviously, when promoting candidates costs money, this offers a disproportionate advantage to the wealthiest parties/factions, hence the name. If the method is being used to choose a policy, rather than a candidate, wealth will not usually be a factor, but this defect still causes problems -- it provides strategisers with an incentive to propose many, trivially different versions of a proposal in order to increase the chances of one of their options winning. If all factions do this, voting becomes very difficult (due to the many options), and the result may still be unfair. 2) Vote Splitting - A voting system with this defect will result in a faction reducing its chances of winning if they run more candidates than are to be elected -- voters supporting the faction will 'split their votes' among their faction's candidates, and this almost invariably causes another, less popular faction to win. Plurality voting is notorious for having this defect, which is why in public elections, formally organised parties long ago adopted the practice of nominating a single candidate for each single-member district. When a method having this defect is used to choose a policy, factions will generally limit themselves to a single proposal that they believe is winnable, rather than suggesting a range of options. The usual result is that the best compromise proposals don't get made, so voters will never get the opportunity to choose them. Over time, similar factions will merge, and policy will flip-flop between the *internal* compromise policies of the two largest factions. This situation is very undesireable, both because it is unstable, and because a sizeable majority of voters will always be dissatisfied with the policy no matter which faction wins. This also tends to increase the factionalism within the group, as those who are the most dissatisfied with the current policy/leaders organise to change the policy and get revenge on the opposing faction. A method which is clone independent is better (all else being equal) than a method which suffers from vote splitting or the 'rich party problem' because it neither provides an incentive for, nor penalises nomination of additional candidates or options. Because a faction cannot increase their chances of winning by proposing many similar options, there is no strategic incentive to do so. Therefore, trivially different proposals will not be made. On the other hand, since vote splitting will not be a problem, a faction may propose a range of options if they are not certain which of their proposals will be more popular, without having to worry about how this will affect their overall chances of winning. As a result, a clone independent method should be better at providing voters with a range of *meaningfully* different (but not trivially different) options from which to choose, than a method which is not clone independent. This allows the group to find the best compromise without wasting time evaluating trivially different options, as well as providing long-term stability and minimising factionalism. How this relates to the Debian Project: One could argue that none of this is relevant to the Debian Project -- there are certainly no formally organised parties, and probably there aren't even any stable factions of developers (I don't know enough about the internal politics of Debian to comment on this, except to ask -- what is this 'cabal' that is sometimes referred to (perhaps jokingly) in some debian list messages?). However, I think that clone independence is still a desireable property for Debian's voting method, because: 1) it isn't necessary for voters to recognise that they are part of a faction for there to *be* factions. For example, in the recent 'remove non-free' debate, I certainly got the impression that there were more or less two dominant points of view being expressed. If Debian was using plurality voting, I doubt very much if more than two proposals would have been made to resolve that issue (even though there are a wide range of proposals that could be made). 2) it isn't necessary for factions to be static -- there can be different sets of factions for every vote, and the concept is still meaningful. 3) Debian is growing larger -- there are currently something like 600 developers, and new developers are being added all the time. It is simply a fact that as organisations grow, they tend to become more formal in their internal organisation, both in terms of operating policy, and in their internal politics. Therefore, it is a good idea to plan ahead for a time when the factions within Debian may be more obvious, to ensure that those sub-groups of developers (if they exist) are always treated fairly. As I argued above, a clone-independent method should help to *minimise* the tendency towards factionalism, which is certainly desireable. ***** Well, that's it for now. I thought I should write up this explanation/justification for the Clone Independence criterion, and send it off before responding to Mike's criticisms (I'll get to that...) I also have some test results for clone independence which I'll post shortly. -- Norm Petry From moth@debian.org Sat Jan 6 19:40:12 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7721 invoked from network); 6 Jan 2001 19:40:12 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Jan 2001 19:40:12 -0000 Received: (qmail 15841 invoked by uid 1000); 6 Jan 2001 19:39:57 -0000 Date: Sat, 6 Jan 2001 14:39:57 -0500 From: Raul Miller To: Norman Petry Cc: Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns , Steve Greenland Subject: Re: Independence of Clones Criterion - Justification Message-ID: <978809626.23c80a7a@debian.org> References: <00ba01c07815$b4e31080$59c07318@cdrva1.bc.wave.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00ba01c07815$b4e31080$59c07318@cdrva1.bc.wave.home.com>; from npetry@accesscomm.ca on Sat, Jan 06, 2001 at 11:20:18AM -0800 X-Evolution: 00000080-0010 On Sat, Jan 06, 2001 at 11:20:18AM -0800, Norman Petry wrote: > (I don't know enough about the internal politics of Debian to comment > on this, except to ask -- what is this 'cabal' that is sometimes > referred to (perhaps jokingly) in some debian list messages?). [Replace "perhaps " with "".] It's "them". > 2) it isn't necessary for factions to be static -- there can be different > sets of factions for every vote, and the concept is still meaningful. Also, people can change their minds. Thanks, -- Raul From nkklrp@hotmail.com Sun Jan 7 01:53:42 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5148 invoked from network); 7 Jan 2001 01:53:42 -0000 Received: from law-f86.hotmail.com (HELO hotmail.com) (209.185.131.149) by qmail.accesscomm.ca with SMTP; 7 Jan 2001 01:53:42 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 17:53:40 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sun, 07 Jan 2001 01:53:39 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Count rule, opening arguments Date: Sun, 07 Jan 2001 01:53:39 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jan 2001 01:53:40.0173 (UTC) FILETIME=[A83C0FD0:01C0784C] X-Evolution: 00000081-0010 Raul wrote: On Sat, Jan 06, 2001 at 10:23:50AM -0000, MIKE OSSIPOFF wrote: >It's similar to the Smith Criterion. If you agree that the Smith Criterion >is natural, and intuitive, then you'll agree that choosing only from the >innermost unbeaten set is also natural & obvious. I agree. However: both Schulze and SSD could be said to be choosing only from "the innermost unbeaten set". I reply: Absolutely. Schulze & SSD both meet the Schwartz Criterion. They both always choose only from the Schwartz set. The difference is that SSD gets its full motivation & justification from that. The intuitive & natural Schwartz set is the basis of SSD's count rule. Raul continues: In Schulze, those set members are specific options [which is what set members are for Smith]. I reply: But the members of the Schwartz set are also specific options. Even though SSD speaks of dropping defeats, it says to only drop defeats that are among the members of the Schwartz set. The Schwartz set, like the Smith set, is a set of some of the alternatives between which we're voting. I'd said: >Cycles may be natural & intuitive for people who like voting systems, but, >believe me, they aren't natural for most people who haven't studied voting >systems. The beauty of SSD is that it doesn't talk about cycles or >beatpaths. The person I spoke to, when I told her that A beats B beats C >beats A, said "No", as if to say "Oh come on". The two contradictory >beatpaths of Schulze would probably be just as counterintuitive. Raul replied: This part of your argument seems unreasonable to me: How are we supposed to pick a good mechanism for breaking circular ties if we're not allowed to admit that circular ties exist? I reply: In terms of properties, SSD is pretty good even though its rule doesn't mention cycles. We have a good solution for circular ties without having to mention them, unless someone asks how it could be that there's no unbeaten alternative. Someone who was put off by mention of cycles understood & liked SSD. I'd said: >So those seem to me to be the 3 issues for SSD vs Schulze: > >1. Clone Criterion 2. Tie convenience & frequency 3. Natural & obvious >motivation & justification Raul replied: I think you left out the Reversal Symmetry Criterion: If alternative X wins, and all rankings on all ballots are reversed, then X must lose. I reply: Schulze complies with that, and I believe that SSD does too. Some of our simpler Condorcet versions, which I haven't brought up here yet, fail the Reversal Symmetry Criterion. But if Schulze & SSD both pass it, then it isn't a factor in choosing between Schulze & SSD. I'm suggesting that the best proposals, Schulze & SSD, be compared first. Then we could consider whether we want some of the simpler methods that don't meet quite all of the criteria that those methods meet. But now that you've brought up that criterion, no doubt some of us will be checking on whether SSD actually does pass it. Raul continues: I claim that #3 isn't knowable unless we're working with specific explicitly written motivations and justifications, and a specific set of people [who are then polled about which of the two write ups they prefer]. I reply: It's true that, ideally, polling should be done. I've only asked one person. But it was a person who definitely had no prior experience with voting systems, and hadn't been interested in them. The innermost unbeaten set was completely intuitive & understandable to her, and cycles were counterintuitive for her. When you tell someone about them they're going to feel as if they don't really understand the method that you then define, mentioning cycles. They might even question the validity & merit of what you're advocating, for that reason. I'd said: >And the Clone Criterion discredits itself by rating Schulze & Plurality >equal. Raul Replied: This would also discredit the Smith Criterion. I reply: Quite so, as Cretney defines it at the website whose clone definitions were quoted here. Likewise for Condorcet's Criterion. Plurality passes all of them when they're defined in the usual way--except when they're defined so that no method passes them, as they sometimes are. That's why I have different definitions for Condorcet's Criterion and the Smith Criterion. (Terms will be defined after these main definitions). Condorcet Criterion: If there's a sincere Condorcet winner, and everyone votes sincerely, then that sincere CW must win. Smith Criterion: If every alternative in set S is socially preferred to every alternative outside S, and if everyone votes sincerely, then the winner should come from S. Definitions of terms: A is socially preferred to B if more voters prefer A to B than vice-versa. (This, of course refers to sincere preference, not necessarily actual votes). The sincere Condorcet winner is a candidate who is socially preferred to each one of the other candidates. A voter votes sincerely if he doesn't falsify a preference or leave unvoted a sincere preference that the balloting system in use would have allowed him to vote in addition to the preferences that he actually voted. A voter has a sincere preference for X over Y if he likes X better than Y. To vote a preference for X over Y means to vote X over Y. A voter votes X over Y if he votes in a way so that it's possible to contrive a configuration of the other voters with which, if we delete from the ballots all the alternatives except X & Y, X is the unique winner if & only if we count that voter's ballot. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sun Jan 7 02:13:52 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26440 invoked from network); 7 Jan 2001 02:13:52 -0000 Received: from law-f79.hotmail.com (HELO hotmail.com) (209.185.131.142) by qmail.accesscomm.ca with SMTP; 7 Jan 2001 02:13:52 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 18:13:50 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sun, 07 Jan 2001 02:13:49 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org, moth@debian.org Cc: nkklrp@hotmail.com Subject: Re: Independence of Clones Criterion - Justification Date: Sun, 07 Jan 2001 02:13:49 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jan 2001 02:13:50.0164 (UTC) FILETIME=[79720940:01C0784F] X-Evolution: 00000082-0010 Just one minor quibble: I still say that Markus Schulze's definition of the Clone Criterion is vague. Or at least its intended meaning is different from its literal meaning. If Markus's definition is taken literally, no method can pass it. No matter what the method is, after the new clone is added, one or more voters could believe, maybe rightly, maybe mistakenly, that the addition of that clone calls for some change of voting strategy and they therefore change their ballot because of the addition of the new clone. Someone trying to write a failure example could always easily find some strategy for those voters to change to that would change the matter of whether or not the winner comes from that clone set. So, if Markus's wording is taken literally, no method meets his Clone Criterion. Obviously that wasn't what Markus intended. We want a wording whose literal meaning is what we intend. Here's the Clone Criterion that both I and Cretney use: Deleting from the ballots a member of a clone set and recounting those ballots should never change the matter of whether the winner comes from that clone set. [end of definition] The way Tideman defines a clone set, in terms of actual votes, rather than preferences, suggests that Tideman's Clone Criterion definition is likely to be the same as that of Cretney & me. Other than that minor quibble, I have don't disagree with Norm's letter. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sun Jan 7 04:07:05 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 13016 invoked from network); 7 Jan 2001 04:07:05 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 7 Jan 2001 04:07:05 -0000 Received: (qmail 20889 invoked by uid 1000); 7 Jan 2001 04:06:49 -0000 Date: Sat, 6 Jan 2001 23:06:49 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Message-ID: <978840286.852af85a@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Jan 07, 2001 at 02:13:49AM -0000 X-Evolution: 00000083-0010 On Sun, Jan 07, 2001 at 02:13:49AM -0000, MIKE OSSIPOFF wrote: > Here's the Clone Criterion that both I and Cretney use: > > Deleting from the ballots a member of a clone set and recounting those > ballots should never change the matter of whether the winner comes from that > clone set. > > [end of definition] If you define this Clone Criterion in terms of social preference (as you have for a couple other criterion) then plurality wouldn't pass (as previously unexpressed preferences would show up on the ballot). -- Raul From nkklrp@hotmail.com Sun Jan 7 06:12:22 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 26061 invoked from network); 7 Jan 2001 06:12:22 -0000 Received: from law-f50.hotmail.com (HELO hotmail.com) (209.185.131.113) by qmail.accesscomm.ca with SMTP; 7 Jan 2001 06:12:22 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 6 Jan 2001 21:56:03 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sun, 07 Jan 2001 05:56:03 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, nkklrp@hotmail.com Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Date: Sun, 07 Jan 2001 05:56:03 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Jan 2001 05:56:03.0429 (UTC) FILETIME=[84B0D150:01C0786E] X-Evolution: 00000084-0010 Raul wrote: >On Sun, Jan 07, 2001 at 02:13:49AM -0000, MIKE OSSIPOFF wrote: > > Here's the Clone Criterion that both I and Cretney use: > > > > Deleting from the ballots a member of a clone set and recounting those > > ballots should never change the matter of whether the winner comes from >that > > clone set. > > > > [end of definition] > >If you define this Clone Criterion in terms of social preference (as >you have for a couple other criterion) then plurality wouldn't pass >(as previously unexpressed preferences would show up on the ballot). Quite so, and that's why I'd rather define it that way. But that would require something more complicated. If the criterion's premise is about sincere preferences rather than votes, then I'm leaving it up to the example-designer to configure the votes any way that he wants to. He'll want to find a vote configuration that makes the method fail. ...Just as I can easily write an example that will make any method fail Markus Schulze's Clone Criterion, when Markus's words are taken literally. So what we have to do, to write a good preference-based Clone Criterion, is write the premise of the crirerion so as to constrain the voting in a reasonably realistic way so that the criterion will act as we expect. If one of these preference clone criteria works better, it might be one that's so complicated that it's very difficult to determine compliance & noncompliance with. For that reason, I'm not suggesting that we switch to one of those more complicated preference-based Clone Criteria yet, but let me define a few now. I emphasize that these are just some possible ways of writing such a criterion and that someone else may well write a better one. The crucial thing is how the criterion constrains voting. I emphasize that these preference clone criteria are new, and untested, and I make no guarantee at this time that they work as intended or that they distinguish between Schulze & Plurality. Or even that they're free of unintended ambiguity or contradiction--though I try to avoid those things. For the purpose of the preference clone criteria, substitute stipulation about sincere preference, rather than about voting in the definitions of clone sets. In other words, for instance, we could say: S is a clone set if , for every voter, and for every candidate C, outside of S: If that voter prefers one candidate in S to C, then he prefers every candidate in S to C. If he prefers C to any candidate in S, then he prefers C to every candidate in S. If he's indifferent between C and some candidate in S, then he's indifferent between C and every candidate in S. S must contain more than 1 and less than all of the candidates. [end of definition] I know that this isn't the same as Markus's definition in some other ways. I like treating indifference the same as preferences above & below. Preference Clone Criterion #1 (PCC1): If voters always vote in ways that are not dominated by any other way of voting, then if we conduct an election, and then add an additional member to a clone set, and then conduct another election, with the same voters, and the same candidates, plus the new one, the winner will be a member of that clone set after the addition of that new clone if & only if the winner was a member of that clone set before the addition of the new clone. [end of definition] Definition of a dominated voting strategy: For a particular voter, strategy S dominates strategy T iff it's possible to contrive a configuration of the other people's votes such that that voter prefers S's result to T's result, but it isn't possible to contrive a configuration of the other people's votes such that that voter prefers T's result to S's result. [end of definition] PCC2: Same as PCC1, except that the following stipulation is added to the criterion's premise: A voter doesn't vote differently in the 2nd election from how he voted in the 1st election unless the way that he voted in the 1st election would be a dominated strategy in the 2nd election, with the new clone in the election. [end of definition] PCC3: If voters always vote so as to maximize their utility expectation, then if we conduct an election, and then add an additional member to a clone set, and then conduct another election, with the same voters, and the same candidates, plus the new one, the winner will be a member of that clone set after the addition of that new clone if & only if the winner was a member of that clone set before the addition of the new clone. [end of definition] It's too early to say, but at 1st glance, it didn't look as if PCC1 or PCC2 would distinguish between Schulze & Plurality. Maybe PCC3 will. Requirements for examples for these criteria: The following isn't part of the definition of the criteria, and isn't necessary to write, but I just want to clarify what kinds of examples these criteria would use: The example-writer, of course, may configure any variable that isn't already stipulated by the criterion. That means that, for PCC1 & PCC2, the example-writer can configure the candidates, the voters, and the voters' sincere rankings or ratings of the candidates in any way that he wants to. For the purposes of those 2 criteria, the voters' sincere rankings of the candidates are probably sufficient, without mentioning ratings. For PCC3, the example-writer may configure, any way that he wants to, the candidates, the voters, the voters' sincere ratings of the candidates, and the probabilities perceived by the voters that are relevant to the voters' utility maximization strategy. The example writer could assume that everyone perceives the same probabilities, but there's nothing in the criterion that says that he must assume that. Maybe different voters perceive different probabilities. PCC3, I would expect,would be very difficult to determine compliance & noncompliance with. Complaince, especially would be very difficult to prove, since there are so many ways to write examples, and one would have to prove that there exists no failure example. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sun Jan 7 07:49:16 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 22511 invoked from network); 7 Jan 2001 07:49:16 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 7 Jan 2001 07:49:16 -0000 Received: (qmail 23312 invoked by uid 1000); 7 Jan 2001 07:49:00 -0000 Date: Sun, 7 Jan 2001 02:49:00 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Message-ID: <978850982.f2465dbd@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Jan 07, 2001 at 05:56:03AM -0000 X-Evolution: 00000085-0010 Here's how I'd define the Independence Clone Criterion, using "preferences" and "sincere voting" rather than "ballots": A ballot is said to have a clone set C if the ballot will include options chosen from the set C such that for every other option Z on the ballot and every voter V who will vote on that ballot, V either sincerely prefers every option in C to Z or Z to every option in C. If the voters vote there preferences sincerely, then the decision about whether or not the winner comes from clone set C should be the same regardless of how many options from C appear on the ballot, as long as at least one option from C is included on that ballot. However, looking at plurality, I've got a problem: it's impossible for voters to vote sincerely if they have preferences ranking more than two options unequally. Looking back at Ossipoff's rephrasing of Smith: If every alternative in set S is socially preferred to every alternative outside S, and if everyone votes sincerely, then the winner should come from S. I see that it shares the same flaw. That is: plurality "passes" because whenever the "if" parts are true the winner comes from S. -- Raul From nkklrp@hotmail.com Mon Jan 8 04:08:34 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 23858 invoked from network); 8 Jan 2001 04:08:34 -0000 Received: from law-f78.hotmail.com (HELO hotmail.com) (209.185.131.141) by qmail.accesscomm.ca with SMTP; 8 Jan 2001 04:08:34 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Jan 2001 20:08:31 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Mon, 08 Jan 2001 04:08:31 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Date: Mon, 08 Jan 2001 04:08:31 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jan 2001 04:08:31.0647 (UTC) FILETIME=[A98AC2F0:01C07928] X-Evolution: 00000086-0010 It's necessary to take a longer look at the proposed preference clone criterion definition before I comment, but I'd like to reply to something else in the letter: >However, looking at plurality, I've got a problem: it's impossible for >voters to vote sincerely if they have preferences ranking more than two >options unequally. Looking back at Ossipoff's rephrasing of Smith: > > > If every alternative in set S is socially preferred to every > alternative outside S, and if everyone votes sincerely, then the > winner should come from S. > > >I see that it shares the same flaw. That is: plurality "passes" because >whenever the "if" parts are true the winner comes from S. But here's my definition of sincere voting: A voter votes sincerely iff he doesn't falsify a preference or leave unvoted a sincere preference that the balloting system in use would have allowed him to vote in addition to the preferences that he actually did vote. "preference" means "pairwise preference" [end of definition] That means that voting for one's favorite is sincere in Plurality. Voting for someone other than one's favorite, however, would be insincere in Plurality. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Mon Jan 8 04:15:03 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11553 invoked from network); 8 Jan 2001 04:15:03 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 8 Jan 2001 04:15:03 -0000 Received: (qmail 2514 invoked by uid 1000); 8 Jan 2001 04:14:46 -0000 Date: Sun, 7 Jan 2001 23:14:46 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Message-ID: <20010107231446.A2430@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Jan 08, 2001 at 04:08:31AM -0000 X-Evolution: 00000087-0010 On Mon, Jan 08, 2001 at 04:08:31AM -0000, MIKE OSSIPOFF wrote: > But here's my definition of sincere voting: > > A voter votes sincerely iff he doesn't falsify a preference or > leave unvoted a sincere preference that the balloting system in use ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > would have allowed him to vote in addition to the preferences that ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > he actually did vote. I missed that, sorry. I've got to slow down, I think [and fight off this fever]. Thanks, -- Raul From bmbuck@14850.com Mon Jan 8 06:03:43 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 15053 invoked from network); 8 Jan 2001 06:03:43 -0000 Received: from syr-66-24-47-66.twcny.rr.com (HELO zaphod) (66.24.47.66) by qmail.accesscomm.ca with SMTP; 8 Jan 2001 06:03:43 -0000 Received: from 14850.com (localhost [127.0.0.1]) by zaphod (Postfix) with ESMTP id D150F156FE; Mon, 8 Jan 2001 01:03:39 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 (debian 2.2-1) with nmh-1.0.4+dev To: Raul Miller Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: What voting methods are we actually considering? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 08 Jan 2001 01:03:39 -0500 From: Buddha Buck Message-Id: <20010108060339.D150F156FE@zaphod> X-Evolution: 00000088-0010 I've seen lots of argument about ICC, and how ICC applies to Plurality. Unless we are actually planning on considering Plurality, I fail to see why it is germane to the conversation. Here are some voting methods that I have seen discussed that may be worthy of consideration: The first two are interpretations by me and Raul (on a different list) as to what the current Debian voting method is. It isn't clear right now because there are contradictory provisions. Raul and I differ on which provision is the "bug" in the intended procedure. Condorcet-Only (CO): If there is no Condorcet Winner, "Further Discussion" wins. If there are multiple Condorcet winners (due to ties), the Project Leader casts a deciding ballot. Smith Instant Run Off (SIRV): Use IRV on the members of the Smith Set to choose a winner. If that fails to find a unique winner, the Project Leader casts a deciding ballot. The rest are methods described on this list and others... Sequential Schwartz Dropping (SSD): Considering only members of the innermost unbeaten set, drop the weakest defeat. Repeat until there is an undefeated option. Schultz' Method (Schultz): The winner is the option that has a beatpath win over all other options. Tideman's Method (Tideman): Order all defeats from strongest to weakest. Eliminate the first defeat that forms a cycle with previous defeats. Continue until there is an undefeated option. I'm uncertain as to the benefits and detriments of these (and other) methods. For instance, I don't know when these various methods break down. I've been told, for instance, that Tideman doesn't always choose a winner from the Smith Set. When does it fail to do so? Or, more generally, when do these methods choose different results, and why? How likely are these cases? -- Buddha Buck bmbuck@14850.com "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice From nkklrp@hotmail.com Mon Jan 8 07:41:21 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7847 invoked from network); 8 Jan 2001 07:41:21 -0000 Received: from law-f91.hotmail.com (HELO hotmail.com) (209.185.131.154) by qmail.accesscomm.ca with SMTP; 8 Jan 2001 07:41:21 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Jan 2001 23:41:18 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Mon, 08 Jan 2001 07:41:18 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: bmbuck@14850.com, moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: What voting methods are we actually considering? Date: Mon, 08 Jan 2001 07:41:18 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jan 2001 07:41:18.0818 (UTC) FILETIME=[635E7420:01C07946] X-Evolution: 00000089-0010 >I've seen lots of argument about ICC, and how ICC applies to Plurality. > Unless we are actually planning on considering Plurality, I fail to >see why it is germane to the conversation. Ok, there's meaning in applying ICC to compare 2 rank methods, in spite of ICC's inability to compare Plurality to them. So I agree on that. But when people talk of why we want a clone criterion, they're talking about different scenarios than the one that my & Cretney's wordings directly speak of. So: Because the only easily usable ICC wordings that we have don't really refer directly to the kind of situations that are our reasons for wanting a clone criterion, I suggest that, in order to use ICC to compare methods, it's essential to look at methods' worst ICC failures. How bad do they look? How likely are they? I think PCC3 is the clone criterion that is closest to what we really mean when we speak of what we want a clone criterion for. But PCC3 might be very difficult to apply to rank methods. For now we have the ordinary ICC. If we use it, let's allow for its weakness described in the previous paragraph by studying how bad and how probable the failure examples look, instead of just judging a method by the fact that it can fail ICC. Actually, the best rank methods might fail PCC3 unless that criterion is modified so as to require that voters know that the new clone is a clone. For a clone criterion to require that voters have specific knowledge about the other voters seems to violate both the letter & the spirit of the clone criteria. I'm not suggesting that we use PCC3, but if it's true that the best rank methods, including Schulze, fail it, then, if PCC3 really comes closest to saying what we'd like a clone criterion to say, then that could mean that what we really would like a clone criterion to ask for is unattainable, which would be an embarrassment for ICC. I'm just saying, then: "When we use ICC, let's use it by evaluating failure examples on an individual basis, rather than just going by the criterion's rulings." That concludes my arguments against ICC. Mr. Buck is saying "Enough. Let's get on with comparing the methods." I have no objection to that. Buck's list of method proposals seems a complete one, unless there will later be interest in some simpler, but slightly less meritorious, Condorcet versions. >I'm uncertain as to the benefits and detriments of these (and other) >methods. For instance, I don't know when these various methods break >down. I've been told, for instance, that Tideman doesn't always choose >a winner from the Smith Set. When does it fail to do so? Tideman doesn't fail to choose from the Smith set, but it can fail to choose from the initial Schwartz set. The Schwartz set is the set of alternatives that are in innermost unbeaten sets. That can happen only when there are pairwise ties. When there are no pairwise ties, the Schwart & Smith sets are identical. Debian votes might have few enough voters to allow a pairwise tie, and so Tideman's ability to fail in that way is probably significant. Having defined the Schwartz set, I can write SSD's definition more briefly: Drop the weakest defeat among the current Schwartz set. Repeat till there's an unbeaten candidate. [end of definition] But let's drop Tideman from the list. Both Norm & I, the ones who brought it here in the first place, agree that it isn't as good as SSD or Schulze. It would simplify the list to drop Tideman. Returning to a previous comment and pasting it to a subsequent one: >I'm uncertain as to the benefits and detriments of these (and other) >methods. For instance, I don't know when these various methods break >down. Or, more generally, when do these methods choose different results, >and >why? How likely are these cases? That's the whole subject of voting system merit. I don't know if others agree, but I like the idea of first comparing the 2 best EM proposals, SSD & Schulze, and then, whichever of those looks the best, compare that to the non-EM proposals. Though good voting systems can let us vote on all the proposals in one balloting, as we of course eventually will, discussion can be a lot more convenient when done piecewise. It would seem chaotic to try to discuss & compare all the proposals simultaneously, applying the same (rather long) list of criteria to all of them. The advantage of starting with just SSD & Schulze is that it's only by a relatively few criteria that they differ. Different criteria will distinguish between different pairs of methods, and so proceeding piecewise seems easier, since fewer criteria are being used at any one time, to compare fewer methods. When we compare SSD &/or Schulze to the Condorcet-Only or SIRV, for instance, I'll mention a number of convincing criteria that the latter 2 fail, but which SSD & Schulze pass. But, unless there's a specific procedure laid down, any comparisons of proposals are in order, and so let me say what I consider to be the differences of SSD & Schulze: Schulze passes ICC, but SSD fails it. Failure examples for SSD are needed, so that we can evaluate how bad they look and how likely. Are Schulze ties more convenient to deal with than SSD ties? If so, examples are needed. Schulze may be marginally better, in terms of pure merit. Examples will show how much better. Norm is the one who has those examples. Norm knows more than I do about the ICC failures & the ties. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Mon Jan 8 08:16:26 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11991 invoked from network); 8 Jan 2001 08:16:26 -0000 Received: from law-f4.hotmail.com (HELO hotmail.com) (209.185.131.67) by qmail.accesscomm.ca with SMTP; 8 Jan 2001 08:16:26 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Jan 2001 00:16:23 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Mon, 08 Jan 2001 08:16:23 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, stevegr@debian.org Subject: Re: Independence of Clones Criterion - Justification Date: Mon, 08 Jan 2001 08:16:23 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Jan 2001 08:16:23.0814 (UTC) FILETIME=[4A0B5A60:01C0794B] X-Evolution: 0000008a-0010 >Here's how I'd define the Independence Clone Criterion, using >"preferences" and "sincere voting" rather than "ballots": > > > A ballot is said to have a clone set C if the ballot will include > options chosen from the set C such that for every other option Z on > the ballot and every voter V who will vote on that ballot, V either > sincerely prefers every option in C to Z or Z to every option in C. > > If the voters vote there preferences sincerely, then the decision > about whether or not the winner comes from clone set C should be > the same regardless of how many options from C appear on the ballot, > as long as at least one option from C is included on that ballot. > > >However, looking at plurality, I've got a problem: it's impossible for >voters to vote sincerely if they have preferences ranking more than two >options unequally. Yes, so my definition of sincere voting would be the one to use. Raul's Clone Criterion seems similar to Cretney's & mine, but Plurality fails Raul's criterion, when my sincerity definition is used. The only sincere Plurality vote is a vote for one's favorite candidate on the ballot. Markus should have stipulated sincere voting. Raul's Clone Criterion appears to be the convenient & contradiction-free one to use. Because Raul's criterion doesn't specify that it's about deletion of a clone, it applies more directly to the kinds of scenarios that we speak of when we tell why we want a clone criterion. We could say that the matter of the winner being in the clone set shouldn't change when we add another clone, for instance, and that's implied by Raul's criterion wording. So the awkwardly different scenario of the deletion definition can be avoided by stipulating sincere voting, and without going to the extra complication of undominated voting or utility-expectation-maximizing voting. I still think utility expectation maximization is what really comes closest to what we'd like, but it might be awkward to use. The sincerity clone criterion avoids both of my main objections: the inapplicability to Plurality, and the different kind of scenario. Though its stipulation of sincere voting isn't always entirely realistic in political elections, it might be a good assumption at Debian. Besides, Condorcet's Criterion & the Smith Criterion require that same assumption when they're written for universal applicability. Now, Norm: Which kind of Clone Criterion has Schulze been proved to pass and SSD to fail?: Deletion or sincere voting? The sincere voting surely seems, among the convenient versions, the Clone Criterion that we should use. But if I determine a result of PCC3, I might just mention it too. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Thu Jan 11 05:21:44 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7593 invoked from network); 11 Jan 2001 05:21:44 -0000 Received: from f251.law10.hotmail.com (HELO hotmail.com) (64.4.14.76) by qmail.accesscomm.ca with SMTP; 11 Jan 2001 05:21:44 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 10 Jan 2001 21:21:41 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 11 Jan 2001 05:21:40 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca, nkklrp@hotmail.com Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: SSD ICC failure example Date: Thu, 11 Jan 2001 05:21:40 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jan 2001 05:21:41.0099 (UTC) FILETIME=[61193BB0:01C07B8E] X-Evolution: 0000008b-0010 Here's an example in which SSD fails the Clone Criterion: I'm using Raul's preference clones/sincere voting clone criterion: Say that B, C, & D are clones, but we start with just A & B in the election. They're pairwise-tied. And so we randomly choose a winner, and we choose B. But then someone says, "Wait, there are 2 more people who want to run, friends of B." So the election is repeated with all 4 candidates. B, C, & D are in a circular tie. So this time A is initially the only unbeaten candidate, and so there's no tie. A wins. Adding B's 2 friends to the election has made B lose. This could also be written in terms of the voted clones/deletion version of ICC. If we did this election by Schulze, the tie would remain, since there's no beatpath between A & the clone set. So, with SSD, B loses because 2 of his friends, very similar to him, have joined the race. That sounds bad, but notice that it requires 3 pairwise ties. Out of 6 pairwise comparisons, half are tied. How likely is that?How much of a problem is that going to be really? Are you going to strategically modify your voting or your candidate nominations based on the fear that that is going to happen? In general, SSD & Schulze produce the same result when there are no pairwise ties or equal defeats. And we can say that Schulze will pick a unique winner, as opposed to returning a tie, if there are no pairwise ties or equal defeats. So those conditions that make Schulze free of tied elections will also make SSD & Schulze elect the same candidate. I said I agreed with Norm's letter about the justification of the clone criterion. But I don't really agree when he says that failing the clone criterion creates strategy problems or spoiler problems. If the problems can only occur when there are pairwise ties, then are you going to be strategically influenced by something that can happen only with pairwise ties or equal defeats? I doubt it. How often does Debian have pairwise ties & exactly equal defeats in its elections? My example requires 3 pairwise ties. Half of all the pairwise comparisons tied. Norm, can you make SSD fail the clone criterion with fewer pairwise ties? Another thing. Norm can verify this, or you can verify it in the EM archives: Perhaps a month ago, I was criticizing the Condorcet Criterion because, in its universally-applicable version, its premise stipulates sincere voting by everyone. You say that doesn't matter, if we use its other version, about a _voted_ CW? It still matters, because even if there's a sincere CW, truncation can & often will make it so there won't be a voted CW. The same objection applies to the Smith Criterion & the Clone Criterion. If we use the voted-clone-set definition of ICC, truncation can create, eliminate, or modify clone sets so that where there was a preference clone set there's no voted clone set, or vice-versa, or the clone set is different. But this objection doesn't apply to Debian if Debian doesn't have any truncation in its elections. If there could be significant truncation, that takes much of the meaning away from the Clone Criterion. Truncation, of course, needn't be strategic. Non-strategic truncation takes place all the time. I only ranked a few of the altenatives in my 1st ballot for the previous poll, for instance. So: Two reasons why SSD's ability to fail ICC doesn't matter: 1. It only happens when there are pairwise ties or equal defeats, and, in fact, so far, it has only been demonstrated here to happen\ when there are 3 pairwise ties, half of the total number of pairwise comparisons. 2. Unless Debian won't have a significant amount of truncation, the clone criterion loses its meaning because its preference clone set depends on sincere voting, and voted clone sets lose meaning when preference clone sets, the kind that relate to the similarity of candidates, get created, eliminated, or modified by truncation. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Thu Jan 11 12:40:59 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1711 invoked from network); 11 Jan 2001 12:40:59 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 11 Jan 2001 12:40:59 -0000 Received: (qmail 25192 invoked by uid 1000); 11 Jan 2001 12:40:38 -0000 Date: Thu, 11 Jan 2001 07:40:38 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: SSD ICC failure example Message-ID: <979216471.346f5f81@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Thu, Jan 11, 2001 at 05:21:40AM -0000 X-Evolution: 0000008c-0010 On Thu, Jan 11, 2001 at 05:21:40AM -0000, MIKE OSSIPOFF wrote: > That sounds bad, but notice that it requires 3 pairwise ties. Out of > 6 pairwise comparisons, half are tied. How likely is that?How much of > a problem is that going to be really? Are you going to strategically > modify your voting or your candidate nominations based on the fear > that that is going to happen? I don't know how likely this is. I should note, however, that the technical committee has up to 8 members and a quorum of 2. [votes can involve only 2 voters, though 3-4 are more likely.] I should add that things are already rather non-optimum, for the to technical committee get involved. -- Raul From npetry@accesscomm.ca Thu Jan 11 23:35:40 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 25580 invoked from network); 11 Jan 2001 23:35:40 -0000 Received: from static24-72-33-128.reverse.accesscomm.ca (HELO aule) (24.72.33.128) by qmail.accesscomm.ca with SMTP; 11 Jan 2001 23:35:40 -0000 From: "Norman Petry" To: "'Anthony Towns'" , "'Buddha Buck'" , "'Mike Ossipoff'" , "'Norman Petry'" , "'Raul Miller'" , "'Rob Lanphier'" , "'Steve Greenland'" Subject: Truncation in Voting Methods (was: RE: SSD ICC failure example) Date: Thu, 11 Jan 2001 17:35:37 -0600 Message-ID: <001a01c07c27$33f5f620$4d01a8c0@archives.gov.sk.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001B_01C07BF4.E95B8620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal X-Evolution: 0000008d-0030 This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C07BF4.E95B8620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Sorry I've been out of touch for the past few days (busy, busy...) Anyway, I thought I'd just pick up on one of Mike's points that caught my attention before returning to the issue of clone independence: > Another thing. Norm can verify this, or you can verify it in the > EM archives: Perhaps a month ago, I was criticizing the Condorcet > Criterion because, in its universally-applicable version, its premise > stipulates sincere voting by everyone. You say that doesn't matter, > if we use its other version, about a _voted_ CW? It still matters, > because even if there's a sincere CW, truncation can & often will > make it so there won't be a voted CW. [...] Intuitively, one would expect that when truncation increases, the probability of having a 'voted' Condorcet winner would go way down. However, my simulations suggest that this is not the case -- what does drop significantly is the probability that the voted CW is the social utility-maximising candidate. In order to assess the effects of truncation on voting methods, I devised a simulation based on concepts I call 'accuracy' and 'involvement'. I've attached a copy of some notes I include with my simulator (also available, if you're interested) which explain these terms and describe the model I'm using. You should probably read that first to make sense of what follows. I've also included one particular simulation result (for 100 voters, 7 candidates, 25,000 elections, and a one-dimensional policy space) which show the Condorcet-winner phenomenon, as well as the results of truncation on a variety of voting methods (in Excel spreadsheet format, as well as .csv and .png formats for the data and graph -- if you need another format, please let me know). Notes regarding the Graphs and Data: 1) Note from the graph that the probability of having a Condorcet winner is consistently higher than 90% (see the line labelled 'CWs'), even when Involvement is as low as 0.1 -- in that case, most voters will only be ranking 1-2 candidates out of the 7, and still there is a high probability of having a CW. If you are interested in the frequency of Smith Sets of sizes other than 1, that information is available in rough form at the end of the data table. 2) Methods are listed in the graph in order of overall performance (average accuracy score over involvement in the range of 0.1 - 1.0). Refer to the data table for details. 3) All pairwise methods yield very similar, 'S' shaped curves, and when there is no truncation (Involvement = 1.0), the accuracy of these methods is excellent (>95%). This demonstrates clearly that pairwise methods respond rationally to additional information about voters' preferences -- the more that is known about these preferences, the higher the accuracy. Because of the high probability of a CW at all levels of Involvement, pairwise methods *must* show very similar performance curves since they are all constrained to satisfying the Condorcet winner criterion (and therefore must choose the same winner >90% of the time). 4) When involvement is low, the voted CW is not always going to be the median candidate, so pairwise methods are constrained to performing worse (assuming sincere voting) than methods like Borda or Bucklin which violate the Condorcet winner criterion but respond more strongly to initial preferences. This is not surprising, of course -- in my spatial model, the ideal compromise candidate is determined using sincere preferences, yet truncation causes most of this preference information to be hidden. When there *are* preferences, but they are not expressed, it obviously becomes difficult for any method to pick the best option. 5) Small differences can be noted within the members of the pairwise family that I have shown here. One noticeable result is that methods which use winning-votes (here -- Schulze(wv), SSD(wv)) slightly out-perform methods using margins (Tideman(m)) under middling levels of involvement. The other thing to note is that Schulze and SSD yield almost exactly identical response curves (not surprising). Note that there are results for a few other pairwise methods (Copeland, SD, Minimax) in the data table which were not included in the graph, in case you are interested. 6) Bucklin, Borda, and Approval are clearly misusing preference information, since they decline in accuracy once individual preferences are specified beyond a certain point (about 0.3 for Bucklin, 0.5 for Borda, and 0.8 for Approval). This is clearly an irrational response from a voting system, which ought to always become *more* accurate as more is known about voter preferences, not less. 7) Analysis of Approval is problematic, since it is necessary to assume that all voters use one particular strategy, which will not be the case in practice. Here, following Mike's suggestion I have assumed that voters approve of candidates they consider better than average. Wildly different response curves can be obtained by assuming different strategies (not shown), so any results for Approval must be taken with a large grain of salt. 8) Runoff and Instant Runoff (aka Majority Preference Voting, the Alternative Vote, single-winner STV,...) respond rationally to preference information, but they are low-accuracy single-winner methods compared to the pairwise family. Instant Runoff is distinctly inferior to a conventional 2-stage runoff (which makes one wonder what reformers in the US hope to gain by by replacing Runoff with IRO in public elections...) 9) Plurality is worse than all methods except Random Ballot. Neither of these two methods are able to improve as accuracy increases, since they only use first preferences. Please let me know if you have any questions or would like simulation results assuming other parameters (more candidates, more dimensions, etc.) Otherwise, I'll try to get out my final comments on the clone issue this evening or tomorrow morning at the latest. -- Norm Petry ------=_NextPart_000_001B_01C07BF4.E95B8620 Content-Type: text/plain; name="accuracy.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="accuracy.txt" This is an excerpt from an e-mail I sent to the EM list which describes=20 the approach I took to simulating voting methods. Reading this might help to understand the VoteSim code... Norman Petry, 5AP00 ----------------- From: Norman Petry To: election-methods-list@eskimo.com Subject: Re: [EM] Why Margins isn't as democratic or ethical as Date: February 8, 2000 9:36 AM Hi Everyone, [...] Still, it seemed like an interesting theory, and one which could be analyse= d empirically. Therefore, I constructed a computer simulation to compare the two methods on the basis of accuracy in the presence of varying degrees of truncation in order to test your assertion. Methodology: For my model, I decided to use ratings as the standard by which to compare each method's results. For each trial, I first created a set of voters represented as points normally distributed in an n-dimensional "issue-space". I then did the same thing for candidates, but used a unifor= m distribution. Ballots were then constructed for each voter by computing th= e "distance" between the voter and each candidate in the issue-space. Each candidate's rating was represented by this distance, so that low ratings corresponded to most-preferred candidates. Rankings could obviously inferred by sorting on these ratings low-high. To compute the ratings winner, I simply summed the ratings between every voter and each candidate to determine a total score, and then declared the candidate with the lowest score the ratings winner. Effectively this method can be seen as minimisin= g the total "error" involved in picking a given candidate, or choosing the candidate with the minimum average distance to all the voters. A more complex heuristic could be devised, of course, but this seemed a simple and reasonable way of determining the "best" choice in a single-winner contest. To simulate the effects of truncation, I constructed a random number generator based on a binomial pdf for n candidates. A value from this generator would be used to determine the number of rankings that would actually be expressed by a given voter when they cast their ballot in the pairwise election. Truncated candidates would simply be ranked equally lowest (the usual assumption on this list). By varying the per-trial probability in the binomial pdf, I could easily construct simulations havin= g as much or as little truncation in the ballots as I wanted. For example, a binomial pdf of B(n,p) =3D B(6,0.5) would select 0 to 6 candidates, and on average rank 3 of them. By changing the value of p, I could skew the distribution to allow different types of electorates to be simulated. I called this my "involvement" index. Lazy electorates would have a low valu= e of p (generally ranking 1 or 2 candidates), and "involved" electorates migh= t always rank them all (p=3D1.0). Once the pairwise matrix was calculated, I simply applied Schulze's method, then the Path Voting method to the matrix, and counted the number of times each method produced the "right" answer (i.e.: ratings result). The rating= s winner was always determined by using *full* ballots (no truncation). This simulation has many variables, of course. Since I wanted to see how each method would respond to varying degrees of truncation, I made the following assumptions for the simulation shown here: candidates =3D 6 voters =3D 100 dimensions =3D 2 (dimensions of "issue-space") trials =3D 10,000 voter distribution =3D normal(SND) candidate distribution =3D uniform(-2..2) involvement =3D 0.1 .. 1.0 Here are the results of my simulation run based on the above parameters (best viewed in a mono-spaced font): Involvement Schulze PathVoting Schulze% PathVoting% 0.1 6,647 6,651 66.5% 66.5% 0.2 7,510 7,500 75.1% 75.0% 0.3 8,121 8,118 81.2% 81.2% 0.4 8,566 8,564 85.7% 85.6% 0.5 8,868 8,863 88.7% 88.6% 0.6 9,078 9,077 90.8% 90.8% 0.7 9,214 9,226 92.1% 92.3% 0.8 9,249 9,255 92.5% 92.6% 0.9 9,305 9,314 93.1% 93.1% 1.0 9,262 9,265 92.6% 92.7% Average: 8,582 8,583 85.8% 85.8% Note that although the two methods do not always produce the same results, they are almost identical in accuracy over the entire range of possible values for involvement. It may be possible to observe slightly better results in Schulze under low involvement (0.2-0.6) and slightly better results in Path Voting when involvement is high (0.7-1.0), but the differences are negligible (under 0.1% in all cases), and may only be a limitation of the simulation (perhaps I need 100,000 elections to make sure= , but this one took about 8 hours and I'm not that patient!). Of course, a simulation like this tells us little about how a method will perform under actual use, since the degree to which voters expressed preferences match their sincere preferences will depend on how manipulable the method is. For example, this simulation also gives quite good results for Borda (not shown), yet the ease with which voters can gain a better result by nominating clones or "turkey raising", etc. ensure that sophisticated electorates using Borda will generally not reveal their true preferences, so the entire election result becomes suspect. The strategy-resistance of Schulze appears to be better than that of Path Voting, so we can expect the accuracy of Schulze to be considerably better than Path Voting in practice, even though Path Voting appears equally good (although no better) in theory. I have repeated this simulation using different values for most of the abov= e variables, and have found only small differences in accuracy between Path Voting and the Schulze method, regardless of the parameters chosen. Thus, = I conclude that the Schulze method equals Path Voting in accuracy under sincere voting assumptions. I will be making my simulation software available to members of the list in a few days so you can run your own simulations to (hopefully!) confirm thes= e results. In addition to Schulze and Path Voting, I have also simulated a number of other methods which have been of interest to members of this list= , and I'm hoping that peoples' experiments with this software will provoke some interesting discussion here on EM (I'm cleaning up the code a bit before distributing it, which is why you're not getting it today -- write t= o me if you're impatient!). [...] Sincerely, Norman Petry ------=_NextPart_000_001B_01C07BF4.E95B8620 Content-Type: application/octet-stream; name="Involvement - 25k, 7, 1, 100.csv" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Involvement - 25k, 7, 1, 100.csv" Involvement,CWs,Schulze(wv),SD(wv),SSD(wv),Minimax(wv),Tideman(m),Copeland,= Borda,Runoff,Bucklin,Approval,Instant Runoff,Plurality,Random Ballot,Smith = Set Sizes 0.1,23042,13242,13241,13241,13242,13229,13272,13901,13283,13961,11107,13281= ,13100,7148,"[23042, 1156, 515, 179, 77, 23, 8]" 0.2,23213,14031,14026,14026,14025,14011,13975,15543,14036,15729,13058,13792= ,13553,7269,"[23213, 682, 607, 263, 151, 65, 19]" 0.3,22942,14833,14826,14826,14822,14703,14722,17040,14767,17516,13904,14212= ,13652,7180,"[22942, 523, 625, 415, 276, 171, 48]" 0.4,22775,16495,16485,16485,16483,16272,16278,18726,15773,17574,14858,14681= ,13811,7141,"[22775, 428, 720, 484, 312, 196, 85]" 0.5,22978,18401,18396,18396,18397,18133,18123,19897,16780,15938,15695,15102= ,13903,7314,"[22978, 444, 658, 460, 278, 130, 52]" 0.6,23444,20414,20413,20413,20413,20193,20104,20188,17610,14961,16584,15428= ,13856,7231,"[23444, 449, 557, 333, 148, 45, 24]" 0.7,23926,22092,22089,22089,22088,22009,21863,19787,18307,14746,17597,15605= ,13798,7133,"[23926, 480, 357, 160, 64, 12, 1]" 0.8,24238,23329,23329,23329,23329,23325,23239,19551,18758,14734,18186,15921= ,14019,7341,"[24238, 535, 176, 43, 7, 0, 1]" 0.9,24120,23768,23768,23768,23768,23767,23711,19581,18808,14895,17609,15981= ,13885,7193,"[24120, 739, 114, 23, 3, 1, 0]" 1.0,24061,23879,23879,23879,23879,23879,23813,19955,18799,14756,15831,15784= ,13722,7326,"[24061, 826, 96, 16, 1, 0, 0]" Totals:,234739,190484,190452,190452,190446,189521,189100,184169,166921,1548= 10,154429,149787,137299,72276, ,,,,,,,,,,,,,,, Trials:,25000,,,,,,,,,,,,,, Candidates:,7,,,,,,,,,,,,,, Dimensions:,1,,,,,,,,,,,,,, Voters:,100,,,,,,,,,,,,, Involvement,CWs,Schulze(wv),SD(wv),SSD(wv),Minimax(wv),Tideman(m),Copeland,= Borda,Runoff,Bucklin,Approval,Instant Runoff,Plurality,Random Ballot 0.1,92.2%,53.0%,53.0%,53.0%,53.0%,52.9%,53.1%,55.6%,53.1%,55.8%,44.4%,53.1%= ,52.4%,28.6% 0.2,92.9%,56.1%,56.1%,56.1%,56.1%,56.0%,55.9%,62.2%,56.1%,62.9%,52.2%,55.2%= ,54.2%,29.1% 0.3,91.8%,59.3%,59.3%,59.3%,59.3%,58.8%,58.9%,68.2%,59.1%,70.1%,55.6%,56.8%= ,54.6%,28.7% 0.4,91.1%,66.0%,65.9%,65.9%,65.9%,65.1%,65.1%,74.9%,63.1%,70.3%,59.4%,58.7%= ,55.2%,28.6% 0.5,91.9%,73.6%,73.6%,73.6%,73.6%,72.5%,72.5%,79.6%,67.1%,63.8%,62.8%,60.4%= ,55.6%,29.3% 0.6,93.8%,81.7%,81.7%,81.7%,81.7%,80.8%,80.4%,80.8%,70.4%,59.8%,66.3%,61.7%= ,55.4%,28.9% 0.7,95.7%,88.4%,88.4%,88.4%,88.4%,88.0%,87.5%,79.1%,73.2%,59.0%,70.4%,62.4%= ,55.2%,28.5% 0.8,97.0%,93.3%,93.3%,93.3%,93.3%,93.3%,93.0%,78.2%,75.0%,58.9%,72.7%,63.7%= ,56.1%,29.4% 0.9,96.5%,95.1%,95.1%,95.1%,95.1%,95.1%,94.8%,78.3%,75.2%,59.6%,70.4%,63.9%= ,55.5%,28.8% 1.0,96.2%,95.5%,95.5%,95.5%,95.5%,95.5%,95.3%,79.8%,75.2%,59.0%,63.3%,63.1%= ,54.9%,29.3% =0D ------=_NextPart_000_001B_01C07BF4.E95B8620 Content-Type: image/png; name="Involvement - 25k, 7, 1, 100.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Involvement - 25k, 7, 1, 100.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAAP8AzP8A//+A AAD/AP+AgICZzP//mcz//5nAwMDM/8zM//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACyajQcAAAgAElEQVR4nO2di5akKLZAmenqvHMnu/z/z53K8MVLRTnAAfdeVfEw FJBw50EFwkwAoAXTugAAsIGPAHrARwA94COAHvARQA/4CKAHfATQAz4C6AEfAfSAjwB6wEcAPeAj gB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR+rYUzxyr7M 4WkROEwqQUVXo2Mfy5ccZqjoWvw5posf1vjYO1R0LSwfzRoqlxfzu5/HZSXjrbG92Z+WBzfobknY q9g5bolti7eimT2CO4tNmA0Ug2quxe6jMZswtm77kW/8NQ583Nfb81gXmsDbfStn8bRvYr+1FuNj PajmSjgWbOZYhuyLHOGCmOZ8bC0Nk/CT8dO6/txZEypARVfCb0GGL5wD32mnRjbcAliQyZ6YtZ7z ob15EEj9xfhYFSq6EnZzcFvkvHBOFD0frdau/ebg/HHCx16houtgnZ9d++g1ZJcPo29i549bkpc+ 2vmHjVN8rA8VXYct8B2eP5pQpsmOXrZ4xlvPzsX6aF/PeOlHtA8zxcf6UNF1sHzcWqNWs9RvIvpr bA6tqbnr7dEy6qOdY7B48n2c/JX9KAzloJqr4DcNLSG2Z+/8MVzVTi4i1HTso5WRv9gqlP+58yEH ShWo5k5AiFfAt9wFNBhfAt9yF6DjS+BrBtADPgLoAR8B9ICPAHrARwA94COAHvBxcrvJ2L22vV40 9l3ArX+42/k69sbbwl1wUS47KXflyy/O3ZF9F662i6dxtUq8jqLJcMidQOVE+pMeLLU/zvYx0DNa sEMfL00xgY9B7/Nrrtf2/5K5dRRLhjupZ1A5036gBl1E526k/ot9leMkLz+I9BK/SObWUe0G+qRN nrBbGKujaMb4eAaVs3eb9rpsb0v9F+4qy0fhyIhI+AuD3R5dtjLs/cft7uFuDsYWIZKXMbG8zPbf 8WaLcW7D3aqEYAUvm4M6cny0A6iXaUrb/SVQCQtmnUZqfz+5h9ixj8Y+qvajPjzI4o1PazOv3bf6 6K8R0dLNK9rQ9UrmbDzZuccyd1bwszmqI09qq8hu5rG6eifUwUxg0C0fp/1gt6PQSVMtCMV7wNpe 2Wpb77zUD/I699FJPJL7wdpH2Vz7GNkFL1M/4XdCHXxwosGyZHlM8NF5Y0ehIJfYS3czywhX7TAH N2yGu+S/Cv9ShMHQLfpRofxsUnx0UgkyRcYZquEH+3DI8TFs53nZxF56m537GGlJxvPK8XHak83z 0V905GOs/O+ESpg2Hb0wtDze8NFtAwZ/9iPWT1tITvMxbGVaiR/Jf+Wjs5pT9II++qVEyA/UgX28 rke8/SZ84W0XOdSixsTeRE4Kbe9M7J0TZY7yivjob+tmdbIfTuYHPh7XkVedsZJHy/9OqIPJOKdh 9nFqtQWdF9uG1tO+iYm8sdf3c/XXjCzzSmj2+BVNwcttzSru42R/FCu6ia3gZXNSR/sfu32NMFNv s9dCHfhmzIusN5EX64bW076Jid2MnCbnKJ6sz73NrMhpO2rcHKatwE5aZz5uSz0fJ+PmGyRnghXC bI7raN97O1S6mVp18XKohCii1VKzjivlxWFTCCo2Cj6qyOZ9ULEx0FFFNi+EmgXQAz4C6AEfAfSA jwB6wEcAPeAjgB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLo AR8B9ICPAHrARwA94COAHvARQA/4CKAHfATQAz4C6AEfAfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE 0AM+AugBHwH0cM/Hz9rmD/vTtDxKFwzghdzyaPZw3my1cPsHALncEWmWEB8BSnG/vRrzER0BJMj2 8dOIxUcACfJ9nJ/MlpBZ+D8AnUjJUwAhH70Yab4BtDK6j+ElHXwEveAjgB7G8tHvD7AudNZrXeUA h4zjY3Kqrasc4BB8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA/4CKAHfIR38a8kWpUOH2FknprW ylV8hJGo4U5ahH3mMT5C72hoZ6aQ4iw+Qo/04uBd8BG6YVAHbfARlDOwhH8H4CPopHMLQ9UihJvh I2iit2B4Q7Uk8BE00JGFEtodgo/Qkk48LKmgAz5CEzrwsJaDNvgIdVEvYn0JLfAR6qC+ZdpSww18 hLKo93A1sXUpPuAjFKGP+xaKTJzBRxCkn9uHX9pMnMFHyKcbCz98falU8QM+nnM1Pqajw1CeDvdf s4s/4KPNU9PepWin+/il3cUf3uxjUYmGk7PrvenCxR/e52OL46rjY7nfkm/MMrYuRRrv87Ht9Zw+ GrUdFDGVXgLjAj62RNF5p4pCSNOXiz/gozJqGjqigjv9NFIt8FE9kSB6z6K8rfuku8C4MJiP5g/7 07Q8uqu0rnJJzlx9g3ZxOnXxh7F8XPRbLdz+Oeu0rnIoyq9+ZfzGRxiKXx2Hxg/j++ingo+j0uUF HI/xfDS7j5/zR3x8BV99t1NXxvLx50KOFR+XJ2Osjz+0rnWQ5av7durKYD7Om7k+ejESGcfi6+vX GKHxw+g+hpd08HEgZhmHsXE0H82064ePozOcjN+j+Tht/QDMpqN9/vh517rKQYIfGQdqp64M5mNK qq2rHLL5GjE0fsBH6IxxZfzGR+iLr0HbqSv4CN2wyjisjfgI3TC+jN/4CH3wCY3fg8v4jY/QAXM7 9QU24iOoZ5XxBTbiI+hmbqe+IjR+wEdQy9erQuMHfASlzDK+JzR+wEdQySzjy2zER9DIfNL4qobq Aj6CNl4aGj/gI6hikfGdNuIjqOJrlfGdNuIjKOLdofEDPoIOfr09NH7AR9DALOOrQ+MHfIT2YOMK PkJjaKha4CM0hdDogI/QEGz0wEdoxS9sDMBHaMMiIzY64CO0ABvj4CPUZ2uoYqMHPkJlOG08AR+h KjRUT8FHqAg2XoCPUItf2HgJPkIddhmx8Rh8hBoQGtPARygODdVk8BEKs8qIjQkM5qP5w/40LY/u Kq2r/F1g4y3G8nHRb7Vw++es07rK3wQ23gQfQYZ/J9G6lNoZ30c/FXyUIMG06EUc7DxnLB+XE8ft rNGE4REfH3PLpKRLqojpM5aPXnxcnsyWkFloXeu9cVuauzc4EHPhBT56MRIZ7/DIkozbjW9uy/7s 9eg+hpd08DGNp1ZI3fx/jZjOjuIjBGRoUOAGx5gh82CvxvLR7w8wWb0CtlUafQGdkHXcF77dOMDF 2avSD+ZjSqpV678nco/yyjf//x1QI9dnJBcRH+GH/MNZwXiq0NDGit4vBj6CxHGrdQRHbUNz88LH dyNzhGq1MUYkiN7z5yyB7LrEx/ciFS16svGcU9WqBFh8fCdyB9Y4NmoAH1+I4B95bJQFH9+GZIsL G6XBx1chevqDjfLg43uQvRaBjSXAx5cgfGFw74sjmSrg4xuQvkrPtDilwMfhEb9lho3lwMexkb9/ jY0lwceBKdCZBBvLEvfRNAQfRSjSs2uzkcs4hTjwsYgJSeCjAGV6WVo2omMh8HE4CnV5HtjGv/SA j2NRavzBUDb6ErQujwU+DkSxwUAD2KjUPx98HIZiI/O6tbETB21yfFzmcrO2EDAIHx9RbpxsdzZ2 56BNho+LjJE5wbN0uVmK+xm0rnJ5Cg5a78jGji3cee6jPd/w4qOEQPh4l4IzSPRh4wgeruT6OPk+ GpOnET7eomho1G7jSCIuSPuYHSbxMZ2SkyvtMuqzcYiWaRwBHzcZRZqs+JhKyZnOlNo4rocrJz7+ 6xjXFttH2quVeJmNw4u4IHA9x/UxceuLZPPTOc6gdZVLUNDGL2U2Spv4T4hc4tnk3+9wHzl/LE/J 08Yv+yJOWxvlGqdX8ilSNL8/wORZSXu1LCUbql86LqnKhcTHcrVyk/5yfTG4jQpMLJrUJfjYEyUb qm1tFLxyWkifOlbiYzcUPm3cJ+Koa6Pg9ZoKypTOAR87YcCGal8merkVSnosH9cZeNZ5eEykl3uX Pg5mo+Q9jEaXQwvlOpaPy1ZmfzZBMt35+PuczNQr2yh6N7H1zcMC2eOjSmzhLmJjjpXWRZzip43C 9/W13McXLsdwPm4dElYZ/VSU++jpldpQfWKlY+O9TW9RpIeNXHL5CBZnaB8/54/d+BhR6u5p4x0r q9go3etUnYorUsUazUfjPswxch8atiBSdYLENXp6ESfFyfI2vkbFFZHivcBHL0ZqlDGyNPNu46mT X4VtFB+LoV3Flfxy5vQnP5vdP5KCf13lINWbpYhtbZyXqn080Ebk/saBk1/7zX/5izhFVOzCxZW8 4kqMt4ptE6YQLIln8iYfj2KY4N3GIItyoVF+hGJvKq5kFHtIH7f+AJPVK2BbRbLmn3PYoBTvFmdn VMjGAoOFe3Vx4WnpRebrWOZh3aZjXYLSYsU2Tev2sfX+LOtx+8sdn9yV6YizZFfCxhLj9jt3ceHR PuSdP24rm+3eguOaJ+iEj9/nMhbrFvcnz91GqdPGElNojOHizIM9ybu+ak1QPrlBMObj51qn2e/S v9LH48ueJfuo/pHx9+/NRoH0ikxnM5KLM7f358THr2OcNY99XM7ejMHHhWY2/lxS/QTmfBvLzCw1 noszN/dKaH7yKeajc8UHH9s0VL/t08a/M7ufF5rkbVQXZ27tm9jvBZz6aAdMK3JeZD2Wj41kdE4b z4pxQan5Fsd2cebGHkr0BzD2hdVpa54G11df7GPtC6obno1zWW6mUWzq0ze4OJO8n/X6ywVpxjMZ 0cd2oXG10b2imj4SpNwsxO9xcSZxb/GxOEcHf2EZrX5xkWs410YWnBD8bS7OJO1zxf7k5vRtZPEI Ph6GosIyxhqqLmdGFpyb/50uziTs+WjjOxIyqFDxK61C47WNP8RLh4sFudx/fCxHrQ6qAQenjSF+ CXGxOBfVgI+lOBpIVVpG28brlbdSFj5dxMWds8rAxzIUHNZ4ytctG3/4U1LCYmWOKwUfS1BixH8K 2yXV9B7jf1TMnjMyDmHxjIOqwUd5Ysd3BRnvNVR/2OKitJGomEC0hvBRmriNhTO931D12qj5Eyuv oGIykZrCR1mi08TVCY3JDdWDSzf5RhIWb+PXl1D/1bWjqvsLrffSC1btz8fwkK4h452G6umlm4wg iYpPcatNbLyVO+bxSYLBmr35GBzNlWRMtTHlMuoTI1ExD7v2xH2Mj2x8gY/+kVxFxuSGavotjVtB krAowl6HAvNZeS+MM/7xdK6ci6x78jG0sUg2Hmmh8fbtxTQlUVGQtSoF5rNyJrZ6p4/Bz26osfHp rf5zJQmL8swVKjCf1fbCabimzM1xkXUvPrqHbjUZv64aqpndbuJKDq3if+V4kPtPvZ74+OuYiDP+ ieRrfHSO2koy2qeN8RVkusB5Sg6horBEotn880+R6zkv8tE+YGvJeNVQFe2OuijZa1gs6txTTgpV 5H5H+GJQH50fTq0m45mNhWYL70ZFhfalsJW3SH+Ad/hoNeaqyXh6f6PkzP1y/enk6dC/Q8r0l3vB /ccHvymez3FoLPODNk5YVKXkSA7a4OMj2oTGIxtL/ORitIXaTslO26G3KdSffOj+q/tRWU/Gw4aq bGC8PldM+TH0XO5ckhwMxnfcpYWMBw1VSRePg2KIqJMvli8CPt7DsjG/8lOJ2Sjo4qMLqA+VRL5z 8PEG2zFYNzSGHXHEXMy6l5ESJrHvHviYTAsZIx1xhALjnfbpCTEn8e85g/lo3Qmd34bpPPRxt1Gu 8i/xQ6OMi9I3+H+cxEEZxvJx0W+1cB9qYq/zpJoWG6uGxtVGS8b8NAVVdNqhv2tcd30BA/o4Sfu4 HGm1ZVxt/HknERglwuJ5GMTJbMb30U/lro9baJSv/EO+ltPGT2gUcDFLxXtN0d9Eyhwe+2hmHAUS dTndINPH9cdgl/6zYXi86WOD0LjK+L3ImJncExWzL4li5UNy4mOKXsepHmyR5+M60muyY+U2anr9 I5Kq5HxIVb65scn4d3ZgvBMWS9yVwMrbDObj/OD66MXI5Pi4hsZyle8xuzjLmOtikop1Lor+/o2X yWT7uDQLl7sMswBbTLKXTMGHV1lL+Bhe0kn0sXZo3AJj/i9NnavY7MbE799dm/n7Hg9zkfDR7Cdq 68tdA++du+551u18/NRnCxnLhUVNdwdFjtyi5Av20FUhH8Mn+/wt/KCQj35/gKWITkLXPi6h8eYX 8JT1lLFIWOzhJn2BKJNdgmb5nfj49zHWWnYYNMbXzl5Sw8cErnysGRoXFz8qJv9CXAQ/LHZgYRpn rsrRei+t/RSOj5Oj23Hg1Orj79nGGl/Bx8W/FhWfy2irOIyG76Voe9U7sZy0+1gtNP64OLdP/851 8RsNR0Lo+up61jZ5ypm4qCp9rBQaFxP/+txizFCxh1NDuEvN/nLm5F1scU0ffxqqxUPjouKvXxlh EQuHplcfrd+avFuKSC1UCI2rin8/VHHVsJ+pUOEBVfuTm4PXB+uc+njx+cmWQR2UDo1z+/ShiVs4 7GpaYnhIh+M75nsoYvHxY2Oh2s0x0W6WouJb6NDHyb/DfzMDe/d/l7Jxv5Fx20Tv/BAX30SfPq7X ch9lsO98kYaqZeK9DSMXanDxbXTo4/5zIc8yWHddPDSuJt7a6PC2BS6+kR59PP4oKYPPfv9pqAqG xvWOYhrXQw1x8a306OPjSznz5t+SoTHVxPShhrj4Zjr0MTeDb5nQmGDi7aGGuFie/yTRqnTv8/HH xrw6uzLxWRcaXCzAY9NaGZrx+8gH7cZMi4r7mGPjcsUm+tnz/qRCU4XnkRY2VMeWshLV2VGB3yt/ sO1lshIpHWXwrKKOTMzqT1rHxNoSVcqv/R+CAvuHj5dEg2Jut24hE2urJkdSyfvbrY2HuyDh4zZr 1TrAKuNufeX+OeeENxTzR1f8c9vEfo9JuCD8QgXOH9fhjcEA5Ge6pJQi55ZHko+uiTJDDdNExLlX IxAfI8ONE5O4yPpyvNWjPK58XLu7CQ419EzsuBUGhTnx8d/H7LYcDP/PCF/Rl9E1n+Vy7OMaFO9r mHSygHJwSZH4WLy9usZHKR9nE+94mGCYgpsY0BulfCwbHzcV8320RLyurdQYp+GGIvSIRH+A/bLO PrNV6es5Nwrqb7vuerqIt1qaqAjP6bS/XEaL+I+PW8v0fGzU/RM+XIQ8+vQxZ/zj7OGJiQ+vu+Ai 5NOpjxefn3GkYs7lT1wEGd7no3s9J/8uBC6CHJ36+Lw7wOyj0L1AXARZ+vQxp8Oc2C15XARxOvUx JwOZikNGKAA+PgIboQid+ph7/pgFDVUoRZ8+Zl/PyQAZoRyd+pjRQSfLR0IjFEV+Pqvt42cdaFJ9 NNHPlzLtPWvDdDJ8REYojPz8OdunD8NXSiks5Q4LZax/zipPqwoboTh9+ng4oquYjzRUoQaS4x+t 0VcZ02ncK0V0Y8dHP5UnPiIj1EHQR+PaWbi9Gl++nD6u68TOMu/7iI1QC8H55fynFj7OD/ZVHKdl u87ycaeGsBHqceLjX8es6xjrRVUfz9rDvo9eUe7FR2yEmmS2V1vFx2Qfw6Lc8REboS59+nhRJiEf sRFqI/R7AcZS01hm3ifLx30+LWPf+XASSvURG6E+nfaXK95/FRuhBfgYBRuhCX36mJXBdaUQHKER PftYKD5iIzSjTx8LtlexERrSs48PMzirDmyEpvTpY1YGx5WBjdCYTn005x+fZnBUFdgIzenTx5zf 7zjwERtBAZ36ePH5aQaxasBGUAE+fmMjqEF8Pitr2OEzXVJKIXq/AxtBDeLz55gpvjxZl6RSyN3v wEZQRKc+ZuD4iI2gCrn5c/aBVvugwwdzsNa834GNoIwS8+dYr+6fRta734GNoA7J+R6XBWZf/iCM 1bq+io2gkBMffx/jOOH5aHrwERtBJQXiY9hyvaVLSiky73dgIyhF1sfg/DExrXjWhe53YCOoRaI/ wD6J1BRcXy3kYwbYCHrps7/c/LFQ/xwANfTqY8vfKwcoRZc+5kwPgI+gmA59tH/E6kkGrasc4JAu fTz79DqD1lUOcEiXPhIfYVA69JHzRxiWLn2cuL4KY9KrjxP3H2FAOvbxaQatqxzgEHwE0EOWjzeE SV4VH+HF5PhobhiDjwDX4COAHgR8XCat2p+WoVfryKttGFZiojdLEUtgHwkWpoOPoJcMH7fRjstY R+dpkdVsVt7R6U4pgu3XzJxBmPYKrasc4BAJH7eD3x6CbKz2LD4CJHHi4z/HzAe+1ZH0xMebvU0z fTST76OfCj6CXkrMn+P4WLm96vgYnf8VH0Evj30027N3/jgF/yvGR6uFarWVt4SWmI6SoBQJH73r q9N6TXV9XTE+xnz0ckdG0ItAfznjPOWS5eNySmv5GF7SwUfQy1g+LlvhI3TKkD5u/QG2FrP9eesq BziE8R0AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9JA7viNNgfPZi42xu3w/yuEG+Ah6EfQx 3Mg4z0eJmiMJ8RHeBj4C6CHLx7WdOc8AYMy0PU77ksny0cS3sxuz+AgvJs9H41q2v3SHVQQ++tsR HwF+yIyPtk3m6IM9BJrgY3wE2Dnx8b/HTI5Q9hSrwRRXa3LGeoGPAFEk4qP3Lu7jwcf4CLAj1V4N Tg7xEeA2IvFxvbQ6P7hq7skta8baufgI8AP95QD0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLo AR8B9ICPAHrARwA9ZPRftQc1xlJ4phM+wovJnT/nyDtjPd7T5V4pHmTQusoBDsFHAD3I+LgNmzLO ICpncFWqLvdKcR98BL3I+ugPMrbGICfrcq8U98FH0IvM9ZxwPgBr3L+5JRY+wos58fE/xzi2eD5u UwC08NFss8AuZQnTwUfQi8D85K6PQXu1po92fm4hrHVaVznAISV89OLjPa/y26v4CN0i46M1T9U+ o5WJtxdTk5Xy0U8FH0EvNfrL1fTR+rsw7Rd8nTVaVznAIaP5ONnxcXmyflxyoXWtA8Qp7+PJD7Fe ZC3koxcjkRH0MuD4DsfH8JIOPoJexvLRu98x4eMV/3+P1sW9y83dq72jYb5j+ej3B9iu+NqriNWd 8i87aRfyU9Cze5HStUvqYU0N5mNKBmJ195g6+RXdhXsZF6nOyvuXtFfZZXmfj0WOjQLc/P472auN 7N1Tvn8PeZ+PnD+CXvARQA/4CKAHgfGPNzb3t4l1Z7tXivvgI+hFYH6AG5v72xjvzYSP8GrwEUAP Ej6u03ZsY/L9hVsTNdxmf2OCwVn4CG9DaL5HM9mjkL2FexR05lA21r89UuIjvBih6zmuVcGTNfjJ eYOPADYnPp50jVjXWRSy51lN9NGf9QofAbLbq27bM91H2qsAEWR8vB0f3fPNCR8BfpC5vuqotw15 mkIft3NOe9ardV2zJ5tcivvgI+iF/nIAesBHAD3gI4Ae8BFAD/gIoIcDHxuCj/Be4j7qAB/hbeAj gB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoYTAfzTo11jZr VpAOPoJexvJx0W+1cJ/Bzl6ndZUDHDKWj8tm+AidMr6Pfir4CHoZ2kf7p7X2j1tXOcAh4/lopsm+ imOm/ecnt3mBWtc6QJzhfNx+nWDz0YuRyAh6Gc1H4z5ELungI+hlMB+t38jCR+iPsXxcZ3Dd5nG1 egVs67SucoBDxvIxKdXWVQ5wCD4C6AEfAfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE0AM+AugBHwH0 gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA/4CKAHfATQAz4C 6AEfAfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE0AM+AugBHwH0MJyPn43MH+bnMB18BL2M5uPHwNXC 7Z+zRusqBzhkMB/NhI/QMYP5OIU++qngI+hlaB8/rVd8hH4Y28f5yWwJmYXWtQ4Q5wU+ejESGUEv o/sYXtLBR9ALPgLoYUgft/4A6ztnhdZVDnDIcD5ep9q6ygEOwUcAPeAjgB7wEUAP+AigB3wE0AM+ AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA/4CKAH fATQAz4C6AEfAfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4AexvTR /GF+DtPBR9DLkD6uFm7/nA9bVznAIfj4HEGzKVT9pHQWKk+Zosj46Kcy+hcqlhKFapDU0D5+zh/x sX1SFCo5pRxhCpPv4/xktoQMgG5ypSmIkI9ejJTbY8G6o1D1kxq9UOJI+Bhe0lFZdxSqflKjF0oc fGyaEoVqkNSQPm79ASarV0B+qkEuYilRqAZJjV4ocTSXDeBt4COAHvARQA/4CKAHfATQAz4C6AEf AfSAjwB6wEcAPcj66HSez0raSim3R75cUu7mkoXKSKtITeWOg1D59VlfmdpRHqKlcmbSyTvy95Sc RJsm5W4utX+ZX0GZmpJLSc/XZ31l2SkVo5iP4aQBT1PyXrZLqgsfZZLKTE6nj/sh+UIfM/+SeQno 81Hs703mN1DMx+GaN5P95eWmVIqX+Zh3UuSkJHbAZp6pWSnl7V6hry/3nH1PykyZrRJ8lElJidpe I1NHAHHMzkrJ/3uTQZn4+Plzg483Eyvgo9SxkZlYGR/lCiV56Kv0MTMpfJRJKa+MZQ59uVamYKHy UvL/3mSAj0/pwMfMIhZpGuYlVKq9mlkq7T5mNsetrV/i43rubn0T+SllT9FnFUoupUls/wQLJXTr Pf+4L1Wo3Jv4m4fv6A8AAFngI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA/4 CKAHfATQAx5OwJ0AAADySURBVD425WSUgdIBCFAUvvSmCPrINzkCfItNkfORcDoEfItNMZ8B1+vT +n59GV20LPZWUzvAFm7Bl9iURSVbvtXN6KJdSHcZ8XEQ+Bab4prlvz1YdPgfuodvsSmpPs7NUS8u Bsuge/gWm5IeHyNrB8uge/gWm+LYtF2gOVtEe3Vo+BabEpHPunAaW2SvbS9DyCHgSwTQAz4C6AEf AfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNAD PgLoAR8B9ICPAHrARwA94COAHvARQA/4CKCH/wEiiDyU4QQEZgAAAABJRU5ErkJggi== ------=_NextPart_000_001B_01C07BF4.E95B8620 Content-Type: application/vnd.ms-excel; name="Involvement - 25k, 7, 1, 100.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Involvement - 25k, 7, 1, 100.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOAAAAAAAAAAA EAAA/v///wAAAAD+////AAAAADcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAPIVzAdJAAAABgAAAOEAAgCwBMEAAgAAAOIAAABcAHAADAAATm9ybWFuIFBldHJ5ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAD0BCAAFAAEA AgADAJwAAgAOABkAAgAAABIAAgAAABMAAgAAAK8BAgAAALwBAgAAAD0AEgDgATsBnDbAITgAAQAA AAEAWAJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3AQIAAADaAAIAAAAxABoAyAAAAP9/kAEAAAAA AAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAFAP9/ vAIAAAECAAAFAUEAcgBpAGEAbAAxABoAyAABAP9/vAIAAAACAAAFAUEAcgBpAGEAbAAxABoAyAAA AP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoA8AABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAxABoA yAABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAeBBgABQATAAAiJCIjLCMjMDtcLSIkIiMsIyMwHgQd AAYAGAAAIiQiIywjIzA7W1JlZF1cLSIkIiMsIyMwHgQeAAcAGQAAIiQiIywjIzAuMDA7XC0iJCIj LCMjMC4wMB4EIwAIAB4AACIkIiMsIyMwLjAwO1tSZWRdXC0iJCIjLCMjMC4wMB4ENQAqADAAAF8t IiQiKiAjLCMjMF8tO1wtIiQiKiAjLCMjMF8tO18tIiQiKiAiLSJfLTtfLUBfLR4ELAApACcAAF8t KiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAiLSJfLTtfLUBfLR4EPQAsADgAAF8tIiQiKiAjLCMj MC4wMF8tO1wtIiQiKiAjLCMjMC4wMF8tO18tIiQiKiAiLSI/P18tO18tQF8tHgQ0ACsALwAAXy0q ICMsIyMwLjAwXy07XC0qICMsIyMwLjAwXy07Xy0qICItIj8/Xy07Xy1AXy0eBAgApAADAAAwLjAe BAkApQAEAAAwLjAl4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1 /yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAU AAEAKwD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAA APgAAAAAAAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAEACQD1/yAAAPgAAAAAAAAA AMAg4AAUAAUApAABACAAAAwAAAAAAAAAAMAg4AAUAAUAAwABACMAABwAAAAAAAAAAMAg4AAUAAUA AAABACMAABgAAAAAAAAAAMAg4AAUAAUAAAABACAAAAgAAAAAAAAAAMAg4AAUAAAApAABACAAAAQA AAAAAAAAAMAg4AAUAAAAAwABACMAABQAAAAAAAAAAMAg4AAUAAYApAABACAAAAwAAAAAAAAAAMAg 4AAUAAYAAAABACAAAAgAAAAAAAAAAMAg4AAUAAYAAAABACMAABgAAAAAAAAAAMAg4AAUAAAAAAAB ACMAABAAAAAAAAAAAMAg4AAUAAAApQABACMAABQAAAAAAAAAAMAg4AAUAAUAAAABACMAABwAAAAA AAAAAMAg4AAUAAAAAAABACMAABQAAAAAAAAAAMAg4AAUAAYAAAABACMAABwAAAAAAAAAAMAg4AAU AAAAAQABACMAABQAAAAAAAAAAMAgkwIEABCAA/+TAgQAEYAG/5MCBAASgAT/kwIEABOAB/+TAgQA AIAA/5MCBAAUgAX/YAECAAEAhQASAC0OAAAAAgoATGluZSBHcmFwaIUADAAuLAAAAAAEAERhdGGF AA4A7EoAAAAABgBTaGVldDKFAA4A6UsAAAAABgBTaGVldDOMAAQAAQACAK4BBAAEAAEEFwAIAAEA AAABAAEA/ABuAi4AAAAfAAAACwAASW52b2x2ZW1lbnQDAABDV3MLAABTY2h1bHplKHd2KQYAAFNE KHd2KQcAAFNTRCh3dikKAABUaWRlbWFuKG0pCAAAQ29wZWxhbmQFAABCb3JkYQYAAFJ1bm9mZgcA AEJ1Y2tsaW4IAABBcHByb3ZhbA4AAEluc3RhbnQgUnVub2ZmCQAAUGx1cmFsaXR5DQAAUmFuZG9t IEJhbGxvdA8AAFNtaXRoIFNldCBTaXplcyIAAFsyMzA0MiwgMTE1NiwgNTE1LCAxNzksIDc3LCAy MywgOF0jAABbMjMyMTMsIDY4MiwgNjA3LCAyNjMsIDE1MSwgNjUsIDE5XSQAAFsyMjk0MiwgNTIz LCA2MjUsIDQxNSwgMjc2LCAxNzEsIDQ4XSQAAFsyMjc3NSwgNDI4LCA3MjAsIDQ4NCwgMzEyLCAx OTYsIDg1XSQAAFsyMjk3OCwgNDQ0LCA2NTgsIDQ2MCwgMjc4LCAxMzAsIDUyXSMAAFsyMzQ0NCwg NDQ5LCA1NTcsIDMzMywgMTQ4LCA0NSwgMjRdIQAAWzIzOTI2LCA0ODAsIDM1NywgMTYwLCA2NCwg MTIsIDFdHgAAWzI0MjM4LCA1MzUsIDE3NiwgNDMsIDcsIDAsIDFdHgAAWzI0MTIwLCA3MzksIDEx NCwgMjMsIDMsIDEsIDBdHQAAWzI0MDYxLCA4MjYsIDk2LCAxNiwgMSwgMCwgMF0HAABUb3RhbHM6 BwAAVHJpYWxzOgsAAENhbmRpZGF0ZXM6CwAARGltZW5zaW9uczoHAABWb3RlcnM6CwAATWluaW1h eCh3din/ABoECAClBwAADAAUw/oHAABhAARUfAgAAOMAIsmjCQAACgIABAAAAAAAACCXQADH7hAA IJdAADSqQABEx2IAq4U1ZUTDYgBHADSTAABUk/mNNJOHAU9IhwFGW7AbRwL0BEMBnwGBAKABkgAE AAAABAAAAAkQAAABAAAAdjmJARLFYgAAAAAAAAAAAAAAEACiKPe/oigAAE9IAAAYEwIAC3D+/30k 8r8AMGIAoij3v44i8r8AMGIAADBiAAAArpOnh3cFGNCdMIcBAABPSIcBLgcXGQtwPGxCbPiTKAC3 AaIo978QAAAAAQAAABEAAAAhAPAAEQAAABBgDQIQAAAAGSXyvwAwYgAGAAAAMAlUMPzDYgC2PQAw AAAAADAJVDAuBwAAAAAAAGmHcDBuOYkBBAAAAArFYgAEAAAAAQAAAAQAAAAKxWIAbjmJAQQAAAAB AAAAAAAAAHM5ADAAAAAAAgAAAMjWYgAGAAAAkMRiAAAEAAABAAAAzD9BAMfuEACIOYkBtAZUMLjE YgB0AAAAAAAAAAIAxzAAAMUwzD9BAAAAAABNhTVlAQATAAAAAAB/em0wDgDHMNEAAAD6xGIA/AAA AAkAAACdRQQwAADFMOyjxzDRAAAA+sRiAP0AAAD6xGIA/MZiAN+/AzD6xGIAiDmJAQAAAAD8xmIA dAAAAAAAAACGqQ4wAAAAAPjEYgAHAAAA/////7ACiQE4x2IAAAAAAAcAUABlAHIAYwBlAG4AdAAA AAAAAAAwAF0AAAAHAAAA5wYDAPiVAABeCZ8GEAIAAAAAAAAAALaVFxn0nIwziQEBAAAAjMZiAAAA AAAEAAAAAQAAANzunTAAAAAAWACHAIjGYgABAAAA/xAAMMZ7VDCCgVQwrogQMIKBVDAjAAAAJQAA ADgCiQEQAIcAyMViAAIAAAAxoQ4wJQAAAICBVDAsAokBAAAAAAgAhwD8AYcAAQAAAAEAAAA4AokB AAAAAAEAAAAAAAAAMAAAAAEAAAAMxmIAgZ8OMAsAAAAAAAAAJQAAAAAAAAAGAocAOsdiADjHYgAI AIcAAQAAAAwAAADua1QwAAAAAGUQADCge1Qw7ASJAEwAAAD/EAAw7ASJAKB7VDBMAAAA7mtUMBbH YgAcx2IAAAAAAAAAAAAAAAAAjocQMAkEAAAAAAAAAAAAACYAAABY52IA6p0OMKjGYgABAAAAxbn3 v7hsbIEBAAAA2qxwMDjXnTCbrHAw1R8AMIjGYgAEAAAAjDOJARADiQGUag0CjDOJARADiQFTXQ4w jDOJAURZiQEIAIcAAAAAAPTGYgAIAAAAFwAAABTHYgAsA4kBQMdiACWFEDA4x2IACAAAAAgAAAA4 x2IAlmEOMBcAAAAIAAAAdgWIAQgAhwAAAAAA/sJiAP//CgAAAAkIEAAABiAA8hXMB0kAAAAGAAAA FAAFAAIAACZBFQAKAAcAAFBhZ2UgJlCDAAIAAACEAAIAAAChACIAAAAAUAEAAQABAEYBdmFsDgAA AAAAAOA/AAAAAAAA4D8JADMAAgADAAEQAgAAAAIQEAAAAAAAAAAAADAKqwIwCtMBMxAAAKAABAAT ABQAZBAIAAAAAQAAAAEAAxAMAAEAAQAKAAoAAQAAADMQAABREA8AAAIAAAMABwA6AAASAAEADRAK AAAAAwFDAFcAcwBREBMAAQIAAKUACwA7AAATABwAAQABAFEQEwACAgAApAALADsAABMAHAAAAAAA URAIAAMBAAAAAAAABhAIAP//AAAAAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAK AAoAAQAAADMQAABREA8AAAIAAAAABwA6AAASAAIADRAaAAAACwFTAGMAaAB1AGwAegBlACgAdwB2 ACkAURATAAECAAClAAsAOwAAEwAcAAIAAgBREBMAAgIAAKQACwA7AAATABwAAAAAAFEQCAADAQAA AAAAAAYQCAD//wEAAQAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACgAKAAEAAAAz EAAAURAPAAACAAAAAAcAOgAAEgADAA0QEAAAAAYBUwBEACgAdwB2ACkAURATAAECAAClAAsAOwAA EwAcAAMAAwBREBMAAgIAAKQACwA7AAATABwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wIAAgAAADMQ AABfEAIAAAA0EAAARRACAAAAQxAEAP//AQA0EAAAAxAMAAEAAQAKAAoAAQAAADMQAABREA8AAAIA AAAABwA6AAASAAQADRASAAAABwFTAFMARAAoAHcAdgApAFEQEwABAgAApQALADsAABMAHAAEAAQA URATAAICAACkAAsAOwAAEwAcAAAAAABREAgAAwEAAAAAAAAGEAgA//8DAAMAAAAzEAAAXxACAAAA NBAAAEUQAgAAADQQAAADEAwAAQABAAoACgABAAAAMxAAAFEQDwAAAgAAAAAHADoAABIABgANEBgA AAAKAVQAaQBkAGUAbQBhAG4AKABtACkAURATAAECAAClAAsAOwAAEwAcAAYABgBREBMAAgIAAKQA CwA7AAATABwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wQABQAAADMQAABfEAIAAAA0EAAARRACAAAA NBAAAAMQDAABAAEACgAKAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAEgAIAA0QDgAAAAUBQgBvAHIA ZABhAFEQEwABAgAApQALADsAABMAHAAIAAgAURATAAICAACkAAsAOwAAEwAcAAAAAABREAgAAwEA AAAAAAAGEAgA//8FAAcAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAoACgABAAAA MxAAAFEQDwAAAgAAAAAHADoAABIACQANEBAAAAAGAVIAdQBuAG8AZgBmAFEQEwABAgAApQALADsA ABMAHAAJAAkAURATAAICAACkAAsAOwAAEwAcAAAAAABREAgAAwEAAAAAAAAGEAgA//8GAAgAAAAz EAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAoACgABAAAAMxAAAFEQDwAAAgAAAAAHADoA ABIACgANEBIAAAAHAUIAdQBjAGsAbABpAG4AURATAAECAAClAAsAOwAAEwAcAAoACgBREBMAAgIA AKQACwA7AAATABwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wcACQAAADMQAABfEAIAAAA0EAAARRAC AAAANBAAAAMQDAABAAEACgAKAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAEgALAA0QFAAAAAgBQQBw AHAAcgBvAHYAYQBsAFEQEwABAgAApQALADsAABMAHAALAAsAURATAAICAACkAAsAOwAAEwAcAAAA AABREAgAAwEAAAAAAAAGEAgA//8IAAoAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQAB AAoACgABAAAAMxAAAFEQDwAAAgAAAAAHADoAABIADAANECAAAAAOAUkAbgBzAHQAYQBuAHQAIABS AHUAbgBvAGYAZgBREBMAAQIAAKUACwA7AAATABwADAAMAFEQEwACAgAApAALADsAABMAHAAAAAAA URAIAAMBAAAAAAAABhAIAP//CQALAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAK AAoAAQAAADMQAABREA8AAAIAAAAABwA6AAASAA0ADRAWAAAACQFQAGwAdQByAGEAbABpAHQAeQBR EBMAAQIAAKUACwA7AAATABwADQANAFEQEwACAgAApAALADsAABMAHAAAAAAAURAIAAMBAAAAAAAA BhAIAP//CgAMAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAKAAoAAQAAADMQAABR EA8AAAIAAAAABwA6AAASAA4ADRAeAAAADQFSAGEAbgBkAG8AbQAgAEIAYQBsAGwAbwB0AFEQEwAB AgAApQALADsAABMAHAAOAA4AURATAAICAACkAAsAOwAAEwAcAAAAAABREAgAAwEAAAAAAAAGEAgA //8LAA0AAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAABEEAQADgAAACQQAgACACUQIAACAgEAAAAA APH+///e////AAAAAAAAAACxAE0AIBAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAAAmEAIA BwBREAgAAAEAAAAAAAA0EAAAJBACAAMAJRAgAAICAQAAAAAA8f7//97///8AAAAAAAAAALEATQAg EAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAHAFEQCAAAAQAAAAAAADQQAABGEAIA AQBBEBIAAABtAQAAeAIAAJELAABwCwAAMxAAAE8QFAACAAIAmgAAAC0CAACXDAAAkAwAAB0QEgAA AAAAAAAAAAAAAAAAAAAAAAAzEAAAIBAIAAEAAQABAAAAYhASAAAAAAABAAAAAQAAAAAAAABvADQQ AAAdEBIAAQAAAAAAAAAAAAAAAAAAAAAAMxAAAB8QKgAAAAAAAAAAAAAAAAAAAPA/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAHQFOEAIACQA0EAAAJRAgAAICAQAAAAAAcwYAAL0OAACAAQAAlwAAAIEA TQAAAAAAMxAAAE8QFAACAAIAAAAAAAAAAABOAAAAFgAAACYQAgAJAFEQCAAAAQAAAAAAAA0QGgAA AAsBSQBuAHYAbwBsAHYAZQBtAGUAbgB0ACcQBgADAAAAAAA0EAAAJRAgAAICAQAAAAAAMwAAACsH AABnAAAACgIAAIECTQAAAFoAMxAAAE8QFAACAAIAAAAAAAAAAAAWAAAASAAAACYQAgAJAFEQCAAA AQAAAAAAAA0QGAAAAAoBQQBjAGMAdQByAGEAYwB5ACAAJQAnEAYAAgAAAAAANBAAADUQAAAyEAQA AAADADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAAAQAAABYACAA0EAAAFBAUAAAAAAAA AAAAAAAAAAAAAAAAAAAAMxAAABgQAgAAACIQCgAAAAAAAAAAAA8AFRAUAGUNAAA8BQAAKAIAAOEF AAADAR8AMxAAAE8QFAAFAAIAZQ0AADwFAAAAAAAAAAAAACUQIAACAgEAAAAAAPH+///e////AAAA AAAAAACxAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABREAgAAAEAAAAAAAA0EAAA NBAAAAYQCAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8JAE0AChAQAP///wAAAAAAAQAB AE4ATQALEAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQAAAA0EAAANBAAADQQAAAlECAA AgIBAAAAAABxBAAAUgAAAL4GAABKAQAAgQBNADAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAH0BAAAw AAAAJhACAAgAURAIAAABAAAAAAAADRCeAAAATQFBAGMAYwB1AHIAYQBjAHkAIAB2AHMALgAgAEkA bgB2AG8AbAB2AGUAbQBlAG4AdAAKADIANQAsADAAMAAwACAAVAByAGkAYQBsAHMALAAgADcAIABD AGEAbgBkAGkAZABhAHQAZQBzACwAIAAxACAARABpAG0AZQBuAHMAaQBvAG4ALAAgADEAMAAwACAA VgBvAHQAZQByAHMAJxAGAAEAAAAAADQQAAA0EAAAAAIOAAAAAAAKAAAAAAAMAAAAZRACAAIAAwIO AAAAAAAAAJqZmZmZmbk/AwIOAAAAAQAAAJqZmZmZmbk/AwIOAAAAAgAAAJqZmZmZmbk/AwIOAAAA AwAAAJqZmZmZmbk/AwIOAAAABAAAAJqZmZmZmbk/AwIOAAAABQAAAJqZmZmZmbk/AwIOAAAABgAA AJqZmZmZmbk/AwIOAAAABwAAAJqZmZmZmbk/AwIOAAAACAAAAJqZmZmZmbk/AwIOAAAACQAAAJqZ mZmZmbk/AwIOAAAACgAAAJqZmZmZmbk/AwIOAAAACwAAAJqZmZmZmbk/AwIOAAEAAAAAAJqZmZmZ mck/AwIOAAEAAQAAAJqZmZmZmck/AwIOAAEAAgAAAJqZmZmZmck/AwIOAAEAAwAAAJqZmZmZmck/ AwIOAAEABAAAAJqZmZmZmck/AwIOAAEABQAAAJqZmZmZmck/AwIOAAEABgAAAJqZmZmZmck/AwIO AAEABwAAAJqZmZmZmck/AwIOAAEACAAAAJqZmZmZmck/AwIOAAEACQAAAJqZmZmZmck/AwIOAAEA CgAAAJqZmZmZmck/AwIOAAEACwAAAJqZmZmZmck/AwIOAAIAAAAAADMzMzMzM9M/AwIOAAIAAQAA ADMzMzMzM9M/AwIOAAIAAgAAADMzMzMzM9M/AwIOAAIAAwAAADMzMzMzM9M/AwIOAAIABAAAADMz MzMzM9M/AwIOAAIABQAAADMzMzMzM9M/AwIOAAIABgAAADMzMzMzM9M/AwIOAAIABwAAADMzMzMz M9M/AwIOAAIACAAAADMzMzMzM9M/AwIOAAIACQAAADMzMzMzM9M/AwIOAAIACgAAADMzMzMzM9M/ AwIOAAIACwAAADMzMzMzM9M/AwIOAAMAAAAAAJqZmZmZmdk/AwIOAAMAAQAAAJqZmZmZmdk/AwIO AAMAAgAAAJqZmZmZmdk/AwIOAAMAAwAAAJqZmZmZmdk/AwIOAAMABAAAAJqZmZmZmdk/AwIOAAMA BQAAAJqZmZmZmdk/AwIOAAMABgAAAJqZmZmZmdk/AwIOAAMABwAAAJqZmZmZmdk/AwIOAAMACAAA AJqZmZmZmdk/AwIOAAMACQAAAJqZmZmZmdk/AwIOAAMACgAAAJqZmZmZmdk/AwIOAAMACwAAAJqZ mZmZmdk/AwIOAAQAAAAAAAAAAAAAAOA/AwIOAAQAAQAAAAAAAAAAAOA/AwIOAAQAAgAAAAAAAAAA AOA/AwIOAAQAAwAAAAAAAAAAAOA/AwIOAAQABAAAAAAAAAAAAOA/AwIOAAQABQAAAAAAAAAAAOA/ AwIOAAQABgAAAAAAAAAAAOA/AwIOAAQABwAAAAAAAAAAAOA/AwIOAAQACAAAAAAAAAAAAOA/AwIO AAQACQAAAAAAAAAAAOA/AwIOAAQACgAAAAAAAAAAAOA/AwIOAAQACwAAAAAAAAAAAOA/AwIOAAUA AAAAADMzMzMzM+M/AwIOAAUAAQAAADMzMzMzM+M/AwIOAAUAAgAAADMzMzMzM+M/AwIOAAUAAwAA ADMzMzMzM+M/AwIOAAUABAAAADMzMzMzM+M/AwIOAAUABQAAADMzMzMzM+M/AwIOAAUABgAAADMz MzMzM+M/AwIOAAUABwAAADMzMzMzM+M/AwIOAAUACAAAADMzMzMzM+M/AwIOAAUACQAAADMzMzMz M+M/AwIOAAUACgAAADMzMzMzM+M/AwIOAAUACwAAADMzMzMzM+M/AwIOAAYAAAAAAGZmZmZmZuY/ AwIOAAYAAQAAAGZmZmZmZuY/AwIOAAYAAgAAAGZmZmZmZuY/AwIOAAYAAwAAAGZmZmZmZuY/AwIO AAYABAAAAGZmZmZmZuY/AwIOAAYABQAAAGZmZmZmZuY/AwIOAAYABgAAAGZmZmZmZuY/AwIOAAYA BwAAAGZmZmZmZuY/AwIOAAYACAAAAGZmZmZmZuY/AwIOAAYACQAAAGZmZmZmZuY/AwIOAAYACgAA AGZmZmZmZuY/AwIOAAYACwAAAGZmZmZmZuY/AwIOAAcAAAAAAJqZmZmZmek/AwIOAAcAAQAAAJqZ mZmZmek/AwIOAAcAAgAAAJqZmZmZmek/AwIOAAcAAwAAAJqZmZmZmek/AwIOAAcABAAAAJqZmZmZ mek/AwIOAAcABQAAAJqZmZmZmek/AwIOAAcABgAAAJqZmZmZmek/AwIOAAcABwAAAJqZmZmZmek/ AwIOAAcACAAAAJqZmZmZmek/AwIOAAcACQAAAJqZmZmZmek/AwIOAAcACgAAAJqZmZmZmek/AwIO AAcACwAAAJqZmZmZmek/AwIOAAgAAAAAAM3MzMzMzOw/AwIOAAgAAQAAAM3MzMzMzOw/AwIOAAgA AgAAAM3MzMzMzOw/AwIOAAgAAwAAAM3MzMzMzOw/AwIOAAgABAAAAM3MzMzMzOw/AwIOAAgABQAA AM3MzMzMzOw/AwIOAAgABgAAAM3MzMzMzOw/AwIOAAgABwAAAM3MzMzMzOw/AwIOAAgACAAAAM3M zMzMzOw/AwIOAAgACQAAAM3MzMzMzOw/AwIOAAgACgAAAM3MzMzMzOw/AwIOAAgACwAAAM3MzMzM zOw/AwIOAAkAAAAAAAAAAAAAAPA/AwIOAAkAAQAAAAAAAAAAAPA/AwIOAAkAAgAAAAAAAAAAAPA/ AwIOAAkAAwAAAAAAAAAAAPA/AwIOAAkABAAAAAAAAAAAAPA/AwIOAAkABQAAAAAAAAAAAPA/AwIO AAkABgAAAAAAAAAAAPA/AwIOAAkABwAAAAAAAAAAAPA/AwIOAAkACAAAAAAAAAAAAPA/AwIOAAkA CQAAAAAAAAAAAPA/AwIOAAkACgAAAAAAAAAAAPA/AwIOAAkACwAAAAAAAAAAAPA/ZRACAAEAAwIO AAAAAAAAAK4SLA5nfu0/AwIOAAAAAQAAAIkMq3gj8+A/AwIOAAAAAgAAAPvo1JXP8uA/AwIOAAAA AwAAAPvo1JXP8uA/AwIOAAAABAAAAFc+y/Pg7uA/AwIOAAAABQAAACWS6GUUy+E/AwIOAAAABgAA ADi+9sySAOE/AwIOAAAABwAAAFjnGJC93uE/AwIOAAAACAAAAJAUkWEVb9w/AwIOAAAACQAAAB13 Sgfr/+A/AwIOAAAACgAAAPhT46WbxOA/AwIOAAAACwAAALFtUWaDTNI/AwIOAAEAAAAAAErSNZNv tu0/AwIOAAEAAQAAABKgppat9eE/AwIOAAEAAgAAAE7udygK9OE/AwIOAAEAAwAAAE7udygK9OE/ AwIOAAEABAAAAALZ690f7+E/AwIOAAEABQAAAKKcaFch5eM/AwIOAAEABgAAANdR1QRR9+E/AwIO AAEABwAAAItx/iYUIuQ/AwIOAAEACAAAALt+wW7YtuA/AwIOAAEACQAAANZuu9Bcp+E/AwIOAAEA CgAAAJs90AoMWeE/AwIOAAEACwAAAJYJv9TPm9I/AwIOAAIAAAAAAFovhnKiXe0/AwIOAAIAAQAA AM0Bgjl6/OI/AwIOAAIAAgAAAO4IpwUv+uI/AwIOAAIAAwAAAO4IpwUv+uI/AwIOAAIABAAAAODz wwjh0eI/AwIOAAIABQAAAOSDns2qz+U/AwIOAAIABgAAAEnXTL7Z5uI/AwIOAAIABwAAAEGfyJOk a+Y/AwIOAAIACAAAAM78ag4QzOE/AwIOAAIACQAAADfDDfj8MOI/AwIOAAIACgAAAGH9n8N8eeE/ AwIOAAIACwAAABpR2ht8YdI/AwIOAAMAAAAAAPT91HjpJu0/AwIOAAMAAQAAAFvTvOMUHeU/AwIO AAMAAgAAANJvXwfOGeU/AwIOAAMAAwAAANJvXwfOGeU/AwIOAAMABAAAAPnaM0sC1OQ/AwIOAAMA BQAAALmq7Lsi+Oc/AwIOAAMABgAAAOONzCN/MOQ/AwIOAAMABwAAAFitTPilfuY/AwIOAAMACAAA AKJ6a2CrBOM/AwIOAAMACQAAALTlXIqryuI/AwIOAAMACgAAAFoSoKaWreE/AwIOAAMACwAAAPJ7 m/7sR9I/AwIOAAQAAAAAAEUvo1huae0/AwIOAAQAAQAAAOiHEcKjjec/AwIOAAQAAgAAACTW4lMA jOc/AwIOAAQAAwAAACTW4lMAjOc/AwIOAAQABAAAAKBP5EnSNec/AwIOAAQABQAAAJ1LcVXZd+k/ AwIOAAQABgAAAApoImx4euU/AwIOAAQABwAAAC140VeQZuQ/AwIOAAQACAAAALu4jQbwFuQ/AwIO AAQACQAAAKJdhZSfVOM/AwIOAAQACgAAAEDZlCu8y+E/AwIOAAQACwAAAGGJB5RNudI/AwIOAAUA AAAAABnnb0IhAu4/AwIOAAUAAQAAAKgY529CIeo/AwIOAAUAAgAAABv1EI3uIOo/AwIOAAUAAwAA ABv1EI3uIOo/AwIOAAUABAAAAGJnCp3X2Ok/AwIOAAUABQAAAJ612y401+k/AwIOAAUABgAAAEOt ad5xiuY/AwIOAAUABwAAAJ/Ik6RrJuM/AwIOAAUACAAAAJgvL8A+OuU/AwIOAAUACQAAAAGkNnFy v+M/AwIOAAUACgAAAD9SRIZVvOE/AwIOAAUACwAAAIl7LH3ogtI/AwIOAAYAAAAAAMfXnlkSoO4/ AwIOAAYAAQAAABAjhEcbR+w/AwIOAAYAAgAAAGe4AZ8fRuw/AwIOAAYAAwAAAGe4AZ8fRuw/AwIO AAYABAAAACScFrzoK+w/AwIOAAYABQAAAMAEbt3NU+k/AwIOAAYABgAAAOZ5cHfWbuc/AwIOAAYA BwAAAKvsuyL43+I/AwIOAAYACAAAABHfiVkvhuY/AwIOAAYACQAAAO84RUdy+eM/AwIOAAYACgAA AChEwCFUqeE/AwIOAAYACwAAABhDOdGuQtI/AwIOAAcAAAAAAGcsms5OBu8/AwIOAAcAAQAAAHju PVxy3O0/AwIOAAcAAgAAAHjuPVxy3O0/AwIOAAcAAwAAAHjuPVxy3O0/AwIOAAcABAAAAEJg5dAi 2+0/AwIOAAcABQAAAC0+BcB4Buk/AwIOAAcABgAAAG0csRafAug/AwIOAAcABwAAAAdCsoAJ3OI/ AwIOAAcACAAAAPOrOUAwR+c/AwIOAAcACQAAAMUbmUf+YOQ/AwIOAAcACgAAAG/1nPS+8eE/AwIO AAcACwAAAEIJM23/ytI/AwIOAAgAAAAAAB3J5T+k3+4/AwIOAAgAAQAAAFzmdFlMbO4/AwIOAAgA AgAAAFzmdFlMbO4/AwIOAAgAAwAAAFzmdFlMbO4/AwIOAAgABAAAAM7Cnnb4a+4/AwIOAAgABQAA AMdoHVVNEOk/AwIOAAgABgAAABcOhGQBE+g/AwIOAAgABwAAABueXinLEOM/AwIOAAgACAAAALWJ k/sdiuY/AwIOAAgACQAAAPhwyXGndOQ/AwIOAAgACgAAAEtZhjjWxeE/AwIOAAgACwAAAHztmSUB atI/AwIOAAkAAAAAAHiXi/hOzO4/AwIOAAkAAQAAAMZQTrSrkO4/AwIOAAkAAgAAAMZQTrSrkO4/ AwIOAAkAAwAAAMZQTrSrkO4/AwIOAAkABAAAAMZQTrSrkO4/AwIOAAkABQAAALRZ9bnaiuk/AwIO AAkABgAAABzO/GoOEOg/AwIOAAkABwAAADNQGf8+4+I/AwIOAAkACAAAAPqbUIiAQ+Q/AwIOAAkA CQAAAPkUAOMZNOQ/AwIOAAkACgAAABy2LcpskOE/AwIOAAkACwAAAKneGtgqwdI/ZRACAAMAPgIK AAkACwAAAKneGtigAAQAEwAUAAoAAAAJCBAAAAYQAPIVzAdJAAAABgAAAAsCFAAAAAAAAAAAAB0A AADqLAAAf0oAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAA ACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAAABUAAACDAAIAAACEAAIA AAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAAAOA/AAAAAAAA4D9ghFUAAgAIAH0ADAAAAAAAJAwZ AAIABAB9AAwAAQABAAAHGgAGAAQAfQAMAAIAAgAADB4AAgAEAH0ADAADAAMASQceAAYABAB9AAwA BAAEAJIIHgACAAQAfQAMAAUABQCSDB4ABgAEAH0ADAAGAAYA2wseAAIABAB9AAwABwAHALYJHgAC AAQAfQAMAAgACQAABx4ABgAEAH0ADAAKAAoAtgceAAIABAB9AAwACwALACQJHgAAAAQAfQAMAAwA DABtDR4AAgAEAH0ADAANAA0AkggeAAIABAB9AAwADgAOAG0OHgACAAQAfQAMAA8ADwAAHw8AAgAE AAACDgAAAAAAHQAAAAAAEAAAAAgCEAAAAAAAEAD/AAAAVDCAARgACAIQAAEAAAAQAP8AAABiAAAB AwAIAhAAAgAAABAA/wAAAAAAAAFiAAgCEAADAAAAEAD/AAAAAAAAAQAACAIQAAQAAAAQAP8AAAC1 gQABAgAIAhAABQAAABAA/wAAAAAAAAEAAAgCEAAGAAAAEAD/AAAAAAAAAQAACAIQAAcAAAAQAP8A AABiAAABAgAIAhAACAAAABAA/wAAAAAAAAFiAAgCEAAJAAAAEAD/AAAAAAAAAQAACAIQAAoAAAAQ AP8AAAAAAAABAAAIAhAACwAAABAA/wAAAAAAgAEcAAgCEAAMAAAAEAD/AAAAAAAAAWIACAIQAA0A AAAQAP8AAAAAAAABYgAIAhAADgAAABAA/wAAAAAAAAFpgQgCEAAPAAAAEAD/AAAAAQEAAUMBCAIQ ABAAAAAPAP8AAAAQIAABT0gIAhAAEgAAAA8A/wAAALcBgAEYAAgCEAATAAAADwD/AAAAYgAAAQAA CAIQABQAAAAPAP8AAACdMAABAAAIAhAAFQAAAA8A/wAAAAAAAAH/zwgCEAAWAAAADwD/AAAA978A AfyPCAIQABcAAAAPAP8AAAD//wABAAAIAhAAGAAAAA8A/wAAAOABAAEAAAgCEAAZAAAADwD/AAAA AAAAAQkBCAIQABoAAAAPAP8AAAAAAAABZAAIAhAAGwAAAA8A/wAAAAAAAAFiAAgCEAAcAAAADwD/ AAAA/L8AAfeP/QAKAAAAAAAVAAAAAAD9AAoAAAABACAAAQAAAP0ACgAAAAIAIAACAAAA/QAKAAAA AwAgAAMAAAD9AAoAAAAEACAABAAAAP0ACgAAAAUAIAAeAAAA/QAKAAAABgAgAAUAAAD9AAoAAAAH ACAABgAAAP0ACgAAAAgAIAAHAAAA/QAKAAAACQAgAAgAAAD9AAoAAAAKACAACQAAAP0ACgAAAAsA IAAKAAAA/QAKAAAADAAgAAsAAAD9AAoAAAANACAADAAAAP0ACgAAAA4AIAANAAAA/QAKAAAADwAY AA4AAAC9AGAAAQAAABkAAQAkQCEAgIDWQCEAAN3JQCEAgNzJQCEAgNzJQCEAAN3JQCEAgNbJQCEA AOzJQCEAgCbLQCEAgPHJQCEAgETLQCEAgLHFQCEAgPDJQCEAAJbJQCEAAOy7QA4A/QAKAAEADwAP AA8AAAC9AGAAAgAAABkAAQA0QCEAQKvWQCEAgGfLQCEAAGXLQCEAAGXLQCEAgGTLQCEAgF3LQCEA gEvLQCEAgFvOQCEAAGrLQCEAgLjOQCEAAIHJQCEAAPDKQCEAgHjKQCEAAGW8QA4A/QAKAAIADwAP ABAAAAC9AGAAAwAAABkAAQA+QCEAgGfWQCEAgPjMQCEAAPXMQCEAAPXMQCEAAPPMQCEAgLfMQCEA AMHMQCEAAKTQQCEAgNfMQCEAABvRQCEAACjLQCEAAMLLQCEAAKrKQCEAAAy8QA4A/QAKAAMADwAP ABEAAAC9AGAABAAAABkAAQBEQCEAwD3WQCEAwBvQQCEAQBnQQCEAQBnQQCEAwBjQQCEAAMjPQCEA AMvPQCEAgEnSQCEAgM7OQCEAgCnRQCEAAAXNQCEAgKzMQCEAgPnKQCEAAOW7QA4A/QAKAAQADwAP ABIAAAC9AGAABQAAABkAAADgPyEAgHDWQCEAQPjRQCEAAPfRQCEAAPfRQCEAQPfRQCEAQLXRQCEA wLLRQCEAQG7TQCEAAGPQQCEAACHPQCEAgKfOQCEAAH/NQCEAgCfLQCEAAJK8QA4A/QAKAAUADwAP ABMAAAC9AGAABgAAABkAAQBOQCEAAOXWQCEAgO/TQCEAQO/TQCEAQO/TQCEAQO/TQCEAQLjTQCEA AKLTQCEAALfTQCEAgDLRQCEAgDjNQCEAADLQQCEAACLOQCEAABDLQCEAAD+8QA4A/QAKAAYADwAP ABQAAAC9AGAABwAAABkAAYBRQCEAgF3XQCEAAJPVQCEAQJLVQCEAQJLVQCEAAJLVQCEAQH7VQCEA wFnVQCEAwFLTQCEAwODRQCEAAM3MQCEAQC/RQCEAgHrOQCEAAPPKQCEAAN27QA4A/QAKAAcADwAP ABUAAAC9AGAACAAAABkAAQBUQCEAgKvXQCEAQMjWQCEAQMjWQCEAQMjWQCEAQMjWQCEAQMfWQCEA wLHWQCEAwBfTQCEAgFHSQCEAAMfMQCEAgMLRQCEAgBjPQCEAgGHLQCEAAK28QA4A/QAKAAgADwAP ABYAAAC9AGAACQAAABkAAYBWQCEAAI7XQCEAADbXQCEAADbXQCEAADbXQCEAADbXQCEAwDXXQCEA wCfXQCEAQB/TQCEAAF7SQCEAgBfNQCEAQDLRQCEAgDbPQCEAgB7LQCEAABm8QA4A/QAKAAkADwAP ABcAAAC9AGAACgAAABkAAADwPyEAQH/XQCEAwFHXQCEAwFHXQCEAwFHXQCEAwFHXQCEAwFHXQCEA QEHXQCEAwHzTQCEAwFvSQCEAANLMQCEAgOvOQCEAANTOQCEAAM3KQCEAAJ68QA4A/QAKAAoADwAP ABgAAAD9AAoACwAAABsAGQAAAAYAIwALAAEAIgAAAAAAmKcMQQAAIQDA/Q0AJQEACgABwAHAGRBo TgYAGwALAAIAIgAAAAAAoEAHQQgACwAB/wUAAQsAAgC8BBcACwALAAINAAwNAC32////AMAAwBkQ vLgGABsACwADACIAAAAAAKA/B0EIAAsAAv8FAAELAAIABgAbAAsABAAiAAAAAACgPwdBCAALAAP/ BQABCwACAAYAGwALAAUAIgAAAAAAcD8HQQgACwAE/wUAAQsAAgAGABsACwAGACIAAAAAAIgiB0EI AAsABf8FAAELAAIABgAbAAsABwAiAAAAAABgFQdBCAALAAb/BQABCwACAAYAGwALAAgAIgAAAAAA SHsGQQgACwAH/wUAAQsAAgAGABsACwAJACIAAAAAAEhgBEEIAAsACP8FAAELAAIABgAbAAsACgAi AAAAAADQ5QJBCAALAAn/BQABCwACAAYAGwALAAsAIgAAAAAA6NkCQQgACwAK/wUAAQsAAgAGABsA CwAMACIAAAAAANhIAkEIAAsAC/8FAAELAAIABgAbAAsADQAiAAAAAACYwgBBCAALAAz/BQABCwAC AAYAIwALAA4AIgAAAAAAQKXxQAAACwAN/w0AJQEACgAOwA7AGRC8uL4AIAAMAAIAHQAdAB0AHQAd AB0AHQAdAB0AHQAdAB0AHQAOAP0ACgANAAAAGQAaAAAAfgIKAA0AAQAjAABq2ED9AAoADgAAABkA GwAAAH4CCgAOAAEAGgAAABxA/QAKAA8AAAAZABwAAAB+AgoADwABABoAAADwP/0ACgAQAAAAGQAd AAAAfgIKABAAAQAaAAAAWUD9AAoAEgAAABUAAAAAAP0ACgASAAEAFgABAAAA/QAKABIAAgAXAAIA AAD9AAoAEgADABcAAwAAAP0ACgASAAQAFwAEAAAA/QAKABIABQAgAB4AAAD9AAoAEgAGABcABQAA AP0ACgASAAcAFwAGAAAA/QAKABIACAAXAAcAAAD9AAoAEgAJABcACAAAAP0ACgASAAoAFwAJAAAA /QAKABIACwAXAAoAAAD9AAoAEgAMABcACwAAAP0ACgASAA0AFwAMAAAA/QAKABIADgAXAA0AAAB+ AgoAEwAAABkAAQAkQAYAIQATAAEAHwCuEiwOZ37tPwAACwAO/wsARAEAAcBEDQABAAYGABsAEwAC AB8AiQyreCPz4D8IABMAA/4FAAETAAIAvAQVABMAEwACDgANCwBM7v8AwEQNAAEABgYAGwATAAMA HwD76NSVz/LgPwgAEwAE/wUAARMAAgAGABsAEwAEAB8A++jUlc/y4D8IABMABf8FAAETAAIABgAb ABMABQAfAIkMq3gj8+A/CAATAAb/BQABEwACAAYAGwATAAYAHwBXPsvz4O7gPwgAEwAH/wUAARMA AgAGABsAEwAHAB8AIjfDDfj84D8IABMACP8FAAETAAIABgAbABMACAAfACWS6GUUy+E/CAATAAn/ BQABEwACAAYAGwATAAkAHwA4vvbMkgDhPwgAEwAK/wUAARMAAgAGABsAEwAKAB8AWOcYkL3e4T8I ABMAC/8FAAETAAIABgAbABMACwAfAJAUkWEVb9w/CAATAAz/BQABEwACAAYAGwATAAwAHwAdd0oH 6//gPwgAEwAN/wUAARMAAgAGABsAEwANAB8A+FPjpZvE4D8IABMADv8FAAETAAIABgAbABMADgAf ALFtUWaDTNI/CAAUAAL/BQABEwACAH4CCgAUAAAAGQABADRABgAbABQAAQAfAErSNZNvtu0/CAAV AAH/BQABFAABALwEFQAUABwAAQ4AfgsATO7/AMBEDQABAAYGABsAFAACAB8AEqCmlq314T8IABQA A/8FAAEUAAEABgAbABQAAwAfAE7udygK9OE/CAAUAAT/BQABFAABAAYAGwAUAAQAHwBO7ncoCvTh PwgAFAAF/wUAARQAAQAGABsAFAAFAB8AwcqhRbbz4T8IABQABv8FAAEUAAEABgAbABQABgAfAALZ 690f7+E/CAAUAAf/BQABFAABAAYAGwAUAAcAHwAX2c73U+PhPwgAFAAI/wUAARQAAQAGABsAFAAI AB8AopxoVyHl4z8IABQACf8FAAEUAAEABgAbABQACQAfANdR1QRR9+E/CAAUAAr/BQABFAABAAYA GwAUAAoAHwCLcf4mFCLkPwgAFAAL/wUAARQAAQAGABsAFAALAB8Au37Bbti24D8IABQADP8FAAEU AAEABgAbABQADAAfANZuu9Bcp+E/CAAUAA3/BQABFAABAAYAGwAUAA0AHwCbPdAKDFnhPwgAFAAO /wUAARQAAQAGABsAFAAOAB8Algm/1M+b0j8IABUAAv8FAAEUAAEAfgIKABUAAAAZAAEAPkAGABsA FQABAB8AWi+GcqJd7T8IABYAAf8FAAEUAAEABgAbABUAAgAfAM0Bgjl6/OI/CAAVAAP/BQABFAAB AAYAGwAVAAMAHwDuCKcFL/riPwgAFQAE/wUAARQAAQAGABsAFQAEAB8A7ginBS/64j8IABUABf8F AAEUAAEABgAbABUABQAfALd6Tnrf+OI/CAAVAAb/BQABFAABAAYAGwAVAAYAHwDg88MI4dHiPwgA FQAH/wUAARQAAQAGABsAFQAHAB8AY5eo3hrY4j8IABUACP8FAAEUAAEABgAbABUACAAfAOSDns2q z+U/CAAVAAn/BQABFAABAAYAGwAVAAkAHwBJ10y+2ebiPwgAFQAK/wUAARQAAQAGABsAFQAKAB8A QZ/Ik6Rr5j8IABUAC/8FAAEUAAEABgAbABUACwAfAM78ag4QzOE/CAAVAAz/BQABFAABAAYAGwAV AAwAHwA3ww34/DDiPwgAFQAN/wUAARQAAQAGABsAFQANAB8AYf2fw3x54T8IABUADv8FAAEUAAEA BgAbABUADgAfABpR2ht8YdI/CAAWAAL/BQABFAABAH4CCgAWAAAAGQABAERABgAbABYAAQAfAPT9 1HjpJu0/CAAXAAH/BQABFAABAAYAGwAWAAIAHwBb07zjFB3lPwgAFgAD/wUAARQAAQAGABsAFgAD AB8A0m9fB84Z5T8IABYABP8FAAEUAAEABgAbABYABAAfANJvXwfOGeU/CAAWAAX/BQABFAABAAYA GwAWAAUAHwC3KLNBJhnlPwgAFgAG/wUAARQAAQAGABsAFgAGAB8A+dozSwLU5D8IABYAB/8FAAEU AAEABgAbABYABwAfAEuwOJz51eQ/CAAWAAj/BQABFAABAAYAGwAWAAgAHwC5quy7IvjnPwgAFgAJ /wUAARQAAQAGABsAFgAJAB8A443MI38w5D8IABYACv8FAAEUAAEABgAbABYACgAfAFitTPilfuY/ CAAWAAv/BQABFAABAAYAGwAWAAsAHwCiemtgqwTjPwgAFgAM/wUAARQAAQAGABsAFgAMAB8AtOVc iqvK4j8IABYADf8FAAEUAAEABgAbABYADQAfAFoSoKaWreE/CAAWAA7/BQABFAABAAYAGwAWAA4A HwDye5v+7EfSPwgAFwAC/wUAARQAAQB+AgoAFwAAABkAAADgPwYAGwAXAAEAHwBFL6NYbmntPwgA GAAB/wUAARQAAQAGABsAFwACAB8A6IcRwqON5z8IABcAA/8FAAEUAAEABgAbABcAAwAfACTW4lMA jOc/CAAXAAT/BQABFAABAAYAGwAXAAQAHwAk1uJTAIznPwgAFwAF/wUAARQAAQAGABsAFwAFAB8A sfm4NlSM5z8IABcABv8FAAEUAAEABgAbABcABgAfAKBP5EnSNec/CAAXAAf/BQABFAABAAYAGwAX AAcAHwAY7IZtizLnPwgAFwAI/wUAARQAAQAGABsAFwAIAB8AnUtxVdl36T8IABcACf8FAAEUAAEA BgAbABcACQAfAApoImx4euU/CAAXAAr/BQABFAABAAYAGwAXAAoAHwAteNFXkGbkPwgAFwAL/wUA ARQAAQAGABsAFwALAB8Au7iNBvAW5D8IABcADP8FAAEUAAEABgAbABcADAAfAKJdhZSfVOM/CAAX AA3/BQABFAABAAYAGwAXAA0AHwBA2ZQrvMvhPwgAFwAO/wUAARQAAQAGABsAFwAOAB8AYYkHlE25 0j8IABgAAv8FAAEUAAEAfgIKABgAAAAZAAEATkAGABsAGAABAB8AGedvQiEC7j8IABkAAf8FAAEU AAEABgAbABgAAgAfAKgY529CIeo/CAAYAAP/BQABFAABAAYAGwAYAAMAHwAb9RCN7iDqPwgAGAAE /wUAARQAAQAGABsAGAAEAB8AG/UQje4g6j8IABgABf8FAAEUAAEABgAbABgABQAfABv1EI3uIOo/ CAAYAAb/BQABFAABAAYAGwAYAAYAHwBiZwqd19jpPwgAGAAH/wUAARQAAQAGABsAGAAHAB8AJAuY wK276T8IABgACP8FAAEUAAEABgAbABgACAAfAJ612y401+k/CAAYAAn/BQABFAABAAYAGwAYAAkA HwBDrWnecYrmPwgAGAAK/wUAARQAAQAGABsAGAAKAB8An8iTpGsm4z8IABgAC/8FAAEUAAEABgAb ABgACwAfAJgvL8A+OuU/CAAYAAz/BQABFAABAAYAGwAYAAwAHwABpDZxcr/jPwgAGAAN/wUAARQA AQAGABsAGAANAB8AP1JEhlW84T8IABgADv8FAAEUAAEABgAbABgADgAfAIl7LH3ogtI/CAAZAAL/ BQABFAABAH4CCgAZAAAAGQABgFFABgAbABkAAQAfAMfXnlkSoO4/CAAaAAH/BQABFAABAAYAGwAZ AAIAHwAQI4RHG0fsPwgAGQAD/wUAARQAAQAGABsAGQADAB8AZ7gBnx9G7D8IABkABP8FAAEUAAEA BgAbABkABAAfAGe4AZ8fRuw/CAAZAAX/BQABFAABAAYAGwAZAAUAHwDZlCu8y0XsPwgAGQAG/wUA ARQAAQAGABsAGQAGAB8AJJwWvOgr7D8IABkAB/8FAAEUAAEABgAbABkABwAfAFxV9l0R/Os/CAAZ AAj/BQABFAABAAYAGwAZAAgAHwDABG7dzVPpPwgAGQAJ/wUAARQAAQAGABsAGQAJAB8A5nlwd9Zu 5z8IABkACv8FAAEUAAEABgAbABkACgAfAKvsuyL43+I/CAAZAAv/BQABFAABAAYAGwAZAAsAHwAR 34lZL4bmPwgAGQAM/wUAARQAAQAGABsAGQAMAB8A7zhFR3L54z8IABkADf8FAAEUAAEABgAbABkA DQAfAChEwCFUqeE/CAAZAA7/BQABFAABAAYAGwAZAA4AHwAYQznRrkLSPwgAGgAC/wUAARQAAQB+ AgoAGgAAABkAAQBUQAYAGwAaAAEAHwBnLJrOTgbvPwgAGwAB/wUAARQAAQAGABsAGgACAB8AeO49 XHLc7T8IABoAA/8FAAEUAAEABgAbABoAAwAfAHjuPVxy3O0/CAAaAAT/BQABFAABAAYAGwAaAAQA HwB47j1cctztPwgAGgAF/wUAARQAAQAGABsAGgAFAB8AeO49XHLc7T8IABoABv8FAAEUAAEABgAb ABoABgAfAEJg5dAi2+0/CAAaAAf/BQABFAABAAYAGwAaAAcAHwCtbvWc9L7tPwgAGgAI/wUAARQA AQAGABsAGgAIAB8ALT4FwHgG6T8IABoACf8FAAEUAAEABgAbABoACQAfAG0csRafAug/CAAaAAr/ BQABFAABAAYAGwAaAAoAHwAHQrKACdziPwgAGgAL/wUAARQAAQAGABsAGgALAB8A86s5QDBH5z8I ABoADP8FAAEUAAEABgAbABoADAAfAMUbmUf+YOQ/CAAaAA3/BQABFAABAAYAGwAaAA0AHwBv9Zz0 vvHhPwgAGgAO/wUAARQAAQAGABsAGgAOAB8AQgkzbf/K0j8IABsAAv8FAAEUAAEAfgIKABsAAAAZ AAGAVkAGABsAGwABAB8AHcnlP6Tf7j8IABwAAf8FAAEUAAEABgAbABsAAgAfAFzmdFlMbO4/CAAb AAP/BQABFAABAAYAGwAbAAMAHwBc5nRZTGzuPwgAGwAE/wUAARQAAQAGABsAGwAEAB8AXOZ0WUxs 7j8IABsABf8FAAEUAAEABgAbABsABQAfAFzmdFlMbO4/CAAbAAb/BQABFAABAAYAGwAbAAYAHwDO wp52+GvuPwgAGwAH/wUAARQAAQAGABsAGwAHAB8A0vvG155Z7j8IABsACP8FAAEUAAEABgAbABsA CAAfAMdoHVVNEOk/CAAbAAn/BQABFAABAAYAGwAbAAkAHwAXDoRkARPoPwgAGwAK/wUAARQAAQAG ABsAGwAKAB8AG55eKcsQ4z8IABsAC/8FAAEUAAEABgAbABsACwAfALWJk/sdiuY/CAAbAAz/BQAB FAABAAYAGwAbAAwAHwD4cMlxp3TkPwgAGwAN/wUAARQAAQAGABsAGwANAB8AS1mGONbF4T8IABsA Dv8FAAEUAAEABgAbABsADgAfAHztmSUBatI/CAAcAAL/BQABFAABAH4CCgAcAAAAGQAAAPA/BgAb ABwAAQAfAHiXi/hOzO4/CAATAAH/BQABFAABAAYAGwAcAAIAHwDGUE60q5DuPwgAHAAD/wUAARQA AQAGABsAHAADAB8AxlBOtKuQ7j8IABwABP8FAAEUAAEABgAbABwABAAfAMZQTrSrkO4/CAAcAAX/ BQABFAABAAYAGwAcAAUAHwDGUE60q5DuPwgAHAAG/wUAARQAAQAGABsAHAAGAB8AxlBOtKuQ7j8I ABwAB/8FAAEUAAEABgAbABwABwAfAEImGTkLe+4/CAAcAAj/BQABFAABAAYAGwAcAAgAHwC0WfW5 2orpPwgAHAAJ/wUAARQAAQAGABsAHAAJAB8AHM78ag4Q6D8IABwACv8FAAEUAAEABgAbABwACgAf ADNQGf8+4+I/CAAcAAv/BQABFAABAAYAGwAcAAsAHwD6m1CIgEPkPwgAHAAM/wUAARQAAQAGABsA HAAMAB8A+RQA4xk05D8IABwADf8FAAEUAAEABgAbABwADQAfABy2LcpskOE/CAAcAA7/BQABFAAB AAYAGwAcAA4AHwCp3hrYKsHSPwgAFAAB/wUAARQAAQDXADwAjRwAABwC4AByAHIAcgByAHIAcgBy AHIAcgByAOsBJAAcABwAHAAcANIA3wHZAcABwAHAAcABwAHAAcABPgISALYGAAAAAEAAAAAAAAAA AAAAAB0ADwADDQAFAAAAAQANAA0ABQUKAAAACQgQAAAGEADyFcwHSQAAAAYAAAALAhAAAAAAAAAA AAAAAAAApEsAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAA ACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAAABUAAACDAAIAAACEAAIA AAChACIAAAD/AAEAAQABAAQBAAUFBQAAAAAAAOA/AAAAAAAA4D8NAFUAAgAIAAACDgAAAAAAAAAA AAAAAAAAAD4CEgC2AAAAAABAAAAAAAAAAAAAAAAdAA8AAwAAAAAAAAEAAAAAAAAACgAAAAkIEAAA BhAA8hXMB0kAAAAGAAAACwIQAAAAAAAAAAAAAAAAAKFMAAANAAIAAQAMAAIAZAAPAAIAAQARAAIA AAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/ AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEAAQAEAAAAAAAAAAAAAADgPwAA AAAAAOA/DQBVAAIACAAAAg4AAAAAAAAAAAAAAAAAAAA+AhIAtgAAAAAAQAAAAAAAAAAAAAAAHQAP AAMAAAAAAAABAAAAAAAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgA Kyez2TAAAACcAAAABgAAAAEAAAA4AAAABAAAAEAAAAAIAAAAWAAAABIAAABwAAAADAAAAIgAAAAT AAAAlAAAAAIAAADkBAAAHgAAAA0AAABOb3JtYW4gUGV0cnkAAHgAHgAAAA0AAABOb3JtYW4gUGV0 cnkAAHgAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAAAP9/sPfMABAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAA BdXN1ZwuGxCTlwgAKyz5rlgBAAAUAQAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAAfAAAAAsAAACE AAAAEAAAAIwAAAATAAAAlAAAABYAAACcAAAADQAAAKQAAAAMAAAA2gAAAAIAAADkBAAAHgAAABwA AABTYXNrYXRjaGV3YW4gQXJjaGl2ZXMgQm9hcmQAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAAEAAAABQAAAERhdGEABwAAAFNoZWV0MgAHAAAAU2hlZXQzAAsAAABM aW5lIEdyYXBoAAwQAAAEAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAADAAAAHgAAAAcAAABDaGFy dHMAAwAAAAEAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9Q SURfR1VJRAACAAAA5AQAAEEAAABOAAAAewBBAEIAMwA0AEQANQBBAEQALQBFADcAQwBGAC0AMQAx AEQANAAtADkAQQAxADAALQAwADAAMQAwADUAQQAwAEMANAA5AEQAMgB9AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA DwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAd AAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAA/v///ygAAAApAAAAKgAAACsA AAAsAAAALQAAAC4AAAD+////MAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAAP7////9/////v// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAoDGM5yZ8 wAH+////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADmTAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBh AHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAMAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAAABAAAAAAAAA= ------=_NextPart_000_001B_01C07BF4.E95B8620-- From nkklrp@hotmail.com Fri Jan 12 07:11:53 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24413 invoked from network); 12 Jan 2001 07:11:53 -0000 Received: from f261.law10.hotmail.com (HELO hotmail.com) (64.4.14.136) by qmail.accesscomm.ca with SMTP; 12 Jan 2001 07:11:53 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Jan 2001 23:11:50 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 12 Jan 2001 07:11:50 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, aj@azure.humbug.org.au, bmbuck@14850.com, moth@debian.org, robla@eskimo.com, stevegr@debian.org Subject: SSD & ICC, continued Date: Fri, 12 Jan 2001 07:11:50 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jan 2001 07:11:50.0410 (UTC) FILETIME=[EEF7CEA0:01C07C66] X-Evolution: 0000008e-0010 Raul pointed out that some votes in Debian, such as on the technical committee can have very few voters. If the method we recommend will be used for that technical committee, then small electorate matters could be especially important. So the pairwise tie might then not be so rare after all. But I want to add a few more comments about SSD & ICC: 1. Norm pointed out that, among some particular set of alternatives, there's a CW at least 90% or 95% of the time. Now, what about that clone set that forms when, in my example, some clones of B join the race? SSD's clone criterion failure happens only if they form a circular tie. But Norm showed that circular ties are uncommon. Even if the rankings were random (and there are no pairwise ties among the clones), there's only a 1/4 probability of a circular tie among the 3 clones. That increases as we increase the clone set size, but then larger clone sets are less likely. Anyway, of course Debian voting isn't random. If it were, circular ties would be much more common than they are. And Norm mentioned that circular ties are not likely, that typically at least 90% or 95% of the time, a set of candidates will have a CW. If that goes for the clone set too, then that greatly reduces the likelihood of a clone criterion failure. 2. Of course, even if the clones aren't added, there's still only a 50% chance that B will win, since it's a tie between A & B, solved randomly. For one thing, we can't get very upset about B not winning, when it's just a tie anyway. But, more relevantly, the fact that B has a 1/2 chance of losing anyway further reduces the strategy incentive caused by the possibility of clone criterion failure. 3. If there's going to 1 or more clones of B added to B, what's the most likely number. One, wouldn't you say? But the resulting 2 member clone set can't cause SSD to fail the criterion, because you can't make a cycle with 2 candidates. And, as I said, even with random rankings, 3 clones only have a 1/4 probability of forming a cycle. And the probability is considerably than that under more realistic assumptions, as Norm was saying. So my point is that, for all these reasons, and the reasons in my previous letter, a clone criterion violation is less likely. Pair-ties aren't so unlikely on the technical committee, but these other considerations reduce the importance of the clone criterion for SSD. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From npetry@accesscomm.ca Fri Jan 12 14:47:26 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 23261 invoked from network); 12 Jan 2001 14:47:26 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 12 Jan 2001 14:47:26 -0000 Message-ID: <003601c07ca7$cf14bf80$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Independence of Clones Criterion - Test Data Date: Fri, 12 Jan 2001 08:56:09 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0033_01C07C75.84372C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 0000008f-0030 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit There are at least a couple of ways of evaluating how clone-independent a voting method is: 1) Use Independence of Clones criteria to test methods for clone independence. Some methods are provably clone independent, for other methods clone independence can be disproven by coming up with a set of sample ballots showing a clone-independence failure. 2) Carry out voting simulations in which clone sets are known, and then determine to what degree the choice of winner depends on the size of the clone sets. Clone criteria are useful because if a method satisfies the criterion, that fact serves as a *guarantee* that voters can rely upon when deciding how to vote, nominate, etc. Having/not having this guarantee can affect voter behaviour -- if the clone independence of a method is not known, strategisers may experiment to see if they can improve results by nominating/removing options. If the method is known to *not* be clone independent, this will almost certainly affect the behaviour of sophisticated voters/nominators (depending on the type of defect the method has). Unfortunately, criteria don't tell us the whole story -- methods which are proven to not be clone independent differ widely in practice as to the seriousness of the problem. Methods which almost always choose the same winner as a clone-independent method (such as SSD or SD, which are very similar to Schulze in terms of results) are _practically_ clone independent, whereas other methods may have serious problems with vote splitting or the 'rich party' problem. It may be worthwhile to forgo complete clone independence for a method which is practically clone independent, but offers other advantages. Testing Clone Independence: I devised a synthetic test to assess the practical clone independence of various voting methods. This particular test was based on the following thought experiment: Suppose we have a series of elections for an electorate that is divided into N factions. The factions are approximately equal in size. Each faction nominates a different number of candidates. Faction 1 nominates a single candidate; Faction 2 nominates 2 candidates,... Faction N nominates N candidates. A set of ballots are then constructed for each election according to the following rule: For each ballot, factions are first ordered randomly, and then candidates within each faction are ordered randomly. As a result, there should be approximately equal numbers of voters ranking candidates from a particular faction first on their ballot, and candidates within each faction should be about equally likely to be elected. The ballots are then counted using various count rules, and the winner selected by each method is used to determine which clone set the winner belongs to. The percentage of winners that come from each clone set is then plotted against clone set size. When this is done, one would expect the following: 1) For clone independent methods, each faction should win about the same number of elections. Therefore, the line should be flat. 2) For methods which suffer from vote splitting, the clone sets having the fewest candidates will win most elections, so the line should slope downward 3) For methods having the 'rich party problem', factions fielding the most candidates will win more elections, so the line should slope upward. The slopes of these lines should give a rough idea of how clone independent each method is. The steeper the slope, the less clone independent the method is in practice. I applied this test to a variety of voting methods, and have attached a copy of the results to this e-mail (again, the data is in Excel, .csv, and .png formats -- I decided not to use .jpg because lossy compression works very poorly for graphs & charts, but I can send you .gif if you prefer). All three .png charts show more or less the same information, presented in different ways. The charts show the results I had expected: 1) Despite its other, well-known defects, Instant Runoff is clone-independent. 2) Borda's method has a severe 'rich-party' problem 3) Plurality has an extreme vote-splitting problem. This result was based on the assumption that voters in a plurality election would vote for their highest-ranked candidate. 4) Schulze, and other methods which produce similar results (such as SD and SSD -- unfortunately not shown) are practically clone independent. 5) Copeland's method shows that it suffers from the 'rich-party' problem, although it is not as serious as the problem with Borda. This demonstrates that it is possible for pairwise methods to have this problem if they are poorly designed. 6) Surprisingly, Minimax shows a mild problem with vote-splitting -- I had not expected that, although the problem is not likely serious enough to be exploitable. 7) Tideman's method is clone-independent. I have some additional comparative information that does show some meaningful differences between Tideman's and Schulze's clone independence characteristics, which I hope to post later. Summary: What this demonstrates, I think is that pairwise methods like SD and SSD will still be *practically* clone independent, even though they are provably *not* clone independent when assessed on the basis of criteria. This is not surprising, because these methods choose the same winner as a provably clone-independent method almost always. Therefore, I agree with Mike that SSD's clone independence failures will be extremely unlikely, and that the method will be almost as good as Schulze in practice. The only real problem then is psychological -- how will the method be perceived by voters, and how will this affect their voting behavior. A method which is *provably* clone independent provides a guarantee to voters which may affect their nomination and voting strategies in a positive way. Voting methods without this guarantee cannot do that. This is very similar to SD's monotonicity problem. SD ('Sequential Dropping') is a very simple and attractive variant of Condorcet's method which Mike developed that was known to have almost every advantage of SSD and Schulze, yet require a much simpler definition. Unfortunately, it was later proven that the method violates the Monotonicity criterion. The example which demonstrated this was so improbable that it did not demonstrate a *real* problem with the method (unlike Instant Runoff, where the problem occurs regularly), yet unfortunately it can no longer be claimed that SD is monotonic. This leaves the method open to academic criticism, and the lack of a monotonicity guarantee might discourage complete rankings. Therefore, I think that satisfying ICC may have some real benefit that cannot be revealed by simulation studies. -- Norman Petry ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: application/vnd.ms-excel; name="Clones - 30k, 150, 1.0, 1.0.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Clones - 30k, 150, 1.0, 1.0.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAANQAAAAAAAAAA EAAA/v///wAAAAD+////AAAAADQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFANMQzAdJAAAABgAAAOEAAgCwBMEAAgAAAOIAAABcAHAADAAATm9ybWFuIFBldHJ5ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAD0BCAAIAAIA BAABAJwAAgAOABkAAgAAABIAAgAAABMAAgAAAK8BAgAAALwBAgAAAD0AEgDwAHgAjDeDIjgAAQAA AAEAWAJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3AQIAAADaAAIAAAAxABoAyAAAAP9/kAEAAAAA AAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/ kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAFAP9/vAIAAAECAAAFAUEAcgBpAGEAbAAxABoA8AAB AP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAxABoA yAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAx ABoA8AABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAeBBgABQATAAAiJCIjLCMjMDtcLSIkIiMsIyMw HgQdAAYAGAAAIiQiIywjIzA7W1JlZF1cLSIkIiMsIyMwHgQeAAcAGQAAIiQiIywjIzAuMDA7XC0i JCIjLCMjMC4wMB4EIwAIAB4AACIkIiMsIyMwLjAwO1tSZWRdXC0iJCIjLCMjMC4wMB4ENQAqADAA AF8tIiQiKiAjLCMjMF8tO1wtIiQiKiAjLCMjMF8tO18tIiQiKiAiLSJfLTtfLUBfLR4ELAApACcA AF8tKiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAiLSJfLTtfLUBfLR4EPQAsADgAAF8tIiQiKiAj LCMjMC4wMF8tO1wtIiQiKiAjLCMjMC4wMF8tO18tIiQiKiAiLSI/P18tO18tQF8tHgQ0ACsALwAA Xy0qICMsIyMwLjAwXy07XC0qICMsIyMwLjAwXy07Xy0qICItIj8/Xy07Xy1AXy0eBAsApAAGAAAw LjAwMDAeBAwApQAHAAAjLCMjMC4w4AAUAAAAAAD1/yAAAAAAAAAAAAAAAMAg4AAUAAEAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1 /yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAA AAAAAMAg4AAUAAUAKwD1/yAAAPgAAAAAAAAAAMAg4AAUAAUAKQD1/yAAAPgAAAAAAAAAAMAg4AAU AAUALAD1/yAAAPgAAAAAAAAAAMAg4AAUAAUAKgD1/yAAAPgAAAAAAAAAAMAg4AAUAAUACQD1/yAA APgAAAAAAAAAAMAg4AAUAAAApAABACAAAAQAAAAAAAAAAMAg4AAUAAAAAwABACAAAAQAAAAAAAAA AMAg4AAUAAAApAABACMAABQAAAAAAAAAAMAg4AAUAAAAAwABACMAABQAAAAAAAAAAMAg4AAUAAYA AwABACAAAAwAAAAAAAAAAMAg4AAUAAYApAABACAAAAwAAAAAAAAAAMAg4AAUAAAApQABACMAABQA AAAAAAAAAMAg4AAUAAYACgABACMAABwAAAAAAAAAAMAg4AAUAAAACgABACMAABQAAAAAAAAAAMAg kwIEABCAA/+TAgQAEYAG/5MCBAASgAT/kwIEABOAB/+TAgQAAIAA/5MCBAAUgAX/YAECAAAAhQAT ABcMAAAAAgsAQmFyIENoYXJ0IDGFABIAOBwAAAACCgBMaW5lIEdyYXBohQATAP8qAAAAAgsAQmFy IENoYXJ0IDKFAAwAJz4AAAAABABEYXRhjAAEAAEAAgCuAQQABAABBBcACAABAAAAAwADAPwArAAN AAAADQAAAAwAAENsb25lU2V0U2l6ZQsAAFNjaHVsemUod3YpCwAAVGlkZW1hbih3dikGAABTRCh3 dikLAABNaW5pbWF4KHd2KQgAAENvcGVsYW5kBQAAQm9yZGEOAABJbnN0YW50IFJ1bm9mZgkAAFBs dXJhbGl0eQcAAFRyaWFsczoHAABWb3RlcnM6DAAASW52b2x2ZW1lbnQ6DAAARGlzY2Vybm1lbnQ6 /wAKBAgAYQcAAAwAAADHBwAAcgCxAE0AIBAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAAAm EAIACgBREAgAAAEAAAAAAAA0EAAARhACAAEAQRASAAAAQwEAAHgCAAD6DAAADgwAADMQBAAAAAQA AAAJEAAAAQAAACJDywESxWIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxAAACAQCAABAAEAAQAB AGIQEgAAAAAAAQAAAAEAAAAAAAAA7wAeECjQnTADAQAAAAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAA NBAAAB0QEgABAAAAAAAAAAAAAAAAAAAAAAAzEAAAHxAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABhenAwGkPLAQQAAAAKxWIABAAAAAEAAAAEAAAACsViABpDywEEAAAAAAAhEAIA AQAHEAwAAAAAAAAA//8JAE0ANBAAADUQAAAyEAQAAQAAADMQAAAHEAwANEPLAYT2UzC4xGIAdAAA AAAAAAACAMcwAADFMBYATwA0EAAAFBAUAAAAAAAAAAAA4TxtMA4AxzDRAAAA+sRiAPwAAAAJAAAA zRUEMAAAxTDso8cw0QAAAPrEYgD9AAAA+sRiAPzGYgDs6gIw+sRiADRDywEAAAAA/MZiAHQAAAAA AAAAjo8PMAAAAAD4xGIABwAAAP////90QssBOMdiAAAAAAAHAFAAZQByAGMAZQBuAHQAAAAAAAAA MABdAAAAAAAAAAAAAAAAAAAAURAIAAABAAAAAAAANBAAADQQAAAEWxUBAAAAAIzGYgAAAAAABAAA AAEAAAAw750wAAAAAFgAhwCIxmIAAQAAANkQADCWalQwUnBUMMLIEDB+GqoAUACHAGUQADACAAAA FgCHALhCywF4iA8wMAAAABYAhwABAAAArELLAQAAAAAIAIcA/AGHAAEAAAABAAAAuELLAQEAAAAB AAAAAAAAADAAAAAAAAAADMZiAImFDzABAAAAAAAAAAsAAAAAAAAABgKHADrHYgA4x2IACACHAAEA AAAMAAAAzlpUMAAAAABlEAAwcGpUMOwEqgBMAAAA2RAAMOwEqgBwalQwTAAAAM5aVDAWx2IAHMdi AAAAAAAAAAAAAAAAAKLHEDAJBAAAAAAAAAAAAAAmAAAAWOdiAPODDzCoxmIAAQAAAATiyQEwz8kB AAAAAFNOcDABAAAAJ05wMHEVADCIxmIABAAAAARbFQHYR8sBXF5cAgRbFQHYR8sBqGgPMARbFQH0 UssBCACHAAAAAAD0xmIACAAAABcAAAAUx2IA9EfLAUDHYgC6vxAwOMdiAAgAAAAIAAAAOMdiAOts DzAXAAAACAAAAJQBCgAAAAkIEAAABiAA0xDMB0kAAAAGAAAAFAAFAAIAACZBFQAKAAcAAFBhZ2Ug JlCDAAIAAACEAAIAAABNAH4BAABIAFAAIABMAGEAcwBlAHIASgBlAHQAIAA2AFAALwA2AE0AUAAg AC0AIABFAG4AaABhAG4AYwBlAGQAAAAAAAAAAAREANQAqAADDwAAAgABAPYE+AIAAAEABwD8/wIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACkAAAAPyfOZAAABAAEAAQAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAALgCjBQAAAAAAAAD/AAIAAAABAgBYAgAAAAECAAMAAAAAAAAAAA4A+AL2 BAAAhwAAAAACAAQArwQHAAAAsAQBAAAAsQQCAAAAtQQEAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAp AKEAIgABAGQAAQABAAEAAAD8/wAAAAAAAAAA4D8AAAAAAADgPwEAMwACAAMAARACAAAAAhAQAAAA AAAAAAAAMAqrAjAK0wEzEAAAoAAEABMAFABkEAgAAAABAAAAAQADEAwAAQABAAcABwABAAAAMxAA AFEQDwAAAgAACgAHADoAAAAAAQANEBoAAAALAVMAYwBoAHUAbAB6AGUAKAB3AHYAKQBREBMAAQIA AAoACwA7AAABAAcAAQABAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wAAAAAAADMQAABf EAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEABwAHAAEAAAAzEAAAURAPAAACAAAKAAcAOgAAAAAC AA0QGgAAAAsBVABpAGQAZQBtAGEAbgAoAHcAdgApAFEQEwABAgAACgALADsAAAEABwACAAIAURAI AAIAAAAAAAAAURAIAAMBAAAAAAAABhAIAP//AQABAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAA AxAMAAEAAQAHAAcAAQAAADMQAABREA8AAAIAAAoABwA6AAAAAAMADRAQAAAABgFTAEQAKAB3AHYA KQBREBMAAQIAAAoACwA7AAABAAcAAwADAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wIA AgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEABwAHAAEAAAAzEAAAURAPAAACAAAK AAcAOgAAAAAEAA0QGgAAAAsBTQBpAG4AaQBtAGEAeAAoAHcAdgApAFEQEwABAgAACgALADsAAAEA BwAEAAQAURAIAAIAAAAAAAAAURAIAAMBAAAAAAAABhAIAP//AwADAAAAMxAAAF8QAgAAADQQAABF EAIAAAA0EAAAAxAMAAEAAQAHAAcAAQAAADMQAABREA8AAAIAAAoABwA6AAAAAAUADRAUAAAACAFD AG8AcABlAGwAYQBuAGQAURATAAECAAAKAAsAOwAAAQAHAAUABQBREAgAAgAAAAAAAABREAgAAwEA AAAAAAAGEAgA//8EAAQAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAcABwABAAAA MxAAAFEQDwAAAgAACgAHADoAAAAABgANEA4AAAAFAUIAbwByAGQAYQBREBMAAQIAAAoACwA7AAAB AAcABgAGAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wUABQAAADMQAABfEAIAAAA0EAAA RRACAAAANBAAAAMQDAABAAEABwAHAAEAAAAzEAAAURAPAAACAAAKAAcAOgAAAAAHAA0QIAAAAA4B SQBuAHMAdABhAG4AdAAgAFIAdQBuAG8AZgBmAFEQEwABAgAACgALADsAAAEABwAHAAcAURAIAAIA AAAAAAAAURAIAAMBAAAAAAAABhAIAP//BgAGAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAM AAEAAQAHAAcAAQAAADMQAABREA8AAAIAAAoABwA6AAAAAAgADRAWAAAACQFQAGwAdQByAGEAbABp AHQAeQBREBMAAQIAAAoACwA7AAABAAcACAAIAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD/ /wcABwAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAOAAAAJBACAAIAJRAgAAICAQAAAAAA 8f7//97///8AAAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAF AFEQCAAAAQAAAAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADx/v//3v///wAAAAAAAAAAsQBNACAQ AAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAUAURAIAAABAAAAAAAANBAAAEYQAgAB AEEQEgAAAG0BAAB4AgAANQwAAHALAAAzEAAATxAUAAIAAgCaAAAALQIAAAgNAACQDAAAHRASAAAA AAAAAAAAAAAAAAAAAAAAADMQAAAgEAgAAQABAAEAAQBiEBIAAAAAAAEAAAABAAAAAAAAAG8AHhAe AAIAAwEAAAAAAAAAAAAAAAAAAAAAAAAAACMATQAAADQQAAAdEBIAAQAAAAAAAAAAAAAAAAAAAAAA MxAAAB8QKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwFOEAIACQAe EB4AAgADAQAAAAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAANBAAACUQIAACAgEAAAAAAKIGAAC9DgAA ygEAAJcAAACBAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAXQAAABYAAAAmEAIACABREAgAAAEA AAAAAAANECAAAAAOAUMAbABvAG4AZQAgAFMAZQB0ACAAUwBpAHoAZQAnEAYAAwAAAAAANBAAACUQ IAACAgEAAAAAADMAAABABwAAZwAAAOEBAACBAk0AAABaADMQAABPEBQAAgACAAAAAAAAAAAAFgAA AEMAAAAmEAIACABREAgAAAEAAAAAAAANEBYAAAAJASUAIABXAGkAbgBuAGUAcgBzACcQBgACAAAA AAA0EAAANRAAADIQBAAAAAMAMxAAAAcQDACAgIAAAAAAAAAAFwAKEBAAwMDAAAAAAAABAAAAFgAI ADQQAAAUEBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAzEAAAFxAGAAAAlgAAACIQCgAAAAAAAAAAAA8A FRAUANYNAAAKBgAAuAEAAEwEAAADAR8AMxAAAE8QFAAFAAIA1g0AAAoGAAAAAAAAAAAAACUQIAAC AgEAAAAAAPH+///e////AAAAAAAAAACxAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAA AABREAgAAAEAAAAAAAA0EAAANBAAAAYQCAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8J AE0AChAQAP///wAAAAAAAQABAE4ATQALEAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQA AAA0EAAANBAAADQQAAAlECAAAgIBAAAAAAABBAAAUgAAAJoHAABKAQAAgQBNADAQAAAzEAAATxAU AAIAAgAAAAAAAAAAAKoBAAAwAAAAJhACAAcAURAIAAABAAAAAAAADRCkAAAAUAFTAHkAbgB0AGgA ZQB0AGkAYwAgAEMAbABvAG4AZQAgAFQAZQBzAHQACgAzADAALAAwADAAMAAgAFQAcgBpAGEAbABz ACwAIAAxADUAMAAgAFYAbwB0AGUAcgBzACwAIAAxAC4AMAAgAEkAbgB2AG8AbAB2AGUAbQBlAG4A dAAsACAAMQAuADAAIABEAGkAcwBjAGUAcgBuAG0AZQBuAHQAJxAGAAEAAAAAADQQAAA0EAAAAAIO AAAAAAAHAAAAAAAIAAAAZRACAAIAZRACAAEAAwIOAAAAAAAAALfRAN4CCcI/AwIOAAAAAQAAAIPt xEXbHsI/AwIOAAAAAgAAAC3fl5M9L8I/AwIOAAAAAwAAAOOlm8QgsMI/AwIOAAAABAAAAGWV05e4 aLs/AwIOAAAABQAAAIt5VzaGE7s/AwIOAAAABgAAANc07zhFR8I/AwIOAAAABwAAACcxCKwcWu4/ AwIOAAEAAAAAAGHD0ytlGcI/AwIOAAEAAQAAAOmKtV9RJMI/AwIOAAEAAgAAAPle4FK7TMI/AwIO AAEAAwAAAI4z6rrduMI/AwIOAAEABAAAAF7HuUbeTL8/AwIOAAEABQAAALIh/mglmr0/AwIOAAEA BgAAACsYldQJaMI/AwIOAAEABwAAAIhjXdxGA6g/AwIOAAIAAAAAALWmeccpOsI/AwIOAAIAAQAA AD6mUkzLNcI/AwIOAAIAAgAAAD1uW/sVRcI/AwIOAAIAAwAAADpQRB8ZmMI/AwIOAAIABAAAACOZ ch47lcE/AwIOAAIABQAAAJZjFdagQsA/AwIOAAIABgAAAFzRSVZYg8I/AwIOAAIABwAAANyZF9z8 rG8/AwIOAAMAAAAAABm1XnMhacI/AwIOAAMAAQAAAJHtfD81XsI/AwIOAAMAAgAAACsYldQJaMI/ AwIOAAMAAwAAAEymCkYldcI/AwIOAAMABAAAAEnfB4fxrcI/AwIOAAMABQAAANrugb2c7ME/AwIO AAMABgAAAPrt68A5I8I/AwIOAAMABwAAAGEyVTAqqUM/AwIOAAQAAAAAAEwKj53KfMI/AwIOAAQA AQAAACp8GSyvb8I/AwIOAAQAAgAAAEwKj53KfMI/AwIOAAQAAwAAAJMYBFYOLcI/AwIOAAQABAAA APei2kCnDcQ/AwIOAAQABQAAAKO/NKXi7MM/AwIOAAQABgAAAHBfB84ZUcI/AwIOAAQABwAAAC1D HOviNho/AwIOAAUAAAAAANjD+qbDHcI/AwIOAAUAAQAAAAu1pnnHKcI/AwIOAAUAAgAAAOrCrLAG FcI/AwIOAAUAAwAAAJqZmZmZmcE/AwIOAAUABAAAAJsTGEt+scQ/AwIOAAUABQAAAMUgsHJokcU/ AwIOAAUABgAAANc07zhFR8I/AwIOAAUABwAAAOduvZzseQE/AwIOAAYAAAAAADm0yHa+n8I/AwIO AAYAAQAAAI/C9Shcj8I/AwIOAAYAAgAAAD1uW/sVRcI/AwIOAAYAAwAAAJgKjisbw8E/AwIOAAYA BAAAAF2vTF/iosU/AwIOAAYABQAAAIn/2ISh+8c/AwIOAAYABgAAAGJfT9S/EcI/AwIOAAYABwAA AAAAAAAAAAAAZRACAAMAPgIKAAYABwAAAAAAAACgAAQAEwAUAAoAAAAJCBAAAAYgANMQzAdJAAAA BgAAABQABQACAAAmQRUACgAHAABQYWdlICZQgwACAAAAhAACAAAATQB+AQAASABQACAATABhAHMA ZQByAEoAZQB0ACAANgBQAC8ANgBNAFAAIAAtACAARQBuAGgAYQBuAGMAZQBkAAAAAAAAAAAERADU AKgAAw8AAAIAAQD2BPgCAAABAAcA/P8CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApAAAAD8nzmQAAAQABAAEAAAAAAAAAAAAAAAAA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4AowUAAAAAAAAA/wACAAAA AQIAWAIAAAABAgADAAAAAAAAAAAOAPgC9gQAAIcAAAAAAgAEAK8EBwAAALAEAQAAALEEAgAAALUE BAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAKQChACIAAQBkAAEAAQABAAAA/P8AAAAAAAAAAOA/AAAA AAAA4D8BADMAAgADAAEQAgAAAAIQEAAAAAAAAAAAADAKqwIwCtMBMxAAAKAABAATABQAZBAIAAAA AQAAAAEAAxAMAAEAAQAHAAcAAQAAADMQAABREA8AAAIAAAoABwA6AAAAAAEADRAaAAAACwFTAGMA aAB1AGwAegBlACgAdwB2ACkAURATAAECAAAKAAsAOwAAAQAHAAEAAQBREAgAAgAAAAAAAABREAgA AwEAAAAAAAAGEAgA//8AAAAAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAcABwAB AAAAMxAAAFEQDwAAAgAACgAHADoAAAAAAgANEBoAAAALAVQAaQBkAGUAbQBhAG4AKAB3AHYAKQBR EBMAAQIAAAoACwA7AAABAAcAAgACAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wEAAQAA ADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEABwAHAAEAAAAzEAAAURAPAAACAAAKAAcA OgAAAAADAA0QEAAAAAYBUwBEACgAdwB2ACkAURATAAECAAAKAAsAOwAAAQAHAAMAAwBREAgAAgAA AAAAAABREAgAAwEAAAAAAAAGEAgA//8CAAIAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwA AQABAAcABwABAAAAMxAAAFEQDwAAAgAACgAHADoAAAAABAANEBoAAAALAU0AaQBuAGkAbQBhAHgA KAB3AHYAKQBREBMAAQIAAAoACwA7AAABAAcABAAEAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQ CAD//wMAAwAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEABwAHAAEAAAAzEAAAURAP AAACAAAKAAcAOgAAAAAFAA0QFAAAAAgBQwBvAHAAZQBsAGEAbgBkAFEQEwABAgAACgALADsAAAEA BwAFAAUAURAIAAIAAAAAAAAAURAIAAMBAAAAAAAABhAIAP//BAAEAAAAMxAAAF8QAgAAADQQAABF EAIAAAA0EAAAAxAMAAEAAQAHAAcAAQAAADMQAABREA8AAAIAAAoABwA6AAAAAAYADRAOAAAABQFC AG8AcgBkAGEAURATAAECAAAKAAsAOwAAAQAHAAYABgBREAgAAgAAAAAAAABREAgAAwEAAAAAAAAG EAgA//8FAAUAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAcABwABAAAAMxAAAFEQ DwAAAgAACgAHADoAAAAABwANECAAAAAOAUkAbgBzAHQAYQBuAHQAIABSAHUAbgBvAGYAZgBREBMA AQIAAAoACwA7AAABAAcABwAHAFEQCAACAAAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wYABgAAADMQ AABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAOAAAAJBACAAIAJRAgAAICAQAAAAAA8f7//97///8A AAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAFAFEQCAAAAQAA AAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADx/v//3v///wAAAAAAAAAAsQBNACAQAAAzEAAATxAU AAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAUAURAIAAABAAAAAAAANBAAAEYQAgABAEEQEgAAAEwB AAB4AgAA6gsAAHALAAAzEAAATxAUAAIAAgCaAAAALQIAALMMAACQDAAAHRASAAAAAAAAAAAAAAAA AAAAAAAAADMQAAAgEAgAAQABAAEAAABiEBIAAAAAAAEAAAABAAAAAAAAAG8ANBAAAB0QEgABAAAA AAAAAAAAAAAAAAAAAAAzEAAAHxAqAJqZmZmZmak/AAAAAAAA0D8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAcAU4QAgAJADQQAAAlECAAAgIBAAAAAABcBgAAvQ4AAMoBAACXAAAAgQBNAAAAAAAzEAAA TxAUAAIAAgAAAAAAAAAAAF0AAAAWAAAAJhACAAgAURAIAAABAAAAAAAADRAgAAAADgFDAGwAbwBu AGUAIABTAGUAdAAgAFMAaQB6AGUAJxAGAAMAAAAAADQQAAAlECAAAgIBAAAAAAAzAAAAQAcAAGcA AADhAQAAgQJNAAAAWgAzEAAATxAUAAIAAgAAAAAAAAAAABYAAABDAAAAJhACAAgAURAIAAABAAAA AAAADRAWAAAACQElACAAVwBpAG4AbgBlAHIAcwAnEAYAAgAAAAAANBAAADUQAAAyEAQAAAADADMQ AAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAAAQAAABYACAA0EAAAFBAUAAAAAAAAAAAAAAAA AAAAAAAAAAAAMxAAABgQAgAAACIQCgAAAAAAAAAAAA8AFRAUAIENAABPBgAADAIAAMIDAAADAR8A MxAAAE8QFAAFAAIAgQ0AAE8GAAAAAAAAAAAAACUQIAACAgEAAAAAAPH+///e////AAAAAAAAAACx AE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABREAgAAAEAAAAAAAA0EAAANBAAAAYQ CAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8JAE0AChAQAP///wAAAAAAAQABAE4ATQAL EAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQAAAA0EAAANBAAADQQAAAlECAAAgIBAAAA AAABBAAAUgAAAJoHAABKAQAAgQBNADAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAKoBAAAwAAAAJhAC AAcAURAIAAABAAAAAAAADRCkAAAAUAFTAHkAbgB0AGgAZQB0AGkAYwAgAEMAbABvAG4AZQAgAFQA ZQBzAHQACgAzADAALAAwADAAMAAgAFQAcgBpAGEAbABzACwAIAAxADUAMAAgAFYAbwB0AGUAcgBz ACwAIAAxAC4AMAAgAEkAbgB2AG8AbAB2AGUAbQBlAG4AdAAsACAAMQAuADAAIABEAGkAcwBjAGUA cgBuAG0AZQBuAHQAJxAGAAEAAAAAADQQAAA0EAAAAAIOAAAAAAAHAAAAAAAHAAAAZRACAAIAZRAC AAEAAwIOAAAAAAAAALfRAN4CCcI/AwIOAAAAAQAAAIPtxEXbHsI/AwIOAAAAAgAAAC3fl5M9L8I/ AwIOAAAAAwAAAOOlm8QgsMI/AwIOAAAABAAAAGWV05e4aLs/AwIOAAAABQAAAIt5VzaGE7s/AwIO AAAABgAAANc07zhFR8I/AwIOAAEAAAAAAGHD0ytlGcI/AwIOAAEAAQAAAOmKtV9RJMI/AwIOAAEA AgAAAPle4FK7TMI/AwIOAAEAAwAAAI4z6rrduMI/AwIOAAEABAAAAF7HuUbeTL8/AwIOAAEABQAA ALIh/mglmr0/AwIOAAEABgAAACsYldQJaMI/AwIOAAIAAAAAALWmeccpOsI/AwIOAAIAAQAAAD6m UkzLNcI/AwIOAAIAAgAAAD1uW/sVRcI/AwIOAAIAAwAAADpQRB8ZmMI/AwIOAAIABAAAACOZch47 lcE/AwIOAAIABQAAAJZjFdagQsA/AwIOAAIABgAAAFzRSVZYg8I/AwIOAAMAAAAAABm1XnMhacI/ AwIOAAMAAQAAAJHtfD81XsI/AwIOAAMAAgAAACsYldQJaMI/AwIOAAMAAwAAAEymCkYldcI/AwIO AAMABAAAAEnfB4fxrcI/AwIOAAMABQAAANrugb2c7ME/AwIOAAMABgAAAPrt68A5I8I/AwIOAAQA AAAAAEwKj53KfMI/AwIOAAQAAQAAACp8GSyvb8I/AwIOAAQAAgAAAEwKj53KfMI/AwIOAAQAAwAA AJMYBFYOLcI/AwIOAAQABAAAAPei2kCnDcQ/AwIOAAQABQAAAKO/NKXi7MM/AwIOAAQABgAAAHBf B84ZUcI/AwIOAAUAAAAAANjD+qbDHcI/AwIOAAUAAQAAAAu1pnnHKcI/AwIOAAUAAgAAAOrCrLAG FcI/AwIOAAUAAwAAAJqZmZmZmcE/AwIOAAUABAAAAJsTGEt+scQ/AwIOAAUABQAAAMUgsHJokcU/ AwIOAAUABgAAANc07zhFR8I/AwIOAAYAAAAAADm0yHa+n8I/AwIOAAYAAQAAAI/C9Shcj8I/AwIO AAYAAgAAAD1uW/sVRcI/AwIOAAYAAwAAAJgKjisbw8E/AwIOAAYABAAAAF2vTF/iosU/AwIOAAYA BQAAAIn/2ISh+8c/AwIOAAYABgAAAGJfT9S/EcI/ZRACAAMAPgIKAAYGBgAAAGJfT9SgAAQAEwAU AAoAAAAJCBAAAAYgANMQzAdJAAAABgAAABQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAAAAABAAEA AQAGAcI/ZQAAAAAAAADgPwAAAAAAAOA/ZQAzAAIAAwBgEAoAyzTrI8gAAAAJAGAQCgDLNOsjyAAB AAoAYBAKALw05SPwAAAACwABEAIAAAACEBAAAAAAAAAAAAAwCqsCMArTATMQAACgAAQAEwAUAGQQ CAAAAAEAAAABAAMQDAADAAEACAAIAAEAAAAzEAAAURAIAAABAAAAAAAAURATAAECAAAKAAsAOwAA AQABAAEACABREBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQCAADAQAAAAAAAAYQCAD//wAAAAAAADMQ AABfEAIAAAA0EAAARRACAAAANBAAAAMQDAADAAEACAAIAAEAAAAzEAAAURAIAAABAAAAAAAAURAT AAECAAAKAAsAOwAAAgACAAEACABREBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQCAADAQAAAAAAAAYQ CAD//wEAAQAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAADAAEACAAIAAEAAAAzEAAAURAI AAABAAAAAAAAURATAAECAAAKAAsAOwAAAwADAAEACABREBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQ CAADAQAAAAAAAAYQCAD//wIAAgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAADAAEACAAI AAEAAAAzEAAAURAIAAABAAAAAAAAURATAAECAAAKAAsAOwAABAAEAAEACABREBMAAgIAAAoACwA7 AAAAAAAAAQAIAFEQCAADAQAAAAAAAAYQCAD//wMAAwAAADMQAABfEAIAAAA0EAAARRACAAAANBAA AAMQDAADAAEACAAIAAEAAAAzEAAAURAIAAABAAAAAAAAURATAAECAAAKAAsAOwAABQAFAAEACABR EBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQCAADAQAAAAAAAAYQCAD//wQABAAAADMQAABfEAIAAAA0 EAAARRACAAAANBAAAAMQDAADAAEACAAIAAEAAAAzEAAAURAIAAABAAAAAAAAURATAAECAAAKAAsA OwAABgAGAAEACABREBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQCAADAQAAAAAAAAYQCAD//wUABQAA ADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAADAAEACAAIAAEAAAAzEAAAURAIAAABAAAAAAAA URATAAECAAAKAAsAOwAABwAHAAEACABREBMAAgIAAAoACwA7AAAAAAAAAQAIAFEQCAADAQAAAAAA AAYQCAD//wYABgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAOAAAAJBACAAIAJRAgAAIC AQAAAAAA8f7//97///8AAAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAA ACYQAgAJAFEQCAAAAQAAAAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADx/v//3v///wAAAAAAAAAA sQBNACAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAoAURAIAAABAAAAAAAANBAA AEYQAgABAEEQEgAAAEMBAAB4AgAA+gwAAA4MAAAzEAAATxAUAAIAAgAvAAAALQIAAA4OAAAvDQAA HRASAAAAAAAAAAAAAAAAAAAAAAAAADMQAAAgEAgAAQABAAEAAQBiEBIAAAAAAAEAAAABAAAAAAAA AO8AHhAeAAIAAwEAAAAAAAAAAAAAAAAAAAAAAAAAACMATQAAADQQAAAdEBIAAQAAAAAAAAAAAAAA AAAAAAAAMxAAAB8QKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwEe EB4AAgADAQAAAAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAAIRACAAEABxAMAAAAAAAAAP//CQBNADQQ AAA1EAAAMhAEAAAAAwAzEAAABxAMAICAgAAAAAAAAAAXAAoQEADAwMAAAAAAAAEAAAAWAE8ANBAA ABQQFAAAAAAAAAAAAAAAAAAAAAAAAAAAADMQAAAXEAYAnP+WAAYAIhAKAAAAAAAAAAAADwAVEBQA cA4AAJsGAAAdAQAAwgMAAAMBHwAzEAAATxAUAAUAAgBwDgAAmwYAAAAAAAAAAAAAJRAgAAICAQAA AAAA8f7//97///8AAAAAAAAAALEATQAAAAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAAFEQ CAAAAQAAAAAAADQQAAA0EAAANBAAADQQAAAlECAAAgIBAAAAAAABBAAAUgAAAJoHAABKAQAAgQBN ADAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAKoBAAAwAAAAJhACAAsAURAIAAABAAAAAAAADRCkAAAA UAFTAHkAbgB0AGgAZQB0AGkAYwAgAEMAbABvAG4AZQAgAFQAZQBzAHQACgAzADAALAAwADAAMAAg AFQAcgBpAGEAbABzACwAIAAxADUAMAAgAFYAbwB0AGUAcgBzACwAIAAxAC4AMAAgAEkAbgB2AG8A bAB2AGUAbQBlAG4AdAAsACAAMQAuADAAIABEAGkAcwBjAGUAcgBuAG0AZQBuAHQAJxAGAAEAAAAA ADQQAAA0EAAAAAIOAAAAAAAIAAAAAAAHAAAAZRACAAIABAIfAAAAAAAAAAsAAVMAYwBoAHUAbAB6 AGUAKAB3AHYAKQAEAh8AAAABAAAACwABUwBjAGgAdQBsAHoAZQAoAHcAdgApAAQCHwAAAAIAAAAL AAFTAGMAaAB1AGwAegBlACgAdwB2ACkABAIfAAAAAwAAAAsAAVMAYwBoAHUAbAB6AGUAKAB3AHYA KQAEAh8AAAAEAAAACwABUwBjAGgAdQBsAHoAZQAoAHcAdgApAAQCHwAAAAUAAAALAAFTAGMAaAB1 AGwAegBlACgAdwB2ACkABAIfAAAABgAAAAsAAVMAYwBoAHUAbAB6AGUAKAB3AHYAKQAEAh8AAQAA AAAACwABVABpAGQAZQBtAGEAbgAoAHcAdgApAAQCHwABAAEAAAALAAFUAGkAZABlAG0AYQBuACgA dwB2ACkABAIfAAEAAgAAAAsAAVQAaQBkAGUAbQBhAG4AKAB3AHYAKQAEAh8AAQADAAAACwABVABp AGQAZQBtAGEAbgAoAHcAdgApAAQCHwABAAQAAAALAAFUAGkAZABlAG0AYQBuACgAdwB2ACkABAIf AAEABQAAAAsAAVQAaQBkAGUAbQBhAG4AKAB3AHYAKQAEAh8AAQAGAAAACwABVABpAGQAZQBtAGEA bgAoAHcAdgApAAQCFQACAAAAAAAGAAFTAEQAKAB3AHYAKQAEAhUAAgABAAAABgABUwBEACgAdwB2 ACkABAIVAAIAAgAAAAYAAVMARAAoAHcAdgApAAQCFQACAAMAAAAGAAFTAEQAKAB3AHYAKQAEAhUA AgAEAAAABgABUwBEACgAdwB2ACkABAIVAAIABQAAAAYAAVMARAAoAHcAdgApAAQCFQACAAYAAAAG AAFTAEQAKAB3AHYAKQAEAh8AAwAAAAAACwABTQBpAG4AaQBtAGEAeAAoAHcAdgApAAQCHwADAAEA AAALAAFNAGkAbgBpAG0AYQB4ACgAdwB2ACkABAIfAAMAAgAAAAsAAU0AaQBuAGkAbQBhAHgAKAB3 AHYAKQAEAh8AAwADAAAACwABTQBpAG4AaQBtAGEAeAAoAHcAdgApAAQCHwADAAQAAAALAAFNAGkA bgBpAG0AYQB4ACgAdwB2ACkABAIfAAMABQAAAAsAAU0AaQBuAGkAbQBhAHgAKAB3AHYAKQAEAh8A AwAGAAAACwABTQBpAG4AaQBtAGEAeAAoAHcAdgApAAQCGQAEAAAAAAAIAAFDAG8AcABlAGwAYQBu AGQABAIZAAQAAQAAAAgAAUMAbwBwAGUAbABhAG4AZAAEAhkABAACAAAACAABQwBvAHAAZQBsAGEA bgBkAAQCGQAEAAMAAAAIAAFDAG8AcABlAGwAYQBuAGQABAIZAAQABAAAAAgAAUMAbwBwAGUAbABh AG4AZAAEAhkABAAFAAAACAABQwBvAHAAZQBsAGEAbgBkAAQCGQAEAAYAAAAIAAFDAG8AcABlAGwA YQBuAGQABAITAAUAAAAAAAUAAUIAbwByAGQAYQAEAhMABQABAAAABQABQgBvAHIAZABhAAQCEwAF AAIAAAAFAAFCAG8AcgBkAGEABAITAAUAAwAAAAUAAUIAbwByAGQAYQAEAhMABQAEAAAABQABQgBv AHIAZABhAAQCEwAFAAUAAAAFAAFCAG8AcgBkAGEABAITAAUABgAAAAUAAUIAbwByAGQAYQAEAiUA BgAAAAAADgABSQBuAHMAdABhAG4AdAAgAFIAdQBuAG8AZgBmAAQCJQAGAAEAAAAOAAFJAG4AcwB0 AGEAbgB0ACAAUgB1AG4AbwBmAGYABAIlAAYAAgAAAA4AAUkAbgBzAHQAYQBuAHQAIABSAHUAbgBv AGYAZgAEAiUABgADAAAADgABSQBuAHMAdABhAG4AdAAgAFIAdQBuAG8AZgBmAAQCJQAGAAQAAAAO AAFJAG4AcwB0AGEAbgB0ACAAUgB1AG4AbwBmAGYABAIlAAYABQAAAA4AAUkAbgBzAHQAYQBuAHQA IABSAHUAbgBvAGYAZgAEAiUABgAGAAAADgABSQBuAHMAdABhAG4AdAAgAFIAdQBuAG8AZgBmAAQC GwAHAAAAAAAJAAFQAGwAdQByAGEAbABpAHQAeQAEAhsABwABAAAACQABUABsAHUAcgBhAGwAaQB0 AHkABAIbAAcAAgAAAAkAAVAAbAB1AHIAYQBsAGkAdAB5AAQCGwAHAAMAAAAJAAFQAGwAdQByAGEA bABpAHQAeQAEAhsABwAEAAAACQABUABsAHUAcgBhAGwAaQB0AHkABAIbAAcABQAAAAkAAVAAbAB1 AHIAYQBsAGkAdAB5AAQCGwAHAAYAAAAJAAFQAGwAdQByAGEAbABpAHQAeQBlEAIAAQADAg4AAAAA AAAAt9EA3gIJwj8DAg4AAAABAAAAYcPTK2UZwj8DAg4AAAACAAAAtaZ5xyk6wj8DAg4AAAADAAAA GbVecyFpwj8DAg4AAAAEAAAATAqPncp8wj8DAg4AAAAFAAAA2MP6psMdwj8DAg4AAAAGAAAAObTI dr6fwj8DAg4AAQAAAAAAg+3ERdsewj8DAg4AAQABAAAA6Yq1X1Ekwj8DAg4AAQACAAAAPqZSTMs1 wj8DAg4AAQADAAAAke18PzVewj8DAg4AAQAEAAAAKnwZLK9vwj8DAg4AAQAFAAAAC7Wmeccpwj8D Ag4AAQAGAAAAj8L1KFyPwj8DAg4AAgAAAAAALd+Xkz0vwj8DAg4AAgABAAAA+V7gUrtMwj8DAg4A AgACAAAAPW5b+xVFwj8DAg4AAgADAAAAKxiV1Alowj8DAg4AAgAEAAAATAqPncp8wj8DAg4AAgAF AAAA6sKssAYVwj8DAg4AAgAGAAAAPW5b+xVFwj8DAg4AAwAAAAAA46WbxCCwwj8DAg4AAwABAAAA jjPqut24wj8DAg4AAwACAAAAOlBEHxmYwj8DAg4AAwADAAAATKYKRiV1wj8DAg4AAwAEAAAAkxgE Vg4twj8DAg4AAwAFAAAAmpmZmZmZwT8DAg4AAwAGAAAAmAqOKxvDwT8DAg4ABAAAAAAAZZXTl7ho uz8DAg4ABAABAAAAXse5Rt5Mvz8DAg4ABAACAAAAI5lyHjuVwT8DAg4ABAADAAAASd8Hh/Gtwj8D Ag4ABAAEAAAA96LaQKcNxD8DAg4ABAAFAAAAmxMYS36xxD8DAg4ABAAGAAAAXa9MX+KixT8DAg4A BQAAAAAAi3lXNoYTuz8DAg4ABQABAAAAsiH+aCWavT8DAg4ABQACAAAAlmMV1qBCwD8DAg4ABQAD AAAA2u6BvZzswT8DAg4ABQAEAAAAo780peLswz8DAg4ABQAFAAAAxSCwcmiRxT8DAg4ABQAGAAAA if/YhKH7xz8DAg4ABgAAAAAA1zTvOEVHwj8DAg4ABgABAAAAKxiV1Alowj8DAg4ABgACAAAAXNFJ VliDwj8DAg4ABgADAAAA+u3rwDkjwj8DAg4ABgAEAAAAcF8HzhlRwj8DAg4ABgAFAAAA1zTvOEVH wj8DAg4ABgAGAAAAYl9P1L8Rwj8DAg4ABwAAAAAAJzEIrBxa7j8DAg4ABwABAAAAiGNd3EYDqD8D Ag4ABwACAAAA3JkX3Pysbz8DAg4ABwADAAAAYTJVMCqpQz8DAg4ABwAEAAAALUMc6+I2Gj8DAg4A BwAFAAAA5269nOx5AT8DAg4ABwAGAAAAAAAAAAAAAABlEAIAAwA+AgoABwAGAAAAAAAAAKAABAAT ABQACgAAAAkIEAAABhAA0xDMB0kAAAAGAAAACwIUAAAAAAAAAAAADQAAAGVAAABfRwAADQACAAEA DAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAI AAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAAE0AfgEAAEgAUAAgAEwA YQBzAGUAcgBKAGUAdAAgADYAUAAvADYATQBQACAALQAgAEUAbgBoAGEAbgBjAGUAZAAAAAAAAAAA BEQA1ACoAAMPAAABAAEA9gT4AgAAAQAHAPz/AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQAAAA/J85kAAAEAAQABAAAAAAAAAAAA AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAKMFAAAAAAAAAP8A AgAAAAECAFgCAAAAAQIAAwAAAAAAAAAADgD4AvYEAACHAAAAAAIABACvBAcAAACwBAEAAACxBAIA AAC1BAQAAAAAAAAAAAAAAAAAAAAAAAAAAQAAACkAoQAiAAEAZAABAAEAAQACAPz/AAAAAAAAAADg PwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAAEkNFQAGAAIAfQAMAAEAAQAkDBcABgACAH0ADAACAAIA 2wwXAAYAAgB9AAwAAwADAG0HFwAGAAIAfQAMAAQABAC2DBcABgACAH0ADAAFAAUA2wkXAAYAAgB9 AAwABgAGAEkHFwAGAAIAfQAMAAcABwCSDRcABgACAH0ADAAIAAgAtggXAAYAAgB9AAwACQAAASQJ FQAAAAIAAAIOAAAAAAANAAAAAAAJAAAACAIQAAAAAAAJAP8AAABUMIABGgAIAhAAAQAAAAkA/wAA AGIAAAECAAgCEAACAAAACQD/AAAAAAAAAWIACAIQAAMAAAAJAP8AAAAAAAABAAAIAhAABAAAAAkA /wAAAOCBAAECAAgCEAAFAAAACQD/AAAAAAAAAQAACAIQAAYAAAAJAP8AAAAAAAABAAAIAhAABwAA AAkA/wAAAGIAAAECAAgCEAAIAAAACQD/AAAAAAAAAWIACAIQAAkAAAAJAP8AAAAAAAABAAAIAhAA CgAAAAkA/wAAAGIAAAEAAAgCEAALAAAACQD/AAAAAAAAAQAACAIQAAwAAAAJAP8AAAAAAAABqgD9 AAoAAAAAABkAAAAAAP0ACgAAAAEAHAABAAAA/QAKAAAAAgAcAAIAAAD9AAoAAAADABwAAwAAAP0A CgAAAAQAHAAEAAAA/QAKAAAABQAcAAUAAAD9AAoAAAAGABwABgAAAP0ACgAAAAcAHAAHAAAA/QAK AAAACAAcAAgAAAB+AgoAAQAAABYAAADwPwMCDgABAAEAHQC30QDeAgnCPwMCDgABAAIAHQCD7cRF 2x7CPwMCDgABAAMAHQAt35eTPS/CPwMCDgABAAQAHQDjpZvEILDCPwMCDgABAAUAHQBlldOXuGi7 PwMCDgABAAYAHQCLeVc2hhO7PwMCDgABAAcAHQDXNO84RUfCPwMCDgABAAgAHQAnMQisHFruP34C CgACAAAAFgAAAABAAwIOAAIAAQAdAGHD0ytlGcI/AwIOAAIAAgAdAOmKtV9RJMI/AwIOAAIAAwAd APle4FK7TMI/AwIOAAIABAAdAI4z6rrduMI/AwIOAAIABQAdAF7HuUbeTL8/AwIOAAIABgAdALIh /mglmr0/AwIOAAIABwAdACsYldQJaMI/AwIOAAIACAAdAIhjXdxGA6g/fgIKAAMAAAAWAAAACEAD Ag4AAwABAB0AtaZ5xyk6wj8DAg4AAwACAB0APqZSTMs1wj8DAg4AAwADAB0APW5b+xVFwj8DAg4A AwAEAB0AOlBEHxmYwj8DAg4AAwAFAB0AI5lyHjuVwT8DAg4AAwAGAB0AlmMV1qBCwD8DAg4AAwAH AB0AXNFJVliDwj8DAg4AAwAIAB0A3JkX3Pysbz9+AgoABAAAABYAAAAQQAMCDgAEAAEAHQAZtV5z IWnCPwMCDgAEAAIAHQCR7Xw/NV7CPwMCDgAEAAMAHQArGJXUCWjCPwMCDgAEAAQAHQBMpgpGJXXC PwMCDgAEAAUAHQBJ3weH8a3CPwMCDgAEAAYAHQDa7oG9nOzBPwMCDgAEAAcAHQD67evAOSPCPwMC DgAEAAgAHQBhMlUwKqlDP34CCgAFAAAAFgAAABRAAwIOAAUAAQAdAEwKj53KfMI/AwIOAAUAAgAd ACp8GSyvb8I/AwIOAAUAAwAdAEwKj53KfMI/AwIOAAUABAAdAJMYBFYOLcI/AwIOAAUABQAdAPei 2kCnDcQ/AwIOAAUABgAdAKO/NKXi7MM/AwIOAAUABwAdAHBfB84ZUcI/AwIOAAUACAAdAC1DHOvi Nho/fgIKAAYAAAAWAAAAGEADAg4ABgABAB0A2MP6psMdwj8DAg4ABgACAB0AC7Wmeccpwj8DAg4A BgADAB0A6sKssAYVwj9+AgoABgAEAB0AAYArQAMCDgAGAAUAHQCbExhLfrHEPwMCDgAGAAYAHQDF ILByaJHFPwMCDgAGAAcAHQDXNO84RUfCPwMCDgAGAAgAHQDnbr2c7HkBP34CCgAHAAAAFgAAABxA AwIOAAcAAQAdADm0yHa+n8I/fgIKAAcAAgAdAAEALUADAg4ABwADAB0APW5b+xVFwj8DAg4ABwAE AB0AmAqOKxvDwT8DAg4ABwAFAB0AXa9MX+KixT8DAg4ABwAGAB0Aif/YhKH7xz8DAg4ABwAHAB0A Yl9P1L8Rwj9+AgoABwAIAB0AAAAAAAECBgAIAAAAFgD9AAoACQAAABYACQAAAH4CCgAJAAEAGAAA TN1A/QAKAAoAAAAWAAoAAAB+AgoACgABABgAAMBiQP0ACgALAAAAFgALAAAAfgIKAAsAAQAbAAAA 8D/9AAoADAAAABYADAAAAH4CCgAMAAEAGwAAAPA/1wAeAEIGAADwAH4AngCeAJ4AngCeAJoAlgAK ABwAHAAcAD4CEgC2AAAAAABAAAAAAAAAAAAAAAAdAA8AAxEABAAAAAEAEQARAAQECgAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCr kQgAKyez2TAAAACcAAAABgAAAAEAAAA4AAAABAAAAEAAAAAIAAAAWAAAABIAAABwAAAADAAAAIgA AAATAAAAlAAAAAIAAADkBAAAHgAAAA0AAABOb3JtYW4gUGV0cnkAAHgAHgAAAA0AAABOb3JtYW4g UGV0cnkAAHgAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAAB+USHAacABAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5E AAAABdXN1ZwuGxCTlwgAKyz5rkwBAAAIAQAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAAZAAAAAsA AABsAAAAEAAAAHQAAAATAAAAfAAAABYAAACEAAAADQAAAIwAAAAMAAAAzAAAAAIAAADkBAAAHgAA AAEAAAAAAGgAAwAAAGoQCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAEAAAA BQAAAERhdGEADAAAAEJhciBDaGFydCAxAAsAAABMaW5lIEdyYXBoAAwAAABCYXIgQ2hhcnQgMgAM EAAABAAAAB4AAAALAAAAV29ya3NoZWV0cwADAAAAAQAAAB4AAAAHAAAAQ2hhcnRzAAMAAAADAAAA AACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAAC AAAA5AQAAEEAAABOAAAAewBBAEUAOAA4ADAANgA4AEQALQBEADUANwBGAC0AMQAxAEQANAAtAEEA NwAwAEYALQAwADAANQAwAEIAQQA4AEYAMQA0AEQAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAO AAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwA AAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAA ACsAAAD+////LQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAAP7////9/////v////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAAAA AAAAAAD+////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAACuRwAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAMAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAAAAQAAAAAAAABQBEAG8AYwB1AG0A ZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAABAAAAAA AAA= ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: application/octet-stream; name="Clones - 30k, 150, 1.0, 1.csv" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Clones - 30k, 150, 1.0, 1.csv" CloneSetSize,Schulze(wv),Tideman(wv),SD(wv),Minimax(wv),Copeland,Borda,Inst= ant Runoff,Plurality 1,14.09%,14.16%,14.21%,14.60%,10.71%,10.58%,14.28%,94.85% 2,14.14%,14.17%,14.30%,14.63%,12.23%,11.56%,14.38%,4.69% 3,14.24%,14.23%,14.27%,14.53%,13.74%,12.70%,14.46%,0.39% 4,14.38%,14.35%,14.38%,14.42%,14.59%,14.00%,14.17%,0.06% 5,14.44%,14.40%,14.44%,14.20%,15.67%,15.57%,14.31%,0.01% 6,14.15%,14.19%,14.13%,13.75%,16.17%,16.85%,14.28%,0.00% 7,14.55%,14.50%,14.27%,13.88%,16.90%,18.74%,14.12%,0.00% ,,,,,,,, Trials:,"30,000",,,,,,, Voters:,150,,,,,,, Involvement:,1.0,,,,,,, Discernment:,1.0,,,,,,, =0D ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: application/octet-stream; name="Clones1 - 30k, 150, 1.0, 1.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Clones1 - 30k, 150, 1.0, 1.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAABmAGYAZsyZM2aAgICZ mf//gIDAwMDM/////8z///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAArP3CdAAAgAElEQVR4nO2di5qrPJJl1V0z01O8/wN3/ZlcJIHCMkIZ2mjt7xxf YRGEtRLsxGRYCCGjJHgXQAjZg4+EjBN8JGSc4CMh4wQfCRkn+EjIOMFHQsYJPhIyTvCRkHGCj4SM E3wkZJzgIyHjBB8JGSf4SMg4wUdCxgk+EjJO8JGQcYKPhIwTfCRknOAjIeMEHwkZJ/hIyDjBR0LG CT4SMk7w0S/hnxSf/Jngi8c3WBmZTVxcPGPCL/TeLYYRq1UXTxYej/Rq9rEGQDqF3ntl25pdvwKm jyasVqfidPjoGHrvlXXY/+cquRVWqUJ8d9nE3R9fb6esaGc22nvNENnyj4dDvGjiEzrvlWPYxz6G zbgQ381kOR5JCcftdL4EkUwXPZwumviEzrvlEGrfOQ3RreXibj5pyceQXqRzLsk8hUUQn9B7xyQf wRwqZPbs28WyNWcfr26lW754L3V7/gQjfxx675tdyJOAyx/7mP50ID6h917J9hc/+RjPVfSxsJ29 3A292BpGyhOf0Huv7BulJd80XW8frfeP+5QheTLfPl6/fzyT/2T9yVXovVviHcj4g5197zK6u8Q7 ldEjIWWFZPJU6SWefjm0yz9fXdLJyJ+GzvslEuTk45L5uE2RPJ7va6aT58Ql9Sx2OScwKrxC54cI BpCfMA4GCHuIZA3jYICgI1nDQCBknOAjIeMEHwkZJ/hIyDjBR0LGCT4SMk6m8jE+AiUkjxZuHAei ZUeKXt05PR6ulncNqn0drso26vhY6MflVS4+PvLv3pJqS3h5Zlrb5AjNzLjLG8tNH0PmYwr8AlQA J/Cq2W9aks1WXnyI1vXWkmpLeHsmWtv9UM7NyfXRsB0Umt9IZywjz4/GR40uGfByO1I36lIFzkxr zhr+h9k+Lb6LOvj47mSHaceWXj2dTpl8t2J7Jt5SxIhsuF4O3ngDesyyEkrga2YIS1pVxN8miB7e gfnPpoiUFmAvPltKhDyz01q/KOH9mWldl/01/r29HFd1PoZYlI2U7s4uPy09BmXsQIw7dIlGXbJ/ WwYvJ2ZURyJeUsL5J0iIcvFw7qO5+CVaSoY8sZNavynh/ZlpXdt9XLKRnW120jlSP6583EZk+li8 pEtwUvZ+77K8mP/F88mUdYtfolnyBVywb5fw8sy1tr8v9G0fkzvxxuC8lOPiBMxliwZiJnABfCpm iWeKVuLEv1pO7ED+8+O2j0nLrlYtL6y6hJdnrrVdzsLd8jEb0Cdx0plzYPZQyUcTPLSPe+X4+G0m Wttr4e74mO5fXWzJUhvqfUwXWAKnsyaISh9PZSYjv93HrfKrNSqteGUJL89Ea7u/VTnes1w+mjz9 O0l0lQyis0rRHBYwW3YyQ67WCZzOmhS1X4YLfvbwxcYpJxk+5otPSWfkedXulfDyzLS2285QfOP6 0XS7dOFjtFuV72XGkxaB+0COpljvZrNfgzNmwcd0RbOHt0fji3TitayaxYdkSfG9+MaSV1lbwjyZ aV2P13a7EblweWObLbo6Zgnhagylc5SA8UiOHorLMsBp2UvZx3RFk4cjTv58upCqxYdoRaLKTyv4 ycdCCfNkpnW9yKOr362Xzi/S5GPkTzN5r/Fx/MVPlbl7jY7jL36u0GxCxgk+EjJO8JGQcYKPhIwT fCRknOAjIeMEHwkZJ/hIyDjBR0LGCT4SMk7wkZBxgo+EjBN8JGSc4CMh4wQfCRkn+EjIOMFHQsYJ PhIyTvCRkHGCj4SME3wkZJzgIyHjBB8JGSf4SMg4wUdCxgk+EjJO8JGQcYKPhIwTfCRknOAjIeME HwkZJ/hIyDjBR0LGCT4SMk7wkZBxUuPjzzThPzmulvWyX2GETJgKo349/J14s3D/Rwh5Lp+V+pUQ Hwnpn9r91Ssf0ZGQZ3PTx5+dWHwk5Nnc9fH3Kuyz//M5T/g/5YS6GAQr0NvowqU70p+3sdHHbBsZ /qec8N81sQhWoDfRhUu/T/93TSz6YD6eP9LBR1G6cOn36XUxCPgIvQ9duPT79H/VZFgf8+MBtgeT 6fyaC72FLlz6jD5Ws/yaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl46PB8msu9Ba6cOn4aLD8 mgu9hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJv oQuXjo8Gy6+50FvowqXjo8Hyay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl 46PB8msu9Ba6cOn4aLD8mgu9hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw /JoLvYUuXPp9uu75HqtZfs2F3kIXLv0+/f/WBB/vNRd6C124dHw0WH7Nhd5CFy4dHw2WX3Oht9CF S8dHg+XXXOgtdOHS8dFg+TUXegtduHR8NFh+zYXeQhcuHR8Nll9zobfQhUvHR4Pl11zoLXTh0vHR YPk1F3oLXbh0fDRYfs2F3kIXLh0fDZZfc6G30IVLx0eD5ddc6C104dLx0WD5NRd6C124dHw0WH7N hd5CFy4dHw2WX3Oht9CFS8dHg+XXXOgtdOHSp/Xxny9LH1fLeplO4tdc6C104dJn9XHVb7Nw/5dM 49dc6C104dLxER9fRxcuHR8PGfN58VGULlz6zD6Gw8ef94/4+BK6cOmz+vjPBznR9nG9CiF62k5d c+8GegtduPT79Dofjfj/viP3MdtGsn0UpQuXPu328XfiyMfzRzr4KEoXLn1WH8Ny6IePL6MLlz6r jz/vH5fjeIAlOipgn8SvudBb6MKlT+tjDcuvudBb6MKl46PB8msu9Ba6cOn4aLD8mgu9hS5cOj4a LL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJvoQuXjo8Gy6+5 0FvowqXjo8Hyay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl46PB8muuMr0u PWsftDF96fgo+9L1pf+/mszoY98fVPjIwLik42OB3rcxk/vYd0wrG4OPBTo+NrL8mgu9RMfHAh0f Zce0Mh0fC3R8lB3TynR8LNDxUXZMK9PxsUDHR9kxrUzHxwIdH2XHtDIdHwt0fJQd08p0fCzQ8VF2 TCvT8bFAx0fZMa1Mx8cCHR9lx7QyHR8LdHyUHdPK9K4HEuLj08FH6H03vvj4lUNPsvyaC72Fjo/4 +PejDvrjcHx8OvgIHR/x0WHUQX8cjo9PBx+h4yM+Oow66I/D8fHp4CN0fMRHh1EH/XG48mmLxH38 p7HH1bJeppP4NRd6C1249Fl9XPXbLNz/JdP4NRd6C124dHzEx9fRhUvHx0PGfF58FKULlz6rj+sb x/1dYzhvHvFRlS5c+qw+ZtvH9Srss3/8kK2uuXcDvYUuXPp9ep2PRsbzMdtGsn0UpQuXzvZxm+f8 kQ4+itKFS8dHfHwdXbj0WX3MjwdYoqMC9kn8mgu9hS5c+rQ+1rD8mgu9hS5cOj4aLL/mQm+hC5eO jwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJvoQuXjo8Gy6+50FvowqXjo8Hy ay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl46PB8msu9Ba6cOn4aLD8mgu9 hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJvoQuX jo8Gy6+50FvowqXjo8Hyay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl46PB 8msu9Ba6cOn4aLD8mgu9hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoL vYUuXDo+Giy/5kJvoQuXjo8Gy6+50FvowqXjo8Hyay70Frpw6fhosPyaq0yvS8/aB21MXzo+yr50 fen/VRN8fJqOj7IvXV86PrrQ8VH2peu7R4mPBXrftuOj7MDoaww+Fuh9GzO5j31/2ClvwfCxQMdH Y7qf/F7/3j/PbfqoPKaV6fhYoGv7uE4bjutwmhkfB6TjY4GOj7JjWpmOjwW6vI9hyXzM58XHAen4 WKC/ysef94/4KEDHxwJd3ceQXvxuI/fZP362Wdfcu4FeSpUxPeH36X0bU+ejkfF8zLaRbB8HpHfd gtX5eJfetzHi28dwXO438XF8Oj4W6PgoO6aV6fhYoL/Cx/14gCU6KmCfxK+50Et0fCzQxX2sYfk1 F3qJjo8FOj7KjmllOj4W6PgoO6aV6fhYoOOj7JhWpuNjgY6PsmNamY6PBTo+yo5pZTo+Fuj4KDum len4WKDjo+yYVqbjY4GOj7JjWpmOjwU6PsqOaWV6Ve7C8fHp4CP0vhtffPzKoSdZfs2F3kLHR3z8 +1EH/XE4Pj4dfISOj/joMOqgPw7Hx6eDj9DxsdnH22fxWYOP0B+A4+MzGuEj9Cfg+PiMRvgI/Qk4 Pj6jET5CfwKOj89ohI/Qn4Dj4zMa4SP0J+B9j47t25jOPqYfm15OdHy0io/Q31H6qD6G64fPzmTT 4SN05dJH8jH+ZSI+Qr9NFy59KB//+yf5Hmj4/cNwYf27cOF4MP7TVPgI/QWlj+pjYtz6l+DCcW+f BR+hv6n0YX1c1r+mkRoYXcX24SP0d5Q+so/rhjGESMT1/WX2uSo+Qn9H6aP6GP8NuO1++ufg4nv4 CP0dpUv4aF3hI/QXlT6Uj/GXp47ffMRvI5fTg/gI/UWlj+RjgzlPgVKqX3Oht9CFS8dHg+rXXOgt dOHS8dGg+jUXegtduHR8NKh+zYXeQhcuHR8Nql9zobfQhUuf1sfjwIL1A9vz3PgoShcufVYfV/02 C4+jY+Np/JoLvYUuXPrUPi74+Eq6cOn4eMiYz4uPonTh0uf1cT9MfT3u5zwvPorShUuf1sff4+2y L1EeZ+z5eFKjuubeDfQWunDp9+l1PhppPp/V/uFo++c5+714fraPonTh0kfdPuaeGU495OP5Ix18 FKULlz6Sj9uG8ysfi7fwcVq6cOlD+bie/zkzrHg+qxYf8+MBtp8IySR+zYXeQhcufVQfa85nFfLT zH3jY42yfs2F3kIXLn1YH5fl4/msju8k4yP0d5Q+so/rhjGUzmfV8nkOPr6YLlz6qD7Gn7Fs99OP WwI+Qn9d6RI+Fq7wcUh6XXrWPmhj+tI7+Bj9vqPufFZ8njMg/f/XBB+fpj/vY4M5T4FSql9zlen4 6ELHR9mXri8dH13o+Cj70vWl42OB3veNNT4yMC7p+Fig923M5D72HdPKxuBjgY6PjVS/5kIv0fGx QMdH2TGtTMfHAh0fZce0Mh0fC3R8lB3TynR8LNDxUXZMK9PxsUDHR9kxrUzHxwK9s48/H+iXrMun wcdp6PhYoPf1MT9O/FqY8+z4+HI6Phboz/u4/Zr78AofoWd0fCzQO/i4rm9mWJ/zWeGjJh0fC/S+ PladzyoEv+8/Ko9pZTo+FuidfVyWz+ezSi/wcQY6Phbo/X1cPpzPKpMSH2eg42OB3tfH5Pw5S7Zh jM3Dx7no+Fig/6GPhSv2Vyek42OB3sHH6Pcdw5/PSnlMK9PxsUB/3scGc54CpVS/5kIv0fGxQMdH 2TGtTMfHAh0fZce0Mh0fC3R8lB3TynR8LNDxUXZMK9PxsUDHR9kxrUzHxwIdH2XHtDIdHwt0fJQd 08p0fCzQ8VF2TCvT8bFAx0fZMa1Mx8cCHR9lx7QyvesfUsDHokY157PaH7vh4/Y9rv2A2PPc+ChK x8fHfcw9K1p128fjMkT/8PEFdHx8xMevz2eFj9AfheNj4uNaUWZY8XxW+3cgb/iYfZs5HCx8lKfj 4+M+1pzPqsnH4zQgq+fnefFRlI6Pz/u4OlI+P0B86+b2MT7FwG595KuVuubeDfQW+m14nY89S79f e52PRj76uCoSiuezavBxufIx20ayfRSls318fPu4exa90Ut1Wc+/mr/bvO3j+SMdfBSl42NfH0tX 2eU3Pp73V/HxNXR8fMbHcGzxqs5n1eDjcuz4xr/5SGbHR1E6Pj7i4/3c3F/9RPVrLvQWet+D8QZt DD46jzroLywdHw2qX3Oht9CFS8dHg+rXXOgtdOHS8dGg+jUXegtduHR8NKh+zYXeQhcuHR8Nql9z obfQhUvHR4Pq11zoLXTh0vHRoPo1F3oLXbh0fDSofs2F3kIXLh0fDapfc6G30IVLH9bH40jW8kTp wacF0P3goyhduPRRfcw9u/QlvaiY47vgoyhduPSRfIy/31HjYzRneveh4KMoXbj0oXz8909yw4zz WeEj9HeVPqqPleez4v0j9FeVPqyPy/L5fFbHnPgI/RWlj+zjumEsn88KH6G/rPRRfYzPabPdv9gw 4iP0V5Uu4WPhit93QH9b6UP5+O35rDgeAPrLSh/JxwZzngKlVL/mQm+hC5eOjwbVr7nQW+jCpeOj QfVrLvQWunDp+GhQ/ZoLvYUuXDo+GlS/5irT/U8qPGhj+tLxUfal60v/d03w8Wk6Psq+dH3p+OhC x0fZl64vHR8L9L478vjIwLik42OB3rcx+IgxDnR8LNAn9xFjfOj4WKB39vFnOJesi6bJnvkzH5XH tDIdHwv0vj7mnl36kl5UzPFd8HFAOj4W6M/7uO3k1foYzZnefSj4OCAdHwv0Dj7+6ye5YWOez0p5 TCvT8bFA7+tj3fms8HE6Oj4W6J19XJaq81nxec5kdHws0Pv7uHw+n1W8kfzax/gUAyHbzuLjoHR8 LND7+rjrFhmXbBjjfdZ7Pm6aLyH6h4+D0/GxQP9DH60rfJyLjo8Fegcfo9931JzPKv/tyHc+hiX3 MZ8XHwek42OB/ryP99Ps47GxjKfway70Eh0fC3RxH6M91OMt6nGE3scjU+uaezfQS6kypif8Pr1v Y+p8NDKej9k2ku3jgPSuW7A6H+/S+zZGe/v4+yMh9vH8kQ4+DkjHxwJd28fDQHyUouNjgf4KH7Ov bKXf8MLHAen4WKDr+/iR6tdc6CU6Phbo+Cg7ppXp+Fig46PsmFam42OBjo+yY1qZjo8FOj7Kjmll Oj4W6J19DPsnn5ZrIX8GH19Ox8cCva+P4frhfCp8nI2OjwX68z5uB9IdXn2wK7B9nI6OjwV6Bx/X eTLDrPNZ4eNsdHws0Pv6WHk+K3ycjY6PBXpnH5el5nxW+DgbvSp34fho+bhuGEOv81nh40vp+Pi4 j/F3Lrb76dcv2F+F/jQcH6t8LF3hI/RH4fiY+Bj9vqPmfFb4CP1ZOD4+oxE+Qn8Cjo/PaISP0J+A 4+MzGuEj9Cfg+PiMRvgI/Qk4Pj6jET5CfwLe92iDvo151sfG4CP0V5Q+iI/POfQky6+50FvowqXj o8Hyay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELl46PBsuvudBb6MKl46PB8msu9Ba6cOn4aLD8 mgu9hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJv oQuXjo8Gy6+50FvowqXjo8Hyay70Frpw6fhosPyaC72FLlw6Phosv+ZCb6ELlz6tj8eJztcTSJ7n xkdRunDps/q46rdZePy1nngav+ZCb6ELlz6rj+vE+PhGunDp+HjImM+Lj6J04dLn9XH/s1nr3yE4 z4uPonTh0uf1cYm3j+vVcaK6j2e0q2vu3UBvoQuXfp9e56OR8XzMtpFsH0XpwqWzfdzmOX+kg4+i dOHSZ/Ux+33Hgo8voguXPquP+fEA21+gTCbxa64yvS49ax+0MX3p4j7WsPyaq0z/V03w8Wk6Psq+ dH3p+OhCx0fZl67vHiU+Fuh9246Psi9dX2PwsUDv25jJfcQYHzo+FuiT+6g8ppXp+Fig46PsmFam 42OBjo+yY1qZjo8FOj7KjmllOj4W6PgoO6aV6fhYoOOj7JhWpuNjgY6PsmNamY6PBTo+yo5pZTo+ Fuj4KDumlen4WKDjo+yYVqbjY4GOj7JjWpmOjwU6PsqOaWU6Phbo+Cg7ppXp+Fig46PsmFam42OB jo+yY1qZjo8FOj7KjmllOj4W6PgoO6aV6fhYoOOj7JhWpuNjgY6PsmNamY6PBTo+yo5pZTo+Fuj4 KDumlen4WKDjo+yYVqbjY4GOj7JjWpmOjwU6PsqOaWU6Phbo+Cg7ppXpXU9DjY9PBx+h99344uNX Dj3J8msu9BY6PuLj34866I/D8fHp4CP0zm9OB20MPjqPOugvLB0fDZZfc6G30IVLx0eD5ddc6C10 4dLx0WD5NRd6C1249Gl9/OeN+XG1rJfpJH7Nhd5CFy59Vh9X/TYL93/JNH7Nhd5CFy59Vh/XifHx jXTh0vHxkDGfFx9F6cKl4+PvPOG8ecRHVbpw6TP7GJYl/hQnbJ/q/Nz5lLrm3g30Frpw6ffpdT4a 8fYxLLmP2TaS7aMoXbj0ebePIb24+EgHH0XpwqVP62M4LvHxZXTh0mf18XeX+TgeYImOCtin8Wsu 9Ba6cOmz+ljF8msu9Ba6cOn4aLD8mgu9hS5cOj4aLL/mQm+hC5eOjwbLr7nQW+jCpeOjwfJrLvQW unDp+Giw/JoLvYUuXDo+Giy/5kJvoQuXjo8Gy6+50FvowqXjo8Hyay70Frpw6fhosPyaC72FLlw6 Phosv+ZCb6ELl46PBsuvudBb6MKl46PB8msu9Ba6cOn4aLD8mgu9hS5cOj4aLL/mQm+hC5eOjwbL r7nQW+jCpeOjwfJrLvQWunDp+Giw/JoLvYUuXDo+Giy/5kJvoQuXjo8Gy6+50FvowqXjo8Hyay70 Frpw6fhosPyaq0yvS8/aB21MXzo+yr50fY1pHhgmnbYX6JP72Le5g790jnRhHwdvu7aPgzf3tXR8 7EXHR+jf0/GxFx0foX9Px8dedHyE/j0dH3vR8RH693R87EXHR+jf0/GxFx0foX9Px8dedHyE/j0d H3vR8RH693R87EXHR+jf0/GxFx0foX9Px8dedHyE/j0dH3vR8RH693R87EX39vFn0n++JvF7fZ4b Hwek42MvurOPPwZuFu7/kimEm/taOj72ovv6GBZ8VKR3/WIoPj6dL/dXEx/zefFRlN5XduHGyPj4 s/eKjy+hC5eOj/s8YftU5+fOp9St/t1Ab6ELl+5IH8/HbBvJ9lGULlw628dtnvNHOvgoShcuHR/x 8XV04dIn93E/HmC7l0wg3Nyp6cKlT+zjZ5Zwc6emC5eOjwZLuLlT04VLx0eDJdzcqenCpeOjwRJu 7tR04dLx0WAJN3dqunDp+GiwhJs7NV24dHw0WMLNnZouXDo+Gizh5k5NFy4dHw2WcHOnpguXjo8G S7i5U9OFS8dHgyXc3KnpwqXjo8ESbu7UdOHS8dFgCTd3arpw6fhosISbOzVduHR8NFjCzZ2aLlw6 Phos4eZOTRcuHR8NlnBzp6YLl46PBku4uVPThUvHR4Ml3Nyp6cKl46PBEm7u1HTh0vHRYAk3d2q6 cOn4aLCEmzs1Xbh0fDRYws2dmi5cOj4aLOHmTk0XLh0fDZZwc6emC5eOjwZLuLlT04VLx0eDJdzc qenCpeOjwRJu7tR04dLx0WAJN3dqunDp+GiwhJs7NV24dHw0WMLNnZouXDo+Gizh5k5NFy4dHw2W cHOnpguXjo8GS7i5U9OFS8dHgyXc3KnpwqXjo8ESbu7UdOHS8dFgCTd3arpw6fhosISbOzVduPTZ fQz/ye/1eW58FKULlz65j5uF+7/kSeHmTk0XLh0f8fF1dOHS8fGQMZ8XH0XpwqXj4+9FOG8e8VGV Llw6Pu7zhO1TnZ87hMyV8XzMtpFP/u6ksGjof00XLl2Rft/H80c6gqsP3RUOvRGKj7PRhUtXpN89 HmCJjgq4y/pyydA96MKlK9L7lkwI+Sb4SMg4wUdCxgk+EjJO8JGQcYKPhIwTfCRknOAjIeMEHwkZ Jx19DPuxPBdLulhu/u3mT+iwfwOzaiW+wF8ubknWqIV2XIfTg/Ys3ywthPJkl8/cGgohe5Xvwr6Y vrTI/enFeDZDlBrhtpnqt+DosLqLJZ2Xe3qkfojWrMSX+POU26sUf8XlDm0bLR8HjQGvmLU42orz 3/OxMGuzj2VkaZH7s5+Xnb6ixWcdgo+1s4Z4lYb38eOgrXzw7nLw8V56+/hza9012PcQfhsR7QXu j/3+j+7b+HXqmPJz4oJwtdiv8JdrEr+Mt2nLWu/OOQjn2m8vrdD9GJw93urjzstekmpOUmI6NI5H 4kWG6/kqFnvxQq6FR8yo7X+XjkuLvwmyDrR49aOn7gy6zceDvN9MFxRu4Ytr8riPIVmNDB63656P pe6f23PPx/idWMT7djBfDpBz7ceqXa3Ckk5oLi2ZOhtEeQF/mL5Li98zp32+8vFn+IX9h1W1j9ev 4tXz9XhjTVpp2ywFQ9J+xWZ+s7STj6erq8e/z0mO80rUck61XT9x/hGQX1X4GCFyekK5uddwP70X lzY4W/3fixDtGtz3MSQ7GGEFP+Zj+kOku4/bTtd+8ZSPUVPO7bkRy8eaPceIE822gU81RmvU5ON5 senyXuhj8kothe4t2dNN28djIZcv022DsjX5Ax+Pm/Gt7328bEPp8ad9/LbH0fSXoNhH84W+7WOC eLWPxgCIu70/elyY+CJ2bWm4jS+uSQq5QTu/8pc+Hp+O3FtaSP9fvcnqvH3cVqKWcz1O/tjHbPv4 1zr2XN7+SVeytx/tE+Sfr97ycTlRjgVl7b5vUH48QG8fn6h9/xCq+PlqstBvPgxNl3J6lY+XpL4r aSnLqnLahrBPmhSdzfetjxHlWN6+uBf5+GVOlTxb2rP4zsU+v7RxXmet4GP5gYHw+DhJ5vUxL+Xp yp7Fdy728X01caIAAABmSURBVKUN9DoL5d4+fNMS/3qBhJBi8JGQcYKPhIwTfCRknOAjIeMEHwkZ J/hIyDjBR0LGCT4SMk7wkZBxgo+EjBN8JGSc4CMh4wQfCRkn+EjIOMFHQsYJPhIyTvCRkHGCj4SM k/8FwnsMfeH2JoEAAAAASUVORK5CYII= ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: application/octet-stream; name="Clones2 - 30k, 150, 1.0, 1.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Clones2 - 30k, 150, 1.0, 1.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAgIAA//+AAACA AID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABK2F9eAAAZ5ElEQVR4nO3diXazOKJGUVV3Uvea93/gjm0GTYAQAn0SZ6/uPx5A YJJTYGI7ZgCgwtReAQAzegR00COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR00COggx4BHfQI6KBH QAc9AjroEdBBj4AOegR00COggx4BHfQI6KBHQAc9AjroEdBBj/WYt9U7PxMcuH0abH1Ib+LVxfMz UQ/bvpqNIsaqIneu3G7ldbrHlAFwEbZ9LdPeLP4d2Oxxc7DUnFano8eK2Pa1jD/2f1+cS2aMythX hync+fbxsjuWdTBrHb16Q3jLX2429qJRB1u+luXH3u7RTMUZ+6oXy3KLO8Jy2Z3PGcKZzrrZXTTq YMtXswQ1H5wa69IQuepPutajcf9x5xyceVYWgTrY9hU5p2CWFLx65v3iejVhj7FL7p7PPkqd7g8G w83Y9nXNQQYBDjf36P7XAXWw7Wvxjhf3erTnWu1xZT8bPQyN7A2t5FEH276Weac0+Lum+P5x6/nj PKVx7vT3j/Hnj+HItzx+xLDtq7EPIO0TO/PRpXV1sA8qrVuMO5ZxJneTHuzphyU7//zq4E6GW7Hl 67ECCXocvB6nKZzb/WNNd3J/xMHtzG7ZH4GfilrY8hIoAB/8HAjgCBEjfg4EkCNG/CAAOugR0EGP gA56BHTQI6CDHgEdj+rRfgWKcW5dubC8EM17pWjsSnC7iS0vPlDq9yG22hvrsbuiu8tLXLz9yr+8 JaWuQuee9GidV2h6xUUvDJk9Gq9Hd8ADA60M7AyeNHtmJd5s64s31mPNWlLqKvTuQY92finn1OR4 q5leFOpfcGdcHzK81X7V6OANGN2PpP3UuQmEY27NmTL+zmx7i78kHXrsm/cybbvS2N3ulM57K6Z7 7D2FPYT34xr94bV3oMss4whrA8fHNGZw18oaf5rAunke0P9vkzWSuwLbi/eWYg0Zju2u64FV6N+T Huswf4+/l4flS1qPxg5lGsk9nB0+m3T5obQbsIdbcrF+6pzj2/WBh2BMaz2c8JxVCP8LYiyRm/0e Nxc/WEvxhgzGdtb1yCr070mP9XyPg/eT7e123DncPmI9Tj+R7m32kqIDO6s9X4uunj3+gfudKdMW P1iz+AuIjJ29Cp171qP9fqOze3Su2DuDcCnLP8GAfmzWD6IX8MrAwcoM9kzWgwjGjy3HbsD/70d2 j84miz00f8WSV6Fzz3q0QxhcVo/eD3QQjjuzP6B301qPmwNL9zivOT0e9aBHGw8up0f3+CqyJ3Nr SO/RXeDawO6szhCJPQar6fzkn+9xWvPYI1p74Imr0LkHPdr5qcrynCV6q3P3dxLri/NDFKZkzbE1 oLdsZwY/rWBgd1ZnpeZ/TWR87+bIzskfaaNHf/HuSOGQ4UPLW4XOPenRTgdD9oX4re5+KdKjdVjl H2Xak64OOP8gW1OMV73Z4wN7Y6706D5Q7+bpVvsfd+JxtVIWb5wl2dfsC4O/lqmr8BxPeqzL93a6 YLUQvTDNZn1ZZjEm9jPkzrE2oP2TbN1kr9bGwO5qD+s9ug/Uudkax7/fXUjS4o31QKw1Dx7gXo8r q/AcT3qsEUUf/mXbsvI36eE/I7d6+LamR/3FP8qztzU56i/+WdjYgA56BHTQI6CDHgEd9AjooEdA Bz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0C OugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6DjSI/mz/jl+/XoAAA2Hchp ys/MVw05AiUd7Ykegesc79HMl6wrAArI6HF8+vh5/kiPQEEHgzLL08jp6jyCGf0/0IxyKRVxrEfj XTD+U0jzAhrSdI/GuxSe0qFHNKXlHs3yLz2iCw33aMYzOdP5nGE+q2NNU3v7Akc03GPScLW3L3AE PQI66BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI6 6BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI66BHQ 0XKP5s/yZRj/dSepvX2BIxruccxvqnD+nzNN7e0LHNFwj/b09IgudNajPzs9oik99Gg9f6RHNK3x Ho371UxndT5XRrU3MZCs7R6Nd8H4TyGJEU1pukfjXQpP6dAjmtJyj2b5lx7RhYZ7/D47XF4PMFiv Cpinqb19gSMa7jFpuNrbFziCHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0C OugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR 0EGPgA56BHTQI6CDHgEd9AjoaLlH88ea6XvFHYAe0ZSGe5zzm0M0wfz0iKY03OM0vRnoEZ3ooMfB 6tGfnR7RlH56/By20iOa1niP9vmc7wWzXBnV3sRAsrZ7NN5Mxn8KSYxoStM9mvArPaJlLfdo/Av0 iMY13OP32aE10/eyMwI9oikN95g0XO3tCxxBj4AOegR00COggx4BHfQI6KBHQAc9AjroEdBBj4AO egR00COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR00COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR0 0COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR0tN3jZ2rz5/s1HIAe0ZSme/wUOFU4/8+Zovb2BY5o uUcz0CP60nKPQ9ijPzs9oil99Gimf+gRTWu/x/f5nGk2M53VGW//qL2JgWQd9GhdMP5TSGJEU7rq MTylQ49oSvs9zud06BHNa7/HwRjjXHMmqL19gSPa7nF/uNrbFziCHgEZP/QIiPj5Yf8ISPj5q5Hj VUDAN8YXPQLVTTG+6BGo68eqkR6BitwYX/QIVOPH+KJHoI5g1/hBj8Dt4jG+6BG43VqMr0iPpgp6 xEOs7ho/wh7LBpGYzVWLp0dI2YzxRY/AbbZ3jR/0CNwhIcYXPQJ3SIrxRY/A5dJ2jR95PbrnRP2/ mRGZfmcZ9IheHYjxldmjsf4N5wlH2OjPv06P6MmhGF/0CFzm2K7x40SPn0vjn5ia/9LU+JGL4/Hs dLf3wf4bB7D0iD5kxPg68fxxnnj8jH5j9zhYBdIjnicrxteJ86vL3150Qlzp8fNJ/uOn+Vszhgul RzQvb9f4Ee/xn3XOlOs9Tp9UbOgRz5If4+vs+ZzVHp0zPvSIpzixa/w43+PalyHcYVp7zrWF0iPa dTLG1+nXAxj7xOowH54G51fpEb07u2v8uOX1cvz+EZ0rEuOLHoHzCsX4uuv15KuHp8EN9IjGlNo1 fvD+DuCEkjG+6BHIV3TX+EGPQJ7iMb7oEchSftf40XaP0y89zfxadW8AesQFLorx1XiP82cULC8E 8s/kXrTZ8FzXxfhqu0cz0CPudWmMr7Z7dF6wvrxW3Zng0o2HZ7k6xldej9Nn/Ns1JJazezW/x+ld 0e4EV28/PMb1Mb6y949m5XLK9JEbzvXozL187t30t0Fu2Iro3Q27xo/eevT2kcSI8+6K8XWux/GX DPYbq8y8h/I/6Wp5T9ZyPbLQjB7d3SM9oqgbY3yd7tEsT9umi8bOb7lGj2jPvTH+/v6e7zH8Yp1m ce5Y/8SOMj2O+2Vnghu3JjpzX4y/X6+1/eO/6+I92h9cNe0HzfU97qJHZPm5JcbfJcRRuf3j4PQY +0KPaMENLQYdTq46XvWeWA7LPcGzvoEeIePiFldDHJ0/v+p9cJV13oYe0ZQrd4x7IY5uer1cMKpZ uUaPqOOiFsOniJvoEbhix3isw8ldryc3iVfpEfcq3mJeiKOG3t9h/F8upgxcdEujM2VbPBXiqJ0e 3yeIzNEg6RErCrZYIsRRQz1O52wPDVxiG6E3pVosGOKopR5jb3DcG7jgpkIXSrR48KTpAQ31+HkL ND0i3+kWL+tw0k6PObtHesTkXIuXhzhqp8esFaNHvE61eFeII3pE134yW7zuKeKmc3+P1Sy/gdj+ hf/eeAnzTZ+idWzgmzcnlBxP8fe3UoeT83+vPPLy8NRxIhPTI4o40mL1ChcFegzfzpg6TmRiXi+H 01Ja/P0VqnBxosfBDdN6o5XVamI2hxZ/ZODa2xc3W2/x91e0QVv280dr4pt6NMdfnkOPj+K1+NtE ga7s86tmOUqdY1z/QI69wRIWz+sBsOHTYoMBeuI9/t86Z8pbezy81x3o8RF+3y02W6Cr0PkcesT9 3gne80Fwtyn0+47wwiXHq/y+A6/liWFnLb4Vej3ADT0OGTnSY1+sJ4YdtvhW6vVy/P4RV3LO0HTa 4hs9Qpt3rrTjFt+KvZ788tevDjx/fJjgtxadt/jW0Ps76PExIr8/fECLbw31mDVw7e2LY6K/yX9I i2/t9Ji1ZvTYjvhv9B/U4ls7PXK82rGVF9c8q8U3ekRl6y0+LcZXSz3mDVx7+2LT2otOH9niGz2i ko0WHxrjq6keI8erZr59GN8B5g1Aj5poccWpzwcw6Xu27ZcLZD5/dAqMvv+DHvWsvjHq6S2+5fVo 7C8pdl5Ol/f7RzPQY2PW36RIjB/t9Bi7y36f5fzGS2eC2tsXs403DBPjJPN4dXr/8ViBGaxLZnpW twRjlnSiH6+T+/sO9z1f4e6RHkVsvXmfGC0lepyDM861ZaJre7Rmm/9rYM1AkpXttEiMttzzOcvO MbYPtGuxy1z7OI/c33cY78K0VssEtbfvw21+qA0thuI9/nddao+RTw64vMfwlA491rP9AVPEGHXV /jE4Xj3X4/jHyneOV+lRxc6HvRHjmuzfPwYVBj0at0cvnmI9znvi6ZozQe3t+0B7H7xIjBuu6nEw xr3vXI+56PFW+x+CSozbbnq9XDBqZD+3tfjDHyw3zVd7+z5GyucRE+OuZnrM+bRHerxH0keDE2OK u15PbhKvri7eZCVJjxdL/Zh+YkzT0Ps7hmEo2+PGb3Wucte39Q7pfzGDXWOydnrM2j+qxdFJyUf+ eA0xHtFIjzx/FOn34F9yI8YD/vnTTo95A9fextUUr/b431QkxhT/fP371U6PXewf/3OHA+uTFO3h Ej9/KPTnZ+OviJ53dMuLWQocjbc30uOQmeQ1Pd6SSunVyxlpLHE/WbeVf//92zX+e60GE/UeQXSa dnr83Hthj2pVlZbyEJaf7W+JbmQbnDj/Yrz+mexmotcs8jh3/f72ibtzNNNjkd8/FoqsqaOs+Ip4 D35pbvwTi6v/Ad8ReUNj9nPXA/+FzJfzINf9GxT4T0qFi8wet8KI3rOz39ubLvf54+bGr1BV9iLz pRwlJe08dx18c/G7yWtTcY9q4xvgbMjRAI9U6H63Mv8+8taE1/SYsFYRmz+pp7/fN9o8WkxKbtVv cL4mp471Fg8kl7MXTbb5n6mUTedOeiDdAz+FJz7vcW3KK3rMlX8+50gANzhyzJMqDHHLkX3HkZB3 XBVo0sGE9z2I2RxudGDznPr81em41YSfYeXdXqvHEwFcotAP00nHQtxx928Zr9p9fmxmlb6XO8Kt 81yP09sbV94I6X7SVcqApXtsvZyyfouG+FL4OKrLz+PerEyPwZfY7SkD6hyvdqV0h2/1W/R0kWW8 x991TjReiN9ToOPxKj0quCDEN7UWLW1nee58TtqOsVSPMq/PacM1JQruGKMazfLc7zs2nj9esH/c Hyecpfb2reOqFBtp0dLa88uTrwdYP79qh7i7X0t5PQD7xzRXpdhei55LT8zmc1eryOvlTj/pS9k/ Zr0k4Fk9XrZbbL7F0GUvO9hf1taS2+lxyHkT5GN6vC5F6ZM3xZyt80Bymxrp0f0byAcGPr5lm3Nl ih3uGFNs1nU2uU2NvL8j41TOd75S20nUlSk+tMW6Wukx690dffdIix1qpMfsgWtv34vQYqfosTmX tviIkzfC6LEpl7dIjHXRYzNo8QHosQm0+BD0qI8WnyPv/R0rv37Ijoke13Ai9VmKfn4OPZZFi49D j6p4EdwTnexxfr/V9BarvL98k9vj9C6v8Ws4QKs9XvricFrUde75o/d+5KT3Hq92lbx4az2mOYz1 P2eK2ts3x2Ux0qK8kp/XYX1gx0F5PVqfItlNj7yD8dniPf6sW6KJ95j3Z+Eilw7NN8Xoz95Wj7T4 eKX3j7cer04rsjx/bLjH6z58ihbbcUGPlfaP0yott41qb+IUl8RIiu05+XoAY51Smd/BX7NHbx/5 2BhpsU1tv17O6zE8paPf4wUx0mK72u/R+q1jaz1ecDKVFtvWfo/LGV3rVQHzBLW37zpaRKjtHvcH rr19VxSPkRb7QI/3Kxwjv9LoCD3erGyMpNgZerxT6b+FSou9ocfbFIyRFHtFj7co95sNdotdo8fr FW2xzEgQRY8XKxQju8VnOPF68rQgtv/yhjHe2zL66rFMjKT4HGV6DGcyzte1QacUu+yxSIy0+Cz0 eIkS5284RH2g3B7NYL3hanqn1ffl3cstg9Wjic9nvWErefEHVOmxUIslVgWNye7RuJUtF903WQQ9 +vP1tn88HSO7xSfL3z/a2Zm1O8KPovO/9NTj6aNUUny6eI//WedmF35AgN/jYCXXdY8nW2S3iNfp /aN3Ld7jyt099XguRlLEqMDxavDk8GE9njtKpUVYzu4f5w+xGsZPsrLSXIYbp4wd5zbe45kWOUSF j9fLnXAiRlJEDD1myj9KZbeIVfSY41SLZVcFXaHHo7J3jLSIXfR4SGaLHKIiTdhjFU30mBcjKSJd 0GNlqj1mHaWyW8RB9Jggt8UiC8eT0OOOnB0jLSITPW453iKHqDiDHlcdjZEUcRo9Rh07Sv0hRZRB j6EjLVIiSqJHT3qMpIji6NGSepTK8SkuQo+TtBYpEVeix7ekHSMp4nJt9+h+CIH3UQOfawmbIKFF UsQ9mu7ReCGaYP7dHvdi5Kki7tRyj2b68J3MHneOUikRt2u5R/d41cxl2hOsPvDNFkkRdfTTo/eH 68Z7og96a8dIiqioox4H54Mml3dWe494vUVSRG299ejtIxNj5KwNNHTVY3hKx+4xfpRKiRDylB5j LZIi1PTU4/c0qzPCt8cwRlKEpLZ73B8uPEolRejqvEenRc7aQF3nPU7PHykRTei/R1JEOzrvkRTR lM57vOvvlQNF0COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR00COggx4BHfQI6KBHQAc9AjroEdBB j4AOegR00COggx4BHfQI6KBHQAc9AjroEdBBj4AOegR00COggx4BHfQI6KBHQAc9Ajo66NH8+X4N B6BHNKX9HqcK5/85d9bevsAR9Ajo6KxHf3Z6RFP66NFM/9AjmtZ+j+/zOdNsZjqrM97+UXsTA8k6 6NGazfhPIYkRTemqx/CUDj2iKe33aIbBPlylRzSs/R4HY5Yc7eePn2u1ty9wRAc9bg5Xe/sCR9Aj oIMeAR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMe AR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMeAR30COigR0AHPQI66BHQQY+ADnoEdNAjoIMeAR3t 92g+PhfCAegRTWm/x2kuM/3PuaP29gWOoEdARxc9TgeqJpidHtGUfnr8PH+kRzSthx6NfcnM18yo 9iYGkvXWo7ePJEY0pYMe3d0jPaJh9Ajo6KnH72lWZwR6RFM66HFzuNrbFziCHgEd9AjooEdABz0C OugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR 0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9Ajo6KBH8/b5Gg5Aj2hK Dz3OX0wwPz2iKfRYGovsZYlVFnk+oaKOr49Zvppg9od8E5+wyEc8yB56HJ8+fp4/0mO3i3zEg+yh R2s2M53V+VwBmlOoo1Iy12fu0dtHVnh4LLKXJT5kkZtO9Rie0nnGFn3EIh/xIDvo0TpepceOF/mI B9lBj8N81D2f1Tk13FksspclPmSRm9TWB3gyegR00COggx4BHfQI6KBHQAc9AjroEdBBj4CO0p+f U3a4hAXe/xL9Ou8KuHmRFd77UGeJYu/wKLs297cx/9PzIof7t2yl1+c94mWBW4quTvh5Abfof2/1 mB7v13OPlR7dA3q8+790D9ikNZe6jh4zlnf/c47be6zwZK7GdqXH8h6wzMgnFV2+wNsXaW5fpF6O HfT4hF3y7T1OS717afQoPZzkEu9faqXz8v33KJdj8z1yXv66pXW/SHosrcae4zGvB7h3iVUWefPy 9umtEfBc9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGP1YxvTdl9U8Pq W1imO8Q+shAn8K2sZUppr6YwOePdQY/94FtZyRxRUo+xG8iwQ3xPK3F7XI48v7dbh6jOJWPdZeww l2NXMm0Z37xKnB6X/xvn+jjB1OjGHbH70R6+d5Ws9BjLyjpts3oHTyf7wPeukp0e3eNOY98YuWNY ouSAtWl87yrZ3T8GU0fP4wQ9Xr3euBTfv1rsEzhbTQbHqqt3DCsxox1876qxDz+9p4jOaVKznLdx d4LGmYvzqz3gmwfooEdABz0COugR0EGPgA56BHTQI6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQ I6CDHgEd9AjooEdABz0COugR0EGPgA56BHTQI6CDHgEd/wODwX65MPEixwAAAABJRU5ErkJggg== ------=_NextPart_000_0033_01C07C75.84372C00 Content-Type: application/octet-stream; name="Clones3 - 30k, 150, 1.0, 1.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Clones3 - 30k, 150, 1.0, 1.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAABmAGYAZsyZM2aAgICZ mf//gIDAwMDMzP/M/////8z///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABeEU+FAAAaHElEQVR4nO3di3qqyLaAUfb97M37v+/plQhUAU5RcVqlY3zdiVGs MsR/gQbNMAKtGN59A4CZHqEdeoR26BHaoUdohx6hHXqEdugR2qFHaIceoR16hHboEdqhR2iHHqEd eoR26BHaoUdohx6hHXqEdugR2qFHaIceoR16hHboEdqhx/cZ/rh64c8Cd5w/DXZ9yNXCV6d3n3gf 6/5tgiIuVe1ceOX8Iq+nezwyAC9i3b/LtDXb/wmEPYaDHc3p6nJ6fCPr/l0ud/u/PlWnhktUQ/nl OIU7n385XY9V7MwWe6+rIVbzL2cP5dS8hzX/LsvdvuxxmIobyi9XsSzn1CMsp+vrVUNUyxVn11Pz Htb82yxBzTunQ3Fq3Plyvei1Hof6Q33NsbrOlSl4D+v+jaqnYJYUVvXM28Xr1Wx73DtVb/nKvdTp 8s1gJLPu32sOchPgmNxj/a8D72Hdv8tqf/FWj+W1rvZ4ZTu7uxu6szUskuc9rPt3mTdK43rTtL99 jB4/zksO1YXr7eP+48ftyCnfP3us+7cpdyDLJ3bmvcviy7HcqSzOGeqxhmrxOumxXH5csls/vzrW i5HKmn+fIpBNj+Oqx2mJ6vz1vma9+HrEse6sbHk9gnvFu1jzTVAAP9wPGmAPkQv3gwbIkQt3BGiH HqEdeoR26BHaoUdohx6hHV/VY3kEylCde+XEciDa6kjRvS825w978+0PdPTnsHezg9tx84benO/g 9OWRf4/NdPQmfLhv+m6rIzRXxe2eGB/scVj1WA94x0BXBq4GP3T1BytZXe369EPxvT4009Gb8Om+ 6LudD+WcmrycO0wHha5P1Fe8PuT23PKo0XE14O525Ni9rk5gO2Z0zSPj37jarelfko4eP9vqMO2y 0r2L6yWr11ZMl5RbinKI1d11985bbkCXq1xGuDbw/pjDMNa3qhh/WqA4ex5w/W9TMVJ9A+LpV7MU Q27Hrm/rHTfh833T9zrOP+Pf0+Py6ViPQxnKNFK9Ozv+rNLlTlk2UA635FLc66r92+sDj5sxi9tR hVfdhO2/IENh5+x1j+H0YzHLasjN2NVtvecmfL5v+l6f73Fc3bNXm536GnUfez1O98j6vHKm3YGr mz1/tXvzyvHvuLxa8tj0Y3GV9QQ7Yz98Ez7cd323vz/oh3usvig3BttZlg+bAdexFXfEVcBXBt7c mLG8UvFNbMbfm6dsYP3vx8M9Vqts71tb37DDN+HDfdd3O26De6jH1R16E0595fWAq7Ou9RgO3HSP 8y3X472+6LvdD+6RHuv9q50tWV3D8R7rCa8NXF+1GuJgj5ubWd3zn+9xuuV739G1b/zgTfhwX/Td zg9Vlscsu+dWF/8uUnyq7kTblIprRAOu5q6usE5rM3B91epGzR+HnfFXZ+9snNYjBT2up69H2g65 /dYeuwkf7pu+22lnqDyxf269XdrpsditWu9lloteHXC+IxdLXL5cXX1/4NWYV3qsv9HV2dO55Yd6 4cvNOjL9UM1UflWeGNe38uhN+B7f9L0uP9vpRNHC7onpasWn5SrDsHcfqq9xbcDynlycVd6sYOD6 Zo/Xe6y/0ersYpz15fUkh6Yfim+kuOWbb/BWj1duwvf4pu91x6nf/svW5Zt/SF9+H0n15etaj+1P /1W+e13Lsf3pv4uVDe3QI7RDj9AOPUI79Ajt0CO0Q4/QDj1CO/QI7dAjtEOP0A49Qjv0CO3QI7RD j9AOPUI79Ajt0CO0Q4/QDj1CO/QI7dAjtEOP0A49Qjv0CO3QI7RDj9AOPUI79Ajt0CO0Q4/QDj1C O/QI7dAjtEOP0I77evxZevjL8mm8fDz7hsEXuquj3w5/rzZVOP8HPOuekH4j1CO8yv37q3s9yhHO 8HSPPzuxeoQzPN/j76dhHujP8zzDP6FrZwV2p5N6XG0jh/9Az3rucfuUjh7pmx6hHf30uD4eYDqz Wu7dqxOe0kePh0d99+qEp+gR2qFHaIceoR16hHboEdqhR2iHHqEdeoR26BHaoUdohx6hHXqEdugR 2qFHaIceoR16hHboEdqhx9hQOH1wWNFjbPi/mR55OT3G9EgmPcb0SCY9xvRIJj3G9EgmPcb0SCY9 xvRIJj3G9EgmPcb0SCY9xvRIJj3G9EgmPcb0SCY9xvRIJj3G9EgmPcb0SCY9xvRIpo56/POS4OXT ePlYL3L6+tEjmfrp8ZLfVOH8X7XM6etHj2TSY0yPZOq7x/UoeqRvffU4LD3+PH7UI5+lnx7/PJFT bB8vn4ahuPgFbwGnRzJ11OPv1eoeV9tIPdK3nnvcPqWjR/rWT4/DuOSnRz5TPz2O83EAw5xj+fjx 56vT148eydRRj0dGPX396JFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmR THqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6 jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozpkUx6jOmRTHqM6ZFMeozp kUx6jOmRTHqM6ZFMeozpkUwd9Tj8Zfk0Xj7Wi5y+fvRIpn56vOQ3VTj/Vy1z+vrRI5n0GNMjmfru cT2KHulbPz1eHjjOjxqH7eZRj3Sunx5X28fLp2Ee6E+ueqRvnfe42kbqkb713OP2KR090jc9xvRI pn56XB8PMBZHBcyLnL5+9Eimjno8Murp60ePZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TSY0yP ZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TS Y0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k0mNM j2TSY0yPZNJjTI9k0mNMj2TSY0yPZNJjTI9k6qfH4cfv59+vt+Pokb710+PlWsPyedgMo0f6pseY HsnUVY/DuOpxPYoe6Vu3Pf48ftQjn6WnHof6w+82ch7o5+me09ePHsnUeY+rbaQe6VtHPQ7Lx/mk HvkoeozpkUzd9TgfDzAWRwXMi5y+fvRIpo56PDLq6etHj2TSY0yPZCp7HF5PjxCoenxJI1UvL55L j/RNjzE9kkmPMT2SSY8xPZJJjzE9kinusX5OdP1i/J0ewi/1CLGwx2F19q0eg/7WX+sRtjY9lr8p 1KMeSbXt8V8/Vm8W9RvoMA7TS4Ivx3Jfyp0unl8xXH69nmF16kx6pG9hj2N56PYwvyS/am0V6KhH eFjcY1HWtEDc489LhIflzW30CHe42WO5mdvpcXnMqUd41oHHj1GP1TM+eoTnHO/x2qexOmM5d/WM 0KpCPcJW+PuO5XiAoXxidZx3TzfPr+oRnnDq8XKbAdZn6BEieozpkUznHk9+dfd0c4YeYcvrO2J6 JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okU9TjdCTrsH/xfhEHv9QjbN3YPg7x xeHyO2foESLx6zv0qEcybXv8x4+yx99XVE2vtPo54+f1VtUrsQ69o5UeIXKwx0t+U2PLl+U5eoTn HO9x550BloWqC66/Y4ceIXJnj+UbV03bwSGpx+W9CC47yttx9Ejf7t8+jlWPe59e0+PlppR70Jth 9Ejfnt1fXT2wLGstPpzW46hHPtmR33cUe4mr97X6OWe9/UzscT2KHunbycfLbYYYrnz1SI/zI9Xp HwI98mE66nF6cDqW28rlz1P+bNVPXz96JNPZx5OvH9Bd+/Lp53Pmr8qR9Ejf+nl9x7bH7VM6eqRv eozpkUz99Lg+HmB6Orha5PT1o0cyddTjkfFPXz96JJMeY3okkx5jeiSTHmN6JJMeY3okU9xj8fdW 997B4+6u9AiRsMfy13x7h4ffHZYeIRK+vqPucXnhxn5iR3o5crXqqNT76JG+bXv83496Y7g+HmZ6 fcXOSxDjXnZObZYZll/530uP9C3scawOhcnqcZzezO5+eqRvcY/jkt1YxHj9DTlu9bJzarvM3isb D45/+vrRI5lu9lg/fszo8edPFOiRb3Tg8WNyj09sHvVI5+7ocY6vOvGKx48P0yN9i9/PanM8gB7h he49Xu71v3+s3t/uTnqkb3qM6ZFMdx9PPoRfHr6y4+Vgy+s7YnokU4M9Dg8fnqNHOtdej44H4Hs1 2OPdR8UW1z19/eiRTHqM6ZFMDfbo9x18rfZ6HB/PUY90rsEenxn/9PWjRzIdeP+c1eO5uKT4cAE9 QiTucSg/HQoiPuP4/qrHj3yj+P2s3tGj53P4Xtse//vj8lKq6fXHl5cfX15pdXlLjanfcX4J1vyK 5XH/7XW83goi9/Q4BzdUXy0LndLjM0Hqkb7d6LHYOO5tA5frDVWZ197Ow/4qRJ7uceedA/QIj3m2 x83+6tM9PkOP9O1Wj9sKNz0OdY/1CT3CcTf/fseNHi/vJV4+efNsj/ZX+VonHy+3GWK48tUDjx8v Z9e/HF2Nf/r60SOZGuwxvmB5YDtvkItFTl8/eiTT2ceTrwO59mW0vxqer0c+WHuv77i2vzoUn6YY 10vpkb511OPl4eN07b0/86FH+tZej+F1h+pJ2+mXLb9f/HH6+tEjmfrp8XK1usfVNlKP9K2xHi9/ rPzq7x+rHrdP6eiRvvXT43Z/VY98msZ6DK+8/O27ZYg6XD3St8Z6fPSN5aarn75+9EimGz1GB5Lu XhL3dKDHJ97tUY/0Lu5x2D03SurJHsfqePa76ZG+3Xx9x63j146cuXPpjeX0yFfa9vi3H6sXT0zv WrV5D6vV+Sf0aPvI9zrW4yW/+j2shp3zb3Tk8SNE7utx82nv/KiXnVP1As89wapH+vZQj8uR3cWp s3q0feR7Hejx8IbxhB5Hjx/5ZmGPc2HB48dzt4/TpXrkK4W/71jCuP78ahnize3agR79/pEvdtfx ck8911IP4PEjbDXX43Pjn75+9Eimxnp8dvzT148eydTY6zueHf/09aNHMukxpkcy6TGmRzLpMaZH MrXYo98/8q2a7PHh26JH+tZYj/NfsNIj36ixHsfnDgnQI30Le7z6lxgf7uXQEI8fMKdH+hb3eCWd 1/U4/QNgf5Wv9ND7Wb2wx2dG1yO92/b47x+rHufXW00vsXpsp/Lw9vFBeqRvcY/z7uNYvR750GuP d3vZOXUmPdK3Y9vH1RsADMXy9/Wyc+pMeqRvD/f40I6lHiHyaI/2V+F8T/Ro+wgni3/fUZ4qFxjn p1nv7GXn1Jn0SN/aO17uqfFPXz96JJMeY3okkx5jeiRTXz2Wv2gpD+mbLz99/eiRTF31OB0YND3B uxlGj/RNjzE9kqmnHue/FTLHuB5Fj/St2x6XjWW5xOnrR49k6qjHYg91OaB9OUjo59iF09ePHsnU eY+rbaQe6Vs/PV4O3tscWKtHPseB98+5p5brF68e7z38+0c98sHu63Fb0VB9vlbZaj8zWDJWHg8w Hd1eXX76+tEjmQ68n9V6id1zcnq8RY/0bdvj338sv+YrXnA1vdLq97VXyznjWO1B7l2veMGWHuGK mz0OdWXLyfrR26bH9fVsH+Gm29vHMruivvqC7VvRrT/pEW462OP2DQLWPY5FcnqEhxztcVXnbo9X LtYjHHTH/urmwaEe4Vy3ft+x2l+9fKjTXPq6LLm3n6tHuKmf4+UOjX/6+tEjmfQY0yOZ9BjTI5n0 GNMjmfQY0yOZ9BjTI5n0GNMjmfQY0yOZ9BjTI5n0GNMjmfQY0yOZ4vfP2b6uv1783qr0CJED72d1 rbuh+Hi0l+tznUKP9O3A+1npUY8k2fZ4ufMt0SyvX/z5NFQvoqpeXHW7l51TZ9Ijfbu7x/WLjIvX IB/oZefUmfRI3+Iei+dzypcVj6sex+1ffrvSy86pM+mRvh3YPo6bHue3ANAjnOmRHjf7q3qEUzzY 42r7eDQvPULk2N/vGMZiJ3Vc3tHqUqYe4RQnHS+nRziBHmN6JNMpPQZ/iHW14PNzxeOfvn70SCav 74jpkUx6jOmRTFWPr6dHCPzz9p38NeU8cJXpb4hMf3l5O44e6Vs/PZYHAq2ORliWOX396JFM/fR4 uZoe+WB997geRY/0raceiwP2xvkQ2nqJ09ePHsnUU49juX28fFqesv15/vb09aNHMnXe42obqUf6 1nOP26d09Ejf+ulx9fuOUY98nn56XB8PML8Us1zk9PWjRzJ11OORUU9fP3okkx5jeiSTHmN6JJMe Y3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6 JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiST HmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiSTHmN6JJMeY3okkx5jeiRTRz0Of1k+jZeP9SKn rx89kqmfHi/5TRXO/1XLnL5+9Eimfnq8XE2PfLC+e1yPokf61m2PP48f9chn6avHYRzLZ3GG6Vmd ny/+OH396JFMXfU4jOseV9tIPdK3nnoc6g87T+nokb511OOwfNQjn6mfHn8eHw7L8QBjcVTAvMzp 60ePZOqnx0Ojnr5+9MgZhkK0nB5vrEc9coLh3zM9PrMe9cgJ9HjSetQjJ9DjSetRj5xAjyetRz1y Aj2etB71yAn0eNJ61CMn0ONJ61GPnECPJ61HPX66o7+qf25oPZ6zRvX46Y6m8sjQf5vo8aQ1qsdP p8dRj7zZ/buSj0yix7PXqB4/0/2ppEyixxtrVI/pXvf8SjmJHqtyXjPqyetTj+9Q3Itf+NSnHqty XjPqyetTj+/QaCopk+jxxhrVY7pGU0mZRI831qge0zWaSsok39nj8cclT/T4wgc/yZMkT9doKvM1 j68DPR78Yfx39sIeb0xyyl37lEmG4/623MPuvKG3FIvu3otP/ofgiR7/Nbt1o/R4WQ+3HL8XX+/x 6Un+PnkmlVMmKe5h/5gM/5stk+z2WN6cx+co7N6LT1lbxaIPR7//nZw0yYf2ePgOdvNeHPR43iT3 /vDfNknZ4+LvBya55xt5vMdbkxSLvm6SZ/5l0ePuKu+yx91/oV/X484drPkeT9kIv/I70ePuKu+y x72HdnrsaxI97q5yPerxLZPocXeV61GPb5lEj7urXI96fMsketxd5Z33uPfcpx57mESPu6u88x5f dg/Tox7vGfWBVba7ys/uMeFXEXr8hEn0uLvKz+5x+bnsTtLNPUyPerxn1AdW2e4q16Me3zKJHndX +et6fNlTLXr8hEn0uLvKX9djSz/8+yfRox5XV/qzZfn9vB1Hj3rse5KeevwpcKpw/q9a4oFVtrvK 9ajHt0zSUY/D+JIed+lRj2+ZpKMex22P61Ee6fHGKtOjHhMn6bbHn71XPerxsybpt8ffT8M8UHn0 ix712Ocknfe42kbqUY99T9Jzj9undPSox74n0aMe9djOJN31OB8PMH1VLXD+KtOjHhMn6arH26Oe v8r0qMfESfSoRz22M4ke9ajHdibRox712M4ketSjHtuZRI961GM7k+hRj3psZxI96lGP7UyiRz3q sZ1J9KhHPbYziR71qMd2JtGjHvXYziR61KMe25lEj3rUYzuT6FGPemxnEj3qUY/tTKJHPeqxnUn0 qEc9tjOJHvWox3Ym0WMLPe7+/eQW72F61OM9o56/ylJ67GYjrEc93jPq+atMj3pMnESPLaSixw5S SZlEjy2koscOUkmZRI8tpKLHDlJJmUSPLaSixw5SSZlEjy2koscOUkmZRI8tpKLHDlJJmUSPLaSi xw5SSZlEjy2koscOUkmZRI8tpKLHDlJJmUSPLaSixw5SSZlEjy2koscOUkmZRI8tpKLHDlJJmUSP LaSixw5SSZmkvx7/vEjw9/N2HD3qse9JuutxqnD+r7rw/FWmRz0mTqLHFlLRYweppEzSd4/rUfQY THLGm4LoUY87V/zzYdhuHvX46kn0qMedKw7z6WEeaIDudd7jahv5mt+i7N0CkzQ0h0neN2/R4/Yp nc9ZZR8zycd8Ix80yZnz6rGvST7mG/mgSU6d989e9jLEUA30OavsYyb5mG/kgyZpaF5gS4/QDj1C O/QI7dAjtEOP0A49Qjv0CO3QI7SjlR4Tbsd8QFH3k4wZ62vI+Fay5sj5oZygkduZUcr8ofdJxrz1 lTHHxxwteIY2buj2HQZeNtFnTPJJPWZo425+QCs3VI/3zfD6vbxXT5A2SeI8z2vlln5MjykPVTJ6 THlol7O6mrmX39bKLc25HR8yy847Fr1ijoSH20PCJO3cyQ9o5aZ+0u7RR/Q4TfT68fVYaOWmftJe y+u3Kp/yW5WcHlu5jx/Rym1NedCVNMdH/NvyQb8eauU+fkQrtzXp99sf8Qvun3leP8PHHD7Ryn38 iJ5uK3w6PUI79Ajt0CO0Q4/QDj1CO/QI7dAjtEOP0A49Qjv0CO3QI7RDj9AOPTbj8vqTmy94uPo6 lemCbt7ckA0/ulZMKd2qaZvcsLpAj/3yo2vEHNGhHvfOkOEH8DNsRN3jsuf5e36xi1qdGoqLhjLM Zd9Vpj3xw2pE1ePy/1B9fVlgajS4YO9y2udn1YgrPe5lVTxtc/UCDyf75GfViBs91vudQ3nmzgXj EqUd1q74WTXi5vZxs/Tu8zibHl99uzmVn1cryidwoiY3+6pXLxivxEy7/KyaUe5+rh4iVk+TDsvz NvVGcKiu5fnVHvlhQTv0CO3QI7RDj9AOPUI79Ajt0CO0Q4/QDj1CO/QI7dAjtEOP0A49Qjv0CO3Q I7RDj9AOPUI79Ajt0CO0Q4/QDj1CO/QI7dAjtEOP0I7/B6VYRVFc8DqEAAAAAElFTkSuQmCC ------=_NextPart_000_0033_01C07C75.84372C00-- From moth@debian.org Fri Dec 29 12:50:04 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14510 invoked from network); 29 Dec 2000 12:50:04 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 29 Dec 2000 12:50:04 -0000 Received: (qmail 31505 invoked by uid 1000); 29 Dec 2000 12:49:52 -0000 Date: Fri, 29 Dec 2000 07:49:51 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Miller-4? (was Re: Call for Votes on Supermajority Issue) Message-ID: <20001229074951.A30623@usatoday.com> References: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001001c06cf8$7698f9c0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Dec 23, 2000 at 09:53:15AM -0600 X-Evolution: 00000090-0010 Offline, Mike Ossipoff has recomended to me that I vote on the supermajority issue based on the properties supermajority has when Schulze is the vote tallying mechanism (because schulze is almost completely strategy-free, and because it satisfies four major formal voting criteria). Using the writeup at http://www.fortunecity.com/meltingpot/harrow/124/criteria.html to determine the impact of these various supermajority proposals have on the schulze: Condorcet, Condorcet loser, Smith criteria: If an alternative victory pair-wise beats every other alternative, this alternative must win the election. If an alternative pair-wise loses to every other alternative, this alternative must lose the election. The winner must be a member of the Smith set Petry-2 does this, by eliminating supermajority. Miller-2 does this, by redefining pairwise-"beats" in the case of supermajority (though it's poorly phrased for that). All the others redefine the ballots in other ways. independence of clones, majority, mutual majority and pareto criteria: If there are alternatives X1, X2 ... Xn that are a clone set, and if one of these clones is eliminated from every ballot, then, if the winner for the old ballots was in the clone set, the winner for the new ballots must also be in the clone set. If an alternative outside the clone set won for the old ballots, the same alternative must win for the new ballots. If an alternative is ranked first on a majority of ballots, that alternative must win. If there is a majority of voters for which it is true that they all rank a set of candidates above all others, then one of these candidates must win. If an alternative (X) is ranked or rated lower than another alternative (Y) on every ballot, X must lose. schulze+petry-2 meets all these criteria (by eliminating supermajority), while none of the others do. local independence from irrelevant alternatives criterion, monotonicity criterion, reversal symmetry, secret preferences criteria: If an election produces winner X, and a new alternative is added (Y), and Y is not in the Smith set, the new election must also produce winner X. If an alternative X loses, and the ballots are changed only by placing X in lower positions, without changing the relative position of other candidates, then X must still lose. If alternative X wins, and all rankings on all ballots are reversed, then X must lose. If alternative X wins, and some of the ballots are modified in their rankings below X, X must still win. I've not been able to find any examples where any of the proposals alter the behavior of schulze under these criteria. Note that Mike Ossipoff suggested other arguments against miller-2: "complicatedness and nonintuitiveness & nonobviousness". I don't know what this means. [Should I disqualify myself from this vote on that basis?] However, having run through this analysis, I can think of a much better ways to phrase the intent behind miller-2. For example: When an n:m supermajority is in effect for an option on a ballot, each voter is allowed to cast m ballots, but may mention the supermajority option on only n of them. [Where multiple supermajorities are in effect, with supermajorities n1:m1, n2:m2, .. the supermajorities ratios must be scaled as N1:M, N2:M, ... where M is the least common multiple of m1, m2, ... and N1 is n1*(M/m1), N2 is n2*(M/m2), ...] Schulze combined with this proposal seems to satisfy all the criteria that Schulze satisfies by itself. Is it possible to formally propose a new alternative at this late stage? Thanks, -- Raul From nkklrp@hotmail.com Sat Dec 30 03:23:06 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 12338 invoked from network); 30 Dec 2000 03:23:06 -0000 Received: from law-f12.hotmail.com (HELO hotmail.com) (209.185.131.75) by qmail.accesscomm.ca with SMTP; 30 Dec 2000 03:23:06 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 29 Dec 2000 19:23:03 -0800 Received: from 204.120.48.3 by lw1fd.hotmail.msn.com with HTTP; Sat, 30 Dec 2000 03:23:02 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Miller-4? (was Re: Call for Votes on Supermajority Issue) Date: Sat, 30 Dec 2000 03:23:02 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Dec 2000 03:23:03.0443 (UTC) FILETIME=[D1B01E30:01C0720F] X-Evolution: 00000091-0010 Raul wrote: >Offline, Mike Ossipoff has recomended to me that I vote on the >supermajority issue based on the properties supermajority has when >Schulze is the vote tallying mechanism (because schulze is almost >completely strategy-free, and because it satisfies four major >formal voting criteria). Sorry--I misundestood Raul's message the other day. I though that he meant that he was abstaining from the vote on supermajority rules because he didn't know how circular ties would be solved in the supermajority poll. So I told him that the count would be by Schulze, and that all anyone need do is vote sincerely, due to the strategy-freeness of that method. Then, I sent the definition of Schulze. Now I realize that he meant that it is difficult to choose the supermajority recommendation without knowing what the rank-count rule recommendation will be. I voted to do the rank-count tiebreaker first. But collectively, we chose to do supermajority first. If it would have been desirable to do tiebreaker before supermajority because one of the supermajority proposals is too much affected by the count rule, then that should have been pointed out before we voted on the agenda ordering. If Miller-2 works drastically less well with some of the tiebreakers that we'll be proposing, then that of course would make it more complicated to evaluate even if we knew what the tiebreaker recommendation would be. Anyway, if Raul wants to move that we immediately take up the issue of the circular tiebreaker, and then afterwards get back to supermajority, I'll second the motion. In fact I'll make the motion myself: I move that we immediately take up the issue of the circular tiebreaker, and decide our recommendation on that, and then afterwards get bck to supermajority. Mike Ossipoff > >Using the writeup at >http://www.fortunecity.com/meltingpot/harrow/124/criteria.html to >determine the impact of these various supermajority proposals have >on the schulze: > >Condorcet, Condorcet loser, Smith criteria: > > If an alternative victory pair-wise beats every other alternative, > this alternative must win the election. This is a poor definition of the Condorcet Criterion. By this definition, Plurality meets the Condorcet Criterion, contrary to the intent & expectation of people who use that criterion. > > If an alternative pair-wise loses to every other alternative, this > alternative must lose the election. > > The winner must be a member of the Smith set The same can be said for the above Condorcet Loser & Smith definitions too. Defining these criteria doesn't seem important right now, though. All of the EM proposals meet Condorcet's Criterion, as does the current Debian rank-count, and so CC doesn't seem important for us. Some of the rank-counts that we EM members will mention don't meet Condorcet Loser & Smith, but the better ones that we'll define do meet those criteria too. If we apply these criteria to combinations of rank-count and supermajority rule, it seems to me that none of the combinations meet the Condorcet Criterion, even when it's defined correctly. Anything that fails Condorcet's Criterion fails Smith too. But to apply these criteria to combinations of rank-count and supermajority rule seems to unnecessarily complicate the choice of supermajority rule. But if it's desired to do that, then I agree that we have to decide the rank-count recommendation first, and then do the supermajority rule afterwards. We're getting nowhere with the supermajority rule decision. Let's temporarily skip it and go right to the rank-count rule. That's my motion. > >Petry-2 does this, by eliminating supermajority. Miller-2 does this, >by redefining pairwise-"beats" in the case of supermajority (though >it's poorly phrased for that). All the others redefine the ballots in >other ways. > >independence of clones, majority, mutual majority and pareto criteria: > > > If there are alternatives X1, X2 ... Xn that are a clone set, and > if one of these clones is eliminated from every ballot, then, if the > winner for the old ballots was in the clone set, the winner for the > new ballots must also be in the clone set. If an alternative outside > the clone set won for the old ballots, the same alternative must win > for the new ballots. > > If an alternative is ranked first on a majority of ballots, that > alternative must win. > > If there is a majority of voters for which it is true that they all > rank a set of candidates above all others, then one of these > candidates must win. Incidentally, Plurality meets this one too, if we reasonably say that when you vote for a candidate, you're ranking him over everyone. Cretney's criteria, at the website that Raul quoted, are poorly worded. >Note that Mike Ossipoff suggested other arguments against miller-2: >"complicatedness and nonintuitiveness & nonobviousness". I don't >know what this means. [Should I disqualify myself from this vote on >that basis?] What that means is that it seems to me that Miller-2 is complicated, and that it isn't an obvious way of applying a supermajority rule. As I used the terms, "intuitive" really means the same as "obvious". Maybe to someone else, Miller-2 is intuitive, obvious & simple. I was just saying how it seems to me. > > >However, having run through this analysis, I can think of a much better >ways to phrase the intent behind miller-2. For example: > >When an n:m supermajority is in effect for an option on a ballot, each >voter is allowed to cast m ballots, but may mention the supermajority >option on only n of them. [Where multiple supermajorities are in effect, >with supermajorities n1:m1, n2:m2, .. the supermajorities ratios must >be scaled as N1:M, N2:M, ... where M is the least common multiple of m1, >m2, ... and N1 is n1*(M/m1), N2 is n2*(M/m2), ...] Ok, thanks for showing how simple it is :-) Are you suggesting that voters be allowed to cast more than one ballot in a particular election? Your Miller-1 is the best proposal, so why not leave it at that? > >Schulze combined with this proposal seems to satisfy all the criteria >that Schulze satisfies by itself. When Schulze chooses so as to satisfy the Condorcet Criterion, and the winner is something that is disqualified by a supermajity rule, so that it doesn't win, then Schulze-with-supermajority-rule has just failed Condorcet's Criterion. Unless of course you want to write a special Condorcet's Criterion designed so that count-rule/supermajority-rule combinations can pass it. But really we don't need to get into all this to choose a supermajority rule. Anyway, I repeat my motion to skip, immediately, to the rank-count, the circular tiebreaker, so that we can better deal with supermajority after we've chosen a rank-count recommendation. > >Is it possible to formally propose a new alternative at this late stage? If we do the rank-count first, then return to supermajority later, then of course any proposal can be proposed at that time. It's just occurred to me that Raul earlier suggested that we do the circular tiebreaker first, and then return to supermajority rule. He made that suggestion more than once. Can we call that a motion? If so, I've just seconded it, and doesn't that mean it's time to vote on the motion? Or if it has to be _called_ a motion in order to be a motion, then I've just formally moved that we skip immediately to the circular tiebreaker issue and then afterwards return to supermajority. If mine is the first motion for that, then, Raul, second the motion so that it can be voted on. Obviously the supermajority issue isn't goin to be resolved till we decide our circular tiebreaker recommendation. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sat Dec 30 03:29:36 2000 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 22258 invoked from network); 30 Dec 2000 03:29:36 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 30 Dec 2000 03:29:36 -0000 Received: (qmail 11233 invoked by uid 1000); 30 Dec 2000 03:29:22 -0000 Date: Fri, 29 Dec 2000 22:29:22 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Miller-4? (was Re: Call for Votes on Supermajority Issue) Message-ID: <978146931.c0bde3f5@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sat, Dec 30, 2000 at 03:23:02AM -0000 X-Evolution: 00000092-0010 On Sat, Dec 30, 2000 at 03:23:02AM -0000, MIKE OSSIPOFF wrote: > Anyway, if Raul wants to move that we immediately take up the > issue of the circular tiebreaker, and then afterwards get back to > supermajority, I'll second the motion. In fact I'll make the motion > myself: I move that we immediately take up the issue of the circular > tiebreaker, and decide our recommendation on that, and then afterwards > get bck to supermajority. I second this motion. Thanks, -- Raul From npetry@accesscomm.ca Tue Jan 16 04:45:34 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 15339 invoked from network); 16 Jan 2001 04:45:34 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 16 Jan 2001 04:45:34 -0000 Message-ID: <004e01c07f77$27ef3dc0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Re: Tideman Schwartz set failure example Date: Mon, 15 Jan 2001 22:45:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000096-0010 Mike wrote: >Here's an example in which Tideman chooses outside the Schwartz set. >But note that Tideman never chooses outside the Smith set, and so >when it chooses outside the Schwartz set, all it's doing is choosing >an alternative that ties, but doesn't beat, something in the Schwartz >set. Obviously it'd debatable how bad that is. It doesn't sound >bad to me. Only a minor embarrassment or trivial imperfection. >I'm not aware of any strategy problem caused by choosing outside the >Schwartz set (but within the Smith set). Is there one, Norm? > I agree that choosing a winner outside the Schwartz set, but within the Smith set doesn't pose any strategy problems. However, I think that the desireability of choosing from Schwartz, rather than Smith is intuitively obvious, and that is why it was developed. For example, if we have this Smith set: A>B B>C C=A Then there is some merit to choosing the only unbeaten candidate (Schwartz set here is {A}) if we have to make a choice. When there is a circular tie, it is necessary to find *some* reason to choose one candidate over another, and since A has fewer defeats than the other options, it seems like the best choice in this instance. Obviously, in large-scale public elections, pairties are so improbable that a failure to satisfy Schwartz is a 'trivial imperfection'. However, since Debian will probably be using the same method for tech ctte. voting where pairties will be quite common, choosing a method which satisfies Schwartz does seem like a good idea to me (all else being equal). Thanks for providing the example showing Tideman's Schwartz criterion failure, and also the descriptions of a variety of other voting methods that we might want to consider -- that was something no one had done earlier, and I hope the lack of these definitions didn't cause confusion among the Debian members of the committee. Unfortunately, Mike, Rob, and I have been members of EM for so long that I am sure there are other things we take for granted in these discussions, and this isn't really fair to the Debian developers on the committee. If you need additional information or explanations about anything, please ask! -- Norm Petry From npetry@accesscomm.ca Tue Jan 16 06:04:00 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 22594 invoked from network); 16 Jan 2001 06:04:00 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 16 Jan 2001 06:04:00 -0000 Message-ID: <005b01c07f82$1e0e3ee0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Re: Tideman Schwartz set failure example Date: Tue, 16 Jan 2001 00:03:56 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0058_01C07F4F.D3417440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 00000097-0030 This is a multi-part message in MIME format. ------=_NextPart_000_0058_01C07F4F.D3417440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Raul Miller wrote: >However, since it looks like that's what you're advocating, please >allow me to mention what I see as weaknesses of Norm's simulation in >this context: > >[1] Only one "policy" dimension. [I presume that this is an issue >dimension -- I'm thinking that if there were multiple issue dimesions, >Norm would have indicated that.] > My simulator can work with any number of dimensions of policy space, and if you like, I can provide additional examples showing the performance curves for 2,3, or more dimensions. I have found, however that the toughest test for *any* voting method is the one-dimensional case. Perhaps surprisingly, *all* voting methods improve significantly in accuracy if there are 2 or more dimensions. Only the best methods can perform well under 1D assumptions, so it is a useful way of 'separating the wheat from the chaff'. For public elections, we usually assume a 1-dimensional (left-right) policy space, so that is another reason why I usually choose 1 dimension in my simulations. You might want to take a look at the attached graph, which shows how accuracy varies as a function of the number of dimensions in the policy space. >[2] No attempt to simulate groups of voters exercising a strategy. > True -- voters in my simulations could be described as 'sincere, but lazy'. That is, they will never falsify preferences, but they don't always fully express the preferences they do have (they get bored filling out the ballot, I guess ;-) The 'involvement' parameter that my simulator supports is used to represent the overall 'laziness' of the electorate. I haven't tried to simulate strategic voting, mostly because I have no idea how to go about doing it -- it seems to me that there would be an unlimited number of strategies that voters might employ, so it could be very difficult to simulate those behaviours. Mike is our resident expert on strategy questions, and this is a topic I usually avoid commenting on much. I guess the only thing I would say with regard to strategy is that it is very important that the method should make it risky for voters to try to obtain a better result for themselves by falsifying preferences. If these types of offensive stategies are likely to backfire, voters will not attempt them, and we can have confidence that the voters' expressed preferences are similar to their sincere preferences -- in the ideal voting method, the best strategy should be to vote sincerely, and express any felt preferences. That is essential for the group to get satisfactory results from the voting system. Unfortunately, the strategy criteria don't help us much in deciding which method to choose, since all the methods we are discussing (Schulze, SSD, Tideman) satisfy the same set of criteria. Therefore, we must choose a method based on considerations other than strategy-proofness. >[3] No attempt to simulate ballot manipulation by creating options near >other options in issue space. [Or: with only one issue, I find it hard >to look at the simulation results in attempt to understand this aspect.] > The clone independence criterion and simulations address this issue. That is, clones could be seen as multiple options occupying the same point in policy space. Any method which is clone independent will not have problems with many similar options. That said, I have not carried out clone-independence testing by modelling it in this way, so it does give me an idea for something to work on... >[4] No attempt to cluster voters in issue space. > I usually distribute voters normally in the issue space. However, it is surprising how little the distribution of the voters matters. For example, I have tried distributing voters uniformly, rather than normally, and it didn't seem to make much difference (a bit less accuracy overall for all methods, as I recall). Clustering might yield different results, of course. >[5] Truncation is chosen based on an arbitrary number of options the voter >wishes to vote on, not based on a lack of reason to vote. [Thinking as >a voter, I'd truncate my ballot when all the unvoted issues were within >some epsilon distance of each other.] > Note that the point at which each voter decides to truncate is determined probabilistically (that is, it is different for each voter), which is a bit better than assuming all voters truncate to the same number of options. >When positioning voters in issue space, I'd expect a large quantity >of voters to be strongly polarized (at "1" or "0") or maybe undecided >(no opinion -- which isn't exactly the same as 0.5) -- more like the >contribution to "issue distance" from that issue is 0. > >I can see two kinds of expression of weak interest (which might show up >on secondary issues): One expression of weak interest on a secondary >issue places the voter between 1 and 0 in issue space. The other >expression scales the "issue distance" contribution of one issue with >respect to another. [Of course, there's no reason an uncertain voter >couldn't have interest which is weak in both these senses.] > These are interesting ideas. If you like, I can send you a copy of my simulator (it's GPLed Python code), so you can experiment with it by incorporating these models. >This doesn't mean that Norm's results aren't useful, nor does it mean >that they're not interesting, but I don't see that they're a replacement >for any criterion. > I agree. I see the simulation results as being *complementary* to criteria, not a replacement for them. They do reveal some interesting things which cannot be discovered by looking at criteria, though. For example, based on my simulation results I was not surprised that Debian had never encountered a circular tie -- the simulation shows these to be uncommon, yet unfortunately not uncommon enough for the problem to be ignored -- hence the need for this committee. Criteria analysis of the Concorde method would not reveal this. [...] > >However, since you have proposed this variety of options, I'd like to >propose (this is also motivated by Norm's report on his simulations): > >"Pure" Condorcet -- if there's more than one condorcet winner, a revote >is called for, after some discussion. All condorcet winners must appear >on the ballot for the revote. > I'll definitely be commenting on this proposal, but not tonight... -- Norm Petry ------=_NextPart_000_0058_01C07F4F.D3417440 Content-Type: application/octet-stream; name="Dimensions.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Dimensions.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAABmAGYAAIAAZswA//+A AICAgID/gIDAwMDMzP/M//////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD15kjsAAAf9UlEQVR4nO2diZajyJJEo9/Mm9cz/P//TlcmS2wsjnDhBtdOVWoD xxRuNwMhpEwDQiiK0t0GEEKz4BGhOIJHhOIIHhGKI3hEKI7gEaE4gkeE4ggeEYojeEQojuARoTiC R4TiCB4RiiN4RCiO4BGhOIJHhOIIHhGKI3hEKI7gEaE4gkeE4ggeEYojeEQojuARoTiCR4TiCB4R iiN4/J5Sch/t9Kvxum1NF0PIJrrwPX2Px58NwaOg6MLX9E/i3UN/ampEcUTjvqaMx2yfMpvK/vwc F0rVEiVnyzrLckO+wFTqt1xapuY0bynNV0sLqwugb4iR/poWHrNdyhy3BcRUL7HCY/5yMV8g43HR kMO3bDm3kDYWQN8QA/0tFZPaTMuCTnZXAVy2RE5be+8wdHnsFUlthXrp1U0gTzHQ31IJ2nLXciXb Ma32UzsrztNYu5EhJ2woMezNx8UanV8QZOR7Yqy/pc6Bz3UeS3DGBzs3Drx+3OaxeP3Y45HXj18V I/0lZS/j9nmsdmTHB7s39l4/DgWPzfbmCqs8MkV+Uwz0l1TsFnZfP7YzV35fOU2larnOVvrzYxe8 3uvHZgH0DTHQX1JJSnn0dKjnztQsMSM4VSuXy2fLZg80/5HvMbe7sGljAfQNMdDfUbmrmB1FWcCq Xz+2i+blsteZQ8PjvKWKx2Je7SO6ugD6hhhpFQHFG0STNcQk9Q7RZA2B4ztElxGKI3hEKI7gEaE4 gkeE4ggeEYojeEQojl7LY35mTH6idn0OdfbofDJaeVp270azmWz1rcV36+2rPIunOe11p2xx2nnl YdfQ5tidK/k2vXVAOieIdu8tETLz2Ft9Y/FyVfuzqlZr7O6fi7rB4wHH5W+47tO1lXydXjogyzmb zVmhv2eO1leWRdZLrmwmlZvYLXR0gYOr1XRtA1lNXxZ4Fgp7Y5edVHu85Pv00gGZz5fuwJJS50q5 yPhQe0J2Nf+srT7MvwvKlYehPKW7eyZ4kfPi7tTZI20nu2USy1ccJojyDebPKZv1hrxCVr6wWz35 gsd8Aq2exJGd6gfrtU/8j9L0zVHL7aGM0jqPKU/PlOJ6h3CXx3zlLP3F5F1HNy2rNXcf4XEYCtep qlH4yJ5Ti2X1u6f69VE/+epXTlarfDJN4Vfprc/7jxqCTDzOBbIrWebKguXa2cbbKsuPqvj248WS w7CyxeJ6vWJZOb/V/HJon2pRdZvHTu3KS134PXrr8x7KRJQ7U0d4LG7k82O5iXL1hsf5zlTv7dV3 dybS+m4Dj4Xr2kxlrVi0mDbbEe0OYv1g8xyrJ/FaGIc385jaqJ7isd3LG6qlI/K4tmKHx/5ubP1U 82fSH7vqrjUee4Xfo/c+8TobQy9K+zyW+47Vr/dmijjPY14x47HZUBnlzi+dIQ2N6y0e253jrHgH /hM8VgbfPEW+9nlP4Zwjl99or1TrdSLVi2y1ehnmoYpnKtfo3d2ZH/tY1U9zqDZUEZ3VSr1bxWS2 QudQLtEdu2qYeyW7hd+jlz7vVLwOyvOd7YwVV+YVs4tlldS5MQxV9SM8VmuUdxd1FnuNn86UUz7p 2mjnvmqApsrDSoViVFbHrh2VsuSQF36lXvq8q2j+3pXd6FyZVswullVS/jpvyEJaVS8L9Xgs1yju LutU82fuZ4XHxV7lOquV28q/UWuZ67q/IarBWRu7elTKklXhV+q1T7zVpUNx87h+c/NE6EIxmLPg Mf62Hi8GcxI4xt/W88VoIhRH8IhQHMEjQnEEjwjFETwiFEfwiFAcwSNCcQSPCMURPCIUR/CIUBzB I0JxBI8IxRE8IhRH8IhQHMEjQnEEjwjFETwiFEfwiFAcwSNCcQSPCMURPCIUR/CIUBzBI0JxBI8I xRE8IhRH8IhQHMEjQnEEjwjFETwiFEfwiFAcwSNCcQSPCMURPCIUR/CIUBzBI0JxZOPxZ+n0j5aL Yfx5tTGEXigTR78c/q42UTj/Qwh9KgtIvxDCI0Jesu+v9ngER4Su0Mc8/uzEwiNCV+hzHn8v0lzo z3Ge9D8IieoqtE7pIh6rOTL9jZCm9HlsD+nAI1IVPCIUR2o81ucDTHcWy909qAidlBKPh6vePagI nRQ8IhRH8IhQHMEjQnEEjwjFETwiFEfwiFAcwSNCcQSPCMURPCIUR/CIUBzBI0JxBI8IxRE8IhRH 8IhQHMEjQnEEjwjFETwiFEfwiFAcwSNCcQSPCMURPCIUR/CIUBzBI0JxBI8IxRE8IhRH8IhQHMEj QnEEj2alWb7bQS8UPJqV/m8UPKKrBY9mwSNqddFeEzya5cQju8HSSn+Ngsem6kVDvCIvHpl2lQWP 61UvGuIVifHIvFsoOY0HPK5XvWiIV6TGo+i8683Nh+Cs1n0Zj38atFwM489ykYuGeEXw+FPWe9q9 KOCrZeGxlZ3HEb+JwvlfscxFQ7wiWR4vJahT9pq6syR4vNouPJoly+O1QWzKetV14iam3SfwWFeB x37dV/MoYleRx7Tw+PP6ER6P1X1lwFfLxrSrxuOfAznZ/DhepJQ97K7OK6fAZTuJ8SnrVdepbEy7 cjz+rlbyWM2R6vPjomvrvnLCWS0b064+j+0hHXUeYydmtexfl/weebldNR7TsOD3fB6dEuNT9q/0 n1GRAv59u+3oGgZcjcef14/Dcj7AkJ0VMC/ywfge0Bd5dEqMT9kvBjy03bZs+t9RD+TxSNUPxveA 4PGpdk+QD48Hqp4eXWMLnMo+J+Bidg3cmOzCYzlUhr6ZWuBU9jkBv9huR5favZjHRfD4Nzyu1u39 BvcJ+MV2/2uSHZxNuye48bILj2a1dWWPOHyQxGMBv/YFmReP58vC45Gq9VAdHl1jC+Z7VHcAXxBw MbvwaBY87toNFHAxu/BoVufEtq/xyA7gw+3Co1l3HLAMdMThiN1AARezC49m3cFjoMS8wu7h/RB4 PFC1HqqjTTsmeHy+3X9NupjHXczh0Sx4DGT3/Dx2C4+7ZeHRLHg8YddrB/A8N/DYIcenaj1UO2Nq FDyesHtbwMXswqNZ8HjCLjzCIzzu2e0k5mkvyMTswqNZz+bxaQEXswuPZsHjCbvwCI/wuGf3BQEX swuPZsHjCbvwCI/wuGf3BQEXswuPZsXgkTfYH2kXHs2KwSMBf6RdeDRrqwUffHOHSmKw62kXHs06 1gIzmCqJwa6nXXg0ixPQsOtmFx7NgkfsutmFR7PgEbtuduHRLHjErptdeDQLHrHrZhcezYJH7LrZ hUez4BG7bnbh0SxjC/iAL3bh8e8wPD4tMdj1tAuPZr08Mdj1tCvH4589v+ViGH+Wi9RDtTOmRr08 Mdj1tKvG44jfROH8r1imHqqdMTXq5YnBrqddeDTr5YnBrqfdJ/BYV4FH7KraVeNxfOE4v2pM7fQI j9iVtavGYzU/jhdpLpT/zfp5qC7WyRaYyx5MDHYfZPcRPFZzJPMjdlXt6vPYHtKBR+yq2oVHs16e GOx62lXjsT4fYMjOCpgXqYdq0c7oHtLLE4NdT7tyPB6put6CndE9pJcnBrueduHRrJcnBrueduHR rJcnBrueduHRrJcnBrueduHRrJcnBrtX2F07wgiPZr0kMdj1tPvfo+DxY70kMdjdnMg+tAuP8Ijd E3bXwPnQLjzCI3bhcYccn6rrLdjp2iFFSwx24fEqcnyqrrdgp2uHFC0x2IXHq8jxqbregp2uHVK0 xGD3X2eOu8Bjhxyfqust2AnDIb0k4GJ2zdzAY4ccn6rrLdgJwyG9JOBiduHxCnJ8qq63YCcMh/SS gHvZ/fIbep/ahcfPq663YCdkhxQt4GJ2vxxwMbvwaFa0gIvZhUd4hMc4duERHuExjl14hEd4jGMX HuERHuPYhUd4hMc4duERHuExjl14hEd4jGMXHuHxAI/HvzQ5WsCd7D7kBG0xu/A4DazshONk9yEB F7MLj9PAwuMjAy5mFx6ngYXHRwZczC48TgMLj48MuJhdeJwGFh4fGXAxu/A4DSw8PjLgYnbhcRpY eHxkwMXswuM0sPD4yICL2YXHaWBleeQLMB5kFx6ngZXlkYA/yK4aj78zwe/l7+22Djx6Jga7nnbV eBzXSstlasrAo2disOtpFx6ngYXHRwZczK4gj2moeKyrwKNnYrDraVecx5/XjwYe149FwuMzAy5m V4/HVP74nSPnQtnHGDdb0GppwZ5OtsBc1pqYa+2ay2L3AruP4LGaIzfmx3ms2l90zI+PnHDE7Mrx mJaf81V4JOAPsQuP08DC4yMDLmZXlMf5fIAhOytgXuRAC9qBhcdHBlzMrhyPR6oeaEE7sPD4yICL 2YXHaWDh8ZEBF7Ob8bh2RPdywaNyYrDraTfn0QWODi7em4RHz8Rg19MuPE4DC4+PDLiYXXicBhYe HxlwMbvwOA0sPD4y4GJ24XEaWHh8ZMDF7G7yuHk0tMNS/TnEFVx2l/hQ8OiZGOx62t3iMVV37/G4 UmDjXnjUSwx2Pe3WPObvEcLjpS0wl42ZGOx62m14HKuXtPwCmoY0fRZ4PIl7JHd6eP6ocH67xaV7 9ULBo2disOtpd4vHIT9nO82fxS9YqwAd4HG1BbO0E4NdT7ubPGZkTQts8/jz2eC0fKsNPD4vMdj1 tLvHYz7NdXhcXnPC40sSg11Pu/uvH7d4LI74wOMrEoNdT7uHeVy7GNoJM5s5u7h0r14oeMSuqt2t 9zuW8wFSfmB1mHdPm+Or8Pj8xGDX0+6V58s1BfoV4VE6Mdj1tAuP08DCI3bvt3vp+eRp82bnbnjU Swx2Pe3y+Y5pYOERu/fbhcdpYOERu/fbhcdpYOERu/fbhcdpYOERu/fbhcdpYOERu/fbhcdpYOER u/fbhcdpYOERu/fbhcdpYOERu/fb3fz+nOr7rC6iKASPzYeD4RG7Aexavs/qIopC8DgP1Tyw8Ijd ++1avs/qIorgUTox2PW02/A4Fl1oyT9Q9fMZq+yec7h0r14oeMSuqt1NHufPNw7jxx3zi9MwwaN0 YrDraffQ/Fh9I0D6DCZ4lE4Mdj3tnuWxf+T1GC7dq4fXnr+SYJzD2zrwiF1Vuyd5vG1/dTQ2+Zv/ FctYWjAPLDxi936753m8Z37M95XhkYA/ze7m+x2d77Na9hdvnB8rHusq8IhdVbtq58ulYf7u5fF1 bFsFHrGraleOx/mN0HyuXPadU6ZDLZi1tGBPn7bgaFlrYrCrb1eOx98fJY/VHMn8iF1Vu/o8tod0 4BG7qnZfz+MseMTu/XbVeKzPB5gO+haLfNiC/siTGOz625Xj8cgGPmxBf+RJDHb97cIjPGI3jl14 hEfsxrELj/CI3Th24REesRvH7g6PBmCmRVN9BHSj5lb5tFpg18mHLeiPPInBrr/dbR4tJ43nZ3pX Z9B0F1x9PHsMHuMlBruedjf/XvknPOYX3QVXHx8/TsL8GDMx2PW02/A41prums6HScXFsHzKYrre RfD8/Hj+67LgEbu6djd5nDArv8hqITH/mb9+3Obt+OtHM4njmh+2oD/yJAa7/naP8TjMxKXqnuwz TzlKW7gd2l+dPvR8RvCIXVW7WzzOLyV3eFwWqmqt4NK9Wi/B/mrQxGDX0+4mj9Pd2zyW+6vlzLpG W3u1WOL0oZzf1T9sQX/kSQx2/e1u8Di/IKxfPw7N/9ThcRWog68fzwsesatqd+P9jozH6vjqMB9t Ga9Xx3Pmtys+OZ5zXvCIXVW7h86X2zw8Y8flyCY/2sCHLZhFYrALj59vQKsFYonBrqddeLy9BWKJ wa6n3aif77jz+CqJwS48Vgt98JYHPGJX1W5UHrcO0O5uQKsFYonBrqfduDwOpydJeMSuqt24PJaf /DJtQKsFYonBrqfdqDzOKMIjdl9kNy6Pu4usr6vVArHEYNfTblQeP/mMBzxiV9XuFo8GHHZe6qWU /0m4I1u48/OPJAa7Ejy2eJR7lRufsOpDuHdKEDxi9112N/9eeR+S3j3w+JrEYNfTbsPjWGHGKC0f r5q/V3WYHsi+iC7jrrPeypfq7BxfZX8Vuy+zu8djKilbri4PdHms17POj5+cMAeP2FW1uzs/5jRl 9JUPLFNgah4+yeMHgkfsqto9xmP+FavNV1xN66bsCjw+NjHY9bR7kMfyVp/HlYc/2V/l9SN232X3 +P5q8+LQlUeO52D3jXZ33u+o9lfHHyWaC1jjkr39XDOP+dQMj9h9id2o58vNXzLZPLB8fd3vzbYO PGJX1W5cHlf+gOQyEy97wtVi8IhdVbtRecx3hjtrwyN2H2k3LI/bKxc81lXgEbuqdqPyuPZI9hd+ hukQEzxi9yl25Xj8/ZEfxSn2bFOmj1uwok9bcLQsdt9nNyyPv1qrUPJYzZHMj9hVtavPY3tIBx6x q2o3Ko+bK8Mjdh9qV43H6V3JefLMzgqYF9FqgVhisOtpNyqPm/urexvQaoFYYrDraXfz+3P6SGSH Nc/hsrHJatvwiN132d3/PquVu89Pp5/trx7ZgFYLxBKDXU+7+99ndSePzI/YfZfdhsdxxYWGcb90 PIgyzLfms9Ws0LC/Kp0Y7Hra3eRxQmIhMHt3Ic1nxhipMfBoKzyvq9UCscRg19OuZX7Mz4epyDTh 0r16oeARu6p2z/CYvsHjicLzqlotEEsMdj3tnpof2z1XEy7dq/VCafphFzxiV9Wulcfm9eMmVX1c ule7C8Ejdt9ld/P9juLasHJ8FR7flRjsetrlfLnbWyCWGOx62o3KI3+/A7tvtBuWx082oNUCscRg 19NuWB55vwO7L7QblUfe78DuG+2G5XHn8c0NaLVALDHY9bQLj7e3QCwx2PW0G5ZH3u/A7gvtRuWR 9zuw+0a7YXn8ZANaLRBLDHY97Ybmkf1V7L7M7onvs8poOQXMQR55/Yjd99k98X1Wy6MncdnY5PzA By8f4RG7snZPfJ/VsrgXj6MDeMTu2+w2PI7LL7TkH3ecP331yQx2hMetR/c3oNUCscRg19Ouicfe h5FP4NK9WizB/Ijdd9rd5HH1++WceeT1I3ZfandvfsyvfJHHgeOr2H2j3d391Xvmx/FheMTuu+yG 5vGk4BG7qnaPvd+xHF8Zbw3w+NbEYNfTbujz5c5uQKsFYonBrqddeLy9BWKJwa6nXXi8vQViicGu p11FHpdXtNMh2LIOPGJX1a4gj/OpOyn7Vyyg1QKxxGDX0y483t4CscRg19OuHo9pqHmsq8AjdlXt ivPY/fvM8IhdVbtyPGZ7qGm5Zy6UMn3cghV92oKjZbH7PruP4LGaI5kfsatqV43H398iOY/tIR14 xK6q3UPfZ9XF5r7zV8v5ER6x+xy7h77Pao3Hc0Rdej7AdBZ88bhWC8QSg11Pu4c+3xGMx90NaLVA LDHY9bTb8DguttCy7A9Ob/al5fNWKf8c1lFculcvFDxiV9Wulccczex+eHxNYrDraXeTx+x4TnYx DBWPnVNkNnHpXr1Q8IhdVbv78+PQ8JhSgsfXJga7nnZP8Njsr8LjmxKDXU+753is5kcbV/AonRjs etrdf79jyN/wm97tW3gslzyES/fqhYJH7KraveZ8OXh8T2Kw62kXHm9vgVhisOtp9woejV8jDo/S icGup121z3cc2oBWC8QSg11Pu/B4ewvEEoNdT7vweHsLxBKDXU+78Hh7C8QSg11Pu/B4ewvEEoNd T7vweHsLxBKDXU+78Hh7C8QSg11Pu/B4ewvEEoNdT7uHvs+qE/lVFqp1UrssPEonBruedg99n1Un 8qssVA+n6sYAj+KJwa6n3WN/r7yN/CoL1cPw+LTEYNfTbsPjv39U8Th9bcf8NxfrO+dd1Had5Ub9 MS54VEwMdj3tHuKx/RRydecyCxbfoVx8arn34WV41EsMdj3tbvKYH5spqWouZh5zzuDxgYnBrqfd vflxRCglM4/1t17B4zMSg11Pu7v7q+W+53Ee2V99aGKw62n3KI/m+bF8vQmPj0kMdj3tHnu/Y/4G q2xPdCiO2zTHc4pvvZqWzcrCo2hisOtpl/Plbm+BWGKw62kXHm9vgVhisOtpFx5vb4FYYrDraRce b2+BWGKw62kXHm9vgVhi3mp3lqvdnMdvCR6VE3OZXbHR/feor/F4g07wuLzZMr2r0tR5K49OiTmK eZDR9bILj6trpPlUheUdznyZ4IkR4/Fo2SCj62UXHjdWk+ZR7De4V8Cddq/FeKxG4Qk81lWi8yiW GOx+0a4ej2n5O5TDkH/0clkCHrEralePxyGfH8eL5Zhtfhz3uj2qUpe1YKfs6cRgV9buI3is5kjm R+yq2tXnsT2kA4/YVbWrxmP1fscAjwT8SXbVeKzPB5g+tVksAo/YFbUrx+ORqle1oHpviMRgFx5P VNVqgVhisAuPxqpaLRBLDHbh0VhVqwViicEuPBqrarVALDHYhUdjVa0WiCUGu/BorKrVArHEYBce jVW1WiCWGOzCo7GqVgvEEoNdeDRW1WqBWGKwC4/GqlotEEsMduHRWFWrBWKJwS48GqtqtUAsMdiF R2NVrRaIJQa78GisqtUCscRgFx6NVbVaIJYY7MKjsapWC8QSg114NFbVaoFYYrALj8aqWi0QSwx2 4dFYVasFYonBLjwaq2q1QCwx2IVHY1WtFoglBrvwaKyq1QKxxGAXHo1VtVoglhjswqOxqlYLxBKD XXg0VtVqgVhisAuPxqpaLRBLDHbh0VhVqwViicEuPBqrarVALDHYhUdjVa0WiCUGu/BorKrVArHE YBcejVW1WiCWGOzCo7GqVgvEEoNdeDRW1WqBWGKwC4/GqlotEEsMduExX+UfLRfD+LNcRKsFYonB LjxWa6TpYvlXLKPVArHEYBcem9XgEbuPtPsEHusq8IhdVbviPP68foRH7D7FriKPaRjyozhpOqrz cyPTdS0odVkLdspi9312BXlMQ81jNUcyP2JX1a4ej6n80TmkA4/YVbUrx2NafsIjdp9mV43H373s 5XyAITsrYF5GqwViicEuPBqrarVALDHYhUdjVa0WiCUGu/BorKrVArHEYBcejVW1WiCWGOzCo7Gq VgvEEoNdeDRW1WqBWGKwC4/GqlotEEsMduHRWFWrBWKJwS48GqtqtUAsMdiFR2NVrRaIJQa78Gis qtUCscRgFx6NVbVaIJYY7MKjsapWC8QSg114NFbVaoFYYrALj8aqWi0QSwx24dFYVasFYonBLjwa q2q1QCwx2IVHY1WtFoglBrvwaKyq1QKxxGAXHo1VtVoglhjswqOxqlYLxBKDXXg0VtVqgVhisAuP xqpaLRBLDHbh0VhVqwViicEuPBqrarVALDHYhUdjVa0WiCUGu/BorKrVArHEYBcejVW1WiCWGOzC o7GqVgvEEoNdeDRW1WqBWGKwC4/GqlotEEsMduHRWFWrBWKJwS48GqtqtUAsMdiFR2NVrRaIJQa7 8GisqtUCscRgFx7bldI/+r1s68AjdlXt6vH4Q+BE4fyvWEKrBWKJwS48FqvAI3Yfa1eOx6Hlsa4C j9hVtSvO48/eKzxi9yl21Xn8vUhzoZTpuhaUuqwFO2Wx+z67j+CxmiOZH7Gralefx/aQDjxiV9Uu PN7eArHEYBce25Wm8wGmW8UCWi0QSwx24dFYVasFYonBLjwaq2q1QCwx2IVHY1WtFoglBrvwaKyq 1QKxxGAXHo1VtVoglhjswqOxqlYLxBKDXXg0VtVqgVhisAuPxqpaLRBLDHbh0VhVqwViicEuPBqr arVALDHYhUdjVa0WiCUGu/BorKrVArHEYBcejVW1WiCWGOzCo7GqVgvEEoNdeDRW1WqBWGKwC4/G qlotEEsMduHRWFWrBWKJwS48GqtqtUAsMdiFR2NVrRaIJQa78GisqtUCscRgFx6NVbVaIJYY7MKj sapWC8QSg114NFbVaoFYYrALj8aqWi0QSwx24dFYVasFYonBLjwaq2q1QCwx2IVHY1WtFoglBrvw aKyq1QKxxGAXHo1VtVoglhjswqOxqlYLxBKDXXg0VtVqgVhisAuPxqpaLRBLDHbh0VhVqwViicEu PBqrarVALDHYhUdjVa0WiCUGu/DYWfMf/V62deARu6p2RXmcKJz/FQ9qtUAsMdiFx/6K8Ijdp9l9 Ao91FXjErqpdcR5/Xj/CI3afYledx9+LNBdKCAnrETxWc6TPuyhudbHrWRe739h6xmN7SIcWeNbF rmddeDRuVKYsdj3Lqtn13vqffe2lRCoK0QLPutj1rKvKI0LoasEjQnEEjwjFETwiFEfwiFAcwSNC cQSPCMURPCIUR/CIUBzdz6OLg/nkIZG6jsPgUNhpFJKWXRfdbtSns/MPjbpOw+D1bWV+pbWa5qC7 fbbfLXBhaaG6cjw6CR7vFjwOXr+WdOYwz9LwGMOB1ysyl7I+SXR6PeY1CmIHEzx0v1GlacyrcOcr iC4q61H4J906+9fMjxEc+D0xHR6n2h4V4dFF9/uUO+bgMeE47lIJ8ah3OPhy3e9T5xeta2uV9ld9 ysLjEMGn0jvLiucD6JR1+y3K8RyE0AnBI0JxBI8IxRE8IhRH8IhQHMEjQnEEjwjFETwiFEfwiFAc wSNCcQSPCMURPCIUR/CIUBzBYzDNn0w59pkEnU8uoCOincH0B7DfL8SAxxeKdgaTgUX0PNH4YJp5 HP+nn/+/j0yPjZfZVNp5BCmKxgVTxeMCZHnfguvaI0hR9C2Y6vlx7X921Kf/CFIUrQumDR6XPdTp 9vqSdz8NdE40Lpg258dhyK+3e7L5I0hR9C2Yivc7NvdXO68fi7uQoOhbMBXnAxSz3nIUtdpf7T+C FEXjEIojeEQojuARoTiCR4TiCB4RiiN4RCiO4BGhOIJHhOIIHhGKI3hEKI7gEaE4gkeE4ggeEYoj eEQojuARoTiCR4TiCB4RiiN4RCiO4BGhOIJHhOIIHhGKI3hEKI7gEaE4gkeE4uj/AegO9LaBr06g AAAAAElFTkSuQmCC ------=_NextPart_000_0058_01C07F4F.D3417440-- From nkklrp@hotmail.com Sun Jan 14 04:47:46 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 19442 invoked from network); 14 Jan 2001 04:47:46 -0000 Received: from f256.law10.hotmail.com (HELO hotmail.com) (64.4.14.131) by qmail.accesscomm.ca with SMTP; 14 Jan 2001 04:47:46 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 13 Jan 2001 20:47:43 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Sun, 14 Jan 2001 04:47:43 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca, nkklrp@hotmail.com Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Tideman Schwartz set failure example Date: Sun, 14 Jan 2001 04:47:43 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jan 2001 04:47:43.0560 (UTC) FILETIME=[21DEB480:01C07DE5] X-Evolution: 00000098-0010 Here's an example in which Tideman chooses outside the Schwartz set. But note that Tideman never chooses outside the Smith set, and so when it chooses outside the Schwartz set, all it's doing is choosing an alternative that ties, but doesn't beat, something in the Schwartz set. Obviously it'd debatable how bad that is. It doesn't sound bad to me. Only a minor embarrassment or trivial imperfection. I'm not aware of any strategy problem caused by choosing outside the Schwartz set (but within the Smith set). Is there one, Norm? Anyway, here's the example: "AB5" means that A beats B with 5 people voting A over B. CD4, DE1, EF2, FD3, CF5. C & E are pair-tied. Tideman says: Drop the strongest defeat that's the weakest defeat in a cycle. Repeat till there are no cycles. [end of definition] The only defeat that's the weakest defeat in a cycle is DE1. When we drop that, we have 2 undefeated candidates: C & E. The flip of the coin could elect E, a candidate who isn't in the Schwartz set (but who is in the Smith set). That can only happen when there's a pairwise-tie. Without pairwise ties, the Schwartz & Smith sets are identical. Tideman always chooses from the Smith set. Again, I question the importance of choosing from the Schwartz set. Sure, it's aesthetically desirable, because someone who merely ties a Schwartz set member doesn't seem really qualified for the country club. But that alternative is arguably as good as the Schwartz set member that it ties. The voters have voted those 2 alternatives equal. For that reason, I'm re-nominating Tideman. Though Tideman doesn't devote itself to minimizing the winner's defeatedness in the way that Schulze, SSD, PC, & SD do, Tideman still doesn't do appreciably worse than those methods in Norm's social utility simulation study. There's only a barely noticible gap. Tideman's definition may seem counterintuitive, where it says to start with the _strongest_ defeat that's the weakest defeat in a cycle. But that's for the purpose of minimizing the number of defeats that must be dropped in order to solve all the cycles. A clear & compelling demonstration of that could be devised. Let me also nominate a few other briefly-defined methods: Plain Condorcet(PC): Any undefeated alternative wins. If there isn't one, drop the weakest defeat. Repeat till there's an undefeated alternative. [end of definition] Smith//PC: Use PC to choose from the initial voted Smith set. [end of definition] PC doesn't meet the Smith Criterion, which makes it vulnerable to academic criticism about some other criteria that depend on Smith. But PC is the briefest-defined Condorcet version. PC & Smith//PC are monotonic and pass SFC & WDSC. We don't yet know if they pass GSFC or SDSC. They have another Clone Criterion failure mode, in addition to that of SSD, but it requires the clone set members to defeat eachother quite strongly, compared to defeats outside the clone set--something that would be surprising, considering that the clones are assumed to be practically identical. So PC & Smith//PC shouldn't be significantly worse than SSD by the clone set. Norm's simulation demonstrates that. Likewise for Smith/PC. Sequential Dropping (SD): Drop the weakest defeat that's in a cycle. Repeat till there's an unbeaten candidate. [end of definition] As Norm pointed out, the brevity of SD's definition is second only to that of PC. And yet SD meets all 4 of the majority defensive strategy criteria, and of course the Smith Criterion. But SD can be nonmonotonic. Nonmonotonic methods are vulnerable to criticism, but I'm nominating SD anyway, because SIRV might be nonmonotonic too. So if someone likes SIRV best, then I suggest to them' that SD would be an improvement. But Tideman is nearly as briefly defined as SD, and Tideman meets the Clone Criterion, always, even in the tiny technical committee of Debian. SD is more obvious than Tideman, because Tideman requires an explanation of why we start with the strongest droppable defeats. That's partly why I offer SD to people who like SIRV. Likewise, SD is a good proposal to offer against IRV. SD completely dominates IRV, criterion-wise. I should repeat that Schulze, SSD, Tideman, & SD meet all 4 majority defensive strategy criteria (SFC, GSFC, WDSC, & SDSC) and the Smith Criterion. Anyway, I nominate all the methods that I define in this letter, and SSD. Another proposal that I'd like to nominate is: SSD for general Debian voting, and other large committees; and Schulze for the technical committee's voting, and that of other small committees. The proposal would specify a size below which Schulze would be used. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From moth@debian.org Sun Jan 14 15:03:31 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 30116 invoked from network); 14 Jan 2001 15:03:31 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 14 Jan 2001 15:03:31 -0000 Received: (qmail 5637 invoked by uid 1000); 14 Jan 2001 15:03:15 -0000 Date: Sun, 14 Jan 2001 10:03:15 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Tideman Schwartz set failure example Message-ID: <20010114100315.A4644@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Jan 14, 2001 at 04:47:43AM -0000 X-Evolution: 00000099-0010 On Sun, Jan 14, 2001 at 04:47:43AM -0000, MIKE OSSIPOFF wrote: > I'm not aware of any strategy problem caused by choosing outside the > Schwartz set (but within the Smith set). Is there one, Norm? Uh.. Norm's simulation showed almost nothing about strategy. I'm uncomfortable with the idea of abandoning the various criteria in favor of simulations based on that the set of simulation results Norm posted. However, since it looks like that's what you're advocating, please allow me to mention what I see as weaknesses of Norm's simulation in this context: [1] Only one "policy" dimension. [I presume that this is an issue dimension -- I'm thinking that if there were multiple issue dimesions, Norm would have indicated that.] [2] No attempt to simulate groups of voters exercising a strategy. [3] No attempt to simulate ballot manipulation by creating options near other options in issue space. [Or: with only one issue, I find it hard to look at the simulation results in attempt to understand this aspect.] [4] No attempt to cluster voters in issue space. [5] Truncation is chosen based on an arbitrary number of options the voter wishes to vote on, not based on a lack of reason to vote. [Thinking as a voter, I'd truncate my ballot when all the unvoted issues were within some epsilon distance of each other.] When positioning voters in issue space, I'd expect a large quantity of voters to be strongly polarized (at "1" or "0") or maybe undecided (no opinion -- which isn't exactly the same as 0.5) -- more like the contribution to "issue distance" from that issue is 0. I can see two kinds of expression of weak interest (which might show up on secondary issues): One expression of weak interest on a secondary issue places the voter between 1 and 0 in issue space. The other expression scales the "issue distance" contribution of one issue with respect to another. [Of course, there's no reason an uncertain voter couldn't have interest which is weak in both these senses.] This doesn't mean that Norm's results aren't useful, nor does it mean that they're not interesting, but I don't see that they're a replacement for any criterion. > But SD can be nonmonotonic. Nonmonotonic methods are vulnerable > to criticism, but I'm nominating SD anyway, because SIRV might be > nonmonotonic too. So if someone likes SIRV best, then I suggest to > them' that SD would be an improvement. I believe I was the only person who strongly advocated IRV, and that was because, at the time, I felt that this aspect of the constitution wasn't fully understood. Personally: I feel that if we're going to change the constitution from what it currently says, we might as well do it right. > Another proposal that I'd like to nominate is: SSD for general Debian > voting, and other large committees; and Schulze for the technical > committee's voting, and that of other small committees. The proposal > would specify a size below which Schulze would be used. This seems to indicate that Schulze has a flaw when used in large groups. I'm not sure that such a flaw has been demonstrated. However, since you have proposed this variety of options, I'd like to propose (this is also motivated by Norm's report on his simulations): "Pure" Condorcet -- if there's more than one condorcet winner, a revote is called for, after some discussion. All condorcet winners must appear on the ballot for the revote. Thanks, -- Raul From nkklrp@hotmail.com Mon Jan 15 02:59:28 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 29380 invoked from network); 15 Jan 2001 02:59:28 -0000 Received: from f96.law10.hotmail.com (HELO hotmail.com) (64.4.15.96) by qmail.accesscomm.ca with SMTP; 15 Jan 2001 02:59:28 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jan 2001 18:59:25 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 15 Jan 2001 02:59:25 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Tideman Schwartz set failure example Date: Mon, 15 Jan 2001 02:59:25 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jan 2001 02:59:25.0561 (UTC) FILETIME=[2B2C7E90:01C07E9F] X-Evolution: 0000009a-0010 >On Sun, Jan 14, 2001 at 04:47:43AM -0000, MIKE OSSIPOFF wrote: > > I'm not aware of any strategy problem caused by choosing outside the > > Schwartz set (but within the Smith set). Is there one, Norm? > >Uh.. Norm's simulation showed almost nothing about strategy. I'm >uncomfortable with the idea of abandoning the various criteria in favor >of simulations based on that the set of simulation results Norm posted. > >However, since it looks like that's what you're advocating, Uh...Where did I say that I was advocating that? Did I mention Norm's simulation when I asked him if choosing outside the Schwartz set can cause a strategy problem? The Schwartz Criterion is so rarely referred to that I don't know if anyone other than a few people I know have ever mentioned it, or if it exists for anyone else. The Smith Criterion is much more commonly known, used, & accepted. [...] >This doesn't mean that Norm's results aren't useful, nor does it mean >that they're not interesting, but I don't see that they're a replacement >for any criterion. But has anyone suggested substituting simulation studies for criteria? The clone study didn't replace the clone criterion; it studied the magnitude of violations of it. The social utility study didn't replace a criterion either. > > > But SD can be nonmonotonic. Nonmonotonic methods are vulnerable > > to criticism, but I'm nominating SD anyway, because SIRV might be > > nonmonotonic too. So if someone likes SIRV best, then I suggest to > > them' that SD would be an improvement. > >I believe I was the only person who strongly advocated IRV, and that >was because, at the time, I felt that this aspect of the constitution >wasn't fully understood. > >Personally: I feel that if we're going to change the constitution >from what it currently says, we might as well do it right. Agreed. I don't expect SIRV or SD to win, and SD is way down in my ranking. > > > Another proposal that I'd like to nominate is: SSD for general Debian > > voting, and other large committees; and Schulze for the technical > > committee's voting, and that of other small committees. The proposal > > would specify a size below which Schulze would be used. > >This seems to indicate that Schulze has a flaw when used in large >groups. I'm not sure that such a flaw has been demonstrated. No flaw. I merely suggest that Debian could have a powerful beneficial precedence effect if it used a method that was publicly proposable. So that proponents of a good voting system could point to its use in the large, well known, international Debian organization. Schulze doesn't seem publicly proposable. I make no secret of that reason of mine for arguing agains Schulze. Anyone who isn't convinced by that reason can of course ignore the suggestion. I'm not trying to sneakily oppose Schulze while keeping a secret of my motive. > >However, since you have proposed this variety of options, I'd like to >propose (this is also motivated by Norm's report on his simulations): > >"Pure" Condorcet -- if there's more than one condorcet winner, a revote >is called for, after some discussion. All condorcet winners must appear >on the ballot for the revote. There can't be more than 1 CW. Do you mean more than 1 Smith set member, a situation where no one beats everyone? I believe that most people will want something more decisive than what you suggest. Mike > >Thanks, > >-- >Raul _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From npetry@accesscomm.ca Sat Jan 20 22:42:12 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 30044 invoked from network); 20 Jan 2001 22:42:12 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 20 Jan 2001 22:42:12 -0000 Message-ID: <016301c08332$2034ab60$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Decisiveness in Voting Methods (was: Re: Cloneproof SSD) Date: Sat, 20 Jan 2001 16:41:21 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0160_01C082FF.D567E0C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 0000009b-0030 This is a multi-part message in MIME format. ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On January 14, Mike Ossipoff wrote: > >You once mentioned differences in decisiveness among Schulze, SSD, >& Tideman. Could you comment more on that, with a few examples? > Sure. I've actually rewritten some comprehensive tests looking at the decisiveness of a variety of voting methods. For now, I'll just assume that the importance of decisiveness is obvious. I'll present an argument for decisiveness later when we return to some of the supermajority proposals (Miller-2, etc.) and Raul's latest proposal (Condorcet with no tiebreaker). It seems to me that there are at least three ways of judging how decisive a voting method is: 1) Total Tiebreaks: Count the number of times a tiebreaker must be used when the method is applied, over a series of elections. Since the tiebreaker will usually be something arbitrary (either the opinion of a single voter, or a random choice), this measure tells us about how arbitrary the method will *appear* to be. Some voting methods break ties only at the end of the procedure (such as plurality, where a single tiebreak is sometimes made from the top candidates), whereas other methods may require a tiebreaking decision to be made *multiple* times as the winner is sought (Tideman, SD, SSD fall into this category). Note though that this measure only affects our *perceptions*, not necessarily the results. For example, Tideman's method may require multiple tiebreaks (since it determines the winner by first approximating a social ranking), yet not all the ties that need to be broken before the winner can be determined will affect the choice of winner (for example, if there is a tie in a voting cycle outside the smith set). Nevertheless, this measure is important (even if only psychological), because if it appears to the voters that the method is making many arbitrary decisions before it arrives at a winner, then they will be skeptical that the method is producing a *group* decision. In my results, these are shown as average number of tiebreaks/election. 2) Elections Requiring Tiebreaker: A second way of measuring decisiveness is to count the percentage of elections that require the use of a tiebreaker. This measure is useful because it suggests what type of tiebreaker rule would be needed for the method to be considered fair and effective. For example, using a method where the tiebreaker will be needed about 20% of the time, it may be a practical necessity to determine the tiebreaker in advance of determining the outcome of the election. On the other hand, using a method where a tiebreaker might only be needed about 0.05% of the time, one could easily ignore the tiebreaker rule, and just look it up after a tie has occurred (should that ever happen). For example, ties are so improbable in public elections using plurality voting, that very few voters even know what the tiebreaker rule their state uses. However, if the method often returned ties, then knowledge of the tiebreaker rule (and a perception that it be a *fair* rule) would be important. A method requiring knowledge of the tiebreaker may also be perceived as more complex than a method where the tiebreaker is so unimportant that it is not worth mentioning. 3) Outcome Affected by Tiebreaker: A third way of assessing how decisive a voting method is would be to count the percentage of elections where a tiebreaking decision has affected the choice of winner. In elections like plurality, where the tiebreaker is only applied at the end of the procedure, it is obvious that this percentage will be the same as in (2). However, for methods like Tideman's procedure (which requires locking/skipping of defeats), it is possible that the tiebreaker will be needed to break ties which *cannot* affect the choice of winners (such as when ties are broken between options outside the smith set). Unfortunately, measuring (3) is difficult, because in general, it would be necessary to determine the election result for every possible way of breaking ties, and then see if any of the results differed. This is a time-consuming and difficult procedure, so as a simplification I decided to estimate this count for known Smith-compliant methods by first eliminating candidates outside the Smith set from the election (since LIIAC tells us that these options *cannot* ever affect the choice of winner), and then count the percentage of elections requiring Tiebreaks when choosing from the remaining options. For example, Smith//Tideman is provably equivalent to Tideman, yet the first method requires fewer tiebreaks than the second, because it is generally choosing from a much smaller set of options. I have created simulations which attempt to meaure decisiveness in all three of the above ways for a variety of common voting methods. There are two sets of test results: 1) A set of results (see ties551*.*) that are based on sets of ballots derived from a spatial analysis. These results are intended to give probability estimates for *actual* elections. You will note that I chose an 'Involvement' index of 0.5 for this simulation. As you might expect, lower involvement requires greater use of the tiebreaker, so I wanted to choose a reasonable value. Earlier, I analysed the results for three of Debian's previous elections, and estimated Involvement to be 0.5277, 0.7767, and 0.3414, so 0.5 seemed about the right value to use in the model. 2) In actual elections (simulated in (1)), there will be very few elections in which there is no Condorcet Winner. This makes it difficult to perceive how well each of the pairwise methods do at decisively resolving ties for larger Smith Set sizes. Therefore, I constructed a second, synthetic test in which a variety of Smith-compliant methods are applied to choosing a winner from randomly constructed 'Smith Matrices' (a 'Smith Matrix' is what I call a pairwise matrix in which all options are members of the Smith Set). The results for 6-option Smith sets are shown in the 'smithtie6*.*' attachments. Analysis: In the tables and graphs, you will note that voting methods are sorted by decisiveness. The Schulze method is consistently the most decisive method shown, but SSD, Minimax, and SD are also quite close. Tideman's method is very indecisive, producing the worst results of all the methods shown (measured all 3 ways). This is primarily because Tideman's procedure often requires an entire social ranking to be approximated before a winner can determined. Most other methods, even those which might require multiple tiebreaks (SD, SSD) only proceed until there is an unbeaten candidate, so they do not require nearly as much use of the tiebreaker. Graph number 2, shows that even with 192 Voters (about the size of Debian's electorate), the Tideman procedure will require use of the Tiebreaker about 26% of the time, which means that if Debian was to use Tideman's method, it would be quite important for the voters to be familiar with the tiebreaker, and consider it fair. Most of Tideman's indecisiveness can be resolved by applying Smith to filter out 'irrelevant' candidates before calculating the Tideman winner (ie: Smith//Tideman, see graph#3), but this complicates the rules further and Tideman is still the least-decisive pairwise method. Unless a random process is used to select the tiebreaker, it would also be necessary to have the Debian Project Leader (or whoever provides the deciding ballot) supply a complete ranking for use by the secretary in advance of each election -- it would be impractical for the Secretary to track down the DPL for every tie that needs to be broken! Systems like Schulze, Plurality, etc. where a tiebreaking decision is made at most *once*, and only at the end of vote count will be cleaner and easier to implement than methods which require the tiebreaker to be known before the method can be applied (SD, SSD, Tideman), and this is particularly true when there is a high probability that the tiebreaker will be needed. For example, with Schulze, the DPL could simply be asked to choose (after the fact) which of the remaining candidates to elect in the unlikely event of a tie. For an electorate the size of Debian's, this would be necessary in less than 1% of elections. An additional factor that makes the choice of tiebreaker rule with Tideman's method particularly important is that the method is not clone-independent if ties are broken randomly. If a particular ballot (such as the DPL's 'casting' ballot, or a randomly drawn ballot) containing a *complete ranking with no equally ranked options* is used (what N. Tideman calls a 'tie-breaking ranking of candidates', or TBRC), then the method *is* at least weakly clone-independent**, but this claim cannot be made otherwise. Schulze's method is always clone independent. The Schulze method is consistently the most decisive pairwise method under consideration. This is primarily because it contains an iterative step which eliminates all beatpath-losers and recalculates beatpaths between the beatpath-undefeated options, until all the remaining options are pairwise-tied. This procedure can be carried out deterministically, and the result is always that Schulze will only yield a tie when there are clone sets of exactly equal strength (very unlikely). The least-opposed option in each of these clone sets remain eligible, and the tiebreaker then chooses between them. In practice, SD and SSD are almost as decisive as Schulze (SSD is the better method), but the need to sometimes break more than one tie before a winner is found makes them a bit less decisive. Interesting differences in decisiveness can be observed by looking at the 'smithtie' results. As expected, the Schulze procedure is by far the most decisive method, while Tideman is the worst (except for Goldfish, a method we haven't discussed here). Note the unusual result for Copeland -- that method is designed to count candidates (how many pairwins & losses each option has) rather than voters, so it does not improve in decisiveness as the size of the electorate increases. The graph shows SD to perform much worse than SSD at resolving Smith sets, but this difference doesn't translate into a significant real-world difference, due to the tiny probability of large Smith sets. Mike has suggested an alternate proposal, 'Cloneproof SSD', which would probably be equivalent to calculating beatpath-undefeated candidates (both in terms of decisiveness and results) if all the weakest defeats in any cycles are dropped and the Schwartz set recalculated until only pairwise-tied options remain. However, that procedure would actually make SSD *less* decisive, so it would be necessary to wrap the procedure in an iterative elimination step for it to be the same as Schulze. I've started doing some testing to determine if 'Cloneproof SSD' is equivalent to 'beatpath-undefeated', and will let you know what I discover (I think it should be). Please let me know if you have any questions/comments about these results. -- Norm Petry **Tideman's method with an appropriate tiebreaker satisfies ICC, but other tests I have carried out show that it is more susceptible to clone-set 'fragmentation' than Schulze's method. That is, when there are 'fuzzy', near-clone sets (the real-world case, where some voters 'cross party lines', and intermix candidates from different parties/factions), changes to a handful of votes are more likely to result in the election of an option from a different clone set than with Schulze's method. I can post this data if anyone is interested. ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/vnd.ms-excel; name="ties551.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ties551.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATgAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAE0AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFANMQzAdJAAAABgAAAOEAAgCwBMEAAgAAAOIAAABcAHAADAAATm9ybWFuIFBldHJ5ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAD0BCAADAAQA BQABAJwAAgAOABkAAgAAABIAAgAAABMAAgAAAK8BAgAAALwBAgAAAD0AEgDwAHgAjDeDIjgAAwAA AAEAWAJAAAIAAACNAAIAAAAiAAIAAAAOAAIAAQC3AQIAAADaAAIAAAAxABoAyAAAAP9/kAEAAAAA AAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEA AAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAAAAP9/ kAEAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAABAP9/vAIAAAACAAAFAUEAcgBpAGEAbAAxABoAyAAD AP9/vAIAAAACAAAFAUEAcgBpAGEAbAAxABoAyAAFAP9/vAIAAAECAAAFAUEAcgBpAGEAbAAxABoA 8AABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAxABoAyAABAP9/vAIAAAAAAAAFAUEAcgBpAGEAbAAe BBgABQATAAAiJCIjLCMjMDtcLSIkIiMsIyMwHgQdAAYAGAAAIiQiIywjIzA7W1JlZF1cLSIkIiMs IyMwHgQeAAcAGQAAIiQiIywjIzAuMDA7XC0iJCIjLCMjMC4wMB4EIwAIAB4AACIkIiMsIyMwLjAw O1tSZWRdXC0iJCIjLCMjMC4wMB4ENQAqADAAAF8tIiQiKiAjLCMjMF8tO1wtIiQiKiAjLCMjMF8t O18tIiQiKiAiLSJfLTtfLUBfLR4ELAApACcAAF8tKiAjLCMjMF8tO1wtKiAjLCMjMF8tO18tKiAi LSJfLTtfLUBfLR4EPQAsADgAAF8tIiQiKiAjLCMjMC4wMF8tO1wtIiQiKiAjLCMjMC4wMF8tO18t IiQiKiAiLSI/P18tO18tQF8tHgQ0ACsALwAAXy0qICMsIyMwLjAwXy07XC0qICMsIyMwLjAwXy07 Xy0qICItIj8/Xy07Xy1AXy0eBAsApAAGAAAwLjAwMDAeBAgApQADAAAwLjDgABQAAAAAAPX/IAAA AAAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAA wCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAA APX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAA AAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDg ABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/ IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAA AAAAwCDgABQAAAAAAAEAIAAAAAAAAAAAAAAAwCDgABQABQArAPX/IAAA+AAAAAAAAAAAwCDgABQA BQApAPX/IAAA+AAAAAAAAAAAwCDgABQABQAsAPX/IAAA+AAAAAAAAAAAwCDgABQABQAqAPX/IAAA +AAAAAAAAAAAwCDgABQABQAJAPX/IAAA+AAAAAAAAAAAwCDgABQABgAAAAEAIAAACAAAAAAAAAAA wCDgABQABwAAAAEAIAAACAAAAAAAAAAAwCDgABQACAAAAAEAIAAACAAAAAAAAAAAwCDgABQABwAA AAEAIwAAGAAAAAAAAAAAwCDgABQAAAAAAAEAIwAAEAAAAAAAAAAAwCDgABQACAAAAAEAIwAAGAAA AAAAAAAAwCDgABQAAAAAAAEAIQAAEAAAAAAAAAAAwCDgABQACAAAAAEAIQAAGAAAAAAAAAAAwCDg ABQABwADAAEAIQAAHAAAAAAAAAAAwCDgABQAAAADAAEAIQAAFAAAAAAAAAAAwCDgABQACAADAAEA IQAAHAAAAAAAAAAAwCDgABQABgADAAEAIQAAHAAAAAAAAAAAwCDgABQACAADAAEAIwAAHAAAAAAA AAAAwCDgABQAAAADAAEAIwAAFAAAAAAAAAAAwCDgABQABgADAAEAIwAAHAAAAAAAAAAAwCDgABQA AAAKAAEAIwAAFAAAAAAAAAAAwCDgABQABgCkAAEAIwAAHAAAAAAAAAAAwCDgABQAAACkAAEAIwAA FAAAAAAAAAAAwCDgABQABwCkAAEAIwAAHAAAAAAAAAAAwCCTAgQAEIAD/5MCBAARgAb/kwIEABKA BP+TAgQAE4AH/5MCBAAAgAD/kwIEABSABf9gAQIAAACFABsApA8AAAACEwBUaWVicmVha2VyIFJl cXVpcmVkhQAYAG0kAAAAAhAAT3V0Y29tZSBBZmZlY3RlZIUAGQA7NwAAAAIRAEF2ZXJhZ2UgVGll YnJlYWtzhQAMAPBLAAAAAAQARGF0YYwABAABAAIArgEEAAQAAQQXAAgAAQAAAAMAAwD8AEcDTQAA ACAAAAAWAABTaW11bGF0aW9uIFBhcmFtZXRlcnM6BwAAVHJpYWxzOggAAE9wdGlvbnM6DAAASW52 b2x2ZW1lbnQ6CwAARGltZW5zaW9uczoQAABUb3RhbCBUaWVicmVha3M6BgAAVm90ZXJzCQAAUGx1 cmFsaXR5BgAAUnVub2ZmDgAASW5zdGFudCBSdW5vZmYFAABCb3JkYQcAAEJ1Y2tsaW4IAABBcHBy b3ZhbAgAAENvcGVsYW5kBwAATWluaW1heAcAAFRpZGVtYW4HAABTY2h1bHplCAAAR29sZGZpc2gC AABTRAMAAFNTRBsAAFRpZWJyZWFrZXIgQWZmZWN0cyBPdXRjb21lOhIAAEVsZWN0aW9uIEV4YW1w bGVzOg0AAFZvdGluZyBNZXRob2QPAABQYWlyd2lzZSBNYXRyaXhVAABbWzAsIDEsIDEsIDEsIDFd LCBbMywgMCwgMiwgMywgM10sIFszLCAzLCAwLCAzLCAzXSwgWzAsIDEsIDEsIDAsIDBdLCBbMiwg MiwgMSwgMywgMF1dVQAAW1swLCAwLCAyLCAzLCAxXSwgWzMsIDAsIDMsIDMsIDNdLCBbNCwgMywg MCwgNCwgMV0sIFsxLCAxLCAxLCAwLCAxXSwgWzUsIDMsIDUsIDUsIDBdXVUAAFtbMCwgMiwgMSwg MSwgMV0sIFszLCAwLCAzLCAzLCAzXSwgWzEsIDIsIDAsIDIsIDJdLCBbMSwgMiwgMCwgMCwgMl0s IFszLCAyLCAzLCAzLCAwXV1VAABbWzAsIDIsIDQsIDUsIDJdLCBbNCwgMCwgNiwgNiwgM10sIFsx LCAwLCAwLCAxLCAwXSwgWzAsIDAsIDAsIDAsIDBdLCBbNCwgMywgNiwgNiwgMF1dVQAAW1swLCAz LCAyLCAxLCAyXSwgWzAsIDAsIDAsIDAsIDBdLCBbMywgMywgMCwgMywgMV0sIFszLCA0LCAyLCAw LCAyXSwgWzMsIDQsIDMsIDMsIDBdXQYAAFRvdGFsOh8AAEVsZWN0aW9ucyBSZXF1aXJpbmcgVGll YnJlYWtlcjobAABBdmVyYWdlIFRpZWJyZWFrcy9FbGVjdGlvbjr/ABoECABDCAAADAB0jrYIAAB/ AEEADAkAANUAAACBCQAASgFCAAAADgD/AAAAYgAAARUAQwAAAA4A/wAAAAAAAAEVAEQAAAAOAP8A AAD3vwABFoBFAAAADgD/AAAA4IEAAQIARgAAAA4A/wAEAAAABAAAAAkQAAABAAAAFkDLARLFYgAA AAAAAAAAAAAAYgAAAQIASQAAAA4A/wAAAAAAAAFiAEoAAAAOAP8AAAAAAAABAABLAAAADgD/AAAA YgAAAQAAKNCdMA4A/wAAAAAAAAEAAE0AAAAOAP8AAAAAAAABYgBOAAAADgD/AAAAVDAAAQAALgAA AA4A/wAAAAAAAAEQAC8AAAAOAP8AAADMNYABFQAwAAAADgD/AAAAjwEAARUAAAAAAGF6cDAOQMsB BAAAAArFYgAEAAAAAQAAAAQAAAAKxWIADkDLAQQAAACAARcANAAAAA4A/wAAAAAAAAEXwDUAAAAO AP8AAAD3vwAB/I8BAAAA8OdiAAAA//8oQMsBhPZTMLjEYgB0AAAAAAAAAAIAxzAAAMUwAAB5wQAB Lc45AAAADgD/AAAAAADhPG0wDgDHMNEAAAD6xGIA/AAAAAkAAADNFQQwAADFMOyjxzDRAAAA+sRi AP0AAAD6xGIA/MZiAOzqAjD6xGIAKEDLAQAAAAD8xmIAdAAAAAAAAACOjw8wAAAAAPjEYgAHAAAA /////3RCywE4x2IAAAAAAAcAUABlAHIAYwBlAG4AdAAAAAAAAAAwAF0AAAAGyPi/AAgAADiTRAAA AAAAAAgAAAAAAAAQAwAAAQAAANxaFQEAAAAAjMZiAAAAAAAEAAAAAQAAACDvnTAAAAAAWACHAIjG YgABAAAA2RAAMJZqVDBScFQwwsgQMH4aqgBQAIcAZRAAMAIAAAAOAIcAcUPLAXiIDzAwAAAADgCH AAEAAABoQ8sBAAAAAAgAhwD8AYcAAQAAAAEAAABxQ8sBAAAAAAEAAAAAAAAAMAAAAAAAAAAMxmIA iYUPMAEAAAAAAAAACwAAAAAAAAAGAocAOsdiADjHYgAIAIcAAQAAAAkAAADOWlQwAAAAAGUQADBw alQw7ASqALzGYgA4k0QAMMZiAHu397/3Qfe/kJT8v5a397/3Qfe/kJT8v064978BAAAAvMZiAGDG YgBJX/e/AAAAALzGYgA4k0QAAAIAAAEBYgDg9pKBAAAAAJjGYgAwDvR/U05wMAEAAAAnTnAwcRUA MIjGYgAEAAAA3FoVAYRJywEAHmEC3FoVAYRJywGoaA8w3FoVAdhPywEIAIcAAAAAAPTGYgAIAAAA FwAAABTHYgCgScsBQMdiALq/EDA4x2IACAAAAAgAAAA4x2IA62wPMBcAAAAIAAAAVAdbAggAhwAA AAAA/sJiAP//CgAAAAkIEAAABiAA0xDMB0kAAAAGAAAAFAAFAAIAACZBFQAKAAcAAFBhZ2UgJlCD AAIAAACEAAIAAAChACIAAAAAUAEAAQABAEQAaXR5BgAAAAAAAOA/AAAAAAAA4D9udDMAAgADAAEQ AgAAAAIQEAAAAAAAAAAAADAKqwIwCtMBMxAAAKAABAATABQAZBAIAAAAAQAAAAEAAxAMAAEAAQAJ AAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAlAAEADRASAAAABwFTAGMAaAB1AGwAegBlAFEQEwAB AgAACgALADsAACYALgABAAEAURATAAICAAADAAsAOwAAJgAuAAAAAABREAgAAwEAAAAAAAAGEAgA //8AAAAAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAA AgAAAAAHADoAACUAAgANEAoAAAADAVMAUwBEAFEQEwABAgAACgALADsAACYALgACAAIAURATAAIC AAADAAsAOwAAJgAuAAAAAABREAgAAwEAAAAAAAAGEAgA//8BAAEAAAAzEAAAXxACAAAANBAAAEUQ AgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAAAAAHADoAACUAAwANEBIAAAAHAU0A aQBuAGkAbQBhAHgAURATAAECAAAKAAsAOwAAJgAuAAMAAwBREBMAAgIAAAMACwA7AAAmAC4AAAAA AFEQCAADAQAAAAAAAAYQCAD//wIAAgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEA CQAJAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAJQAEAA0QCAAAAAIBUwBEAFEQEwABAgAACgALADsA ACYALgAEAAQAURATAAICAAADAAsAOwAAJgAuAAAAAABREAgAAwEAAAAAAAAGEAgA//8DAAMAAAAz EAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAAAAAHADoA ACUABQANEBYAAAAJAVAAbAB1AHIAYQBsAGkAdAB5AFEQEwABAgAACgALADsAACYALgAFAAUAURAT AAICAAADAAsAOwAAJgAuAAAAAABREAgAAwEAAAAAAAAGEAgA//8EAAQAAAAzEAAAXxACAAAANBAA AEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAAAAAHADoAACUABgANEBQAAAAI AUEAcABwAHIAbwB2AGEAbABREBMAAQIAAAoACwA7AAAmAC4ABgAGAFEQEwACAgAAAwALADsAACYA LgAAAAAAURAIAAMBAAAAAAAABhAIAP//BQAFAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAM AAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAlAAcADRAgAAAADgFJAG4AcwB0AGEAbgB0 ACAAUgB1AG4AbwBmAGYAURATAAECAAAKAAsAOwAAJgAuAAcABwBREBMAAgIAAAMACwA7AAAmAC4A AAAAAFEQCAADAQAAAAAAAAYQCAD//wYABgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAAB AAEACQAJAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAJQAIAA0QEgAAAAcBVABpAGQAZQBtAGEAbgBR EBMAAQIAAAoACwA7AAAmAC4ACAAIAFEQEwACAgAAAwALADsAACYALgAAAAAAURAIAAMBAAAAAAAA BhAIAP//BwAHAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAARBAEAA4AAAAkEAIAAgAlECAAAgIB AAAAAADp////3v///wAAAAAAAAAAsQBNACAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAA JhACAAUAURAIAAABAAAAAAAANBAAACQQAgADACUQIAACAgEAAAAAAOn////e////AAAAAAAAAACx AE0AIBAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAAAmEAIABQBREAgAAAEAAAAAAAA0EAAA RhACAAEAQRASAAAATAEAAHgCAACtCwAAcAsAADMQAABPEBQAAgACAJoAAAAtAgAAswwAAJAMAAAd EBIAAAAAAAAAAAAAAAAAAAAAAAAAMxAAACAQCAABAAEAAQAAAGIQEgAAAAAAAQAAAAEAAAAAAAAA bwA0EAAAHRASAAEAAAAAAAAAAAAAAAAAAAAAADMQAAAfECoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAB8BThACAAkANBAAACUQIAACAgEAAAAAALoGAAC9DgAAzgAAAJcA AACBAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAKgAAABYAAAAmEAIACgBREAgAAAEAAAAAAAAN EBAAAAAGAVYAbwB0AGUAcgBzACcQBgADAAAAAAA0EAAAJRAgAAICAQAAAAAAMwAAAGQGAABnAAAA oAMAAIECTQAAAFoAMxAAAE8QFAACAAIAAAAAAAAAAAAWAAAAgAAAACYQAgAKAFEQCAAAAQAAAAAA AA0QKgAAABMBVABpAGUAYgByAGUAYQBrAGUAcgAgAFIAZQBxAHUAaQByAGUAZAAnEAYAAgAAAAAA NBAAADUQAAAyEAQAAAADADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAAAQAAABYACAA0 EAAAFBAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxAAABgQAgAAACIQCgAAAAAAAAAAAA8AFRAUAIEN AAAKBgAADAIAAEwEAAADAR8AMxAAAE8QFAAFAAIAgQ0AAAoGAAAAAAAAAAAAACUQIAACAgEAAAAA AOn////e////AAAAAAAAAACxAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABREAgA AAEAAAAAAAA0EAAANBAAAAYQCAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8JAE0AChAQ AP///wAAAAAAAQABAE4ATQALEAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQAAAA0EAAA NBAAADQQAAAlECAAAgIBAAAAAABQBAAAUgAAAAAHAABKAQAAgQBNADAQAAAzEAAATxAUAAIAAgAA AAAAAAAAAIcBAAAwAAAAJhACAAkAURAIAAABAAAAAAAADRCuAAAAVQFFAGwAZQBjAHQAaQBvAG4A cwAgAFIAZQBxAHUAaQByAGkAbgBnACAAVABpAGUAYgByAGUAYQBrAGUAcgAKADIANQAsADAAMAAw ACAAVAByAGkAYQBsAHMALAAgADUAIABPAHAAdABpAG8AbgBzACwAIAAwAC4ANQAgAEkAbgB2AG8A bAB2AGUAbQBlAG4AdAAsACAAMQAgAEQAaQBtAGUAbgBzAGkAbwBuACcQBgABAAAAAAA0EAAANBAA AAACDgAAAAAACQAAAAAACAAAAGUQAgACAAMCDgAAAAAAAAAAAAAAAAAYQAMCDgAAAAEAAAAAAAAA AAAYQAMCDgAAAAIAAAAAAAAAAAAYQAMCDgAAAAMAAAAAAAAAAAAYQAMCDgAAAAQAAAAAAAAAAAAY QAMCDgAAAAUAAAAAAAAAAAAYQAMCDgAAAAYAAAAAAAAAAAAYQAMCDgAAAAcAAAAAAAAAAAAYQAMC DgABAAAAAAAAAAAAAAAoQAMCDgABAAEAAAAAAAAAAAAoQAMCDgABAAIAAAAAAAAAAAAoQAMCDgAB AAMAAAAAAAAAAAAoQAMCDgABAAQAAAAAAAAAAAAoQAMCDgABAAUAAAAAAAAAAAAoQAMCDgABAAYA AAAAAAAAAAAoQAMCDgABAAcAAAAAAAAAAAAoQAMCDgACAAAAAAAAAAAAAAA4QAMCDgACAAEAAAAA AAAAAAA4QAMCDgACAAIAAAAAAAAAAAA4QAMCDgACAAMAAAAAAAAAAAA4QAMCDgACAAQAAAAAAAAA AAA4QAMCDgACAAUAAAAAAAAAAAA4QAMCDgACAAYAAAAAAAAAAAA4QAMCDgACAAcAAAAAAAAAAAA4 QAMCDgADAAAAAAAAAAAAAABIQAMCDgADAAEAAAAAAAAAAABIQAMCDgADAAIAAAAAAAAAAABIQAMC DgADAAMAAAAAAAAAAABIQAMCDgADAAQAAAAAAAAAAABIQAMCDgADAAUAAAAAAAAAAABIQAMCDgAD AAYAAAAAAAAAAABIQAMCDgADAAcAAAAAAAAAAABIQAMCDgAEAAAAAAAAAAAAAABYQAMCDgAEAAEA AAAAAAAAAABYQAMCDgAEAAIAAAAAAAAAAABYQAMCDgAEAAMAAAAAAAAAAABYQAMCDgAEAAQAAAAA AAAAAABYQAMCDgAEAAUAAAAAAAAAAABYQAMCDgAEAAYAAAAAAAAAAABYQAMCDgAEAAcAAAAAAAAA AABYQAMCDgAFAAAAAAAAAAAAAABoQAMCDgAFAAEAAAAAAAAAAABoQAMCDgAFAAIAAAAAAAAAAABo QAMCDgAFAAMAAAAAAAAAAABoQAMCDgAFAAQAAAAAAAAAAABoQAMCDgAFAAUAAAAAAAAAAABoQAMC DgAFAAYAAAAAAAAAAABoQAMCDgAFAAcAAAAAAAAAAABoQAMCDgAGAAAAAAAAAAAAAAB4QAMCDgAG AAEAAAAAAAAAAAB4QAMCDgAGAAIAAAAAAAAAAAB4QAMCDgAGAAMAAAAAAAAAAAB4QAMCDgAGAAQA AAAAAAAAAAB4QAMCDgAGAAUAAAAAAAAAAAB4QAMCDgAGAAYAAAAAAAAAAAB4QAMCDgAGAAcAAAAA AAAAAAB4QAMCDgAHAAAAAAAAAAAAAACIQAMCDgAHAAEAAAAAAAAAAACIQAMCDgAHAAIAAAAAAAAA AACIQAMCDgAHAAMAAAAAAAAAAACIQAMCDgAHAAQAAAAAAAAAAACIQAMCDgAHAAUAAAAAAAAAAACI QAMCDgAHAAYAAAAAAAAAAACIQAMCDgAHAAcAAAAAAAAAAACIQAMCDgAIAAAAAAAAAAAAAACYQAMC DgAIAAEAAAAAAAAAAACYQAMCDgAIAAIAAAAAAAAAAACYQAMCDgAIAAMAAAAAAAAAAACYQAMCDgAI AAQAAAAAAAAAAACYQAMCDgAIAAUAAAAAAAAAAACYQAMCDgAIAAYAAAAAAAAAAACYQAMCDgAIAAcA AAAAAAAAAACYQGUQAgABAAMCDgAAAAAAAADzH9JvXwfOPwMCDgAAAAEAAADiWBe30QDOPwMCDgAA AAIAAADzH9JvXwfOPwMCDgAAAAMAAABWn6ut2F/OPwMCDgAAAAQAAAB8YTJVMCrRPwMCDgAAAAUA AAASFD/G3LXUPwMCDgAAAAYAAADZPXlYqDXnPwMCDgAAAAcAAABcj8L1KFzrPwMCDgABAAAAAAAy 5q4l5IO+PwMCDgABAAEAAAD7OnDOiNK+PwMCDgABAAIAAAAdyeU/pN++PwMCDgABAAMAAAB0RpT2 Bl/APwMCDgABAAQAAABhMlUwKqnDPwMCDgABAAUAAAALJCh+jLnLPwMCDgABAAYAAAAbnl4pyxDj PwMCDgABAAcAAAC30QDeAgnqPwMCDgACAAAAAAANcayL22iwPwMCDgACAAEAAADWxW00gLewPwMC DgACAAIAAADnjCjtDb6wPwMCDgACAAMAAABq3nGKjuSyPwMCDgACAAQAAACVZYhjXdy2PwMCDgAC AAUAAACEDU+vlGXAPwMCDgACAAYAAACeXinLEMfaPwMCDgACAAcAAADo2az6XG3nPwMCDgADAAAA AAAyVTAqqROgPwMCDgADAAEAAACC4seYu5agPwMCDgADAAIAAADF/rJ78rCgPwMCDgADAAMAAADw FkhQ/BijPwMCDgADAAQAAADy0k1iEFipPwMCDgADAAUAAAAnwoanV8qyPwMCDgADAAYAAAAwKqkT 0ETQPwMCDgADAAcAAADqBDQRNjzjPwMCDgAEAAAAAAAvbqMBvAWSPwMCDgAEAAEAAAAFNBE2PL2S PwMCDgAEAAIAAAAFNBE2PL2SPwMCDgAEAAMAAAC6SQwCK4eWPwMCDgAEAAQAAABGJXUCmgibPwMC DgAEAAUAAADXEvJBz2alPwMCDgAEAAYAAADVCWgibHjCPwMCDgAEAAcAAADdJAaBlUPbPwMCDgAF AAAAAACfPCzUmuZ9PwMCDgAFAAEAAAB2cRsN4C2APwMCDgAFAAIAAAD8qfHSTWKAPwMCDgAFAAMA AABhMlUwKqmDPwMCDgAFAAQAAAB56SYxCKyMPwMCDgAFAAUAAADD0ytlGeKYPwMCDgAFAAYAAACc oiO5/Ie0PwMCDgAFAAcAAADNzMzMzMzQPwMCDgAGAAAAAABuowG8BRJ0PwMCDgAGAAEAAACIhVrT vON0PwMCDgAGAAIAAACIhVrTvON0PwMCDgAGAAMAAAD6fmq8dJN4PwMCDgAGAAQAAABfB84ZUdp7 PwMCDgAGAAUAAABfB84ZUdqLPwMCDgAGAAYAAAD5oGez6nOlPwMCDgAGAAcAAACNl24Sg8DCPwMC DgAHAAAAAADFjzF3LSFfPwMCDgAHAAEAAADFjzF3LSFfPwMCDgAHAAIAAADFjzF3LSFfPwMCDgAH AAMAAABIUPwYc9diPwMCDgAHAAQAAABGJXUCmghrPwMCDgAHAAUAAACSy39Iv319PwMCDgAHAAYA AACIhVrTvOOUPwMCDgAHAAcAAAAeFmpN846zPwMCDgAIAAAAAAD8qfHSTWJQPwMCDgAIAAEAAAD8 qfHSTWJQPwMCDgAIAAIAAAD8qfHSTWJQPwMCDgAIAAMAAABhMlUwKqlTPwMCDgAIAAQAAACU9gZf mExVPwMCDgAIAAUAAAAvbqMBvAVyPwMCDgAIAAYAAACu2F92Tx6GPwMCDgAIAAcAAAD9h/Tb14Gj P2UQAgADAD4CCgAIAAcAAAD9h/TboAAEABMAFAAKAAAACQgQAAAGIADTEMwHSQAAAAYAAAAUAAUA AgAAJkEVAAoABwAAUGFnZSAmUIMAAgAAAIQAAgAAAKEAIgAAAABQAQABAAEARgGjP2kAAAAAAAAA 4D8AAAAAAADgP2kAMwACAAMAARACAAAAAhAQAAAAAAAAAAAAMAqrAjAK0wEzEAAAoAAEABMAFABk EAgAAAABAAAAAQADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAAAAAHADoAADMAAQANEBIAAAAH AVMAYwBoAHUAbAB6AGUAURATAAECAAAKAAsAOwAANAA8AAEAAQBREBMAAgIAAAMACwA7AAA0ADwA AAAAAFEQCAADAQAAAAAAAAYQCAD//wAAAAAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAAB AAEACQAJAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAMwACAA0QCgAAAAMBUwBTAEQAURATAAECAAAK AAsAOwAANAA8AAIAAgBREBMAAgIAAAMACwA7AAA0ADwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wEA AQAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEAAAAzEAAAURAPAAACAAAA AAcAOgAAMwADAA0QEgAAAAcBTQBpAG4AaQBtAGEAeABREBMAAQIAAAoACwA7AAA0ADwAAwADAFEQ EwACAgAAAwALADsAADQAPAAAAAAAURAIAAMBAAAAAAAABhAIAP//AgACAAAAMxAAAF8QAgAAADQQ AABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAzAAQADRAIAAAA AgFTAEQAURATAAECAAAKAAsAOwAANAA8AAQABABREBMAAgIAAAMACwA7AAA0ADwAAAAAAFEQCAAD AQAAAAAAAAYQCAD//wMAAwAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEA AAAzEAAAURAPAAACAAAAAAcAOgAAMwAFAA0QFgAAAAkBUABsAHUAcgBhAGwAaQB0AHkAURATAAEC AAAKAAsAOwAANAA8AAUABQBREBMAAgIAAAMACwA7AAA0ADwAAAAAAFEQCAADAQAAAAAAAAYQCAD/ /wQABAAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEAAAAzEAAAURAPAAAC AAAAAAcAOgAAMwAGAA0QEgAAAAcBVABpAGQAZQBtAGEAbgBREBMAAQIAAAoACwA7AAA0ADwABgAG AFEQEwACAgAAAwALADsAADQAPAAAAAAAURAIAAMBAAAAAAAABhAIAP//BQAFAAAAMxAAAF8QAgAA ADQQAABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAzAAcADRAU AAAACAFBAHAAcAByAG8AdgBhAGwAURATAAECAAAKAAsAOwAANAA8AAcABwBREBMAAgIAAAMACwA7 AAA0ADwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wYABgAAADMQAABfEAIAAAA0EAAARRACAAAANBAA AEQQBAAOAAAAJBACAAIAJRAgAAICAQAAAAAA8f7//97///8AAAAAAAAAALEATQAgEAAAMxAAAE8Q FAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAFAFEQCAAAAQAAAAAAADQQAAAkEAIAAwAlECAAAgIB AAAAAADx/v//3v///wAAAAAAAAAAsQBNACAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAA JhACAAUAURAIAAABAAAAAAAANBAAAEYQAgABAEEQEgAAAEwBAAB4AgAAMAwAAHALAAAzEAAATxAU AAIAAgCaAAAALQIAADYNAACQDAAAHRASAAAAAAAAAAAAAAAAAAAAAAAAADMQAAAgEAgAAQABAAEA AABiEBIAAAAAAAEAAAABAAAAAAAAAG8ANBAAAB0QEgABAAAAAAAAAAAAAAAAAAAAAAAzEAAAHxAq AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAU4QAgAJADQQAAAlECAA AgIBAAAAAAD7BgAAvQ4AAM4AAACXAAAAgQBNAAAAAAAzEAAATxAUAAIAAgAAAAAAAAAAACoAAAAW AAAAJhACAAoAURAIAAABAAAAAAAADRAQAAAABgFWAG8AdABlAHIAcwAnEAYAAwAAAAAANBAAACUQ IAACAgEAAAAAADMAAACiBgAAZwAAACQDAACBAk0AAABaADMQAABPEBQAAgACAAAAAAAAAAAAFgAA AG8AAAAmEAIACgBREAgAAAEAAAAAAAANECQAAAAQAU8AdQB0AGMAbwBtAGUAIABBAGYAZgBlAGMA dABlAGQAJxAGAAIAAAAAADQQAAA1EAAAMhAEAAAAAwAzEAAABxAMAICAgAAAAAAAAAAXAAoQEADA wMAAAAAAAAEAAAAWAAgANBAAABQQFAAAAAAAAAAAAAAAAAAAAAAAAAAAADMQAAAYEAIAAAAiEAoA AAAAAAAAAAAPABUQFAAEDgAATwYAAIkBAADCAwAAAwEfADMQAABPEBQABQACAAQOAABPBgAAAAAA AAAAAAAlECAAAgIBAAAAAADx/v//3v///wAAAAAAAAAAsQBNAAAAAAAzEAAATxAUAAIAAgAAAAAA AAAAAAAAAAAAAAAAURAIAAABAAAAAAAANBAAADQQAAAGEAgAAAAAAP3/AAAzEAAAXxACAAAABxAM AAAAAAAAAP//CQBNAAoQEAD///8AAAAAAAEAAQBOAE0ACxACAAAAXRACAAEACRAUAAAAAAAAAAAA AAAAAAgACABkAAAANBAAADQQAAA0EAAAJRAgAAICAQAAAAAAUAQAAFIAAAAABwAASgEAAIEATQAw EAAAMxAAAE8QFAACAAIAAAAAAAAAAACHAQAAMAAAACYQAgAJAFEQCAAAAQAAAAAAAA0QpgAAAFEB VABpAGUAYgByAGUAYQBrAGUAcgAgAEEAZgBmAGUAYwB0AHMAIABPAHUAdABjAG8AbQBlAAoAMgA1 ACwAMAAwADAAIABUAHIAaQBhAGwAcwAsACAANQAgAE8AcAB0AGkAbwBuAHMALAAgADAALgA1ACAA SQBuAHYAbwBsAHYAZQBtAGUAbgB0ACwAIAAxACAARABpAG0AZQBuAHMAaQBvAG4AJxAGAAEAAAAA ADQQAAA0EAAAAAIOAAAAAAAJAAAAAAAHAAAAZRACAAIAAwIOAAAAAAAAAAAAAAAAABhAAwIOAAAA AQAAAAAAAAAAABhAAwIOAAAAAgAAAAAAAAAAABhAAwIOAAAAAwAAAAAAAAAAABhAAwIOAAAABAAA AAAAAAAAABhAAwIOAAAABQAAAAAAAAAAABhAAwIOAAAABgAAAAAAAAAAABhAAwIOAAEAAAAAAAAA AAAAAChAAwIOAAEAAQAAAAAAAAAAAChAAwIOAAEAAgAAAAAAAAAAAChAAwIOAAEAAwAAAAAAAAAA AChAAwIOAAEABAAAAAAAAAAAAChAAwIOAAEABQAAAAAAAAAAAChAAwIOAAEABgAAAAAAAAAAAChA AwIOAAIAAAAAAAAAAAAAADhAAwIOAAIAAQAAAAAAAAAAADhAAwIOAAIAAgAAAAAAAAAAADhAAwIO AAIAAwAAAAAAAAAAADhAAwIOAAIABAAAAAAAAAAAADhAAwIOAAIABQAAAAAAAAAAADhAAwIOAAIA BgAAAAAAAAAAADhAAwIOAAMAAAAAAAAAAAAAAEhAAwIOAAMAAQAAAAAAAAAAAEhAAwIOAAMAAgAA AAAAAAAAAEhAAwIOAAMAAwAAAAAAAAAAAEhAAwIOAAMABAAAAAAAAAAAAEhAAwIOAAMABQAAAAAA AAAAAEhAAwIOAAMABgAAAAAAAAAAAEhAAwIOAAQAAAAAAAAAAAAAAFhAAwIOAAQAAQAAAAAAAAAA AFhAAwIOAAQAAgAAAAAAAAAAAFhAAwIOAAQAAwAAAAAAAAAAAFhAAwIOAAQABAAAAAAAAAAAAFhA AwIOAAQABQAAAAAAAAAAAFhAAwIOAAQABgAAAAAAAAAAAFhAAwIOAAUAAAAAAAAAAAAAAGhAAwIO AAUAAQAAAAAAAAAAAGhAAwIOAAUAAgAAAAAAAAAAAGhAAwIOAAUAAwAAAAAAAAAAAGhAAwIOAAUA BAAAAAAAAAAAAGhAAwIOAAUABQAAAAAAAAAAAGhAAwIOAAUABgAAAAAAAAAAAGhAAwIOAAYAAAAA AAAAAAAAAHhAAwIOAAYAAQAAAAAAAAAAAHhAAwIOAAYAAgAAAAAAAAAAAHhAAwIOAAYAAwAAAAAA AAAAAHhAAwIOAAYABAAAAAAAAAAAAHhAAwIOAAYABQAAAAAAAAAAAHhAAwIOAAYABgAAAAAAAAAA AHhAAwIOAAcAAAAAAAAAAAAAAIhAAwIOAAcAAQAAAAAAAAAAAIhAAwIOAAcAAgAAAAAAAAAAAIhA AwIOAAcAAwAAAAAAAAAAAIhAAwIOAAcABAAAAAAAAAAAAIhAAwIOAAcABQAAAAAAAAAAAIhAAwIO AAcABgAAAAAAAAAAAIhAAwIOAAgAAAAAAAAAAAAAAJhAAwIOAAgAAQAAAAAAAAAAAJhAAwIOAAgA AgAAAAAAAAAAAJhAAwIOAAgAAwAAAAAAAAAAAJhAAwIOAAgABAAAAAAAAAAAAJhAAwIOAAgABQAA AAAAAAAAAJhAAwIOAAgABgAAAAAAAAAAAJhAZRACAAEAAwIOAAAAAAAAAPMf0m9fB84/AwIOAAAA AQAAAOJYF7fRAM4/AwIOAAAAAgAAAPMf0m9fB84/AwIOAAAAAwAAAGiR7Xw/Nc4/AwIOAAAABAAA AHxhMlUwKtE/AwIOAAAABQAAAP5l9+RhodI/AwIOAAAABgAAABIUP8bctdQ/AwIOAAEAAAAAADLm riXkg74/AwIOAAEAAQAAAPs6cM6I0r4/AwIOAAEAAgAAAB3J5T+k374/AwIOAAEAAwAAABUdyeU/ pL8/AwIOAAEABAAAAGEyVTAqqcM/AwIOAAEABQAAAERpb/CFycQ/AwIOAAEABgAAAAskKH6Mucs/ AwIOAAIAAAAAAA1xrIvbaLA/AwIOAAIAAQAAANbFbTSAt7A/AwIOAAIAAgAAAOeMKO0NvrA/AwIO AAIAAwAAAN/gC5OpgrE/AwIOAAIABAAAAJVliGNd3LY/AwIOAAIABQAAAOAtkKD4MbY/AwIOAAIA BgAAAIQNT6+UZcA/AwIOAAMAAAAAADJVMCqpE6A/AwIOAAMAAQAAAILix5i7lqA/AwIOAAMAAgAA AMX+snvysKA/AwIOAAMAAwAAADcawFsgQaE/AwIOAAMABAAAAPLSTWIQWKk/AwIOAAMABQAAAKFn s+pztaU/AwIOAAMABgAAACfChqdXyrI/AwIOAAQAAAAAAC9uowG8BZI/AwIOAAQAAQAAAAU0ETY8 vZI/AwIOAAQAAgAAAAU0ETY8vZI/AwIOAAQAAwAAAGEyVTAqqZM/AwIOAAQABAAAAEYldQKaCJs/ AwIOAAQABQAAAOCcEaW9wZc/AwIOAAQABgAAANcS8kHPZqU/AwIOAAUAAAAAAJ88LNSa5n0/AwIO AAUAAQAAAHZxGw3gLYA/AwIOAAUAAgAAAPyp8dJNYoA/AwIOAAUAAwAAAAkbnl4py4A/AwIOAAUA BAAAAHnpJjEIrIw/AwIOAAUABQAAAHsUrkfheoQ/AwIOAAUABgAAAMPTK2UZ4pg/AwIOAAYAAAAA AG6jAbwFEnQ/AwIOAAYAAQAAAIiFWtO843Q/AwIOAAYAAgAAAIiFWtO843Q/AwIOAAYAAwAAAJT2 Bl+YTHU/AwIOAAYABAAAAF8HzhlR2ns/AwIOAAYABQAAABNhw9MrZXk/AwIOAAYABgAAAF8HzhlR 2os/AwIOAAcAAAAAAMWPMXctIV8/AwIOAAcAAQAAAMWPMXctIV8/AwIOAAcAAgAAAMWPMXctIV8/ AwIOAAcAAwAAAPyp8dJNYmA/AwIOAAcABAAAAEYldQKaCGs/AwIOAAcABQAAAGEyVTAqqWM/AwIO AAcABgAAAJLLf0i/fX0/AwIOAAgAAAAAAPyp8dJNYlA/AwIOAAgAAQAAAPyp8dJNYlA/AwIOAAgA AgAAAPyp8dJNYlA/AwIOAAgAAwAAAPyp8dJNYlA/AwIOAAgABAAAAJT2Bl+YTFU/AwIOAAgABQAA AJT2Bl+YTFU/AwIOAAgABgAAAC9uowG8BXI/ZRACAAMAPgIKAAgABgAAAC9uowGgAAQAEwAUAAoA AAAJCBAAAAYgANMQzAdJAAAABgAAABQABQACAAAmQRUACgAHAABQYWdlICZQgwACAAAAhAACAAAA oQAiAAAAAFABAAEAAQAEAXI/ZQAAAAAAAADgPwAAAAAAAOA/ZQAzAAIAAwABEAIAAAACEBAAAAAA AAAAAAAwCqsCMArTATMQAACgAAQAEwAUAGQQCAAAAAEAAAABAAMQDAABAAEACQAJAAEAAAAzEAAA URAPAAACAAADAAcAOgAAFwABAA0QEgAAAAcBUwBjAGgAdQBsAHoAZQBREBMAAQIAAAAACwA7AAAY ACAAAQABAFEQEwACAgAAAwALADsAABgAIAAAAAAAURAIAAMBAAAAAAAABhAIAP//AAAAAAAAMxAA AF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAMABwA6AAAX AAIADRAKAAAAAwFTAFMARABREBMAAQIAAAAACwA7AAAYACAAAgACAFEQEwACAgAAAwALADsAABgA IAAAAAAAURAIAAMBAAAAAAAABhAIAP//AQABAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAM AAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAMABwA6AAAXAAMADRASAAAABwFNAGkAbgBpAG0AYQB4 AFEQEwABAgAAAAALADsAABgAIAADAAMAURATAAICAAADAAsAOwAAGAAgAAAAAABREAgAAwEAAAAA AAAGEAgA//8CAAIAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAA AFEQDwAAAgAAAwAHADoAABcABAANEAgAAAACAVMARABREBMAAQIAAAAACwA7AAAYACAABAAEAFEQ EwACAgAAAwALADsAABgAIAAAAAAAURAIAAMBAAAAAAAABhAIAP//AwADAAAAMxAAAF8QAgAAADQQ AABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAMABwA6AAAXAAUADRAWAAAA CQFQAGwAdQByAGEAbABpAHQAeQBREBMAAQIAAAAACwA7AAAYACAABQAFAFEQEwACAgAAAwALADsA ABgAIAAAAAAAURAIAAMBAAAAAAAABhAIAP//BAAEAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAA AxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAMABwA6AAAXAAYADRAUAAAACAFBAHAAcAByAG8A dgBhAGwAURATAAECAAAAAAsAOwAAGAAgAAYABgBREBMAAgIAAAMACwA7AAAYACAAAAAAAFEQCAAD AQAAAAAAAAYQCAD//wUABQAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEA AAAzEAAAURAPAAACAAADAAcAOgAAFwAHAA0QIAAAAA4BSQBuAHMAdABhAG4AdAAgAFIAdQBuAG8A ZgBmAFEQEwABAgAAAAALADsAABgAIAAHAAcAURATAAICAAADAAsAOwAAGAAgAAAAAABREAgAAwEA AAAAAAAGEAgA//8GAAYAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAA MxAAAFEQDwAAAgAAAwAHADoAABcACAANEBIAAAAHAVQAaQBkAGUAbQBhAG4AURATAAECAAAAAAsA OwAAGAAgAAgACABREBMAAgIAAAMACwA7AAAYACAAAAAAAFEQCAADAQAAAAAAAAYQCAD//wcABwAA ADMQAABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAOAAAAJBACAAIAJRAgAAICAQAAAAAA6f///97/ //8AAAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAFAFEQCAAA AQAAAAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADp////3v///wAAAAAAAAAAsQBNACAQAAAzEAAA TxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAUAURAIAAABAAAAAAAANBAAAEYQAgABAEEQEgAA ACcBAAB4AgAA0wsAAHALAAAzEAAATxAUAAIAAgCaAAAALQIAALMMAACQDAAAHRASAAAAAAAAAAAA AAAAAAAAAAAAADMQAAAgEAgAAQABAAEAAABiEBIAAAAAAAEAAAABAAAAAAAAAG8ANBAAAB0QEgAB AAAAAAAAAAAAAAAAAAAAAAAzEAAAHxAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAfAU4QAgClADQQAAAlECAAAgIBAAAAAACnBgAAvQ4AAM4AAACXAAAAgQBNAAAAAAAz EAAATxAUAAIAAgAAAAAAAAAAACoAAAAWAAAAJhACAAoAURAIAAABAAAAAAAADRAQAAAABgFWAG8A dABlAHIAcwAnEAYAAwAAAAAANBAAACUQIAACAgEAAAAAADMAAACNBgAAZwAAAE0DAACBAk0AAABa ADMQAABPEBQAAgACAAAAAAAAAAAAFgAAAHUAAAAmEAIACgBREAgAAAEAAAAAAAANECYAAAARAUEA dgBlAHIAYQBnAGUAIABUAGkAZQBiAHIAZQBhAGsAcwAnEAYAAgAAAAAANBAAADUQAAAyEAQAAAAD ADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAAAQAAABYACAA0EAAAFBAUAAAAAAAAAAAA AAAAAAAAAAAAAAAAMxAAABgQAgAAACIQCgAAAAAAAAAAAA8AFRAUAIENAAAKBgAADAIAAEwEAAAD AR8AMxAAAE8QFAAFAAIAgQ0AAAoGAAAAAAAAAAAAACUQIAACAgEAAAAAAOn////e////AAAAAAAA AACxAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABREAgAAAEAAAAAAAA0EAAANBAA AAYQCAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8JAE0AChAQAP///wAAAAAAAQABAE4A TQALEAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQAAAA0EAAANBAAADQQAAAlECAAAgIB AAAAAABQBAAAUgAAAAAHAABKAQAAgQBNADAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAIcBAAAwAAAA JhACAAkAURAIAAABAAAAAAAADRCeAAAATQFUAGkAZQBiAHIAZQBhAGsAcwAgAHAAZQByACAARQBs AGUAYwB0AGkAbwBuAAoAMgA1ACwAMAAwADAAIABUAHIAaQBhAGwAcwAsACAANQAgAE8AcAB0AGkA bwBuAHMALAAgADAALgA1ACAASQBuAHYAbwBsAHYAZQBtAGUAbgB0ACwAIAAxACAARABpAG0AZQBu AHMAaQBvAG4AJxAGAAEAAAAAADQQAAA0EAAAAAIOAAAAAAAJAAAAAAAIAAAAZRACAAIAAwIOAAAA AAAAAAAAAAAAABhAAwIOAAAAAQAAAAAAAAAAABhAAwIOAAAAAgAAAAAAAAAAABhAAwIOAAAAAwAA AAAAAAAAABhAAwIOAAAABAAAAAAAAAAAABhAAwIOAAAABQAAAAAAAAAAABhAAwIOAAAABgAAAAAA AAAAABhAAwIOAAAABwAAAAAAAAAAABhAAwIOAAEAAAAAAAAAAAAAAChAAwIOAAEAAQAAAAAAAAAA AChAAwIOAAEAAgAAAAAAAAAAAChAAwIOAAEAAwAAAAAAAAAAAChAAwIOAAEABAAAAAAAAAAAAChA AwIOAAEABQAAAAAAAAAAAChAAwIOAAEABgAAAAAAAAAAAChAAwIOAAEABwAAAAAAAAAAAChAAwIO AAIAAAAAAAAAAAAAADhAAwIOAAIAAQAAAAAAAAAAADhAAwIOAAIAAgAAAAAAAAAAADhAAwIOAAIA AwAAAAAAAAAAADhAAwIOAAIABAAAAAAAAAAAADhAAwIOAAIABQAAAAAAAAAAADhAAwIOAAIABgAA AAAAAAAAADhAAwIOAAIABwAAAAAAAAAAADhAAwIOAAMAAAAAAAAAAAAAAEhAAwIOAAMAAQAAAAAA AAAAAEhAAwIOAAMAAgAAAAAAAAAAAEhAAwIOAAMAAwAAAAAAAAAAAEhAAwIOAAMABAAAAAAAAAAA AEhAAwIOAAMABQAAAAAAAAAAAEhAAwIOAAMABgAAAAAAAAAAAEhAAwIOAAMABwAAAAAAAAAAAEhA AwIOAAQAAAAAAAAAAAAAAFhAAwIOAAQAAQAAAAAAAAAAAFhAAwIOAAQAAgAAAAAAAAAAAFhAAwIO AAQAAwAAAAAAAAAAAFhAAwIOAAQABAAAAAAAAAAAAFhAAwIOAAQABQAAAAAAAAAAAFhAAwIOAAQA BgAAAAAAAAAAAFhAAwIOAAQABwAAAAAAAAAAAFhAAwIOAAUAAAAAAAAAAAAAAGhAAwIOAAUAAQAA AAAAAAAAAGhAAwIOAAUAAgAAAAAAAAAAAGhAAwIOAAUAAwAAAAAAAAAAAGhAAwIOAAUABAAAAAAA AAAAAGhAAwIOAAUABQAAAAAAAAAAAGhAAwIOAAUABgAAAAAAAAAAAGhAAwIOAAUABwAAAAAAAAAA AGhAAwIOAAYAAAAAAAAAAAAAAHhAAwIOAAYAAQAAAAAAAAAAAHhAAwIOAAYAAgAAAAAAAAAAAHhA AwIOAAYAAwAAAAAAAAAAAHhAAwIOAAYABAAAAAAAAAAAAHhAAwIOAAYABQAAAAAAAAAAAHhAAwIO AAYABgAAAAAAAAAAAHhAAwIOAAYABwAAAAAAAAAAAHhAAwIOAAcAAAAAAAAAAAAAAIhAAwIOAAcA AQAAAAAAAAAAAIhAAwIOAAcAAgAAAAAAAAAAAIhAAwIOAAcAAwAAAAAAAAAAAIhAAwIOAAcABAAA AAAAAAAAAIhAAwIOAAcABQAAAAAAAAAAAIhAAwIOAAcABgAAAAAAAAAAAIhAAwIOAAcABwAAAAAA AAAAAIhAAwIOAAgAAAAAAAAAAAAAAJhAAwIOAAgAAQAAAAAAAAAAAJhAAwIOAAgAAgAAAAAAAAAA AJhAAwIOAAgAAwAAAAAAAAAAAJhAAwIOAAgABAAAAAAAAAAAAJhAAwIOAAgABQAAAAAAAAAAAJhA AwIOAAgABgAAAAAAAAAAAJhAAwIOAAgABwAAAAAAAAAAAJhAZRACAAEAAwIOAAAAAAAAAPMf0m9f B84/AwIOAAAAAQAAABnnb0IhAs4/AwIOAAAAAgAAAPMf0m9fB84/AwIOAAAAAwAAAPtXVpqUgs4/ AwIOAAAABAAAAGEaho+IKdE/AwIOAAAABQAAAC1b64uEttQ/AwIOAAAABgAAAJtyhXe5iPM/AwIO AAAABwAAAAU0ETY8vQdAAwIOAAEAAAAAADLmriXkg74/AwIOAAEAAQAAAI4ev7fpz74/AwIOAAEA AgAAALCsNCkF3b4/AwIOAAEAAwAAAO/hkuNO6cA/AwIOAAEABAAAAGEyVTAqqcM/AwIOAAEABQAA ANWVz/I8uMs/AwIOAAEABgAAABo09E9wseo/AwIOAAEABwAAALG/7J48LAJAAwIOAAIAAAAAAEP/ BBcrarA/AwIOAAIAAQAAAKA3FakwtrA/AwIOAAIAAgAAAOeMKO0NvrA/AwIOAAIAAwAAALH5uDZU jLM/AwIOAAIABAAAAMvz4O6s3bY/AwIOAAIABQAAAKBU+3Q8ZsA/AwIOAAIABgAAAMjNcAM+P+A/ AwIOAAIABwAAAPbuj/eqlfk/AwIOAAMAAAAAAFgczvxqDqA/AwIOAAMAAQAAAILix5i7lqA/AwIO AAMAAgAAAMX+snvysKA/AwIOAAMAAwAAAJzc71AU6KM/AwIOAAMABAAAAF/v/nivWqk/AwIOAAMA BQAAALml1ZC4x7I/AwIOAAMABgAAACTusfShC9I/AwIOAAMABwAAAF+YTBWMSvA/AwIOAAQAAAAA AC9uowG8BZI/AwIOAAQAAQAAACv7rgj+t5I/AwIOAAQAAgAAAN9sc2N6wpI/AwIOAAQAAwAAAMe6 uI0G8JY/AwIOAAQABAAAAPuWOV0WE5s/AwIOAAQABQAAAP3ZjxSRYaU/AwIOAAQABgAAAECk374O nMM/AwIOAAQABwAAAJ8CYDyDhuI/AwIOAAUAAAAAADZZox6i0X0/AwIOAAUAAQAAACrj32dcOIA/ AwIOAAUAAgAAAPyp8dJNYoA/AwIOAAUAAwAAAJzc71AU6IM/AwIOAAUABAAAABAGnnsPl4w/AwIO AAUABQAAAOmayTfb3Jg/AwIOAAUABgAAADBMpgpGJbU/AwIOAAUABwAAANFcp5GWytM/AwIOAAYA AAAAANeGinH+JnQ/AwIOAAYAAQAAAB+i0R3EznQ/AwIOAAYAAgAAAB+i0R3EznQ/AwIOAAYAAwAA APp+arx0k3g/AwIOAAYABAAAAI5AvK5fsHs/AwIOAAYABQAAAF8HzhlR2os/AwIOAAYABgAAAO31 7o/3qqU/AwIOAAYABwAAAM/3U+Olm8Q/AwIOAAcAAAAAACECDqFKzV4/AwIOAAcAAQAAAGkdVU0Q dV8/AwIOAAcAAgAAAGkdVU0QdV8/AwIOAAcAAwAAAHaJ6q2BrWI/AwIOAAcABAAAABjshm2LMms/ AwIOAAcABQAAAMAEbt3NU30/AwIOAAcABgAAAPFo44i1+JQ/AwIOAAcABwAAAFVNEHUfgLQ/AwIO AAgAAAAAAGkdVU0QdU8/AwIOAAgAAQAAAGkdVU0QdU8/AwIOAAgAAgAAAGkdVU0QdU8/AwIOAAgA AwAAABoXDoRkAVM/AwIOAAgABAAAAPFo44i1+FQ/AwIOAAgABQAAAC9uowG8BXI/AwIOAAgABgAA AICfceFASIY/AwIOAAgABwAAAH+HokCfyKM/ZRACAAMAPgIKAAgABwAAAH+HokCgAAQAEwAUAAoA AAAJCBAAAAYQANMQzAdJAAAABgAAAAsCHAAAAAAAAAAAAE8AAAA2TgAAwWAAAIt1AACTeAAADQAC AAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEA gAAIAAAAAAAAAAAAJQIEAAAA/wCBAAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAAE0AfgEAAEgAUAAg AEwAYQBzAGUAcgBKAGUAdAAgADYAUAAvADYATQBQACAALQAgAEUAbgBoAGEAbgBjAGUAZAAAAAAA AAAABEQA1ACoAAMPAAABAAEA9gT4AgAAAQAHAPz/AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQAAAA/J85kAAAEAAQABAAAAAAAA AAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAuAKMFAAAAAAAA AP8AAgAAAAECAFgCAAAAAQIAAwAAAAAAAAAADgD4AvYEAACHAAAAAAIABACvBAcAAACwBAEAAACx BAIAAAC1BAQAAAAAAAAAAAAAAAAAAAAAAAAAAQAAACkAoQAiAAEAZAABAAEAAQACAPz/AAAAAAAA AADgPwAAAAAAAOA/AQBVAAIACAB9AAwAAAAAAJIOHgACAAIAfQAMAAEAAQCSCRkAAgACAH0ADAAC AAIASQcZAAYAAgB9AAwAAwADANsIGQAGAAIAfQAMAAQABABJBxkABgACAH0ADAAFAAUAkggZAAYA AgB9AAwABgAGACQJGQAEAAIAfQAMAAcACABtDRkABgACAH0ADAAJAAkAkggZAAYAAgB9AAwACgAK ACQJGQAAAAIAfQAMAAsACwBtDRkABgACAH0ADAAMAAwAJAkZAAAAAgB9AAwADQANAG0NGQAGAAIA kAAUAAEABgYAAFJvdyA0OABSb3cgMzgAAAIOAAAAAABPAAAAAAAOAAAACAIQAAAAAAAOAP8AAABU MIABFgAIAhAAAgAAAA4A/wAAAGIAAAECAAgCEAADAAAADgD/AAAAAAAAAWIACAIQAAQAAAAOAP8A AAD3vwAB948IAhAABQAAAA4A/wAAAOCBAAECAAgCEAAHAAAADgD/AAAAAACAARYACAIQAAkAAAAO AP8AAAAAAIABFwAIAhAACgAAAA4A/wAAAGIAAAECAAgCEAALAAAADgD/AAAAAAAAAWIACAIQAAwA AAAOAP8AAAAAAAABAAAIAhAADQAAAA4A/wAAAGIAAAEAAAgCEAAOAAAADgD/AAAAAAAAAQAACAIQ AA8AAAAOAP8AAAAAAAABYgAIAhAAEAAAAA4A/wAAAFQwAAEAAAgCEAARAAAADgD/AAAAAAAAARAA CAIQABIAAAAOAP8AAADMNQABYgAIAhAAEwAAAA4A/wAAAI8BgAEVAAgCEAAUAAAADgD/AAAAvwGA ARUACAIQABUAAAAOAP8AAABiAIABFgAIAhAAFgAAAA4A/wAAAJ0wAAEAAAgCEAAXAAAADgD/AAAA AACAARfACAIQABgAAAAOAP8AAAD3vwAB/I8IAhAAGQAAAA4A/wAAAP//AAH3jwgCEAAaAAAADgD/ AAAAyQEAAQAACAIQABsAAAAOAP8AAAB5wQABLc4IAhAAHAAAAA4A/wAAAAAAAAFkAAgCEAAdAAAA DgD/AAAAAAAAAWIACAIQAB4AAAAOAP8AAAD8vwAB948IAhAAHwAAAA4A/wAAAGIAAAH3j/0ACgAA AAAAHQAAAAAAvgAgAAAAAQAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYAA0A/QAKAAIAAAAeAAEA AAB+AgoAAgABACIAAGrYQP0ACgADAAAAHgACAAAAfgIKAAMAAQAZAAAAFED9AAoABAAAAB4AAwAA AH4CCgAEAAEAGQAAAOA//QAKAAUAAAAeAAQAAAB+AgoABQABABkAAADwP/0ACgAHAAAAHQAFAAAA vgAgAAcAAQAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYAA0A/QAKAAkAAAAfAAYAAAD9AAoACQAB ACEAEAAAAP0ACgAJAAIAIQATAAAA/QAKAAkAAwAhAA4AAAD9AAoACQAEACEAEgAAAP0ACgAJAAUA IQAHAAAA/QAKAAkABgAhAAwAAAD9AAoACQAHACEACQAAAP0ACgAJAAgAIQAPAAAAvQA8AAoAAAAe AAAAGEAiAADptkAiAADltkAiAADptkAiAABHt0AiAAAwukAiAACbv0AiAIDO3UAiAJAc8kAIAL4A EAAKAAkADwAPAA8ADwAPAA0AvQA8AAsAAAAeAAAAKEAiAABIp0AiAACCp0AiAACMp0AiAADOqUAi AAAArkAiAAAmtUAiAIBd1EAiAMC660AIAL4AEAALAAkADwAPAA8ADwAPAA0AvQA8AAwAAAAeAAAA OEAiAAAMmUAiAACAmUAiAACMmUAiAADUnUAiAAByoUAiAAAGqUAiAIDKyEAiAACF40AIAL4AEAAM AAkADwAPAA8ADwAPAA0AvQA8AA0AAAAeAAAASEAiAACAiEAiAABQiUAiAAB4iUAiAABgjkAiAABY k0AiAAConEAiAACJu0AiAMDb2EAIAL4AEAANAAkADwAPAA8ADwAPAA0AvQA8AA4AAAAeAAAAWEAi AACAe0AiAACQfEAiAACgfEAiAACAgUAiAACohEAiAABQkEAiAADsrUAiAIBEzEAIAL4AEAAOAAkA DwAPAA8ADwAPAA0AvQA8AA8AAAAeAAAAaEAiAADAZkAiAADAaEAiAAAAaUAiAABgbkAiAADQdUAi AAD4gkAiAAAioEAiAAAzvkAIAL4AEAAPAAkADwAPAA8ADwAPAA0AvQA8ABAAAAAeAAAAeEAiAADA XkAiAADAX0AiAADAX0AiAADAYkAiAAAgZUAiAABAdUAiAACIkEAiAAByr0AIAL4AEAAQAAkADwAP AA8ADwAPAA0AvQA8ABEAAAAeAAAAiEAiAACAR0AiAAAASEAiAAAASEAiAACATEAiAADAVEAiAABg ZkAiAAAAgEAiAABIn0AIAL4AEAARAAkADwAPAA8ADwAPAA0AvQA8ABIAAAAeAAAAmEAiAAAAOEAi AAAAOEAiAAAAOEAiAAAAPUAiAAAAQEAiAACAW0AiAAAAcUAiAAAwjkAIAL4AEAASAAkADwAPAA8A DwAPAA0A/QAKABMAAAAgAB0AAAAGABsAEwABACMAAAAAAACIx0AIABMABP8FAAETAAEAvAQXABMA EwABCAAHDQAt9////wDAAMAZEAQABgAbABMAAgAjAAAAAAAAw8dACAATAAX/BQABEwABAAYAGwAT AAMAIwAAAAAAAM3HQAgAEwAI/wUAARMAAQAGABsAEwAEACMAAAAAAAC/yUAIABMAAv8FAAETAAEA BgAjABMABQAjAAAAAACA5s1AAAATAAL9DQAlCgASAAXABcAZEAQABgAbABMABgAjAAAAAACAVdRA CAATAAP/BQABEwABAAYAGwATAAcAIwAAAAAAcEDzQAgAEwAG/wUAARMAAQAGABsAEwAIACMAAAAA ABiKC0EIABMAAf8FAAETAAEAvgAYABQAAAAgACMAIwAjACMAIwAjACMAIwAIAP0ACgAVAAAAHQAf AAAAvgAWABUAAQAYABgAGAAYABgAGAAYABgACAC+ABAAFgAJAA8ADwAPAA8ADwANAP0ACgAXAAAA HwAGAAAA/QAKABcAAQAhABAAAAD9AAoAFwACACEAEwAAAP0ACgAXAAMAIQAOAAAA/QAKABcABAAh ABIAAAD9AAoAFwAFACEABwAAAP0ACgAXAAYAIQAMAAAA/QAKABcABwAhAAkAAAD9AAoAFwAIACEA DwAAAH4CCgAYAAAAHgAAABhABgAbABgAAQAmAPMf0m9fB84/CAAYAAL+BQABGAABALwEFQAYABgA AQgACAsATPL/AMBEAgABAAYGABsAGAACACYAGedvQiECzj8IABgAA/8FAAEYAAEABgAbABgAAwAm APMf0m9fB84/CAAYAAT/BQABGAABAAYAGwAYAAQAJgD7V1aalILOPwgAGAAF/wUAARgAAQAGABsA GAAFACYAYRqGj4gp0T8IABgABv8FAAEYAAEABgAbABgABgAmAC1b64uEttQ/CAAYAAf/BQABGAAB AAYAGwAYAAcAJgCbcoV3uYjzPwgAGAAI/wUAARgAAQAGABsAGAAIACYABTQRNjy9B0AIABkAAf8F AAEYAAEAvgAQABgACQAPAA8ADwAPAA8ADQB+AgoAGQAAAB4AAAAoQAYAGwAZAAEAJgAy5q4l5IO+ PwgAGQAC/wUAARkAAQC8BBUAGQAgAAEIAEALAEzy/wDARAIAAQAGBgAbABkAAgAmAI4ev7fpz74/ CAAZAAP/BQABGQABAAYAGwAZAAMAJgCwrDQpBd2+PwgAGQAE/wUAARkAAQAGABsAGQAEACYA7+GS 407pwD8IABkABf8FAAEZAAEABgAbABkABQAmAGEyVTAqqcM/CAAZAAb/BQABGQABAAYAGwAZAAYA JgDVlc/yPLjLPwgAGQAH/wUAARkAAQAGABsAGQAHACYAGjT0T3Cx6j8IABkACP8FAAEZAAEABgAb ABkACAAmALG/7J48LAJACAAaAAH/BQABGQABAL4AEAAZAAkADwAPAA8ADwAPAA0AfgIKABoAAAAe AAAAOEAGABsAGgABACYAQ/8EFytqsD8IABoAAv8FAAEZAAEABgAbABoAAgAmAKA3FakwtrA/CAAa AAP/BQABGQABAAYAGwAaAAMAJgDnjCjtDb6wPwgAGgAE/wUAARkAAQAGABsAGgAEACYAsfm4NlSM sz8IABoABf8FAAEZAAEABgAbABoABQAmAMvz4O6s3bY/CAAaAAb/BQABGQABAAYAGwAaAAYAJgCg VPt0PGbAPwgAGgAH/wUAARkAAQAGABsAGgAHACYAyM1wAz4/4D8IABoACP8FAAEZAAEABgAbABoA CAAmAPbuj/eqlfk/CAAbAAH/BQABGQABAL4AEAAaAAkADwAPAA8ADwAPAA0AfgIKABsAAAAeAAAA SEAGABsAGwABACYAWBzO/GoOoD8IABsAAv8FAAEZAAEABgAbABsAAgAmAILix5i7lqA/CAAbAAP/ BQABGQABAAYAGwAbAAMAJgDF/rJ78rCgPwgAGwAE/wUAARkAAQAGABsAGwAEACYAnNzvUBTooz8I ABsABf8FAAEZAAEABgAbABsABQAmAF/v/nivWqk/CAAbAAb/BQABGQABAAYAGwAbAAYAJgC5pdWQ uMeyPwgAGwAH/wUAARkAAQAGABsAGwAHACYAJO6x9KEL0j8IABsACP8FAAEZAAEABgAbABsACAAm AF+YTBWMSvA/CAAcAAH/BQABGQABAL4AEAAbAAkADwAPAA8ADwAPAA0AfgIKABwAAAAeAAAAWEAG ABsAHAABACYAL26jAbwFkj8IABwAAv8FAAEZAAEABgAbABwAAgAmACv7rgj+t5I/CAAcAAP/BQAB GQABAAYAGwAcAAMAJgDfbHNjesKSPwgAHAAE/wUAARkAAQAGABsAHAAEACYAx7q4jQbwlj8IABwA Bf8FAAEZAAEABgAbABwABQAmAPuWOV0WE5s/CAAcAAb/BQABGQABAAYAGwAcAAYAJgD92Y8UkWGl PwgAHAAH/wUAARkAAQAGABsAHAAHACYAQKTfvg6cwz8IABwACP8FAAEZAAEABgAbABwACAAmAJ8C YDyDhuI/CAAdAAH/BQABGQABAL4AEAAcAAkADwAPAA8ADwAPAA0AfgIKAB0AAAAeAAAAaEAGABsA HQABACYANlmjHqLRfT8IAB0AAv8FAAEZAAEABgAbAB0AAgAmACrj32dcOIA/CAAdAAP/BQABGQAB AAYAGwAdAAMAJgD8qfHSTWKAPwgAHQAE/wUAARkAAQAGABsAHQAEACYAnNzvUBTogz8IAB0ABf8F AAEZAAEABgAbAB0ABQAmABAGnnsPl4w/CAAdAAb/BQABGQABAAYAGwAdAAYAJgDpmsk329yYPwgA HQAH/wUAARkAAQAGABsAHQAHACYAMEymCkYltT8IAB0ACP8FAAEZAAEABgAbAB0ACAAmANFcp5GW ytM/CAAeAAH/BQABGQABAL4AEAAdAAkADwAPAA8ADwAPAA0AfgIKAB4AAAAeAAAAeEAGABsAHgAB ACYA14aKcf4mdD8IAB4AAv8FAAEZAAEABgAbAB4AAgAmAB+i0R3EznQ/CAAeAAP/BQABGQABAAYA GwAeAAMAJgAfotEdxM50PwgAHgAE/wUAARkAAQAGABsAHgAEACYA+n5qvHSTeD8IAB4ABf8FAAEZ AAEABgAbAB4ABQAmAI5AvK5fsHs/CAAeAAb/BQABGQABAAYAGwAeAAYAJgBfB84ZUdqLPwgAHgAH /wUAARkAAQAGABsAHgAHACYA7fXuj/eqpT8IAB4ACP8FAAEZAAEABgAbAB4ACAAmAM/3U+Olm8Q/ CAAfAAH/BQABGQABAL4AEAAeAAkADwAPAA8ADwAPAA0AfgIKAB8AAAAeAAAAiEAGABsAHwABACYA IQIOoUrNXj8IAB8AAv8FAAEZAAEABgAbAB8AAgAmAGkdVU0QdV8/CAAfAAP/BQABGQABAAYAGwAf AAMAJgBpHVVNEHVfPwgAHwAE/wUAARkAAQAGABsAHwAEACYAdonqrYGtYj8IAB8ABf8FAAEZAAEA BgAbAB8ABQAmABjshm2LMms/CAAfAAb/BQABGQABAAYAGwAfAAYAJgDABG7dzVN9PwgAHwAH/wUA ARkAAQAGABsAHwAHACYA8WjjiLX4lD8IAB8ACP8FAAEZAAEABgAbAB8ACAAmAFVNEHUfgLQ/CAAg AAH/BQABGQABAL4AEAAfAAkADwAPAA8ADwAPAA0A1wA+AIsRAAAwAjIAHAAcABwAHAAyAH4AVABU AFQAVABUAFQAVABUAFQAKQEcACgAFAB+ADMBMwEaARoBGgEaARoBCAIQACAAAAAOAP8AAABUMAAB FgAIAhAAIQAAAA4A/wAAAGIAgAEVAAgCEAAiAAAADgD/AAAAAACAARUACAIQACMAAAAOAP8AAAD3 v4ABFoAIAhAAJAAAAA4A/wAAAOCBAAECAAgCEAAlAAAADgD/AAAAAACAARcACAIQACYAAAAOAP8A AAAAAAABFwAIAhAAJwAAAA4A/wAAAGIAAAECAAgCEAAoAAAADgD/AAAAAAAAAWIACAIQACkAAAAO AP8AAAAAAAABAAAIAhAAKgAAAA4A/wAAAGIAAAEAAAgCEAArAAAADgD/AAAAAAAAAQAACAIQACwA AAAOAP8AAAAAAAABYgAIAhAALQAAAA4A/wAAAFQwAAEAAAgCEAAuAAAADgD/AAAAAAAAARAACAIQ AC8AAAAOAP8AAADMNYABFQAIAhAAMAAAAA4A/wAAAI8BAAEVAAgCEAAxAAAADgD/AAAAvwGAARYA CAIQADIAAAAOAP8AAABiAAABFgAIAhAAMwAAAA4A/wAAAJ0wgAEXAAgCEAA0AAAADgD/AAAAAAAA ARfACAIQADUAAAAOAP8AAAD3vwAB/I8IAhAANgAAAA4A/wAAAP//AAH3jwgCEAA3AAAADgD/AAAA yQEAAQAACAIQADgAAAAOAP8AAAB5wQABLc4IAhAAOQAAAA4A/wAAAAAAAAFkAAgCEAA6AAAADgD/ AAAAAAAAAWIACAIQADsAAAAOAP8AAAD8vwAB948IAhAAPAAAAA4A/wAAAGIAAAH3jwgCEAA9AAAA DgD/AAAA/L+AARWACAIQAD8AAAAOAP8AAAAt3oABFgB+AgoAIAAAAB4AAACYQAYAGwAgAAEAJgBp HVVNEHVPPwgAIAAC/wUAARkAAQAGABsAIAACACYAaR1VTRB1Tz8IACAAA/8FAAEZAAEABgAbACAA AwAmAGkdVU0QdU8/CAAgAAT/BQABGQABAAYAGwAgAAQAJgAaFw6EZAFTPwgAIAAF/wUAARkAAQAG ABsAIAAFACYA8WjjiLX4VD8IACAABv8FAAEZAAEABgAbACAABgAmAC9uowG8BXI/CAAgAAf/BQAB GQABAAYAGwAgAAcAJgCAn3HhQEiGPwgAIAAI/wUAARkAAQAGABsAIAAIACYAf4eiQJ/Ioz8IACEA CP8FAAEZAAEAvgAQACAACQAPAA8ADwAPAA8ADQD9AAoAIQAAACAAHQAAAAYAGwAhAAEAJQDWc9L7 xtfePwgAPQAH/wUAASEAAQC8BBcAIQAhAAEIAAgNAC33////AMAAwBkQBAAGABsAIQACACUAaDo7 GRwl3z8IACEAAf8FAAEhAAEABgAbACEAAwAlAIvIsIo3Mt8/CAAhAAL/BQABIQABAAYAGwAhAAQA JQBVt3pOet/gPwgAIQAD/wUAASEAAQAGABsAIQAFACUAKR2s/3OY4z8IACEABP8FAAEhAAEABgAb ACEABgAlAGTCL/Xzpuo/CAAhAAX/BQABIQABAAYAGwAhAAcAJQB6WKg1zTsJQAgAIQAG/wUAASEA AQAGABsAIQAIACUA6lvmdFkMIkAIACEAB/8FAAEhAAEAvgAYACIAAAAgACUAJQAlACUAJQAlACUA JQAIAP0ACgAjAAAAHQAeAAAAvgAWACMAAQAnACcAJwAnACcAJwAnACcACAC+ABAAJAAJAA8ADwAP AA8ADwANAP0ACgAlAAAAHwAGAAAA/QAKACUAAQAaABAAAAD9AAoAJQACABoAEwAAAP0ACgAlAAMA GgAOAAAA/QAKACUABAAaABIAAAD9AAoAJQAFABoABwAAAP0ACgAlAAYAGgAMAAAA/QAKACUABwAa AAkAAAD9AAoAJQAIABoADwAAAH4CCgAmAAAAHgAAABhAAwIOACYAAQAkAPMf0m9fB84/AwIOACYA AgAkAOJYF7fRAM4/AwIOACYAAwAkAPMf0m9fB84/AwIOACYABAAkAFafq63YX84/AwIOACYABQAk AHxhMlUwKtE/AwIOACYABgAkABIUP8bctdQ/AwIOACYABwAkANk9eVioNec/fgIKACYACAAkAAFg VUC+ABAAJgAJAA8ADwAPAA8ADwANAH4CCgAnAAAAHgAAAChAAwIOACcAAQAkADLmriXkg74/AwIO ACcAAgAkAPs6cM6I0r4/AwIOACcAAwAkAB3J5T+k374/AwIOACcABAAkAHRGlPYGX8A/AwIOACcA BQAkAGEyVTAqqcM/AwIOACcABgAkAAskKH6Mucs/AwIOACcABwAkABueXinLEOM/AwIOACcACAAk ALfRAN4CCeo/vgAQACcACQAPAA8ADwAPAA8ADQB+AgoAKAAAAB4AAAA4QAMCDgAoAAEAJAANcayL 22iwPwMCDgAoAAIAJADWxW00gLewPwMCDgAoAAMAJADnjCjtDb6wPwMCDgAoAAQAJABq3nGKjuSy PwMCDgAoAAUAJACVZYhjXdy2PwMCDgAoAAYAJACEDU+vlGXAPwMCDgAoAAcAJACeXinLEMfaPwMC DgAoAAgAJADo2az6XG3nP74AEAAoAAkADwAPAA8ADwAPAA0AfgIKACkAAAAeAAAASEADAg4AKQAB ACQAMlUwKqkToD8DAg4AKQACACQAguLHmLuWoD8DAg4AKQADACQAxf6ye/KwoD8DAg4AKQAEACQA 8BZIUPwYoz8DAg4AKQAFACQA8tJNYhBYqT8DAg4AKQAGACQAJ8KGp1fKsj8DAg4AKQAHACQAMCqp E9BE0D8DAg4AKQAIACQA6gQ0ETY84z++ABAAKQAJAA8ADwAPAA8ADwANAH4CCgAqAAAAHgAAAFhA AwIOACoAAQAkAC9uowG8BZI/AwIOACoAAgAkAAU0ETY8vZI/AwIOACoAAwAkAAU0ETY8vZI/AwIO ACoABAAkALpJDAIrh5Y/AwIOACoABQAkAEYldQKaCJs/AwIOACoABgAkANcS8kHPZqU/AwIOACoA BwAkANUJaCJseMI/AwIOACoACAAkAN0kBoGVQ9s/vgAQACoACQAPAA8ADwAPAA8ADQB+AgoAKwAA AB4AAABoQAMCDgArAAEAJACfPCzUmuZ9PwMCDgArAAIAJAB2cRsN4C2APwMCDgArAAMAJAD8qfHS TWKAPwMCDgArAAQAJABhMlUwKqmDPwMCDgArAAUAJAB56SYxCKyMPwMCDgArAAYAJADD0ytlGeKY PwMCDgArAAcAJACcoiO5/Ie0P34CCgArAAgAJAABQDpAvgAQACsACQAPAA8ADwAPAA8ADQB+AgoA LAAAAB4AAAB4QAMCDgAsAAEAJABuowG8BRJ0PwMCDgAsAAIAJACIhVrTvON0PwMCDgAsAAMAJACI hVrTvON0PwMCDgAsAAQAJAD6fmq8dJN4PwMCDgAsAAUAJABfB84ZUdp7PwMCDgAsAAYAJABfB84Z UdqLPwMCDgAsAAcAJAD5oGez6nOlPwMCDgAsAAgAJACNl24Sg8DCP74AEAAsAAkADwAPAA8ADwAP AA0AfgIKAC0AAAAeAAAAiEADAg4ALQABACQAxY8xdy0hXz8DAg4ALQACACQAxY8xdy0hXz8DAg4A LQADACQAxY8xdy0hXz8DAg4ALQAEACQASFD8GHPXYj8DAg4ALQAFACQARiV1ApoIaz8DAg4ALQAG ACQAkst/SL99fT8DAg4ALQAHACQAiIVa07zjlD8DAg4ALQAIACQAHhZqTfOOsz++ABAALQAJAA8A DwAPAA8ADwANAH4CCgAuAAAAHgAAAJhAAwIOAC4AAQAkAPyp8dJNYlA/AwIOAC4AAgAkAPyp8dJN YlA/AwIOAC4AAwAkAPyp8dJNYlA/AwIOAC4ABAAkAGEyVTAqqVM/AwIOAC4ABQAkAJT2Bl+YTFU/ AwIOAC4ABgAkAC9uowG8BXI/AwIOAC4ABwAkAK7YX3ZPHoY/AwIOAC4ACAAkAP2H9NvXgaM/vgAQ AC4ACQAPAA8ADwAPAA8ADQD9AAoALwAAACAAHQAAAAYAGwAvAAEAJQAMAiuHFtnePwgALwAE/wUA AS8AAQC8BBcALwAvAAEIAAcNAC33////AMAAwBkQAAAGABsALwACACUAEqW9wRcm3z8IAC8ABf8F AAEvAAEABgAbAC8AAwAlADQzMzMzM98/CAAvAAj/BQABLwABAAYAGwAvAAQAJQCuad5xio7gPwgA LwAC/wUAAS8AAQAGACMALwAFACUAt0CC4seY4z8AABMAB/8NACUmAC4ABcAFwBkQAAAGABsALwAG ACUADS2yne+n6j8IAC8AA/8FAAEvAAEABgAbAC8ABwAlADGZKhiVVAJACAAvAAb/BQABLwABAAYA GwAvAAgAJQB6eqUsQ5wPQAgALwAB/wUAAS8AAQC+AA4AMAAKAA8ADwAPAA8ADQD9AAoAMQAAAB0A FAAAAL4AGAAxAAEAGAAYABgAGAAYABgAGAAYABgACQC+AA4AMgAKAA8ADwAPAA8ADQD9AAoAMwAA AB8ABgAAAP0ACgAzAAEAGgAQAAAA/QAKADMAAgAaABMAAAD9AAoAMwADABoADgAAAP0ACgAzAAQA GgASAAAA/QAKADMABQAaAAcAAAD9AAoAMwAGABoADwAAAP0ACgAzAAcAGgAMAAAAfgIKADQAAAAe AAAAGEADAg4ANAABACQA8x/Sb18Hzj8DAg4ANAACACQA4lgXt9EAzj8DAg4ANAADACQA8x/Sb18H zj8DAg4ANAAEACQAaJHtfD81zj8DAg4ANAAFACQAfGEyVTAq0T8DAg4ANAAGACQA/mX35GGh0j8D Ag4ANAAHACQAEhQ/xty11D++ABIANAAIAA8ADwAPAA8ADwAPAA0AfgIKADUAAAAeAAAAKEADAg4A NQABACQAMuauJeSDvj8DAg4ANQACACQA+zpwzojSvj8DAg4ANQADACQAHcnlP6Tfvj8DAg4ANQAE ACQAFR3J5T+kvz8DAg4ANQAFACQAYTJVMCqpwz8DAg4ANQAGACQARGlv8IXJxD8DAg4ANQAHACQA CyQofoy5yz++ABIANQAIAA8ADwAPAA8ADwAPAA0AfgIKADYAAAAeAAAAOEADAg4ANgABACQADXGs i9tosD8DAg4ANgACACQA1sVtNIC3sD8DAg4ANgADACQA54wo7Q2+sD8DAg4ANgAEACQA3+ALk6mC sT8DAg4ANgAFACQAlWWIY13ctj8DAg4ANgAGACQA4C2QoPgxtj8DAg4ANgAHACQAhA1Pr5RlwD++ ABIANgAIAA8ADwAPAA8ADwAPAA0AfgIKADcAAAAeAAAASEADAg4ANwABACQAMlUwKqkToD8DAg4A NwACACQAguLHmLuWoD8DAg4ANwADACQAxf6ye/KwoD8DAg4ANwAEACQANxrAWyBBoT8DAg4ANwAF ACQA8tJNYhBYqT8DAg4ANwAGACQAoWez6nO1pT8DAg4ANwAHACQAJ8KGp1fKsj++ABIANwAIAA8A DwAPAA8ADwAPAA0AfgIKADgAAAAeAAAAWEADAg4AOAABACQAL26jAbwFkj8DAg4AOAACACQABTQR Njy9kj8DAg4AOAADACQABTQRNjy9kj8DAg4AOAAEACQAYTJVMCqpkz8DAg4AOAAFACQARiV1ApoI mz8DAg4AOAAGACQA4JwRpb3Blz8DAg4AOAAHACQA1xLyQc9mpT++ABIAOAAIAA8ADwAPAA8ADwAP AA0AfgIKADkAAAAeAAAAaEADAg4AOQABACQAnzws1JrmfT8DAg4AOQACACQAdnEbDeAtgD8DAg4A OQADACQA/Knx0k1igD8DAg4AOQAEACQACRueXinLgD8DAg4AOQAFACQAeekmMQisjD9+AgoAOQAG ACQAAQDwPwMCDgA5AAcAJADD0ytlGeKYP74AEgA5AAgADwAPAA8ADwAPAA8ADQB+AgoAOgAAAB4A AAB4QAMCDgA6AAEAJABuowG8BRJ0PwMCDgA6AAIAJACIhVrTvON0PwMCDgA6AAMAJACIhVrTvON0 PwMCDgA6AAQAJACU9gZfmEx1PwMCDgA6AAUAJABfB84ZUdp7PwMCDgA6AAYAJAATYcPTK2V5PwMC DgA6AAcAJABfB84ZUdqLP74AEgA6AAgADwAPAA8ADwAPAA8ADQB+AgoAOwAAAB4AAACIQAMCDgA7 AAEAJADFjzF3LSFfPwMCDgA7AAIAJADFjzF3LSFfPwMCDgA7AAMAJADFjzF3LSFfPwMCDgA7AAQA JAD8qfHSTWJgPwMCDgA7AAUAJABGJXUCmghrPwMCDgA7AAYAJABhMlUwKqljPwMCDgA7AAcAJACS y39Iv319P74AEgA7AAgADwAPAA8ADwAPAA8ADQB+AgoAPAAAAB4AAACYQAMCDgA8AAEAJAD8qfHS TWJQPwMCDgA8AAIAJAD8qfHSTWJQPwMCDgA8AAMAJAD8qfHSTWJQPwMCDgA8AAQAJAD8qfHSTWJQ PwMCDgA8AAUAJACU9gZfmExVPwMCDgA8AAYAJACU9gZfmExVPwMCDgA8AAcAJAAvbqMBvAVyP74A EgA8AAgADwAPAA8ADwAPAA8ADQD9AAoAPQAAACAAHQAAAAYAGwA9AAEAJQAMAiuHFtnePwgAPQAE /wUAAT0AAQC8BBcAPQA9AAEHAAYNAC33////AMAAwBkQAAAGABsAPQACACUAEqW9wRcm3z8IAD0A Bf8FAAE9AAEABgAbAD0AAwAlADQzMzMzM98/CAA9AAb/BQABPQABAAYAGwA9AAQAJQBOQBNhw9Pf PwgAPQAC/wUAAT0AAQAGACMAPQAFACUAt0CC4seY4z8AAC8AB/8NACU0ADwABcAFwBkQAAAGABsA PQAGACUALm6jAbwF5D8IAD0AAf8FAAE9AAEABgAbAD0ABwAlAA0tsp3vp+o/CAA9AAP/BQABPQAB AP0ACgA/AAAAHQAVAAAAvgAgAD8AAQAYABgAGAAYABgAGAAYABgAGAAYABgAGAAYAA0A1wBCAIgU AABYAhoBIQEcACgAFAB+AK4AsgCyALIAsgCuALIAsgCyACkBEgAqABIAcACiAKIAogCiAKIAngCi AKIAogAKAQgCEABBAAAADgD/AAAAVDCAARcACAIQAEIAAAAOAP8AAABiAAABFQAIAhAAQwAAAA4A /wAAAAAAAAEVAAgCEABEAAAADgD/AAAA978AARaACAIQAEUAAAAOAP8AAADggQABAgAIAhAARgAA AA4A/wAAAAAAAAEXAAgCEABHAAAADgD/AAAAAAAAARcACAIQAEgAAAAOAP8AAABiAAABAgAIAhAA SQAAAA4A/wAAAAAAAAFiAAgCEABKAAAADgD/AAAAAAAAAQAACAIQAEsAAAAOAP8AAABiAAABAAAI AhAATAAAAA4A/wAAAAAAAAEAAAgCEABNAAAADgD/AAAAAAAAAWIACAIQAE4AAAAOAP8AAABUMAAB AAD9AAoAQQAAAB8AFgAAAP0ACgBBAAEAHAAXAAAAvgAeAEEAAgAaABoAGgAaABoAGgAaABoAGgAa ABoAGgANAP0ACgBCAAAAHgAHAAAA/QAKAEIAAQAbABgAAAD9AAoAQwAAAB4ACAAAAP0ACgBDAAEA GwAZAAAA/QAKAEQAAAAeAAkAAAD9AAoARAABABsAGgAAAP0ACgBFAAAAHgAKAAAA/QAKAEUAAQAb ABsAAAD9AAoARgAAAB4ACwAAAP0ACgBGAAEAGwAcAAAA/QAKAEcAAAAeAAwAAAD9AAoARwABABsA GQAAAP0ACgBIAAAAHgANAAAA/QAKAEgAAQAbABsAAAD9AAoASQAAAB4ADgAAAP0ACgBJAAEAGwAZ AAAA/QAKAEoAAAAeAA8AAAD9AAoASgABABsAGgAAAP0ACgBLAAAAHgAQAAAA/QAKAEsAAQAbABkA AAD9AAoATAAAAB4AEQAAAP0ACgBMAAEAGwAaAAAA/QAKAE0AAAAeABIAAAD9AAoATQABABsAGQAA AP0ACgBOAAAAHgATAAAA/QAKAE4AAQAbABkAAADXACAAwgIAAAQBPgAcABwAHAAcABwAHAAcABwA HAAcABwAHAA+AhIAtgYsAAAAQAAAAAAAAAAAAAAAHQAPAAM8AAoAAAABADwAPAAKCgoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAE CgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJwAAAAGAAAAAQAAADgA AAAEAAAAQAAAAAgAAABYAAAAEgAAAHAAAAAMAAAAiAAAABMAAACUAAAAAgAAAOQEAAAeAAAADQAA AE5vcm1hbiBQZXRyeQAAeAAeAAAADQAAAE5vcm1hbiBQZXRyeQAAeAAeAAAAEAAAAE1pY3Jvc29m dCBFeGNlbABAAAAAgGYPu/eAwAEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAA AAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuYAEAABwB AAAJAAAAAQAAAFAAAAAPAAAAWAAAABcAAABkAAAACwAAAGwAAAAQAAAAdAAAABMAAAB8AAAAFgAA AIQAAAANAAAAjAAAAAwAAADgAAAAAgAAAOQEAAAeAAAAAQAAAAAAZwADAAAAahAIAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAQAAAAFAAAARGF0YQAUAAAAVGllYnJlYWtlciBS ZXF1aXJlZAARAAAAT3V0Y29tZSBBZmZlY3RlZAASAAAAQXZlcmFnZSBUaWVicmVha3MADBAAAAQA AAAeAAAACwAAAFdvcmtzaGVldHMAAwAAAAEAAAAeAAAABwAAAENoYXJ0cwADAAAAAwAAAAAAmAAA AAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQE AABBAAAATgAAAHsAOABGADUAOAA4ADMAOABEAC0ARQBDAEIANwAtADEAMQBEADQALQBBADcAMABG AC0AMAAwADUAMABCAEEAOABGADEANABEADAAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAA/v///z4AAAA/ AAAAQAAAAEEAAABCAAAAQwAAAEQAAAD+////RgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAP7/ ///9/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AgAA ACAIAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACgrYzCIoPAAf7///8AAAAAAAAAAFcAbwByAGsA YgBvAG8AawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOR4 AAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACgAAgEBAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA9AAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBm AG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEUAAAAAEAAAAAAAAA== ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="ties551.csv" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ties551.csv" Simulation Parameters:,,,,,,,,,,,,, Trials:,"25,000",,,,,,,,,,,, Options:,5,,,,,,,,,,,, Involvement:,0.5,,,,,,,,,,,, Dimensions:,1,,,,,,,,,,,, Total Tiebreaks:,,,,,,,,,,,,, Voters,Schulze,SSD,Minimax,SD,Plurality,Approval,Instant Runoff,Tideman,,,,= , 6,"5,865","5,861","5,865","5,959","6,704","8,091","30,522","74,185",,,,, 12,"2,980","3,009","3,014","3,303","3,840","5,414","20,854","56,790",,,,, 24,"1,603","1,632","1,635","1,909","2,233","3,203","12,693","39,976",,,,, 48,784,810,815,972,"1,238","1,834","7,049","25,455",,,,, 96,440,457,458,560,661,"1,044","3,830","14,473",,,,, 192,182,198,200,243,349,607,"2,065","7,731",,,,, 384,123,127,127,150,169,340,"1,058","4,025",,,,, 768,47,48,48,57,83,179,512,"2,002",,,,, "1,536",24,24,24,29,32,110,272,966,,,,, Total:,"12,048","12,166","12,186","13,182","15,309","20,822","78,855","225,= 603",,,,, ,,,,,,,,,,,,, Average Tiebreaks/Election:,,,,,,,,,,,,, ,,,,,,,,,,,,, Voters,Schulze,SSD,Minimax,SD,Plurality,Approval,Instant Runoff,Tideman,,,,= , 6,0.2346,0.2344,0.2346,0.2384,0.2682,0.3236,1.2209,2.9674,,,,, 12,0.1192,0.1204,0.1206,0.1321,0.1536,0.2166,0.8342,2.2716,,,,, 24,0.0641,0.0653,0.0654,0.0764,0.0893,0.1281,0.5077,1.5990,,,,, 48,0.0314,0.0324,0.0326,0.0389,0.0495,0.0734,0.2820,1.0182,,,,, 96,0.0176,0.0183,0.0183,0.0224,0.0264,0.0418,0.1532,0.5789,,,,, 192,0.0073,0.0079,0.0080,0.0097,0.0140,0.0243,0.0826,0.3092,,,,, 384,0.0049,0.0051,0.0051,0.0060,0.0068,0.0136,0.0423,0.1610,,,,, 768,0.0019,0.0019,0.0019,0.0023,0.0033,0.0072,0.0205,0.0801,,,,, "1,536",0.0010,0.0010,0.0010,0.0012,0.0013,0.0044,0.0109,0.0386,,,,, Total:,0.4819,0.4866,0.4874,0.5273,0.6124,0.8329,3.1542,9.0241,,,,, ,,,,,,,,,,,,, Elections Requiring Tiebreaker:,,,,,,,,,,,,, ,,,,,,,,,,,,, Voters,Schulze,SSD,Minimax,SD,Plurality,Approval,Instant Runoff,Tideman,,,,= , 6,23.46%,23.44%,23.46%,23.73%,26.82%,32.36%,72.53%,85.50%,,,,, 12,11.92%,12.04%,12.06%,12.79%,15.36%,21.66%,59.58%,81.36%,,,,, 24,6.41%,6.53%,6.54%,7.38%,8.93%,12.81%,41.84%,73.21%,,,,, 48,3.14%,3.24%,3.26%,3.73%,4.95%,7.34%,25.42%,60.11%,,,,, 96,1.76%,1.83%,1.83%,2.20%,2.64%,4.18%,14.43%,42.60%,,,,, 192,0.73%,0.79%,0.80%,0.96%,1.40%,2.43%,8.02%,26.25%,,,,, 384,0.49%,0.51%,0.51%,0.60%,0.68%,1.36%,4.19%,14.65%,,,,, 768,0.19%,0.19%,0.19%,0.23%,0.33%,0.72%,2.04%,7.64%,,,,, "1,536",0.10%,0.10%,0.10%,0.12%,0.13%,0.44%,1.08%,3.81%,,,,, Total:,0.4820,0.4867,0.4875,0.5174,0.6124,0.8330,2.2913,3.9513,,,,, ,,,,,,,,,,,,, Tiebreaker Affects Outcome:,,,,,,,,,,,,, ,,,,,,,,,,,,, Voters,Schulze,SSD,Minimax,SD,Plurality,Tideman,Approval,,,,,, 6,23.46%,23.44%,23.46%,23.60%,26.82%,29.11%,32.36%,,,,,, 12,11.92%,12.04%,12.06%,12.36%,15.36%,16.24%,21.66%,,,,,, 24,6.41%,6.53%,6.54%,6.84%,8.93%,8.67%,12.81%,,,,,, 48,3.14%,3.24%,3.26%,3.37%,4.95%,4.24%,7.34%,,,,,, 96,1.76%,1.83%,1.83%,1.92%,2.64%,2.32%,4.18%,,,,,, 192,0.73%,0.79%,0.80%,0.82%,1.40%,1.00%,2.43%,,,,,, 384,0.49%,0.51%,0.51%,0.52%,0.68%,0.62%,1.36%,,,,,, 768,0.19%,0.19%,0.19%,0.20%,0.33%,0.24%,0.72%,,,,,, "1,536",0.10%,0.10%,0.10%,0.10%,0.13%,0.13%,0.44%,,,,,, Total:,0.4820,0.4867,0.4875,0.4973,0.6124,0.6257,0.8330,,,,,, Election Examples:,,,,,,,,,,,,, Voting Method,Pairwise Matrix,,,,,,,,,,,, Plurality,"[[0, 1, 1, 1, 1], [3, 0, 2, 3, 3], [3, 3, 0, 3, 3], [0, 1, 1, 0,= 0], [2, 2, 1, 3, 0]]",,,,,,,,,,,, Runoff,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, 1]= , [5, 3, 5, 5, 0]]",,,,,,,,,,,, Instant Runoff,"[[0, 2, 1, 1, 1], [3, 0, 3, 3, 3], [1, 2, 0, 2, 2], [1, 2, = 0, 0, 2], [3, 2, 3, 3, 0]]",,,,,,,,,,,, Borda,"[[0, 2, 4, 5, 2], [4, 0, 6, 6, 3], [1, 0, 0, 1, 0], [0, 0, 0, 0, 0],= [4, 3, 6, 6, 0]]",,,,,,,,,,,, Bucklin,"[[0, 3, 2, 1, 2], [0, 0, 0, 0, 0], [3, 3, 0, 3, 1], [3, 4, 2, 0, 2= ], [3, 4, 3, 3, 0]]",,,,,,,,,,,, Approval,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, = 1], [5, 3, 5, 5, 0]]",,,,,,,,,,,, Copeland,"[[0, 2, 4, 5, 2], [4, 0, 6, 6, 3], [1, 0, 0, 1, 0], [0, 0, 0, 0, = 0], [4, 3, 6, 6, 0]]",,,,,,,,,,,, Minimax,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, 1= ], [5, 3, 5, 5, 0]]",,,,,,,,,,,, Tideman,"[[0, 2, 1, 1, 1], [3, 0, 3, 3, 3], [1, 2, 0, 2, 2], [1, 2, 0, 0, 2= ], [3, 2, 3, 3, 0]]",,,,,,,,,,,, Schulze,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, 1= ], [5, 3, 5, 5, 0]]",,,,,,,,,,,, Goldfish,"[[0, 2, 1, 1, 1], [3, 0, 3, 3, 3], [1, 2, 0, 2, 2], [1, 2, 0, 0, = 2], [3, 2, 3, 3, 0]]",,,,,,,,,,,, SD,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, 1], [5= , 3, 5, 5, 0]]",,,,,,,,,,,, SSD,"[[0, 0, 2, 3, 1], [3, 0, 3, 3, 3], [4, 3, 0, 4, 1], [1, 1, 1, 0, 1], [= 5, 3, 5, 5, 0]]",,,,,,,,,,,, =0D ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="ties5511.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ties5511.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAAP8AgIAA//+A AACAAID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADKvVWfAAAbNElEQVR4nO3djXabuhJAYTVpe3rD+7/vTfwDkhAgYEAzo/2tdRon tmWieB9hBzthAKBFaL0BAEb0COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGP gB70COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPtwuj75PJ17evefzGFq8d jg2MS/CDuJ2uHgM9asIPoolSABf1uHFtUlSFn0YTrwqeH8L7Q3JqOmN4LXBD/E8YQ5quN+QDFHqM LxreA41nRRvCPaMFZr2JuJaptuRU4Yxxr3O6aPpJNsAw7zG9aIh7TG+eIJtg0puIahkXvZD+E58x nRhXsCm1+HrxUO8zCzVHl1+/edyMSW8i6TF5viU+FS9z8YKZ7k7G15s9dTPrMb9EWn12Cndj0pvY 1+N0ibjPpKjlHpPbpEflmPQm8v3V6WuFIOLVLd5LDeXrDas95l+nR1WY9CbS9XH+AO555vwhXvzQ sfT4MWTZFdbHmseP2TVxGya9iajHcd8z3j99nZudEbcTr4/J48r0uZjs8WP6EPQ9VHTWdG16bIFJ byLucRgLiU4N0RljM/HamDx+DNk1lntMLjp+YUo03irx7xqbmHTzCMcRfpbm0aMj/CzNo0dH+FkC etAjoAc9AnrQI6AHPQJ60COgR+c95kePpV8tnIiOeJkfvJ1/MiRXmd9qcpmlK69u92z0zSGO/nYk u9rsCKADg/OLmrm+pyQ6ZHNW3NLZp3vMrh5dr/oOWt7cxduf3dB+s80tHZFHj6d1PSXTnShbvd5H deYnpossD7n5xeLhobvum+n2bP//4PANLV0t/d/LmXGR6noW8+O4Z1/NT6QXGZKjvKMVYr57OrvR 8X8D0QI8P6w72Z0ubGF59OmKycs1pmulX47nIKSDjiOlGxDid6rMvp/NobK5Kn27Hev9+x/GO0K2 y1fX47uicZct+WS8dGE9ya829pjtJJcHzDciGT2+4jDMRp19Obqt+NN4E7Lbjydj3uP6UOlclb7d nnX+7Q+Fgnb1OGT38Gz5eV9slvt4u+M/hS/N+8m2sDx6cbPiG9pxfnLJbNZK30/tUKVLZ99llzr/ 9tMa3nfw178VPSafxCtEehPR6LP7bymR2anCgMlGhPKo48bPbyhek9IVM//y7h43h4q2vPTt9qzz b3+I7+lnepzvg81vaf6xssd8wMJd11CP43dDj3O9f/vxveBEj+n+WbaipVc/0uPagPPR9/QYj5ht w/xqycTlp5Z6LG9zOl/0+Nb3tz/dl95NxZ/MT2TXW8gpvasP+dXTlSJqOS67HGtpwHT0/J4dog/J qPGXC4tauZb5zKVzUT/U9OX5t9uzrr/9EO1NJftQ4yf5ifGK0YfpKqHwyTC7+nSrQ3pqyG+0OPqQ XyYZfaHH+ajRl99fjf8pbUL6v4T82yn3uDBU/P+g2QV61vW3n5Xx/FL0SeHE+4rRh6Snwn2wdPVp gOgWplZCYfTigOnmDss9zkadvhyNk5+f3shqj+mtbw2Vnp9foGOdf/tzohOyNdjue1/jHxf3lqsx wxl61HvzHWCGU7fmuLtHcvSOKQb0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSg R0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBH QA96BPSgR0APegT0oEdAD3oE9KBHQA96BPTY02MI49+7D9FpAEJ2RBWiy9MicIG9YdEjcJ1jPZIj cIVdZY2PGXn4CFzhxPqYPLfz7X+ABYL5iDv4+DG/avgCbKBHQA8vPUY7qcn+6uN060kGKnnp8X08 QJhOTme1nmSgkpse14ZpPclAJXoE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0 oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSg R0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0oEdAD3oE9KBH QA96BPSgR0APegT0oEdAD3oE9KBHQA96BPSgR0APegT0cNNj+DY/+fy89SQDlbz0GKbLRydf57We ZKCSlx6jy9MjzKJHQA8/PY4PGukRZvnpcSiuj+Gl9TwDNbz3+DjdepKBSvQI6OGlR37fAQ+89Pg+ CCBMJ6ezWk8yUMlNjys+Wk8yUKmHHgNBwoguevwiSNjQR48ECRs66ZEgYUIvPRIkLOimR4KEAf30 SJDQr6MeCRLq9dQjQUK7rnokSCjXV48ECd3oEdCjsx4JEqr11iNBQrPueiRIKNZfjwQJvTrskSCh Vo89EiS06rJHgoRSffZIkNCp0x4JEir12iNBQqNueyRIKNRvjwQJfTrukSChTs89EiS06bpHgoQy ffdIkNCl8x4JEqr03iNBQpPueyRIKEKPBAk96JEgoQc90iP0oMcvgoQa9PiDIKEDPT4QJFSgxyeC hAb0+EKQUIAe3wgS7dHjiCDRHD1OCBKt0WOEINEYPcYIEm3RY4Ig0RQ9pggSLdFjhiDRED3mCBLt 0OMMQaIZepwjSLRCjwUEiUbosYQg0QY9FhEkmqDHMoJEC256DN+ik/FVj/RIkGjBS48hunx+tUM9 EiQa8NJjfHmZHgkS93PY4+xaB3skSNzOY4/Zw8fDPRIk7uapx3h3NXlu59ux2SFI3MtRj2Hpk8Pr I0HiZn56DIufneiRIHErNz2G9JRUjwSJO3npMbyexQlDcmjA87xTM0SQuI+XHleHOTdFBInb0OM2 gsRd6HEbPeIu9FiBIHETeqxBkLgHPVYhSNyCHusQJO5Aj5UIEjdY7zE0obJHgsQNNnqUCWIfpT0S JK5Hj/UIElejxx0IEhejxz0IEteix10IEpcS6DF9TnTldcG1+Zy5cnFAwfkiSFzpfI/5m7r57pEg cSV63IsgcR2pHh+nHrutYXh9ePwXpv3Z7FX7NQNWXX57QNkpI0hcRubx43jhR37vEN8fxk8qx9t3 8xUDCs8ZQeIqMs+vhii2KESnPRIkrlLR469lySWXe3z+k7/N1OqNZqdOEe+RIHERwedzFntc+LMa 2zeqtkeCxDWEe1z6MLjaX/0iSFxD8niAED+x+noXVIfPrz4RJC7A8XJHESTk0eNhBAlx9HgcQUIa PZ5AkBBGj2cQJGTR4ykECVH0eA5BQhI9nkSQEGS1x9cLSeoGvHQGCRJyjPYYwuyvIK8MeO0UEiTE WO3xmWTlgBfPIUFCivDxq+8DVav3JVdvdK3HEKr/d0GPsEL89VbJax4PqdtfDaH6AeTVPRIkpFzW 4/Eg657PqV8er++RICFE8P2sshOX9rjrJq7vkSAhQ/D9rJI3trq6x1D/eso7eiRIiBB8P6vxxD37 q/XPGd3RI0FCQkWP/y0rRHTT48f6owFu6pEgIcDi8zmFv6S8PuA9U0mQOM3i7zuU9kiQOM3o8QD7 BrxrMgkSJxk9Xm7fgLfNJkHiHKs9atxf/SJInGS0R5WPH38QJM6w2uP4tss1A945oQSJE+z2qOf1 HSmCxHFme9TzeuQcQeIwoz0qer+OOYLEUVZ73DXg3ZNKkDiIHq9AkDjGao8hf/uc6OFk/sjy/h4J EscY7XH2fh3RMbOzw2cb9EiQOETu/QGC1J5m7fOr8/MV9UiQOEKgxxB/EECP6JbVHovHy2nqkSBx gMT+anj/G94HzkynxldivUarGLH+ePLyFZMe36+UbDC1BIndxHsc9yRD8tl0oYoB99z8/HpK1keC xH4iz+dMi+M7vSTCcSi5HgvnhOSEhh4JEntV9Phv2esymz2O7yCwXmLe2p4es2up6JEgsdMt66P8 /urs+Zz353H943ntppcgsYvM7x9nFc56DBf3uDpgw/klSOxxS4+vvw0n+fzqHi17JEjsYfR4uX0D Np1hgkQ9qz2q+3sBywgS1Yz2aObx4w+CRC2rPW6cn1649SQTJCoZ7bH2uaHnZVtPMkGiksUetf79 jhUEiSr0eA+CRA2LPe4esPUk/yBIVKDHuxAktlntcfZ+VmsDtp7kJ4LEJqM9zt7PanXA1pP8QpDY Ivj3WE/+GdbCja7+/jHY+f3jG0Fig/TfKxcI0m+PBIkN0j0KBOnueLkIQWKV3Puv3tqjpePJEwSJ NTKPH6ML39TjrgFbT3KMILFC5vnV8e0c6XETQWJZRY+/lyWXvK3Hx686bD5+/EGQWGTx+RzjPRIk Fhn9fce+AVtPco4gscDi8QB7b0RdjwSJBRaPl7PfI0GijB7bIEiUmOzR4OuRZwgSBfTYCkFizmSP ewdsPcllBIkZemyHIJGjx4YIEhmLPe4esPUkLyJIpOixKYJEgh7bIkjE6LExgkRE4Hjy8fjVhRF2 P/2y6+ZrBmw9yasIEhPx11stnbsjn5qbN/j+q0sIEiOjPZp8/9UlBIk32R7D+1QYhnEnNjxPLu7S Lt/oSo979oS190iQeLumxzjN6Ov0uIAg8ST7fE70Ianm9dYBdf3U7q8aP548QZB4qOjx77IkmqzH 8N5LvaJHs++/uoQg8UP2/ZDTZfLC9XEXCz0SJH5c2WO2PlY/3Nt18zUDtp7kKgQJ8b8XMO6kPmqc egy1ow11Pe56RbKNHgkS9x4vd0WPVf/HaD3JlQgSRnvc9RsUKz0SJO7rsf7p0Iqbj3/puT1g60mu RpC9M/r6jnFn1VePBNk7oz0OO3K01CNBds5qj7sGbD3JexBk1+hRG4LsmdUenR2/GiPIjhnt0dvx 5AmC7JfVHutfvmWvR4Lsl90ePb3+MUeQvRLpcUe2FRetPB5gtr86HUibnWWvR4LslUSP9e8sJdbj dJD69JXkwPbknNaTfABB9slqj2sb4aHHrw+K7JFgj683fJs+DMkbWa28SevSjW4dv1r+2uw8kz2y RHZJoMfxpRbTax2nD+MzodFLlSvG27r51R7zR5ZGeyTIDkn2OIzFhewrYbykVI+F3z8m62NIL2gz SYLsTkWPf5YlaWz0WH0A+NkeZ5/YjPEHQfZG+P3Jl3uU3V/d3FgfPRJkb073OO0lZo8fh/me7D09 Jvurj9OtJ/kEguyLZI/Z86vD+znV92nJ9bHw93TGm/LyfM4DQXZF8Hi5kHw4rvbxo5u/p7OOIHti tcfaB6OPC7ee5HMIsiP0qB9B9sPq6zs8v/5xhiC7YbRHd39PZx1B9sJqj7sGbD3J53F0eSeM9li9 Nj4u3HqSJRBkF8z2WL+76qNHguyC0R53FemjR4Lsgdkeh/qdVic9EmQHzPbY3/pIkB0Q/HusFRdd jyjk7xrH48cMT7N6d0GP8yslr7xYHPSdIs+vriBI34z2+Dy7t/3VHwTpmkiP75daPN8BIIRh/HeY vjJEPYby9fK3vOLxYwFBeibTY0grm06mx33PesyvV7s+7jl61VuPBOmZ0PoYZxeWzkiXwFnA1T3u +Vusj8u3nmRhBOlXRY+fy9Ls4rdYnb3F1Xu4EJ043OPauf57JEi/JNfH7LNyjwtnsz7uwe89vJLe X509OLygx84fPz4QpE+i6+P7qdXnP2ma03CvS5b2c2t7HIZ+n199IUiXzB4vNwx9/v5xRJAeWe6x esDWk3wNgnSIHu0iSH/o0TCeZnWHHk0jSGfo0TaC9IUejSNIV+jROoL0hB7NI0hH6NE+nmb1o4ce P1tP8uUI0ovzf4/1dWx3cojqKfLr46f7IgnSCYn1MSycPuiK/VX3RRKkD5306L9IgnRBrMfpRVbZ e1kN2Vfqhttx89sDPr9VgoR6kj1mL0KePs1eoVwz3I6b3x7w9b06XyIJ0gHhHucfoid6os/qblT8 9x2+i+T3HvZV9PixLLpUvAymL/4f8rcD2MqncOqU+PeProNkiTTvovVxSHrMVsya4Xbc/PaA8Tfs fIlsvQE455b91fSBZdVwO25+e8D0W3ZdJEHaJvz8avK3AuL9VTXr4w/PRRKkaT0cL1c4ftVzkBRp WKc9skRCpV57dF0kQZrVb4+ed1oJ0qqee3S8RPIg0qiNHpu4rUfXRbbeAByx3mNj1/fouEiCtKj7 Hv0+jCRIg+jR7xJJkPbQ4w+nRfKsjjn0+OQzSJZIa+jxxesS2XoDsIujHsdLJ78zGSp79FokQZri p8exwfHlJuM5tZPhskgeRFripsfxHWBP9Oj0YSRB2uGmx0GkR6dLZOsNQC16zHkskiCt8N7j+5jY PXPiMUiKtMF7j4/TeyeFJRKN0GORwyIJ0gJ6XOCvSPZZDfDWY/Q2d9MZx6bGXZAskfo56nF5mINz 43CJbL0B2ECPa9wVyT6rcvS4zluQLJG60eMGf0tk6w3ACnrc5K1I9lkVo8cKzoJkidSLHmu4WyJb bwAW0GMdZ0Wyz6oUPdbyVmTrDUAJPdYjSFyNHnfwtUSyz6oQPe7irMjWG4AcPe7kqkiC1IYed3MV JEXqQo/7sUTiKvR4hKciWSI1ocdjXBXZegMwosejCBLy6PEwR0sk+6xa0OMJnopsvQF4oMdT/BTJ EqkCPZ7kqMjWGwB6FOCmSIJsjx4FeCmSfdbm6FGEmyJbb0Dv6FGIkyJZItuiRzEUidPoUZCXIltv QMfoUZSTICmyFXqU5WWJpMg26FEaReI4epTnpcjWG9AjeryCjyJZIu9Hj9egSBxBj1dxUmTrDegM PV7HRZEskbeixytRJPahx2v5KLL1BvSDHq/moUiWyLvQ4/UoErXo8Q4UiTr0eA8XRbbegA7Q410c FMkSeTl6vA9FYgs93okisY4e7+WhyNYb4Bk93s1+kSyR16HH+1EkltBjCxSJMnpsw0GRrTfAJXps xXyRLJEXoMd2KBI5emyJIpGix7Y+rSdJkaLosTmKxMhNj+FbdDK+qvIeKRIjLz2G6PL51dT3aH+3 lSKF0KMWFAmXPc6uZaNHioTPHrOHj2Z6NL/bSpGneewxvmp4aT3P1Siyaw57nF3VTowPthdJijyF HjUyneQHSR7nsMc8TYM9fhnfb6XIo7z0+D4eIEwnp7NaT/IxLJIdctPj2jCtJ/kw40m23gKD6FE5 iuwKPapneZFkt3UnerTAdpKtt8ASejTCdJEkWYsezbC9SJJkFXq0xHaSrbfAAno0xnCSLJLb6NEe u0WS5BZ6tMjwIkmSq+jRKNtJtt4CtejRLsNJskguoEfTSNIZerTu026TJDlDjx6QpBf06ARJukCP fpCkfT30+Odb63m+CUka10OPP+vjnz+9VGn3+R2S7KfHp16qJEmr+urxqYsqzS6TH1032WOPTx1U aTXJjpfJfnt88l4ly6Qtvff45LtKy0223oS79dDj379/q+bij+MsrTbZ2zLZQ4/f6+Pfh7opcVsl TerXSY9PO6L0WiVN6tZVjw97ovRZJU3q1UOPv79l3/ae/VeXVX4ajdJ7kz30+O/b799LVVZPlb8q jUbpuckeevzeX/31799Slfui9Fflp8kqP5xG2UmPT8tV7tt/dfirEbtR+qqyqx4ffm1UuWf2nGXJ Utlcfz0+/Fqucu9S+eUtS5NVelkqO+3xaavKnXPpKku7VbbeiFO67vHh13KVB5bKL19ZWqzSdJT0 +PBLvEpPWRqs0ur+Kz1G8irj8/6ey9JBl1arbL0Ru9Bj7tdU5eIvRvZn6aZLe1WaWirpsWxtB/Zr zPJEl7bD/Py01uWHjSzpccWvWZXl42CPdOkjTHNdas+SHjfFVS5kOXZ5JsxzW9nWp7EwP7R2SY+V fpWyXA7zwC388bBiGgtTXZb0uE+a5b+v3wtlnugyLtNumqa61JMlPR7yK+/yKypz/svL422aL/PT 0IqpYC+WHs/Juvz3+OLCovn375k6zS+an2bSbNglPUqZLZg/fv8uL5tfp+p0lGbrLVn1cX+Y9HiB eZcPv6vr3PumBXbTtLFo3hcmPV5q2pHN2lyv89DiabzMOE21cV7eJT3e59+/2jpP7tpaXzS/sjj1 1fkRER2YHltZq1Nu1/ZPRvRbuI3qOj8+BOukRx3+zURnCu7a5n1ajNRznfSo1bzQ+S8613/fufO9 2I1GaqjOikLp0ZZipPNCX5X+nam/pWKk6itVXeePeaFJpG56DN/mJ5+ft5v9e5SX0mKk80L3/fKz XKnWXj/XtN64yFSmlx7DdPno5Ou81tPdRrnSUq/FSK/pVVG6q7G2Spcej7pk1Ds3davXyVavl6d7 sufTs3pfukIP0a5BjzpGrS93T7pnne35mspPlkuPR3XU4+lBN/aXj7FUeUkxUu89BsAS2YJkSa2P clt09ahsqplBLW2qEHpUPCqbamZQKfSoeFQ21cygUg4cDxCmk4eG2XGDZgZlU68Y1NKmClG9cUBn 6BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPUR6vOKg+SA/8DSa8NaWjlg6OeLrUCjZQeVHno0m NejPeHKbOl5ffGRpIvMnNVA85vvIPLmBp9GEfwqPn/A4uMiIz3+EB42mVGjk2WhiMxskN3XaquTw 6yvut2eJ9SgrDNkUyg08GOtRbsz8f3FCw1/ao8TMlu9MwtMrRGmPw5U9XnFH19/jcEOPYps8bqrM zIbs4/O03x6vevyYnBAb9pqFR3IOngNKT+z7Ti78WG+YvnnhHsUfP45vD/B8FHnF/fYkmZ+J0EDJ oNlHuVGD7KAhfrAjNuirRtlBp5HHT0WGfX/zYjM77fvKPMpL7kzj/40uud+eJLa/elGPVzx6NNDj czTpyJMTgjvXF/WYDn56vOwT58/nXNPjFTnKvqfRazhzPUoO+y5Hamajnz09Hhzjkh4vyDE7JTWw 9JJzyU5w9p/MiOkdW2Tcy3pMh/Ta42XHA8guZdFo8j3KHw8wyA86jSw1s5ccDzCuYMLP54R8SKfH AwAWWLivW9hGQIKF+7qFbQR6QY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj0q8 X3nCD6Rr/PiVKPTIz6Y//My1eL0iL/sC+sLPXIupx/g9tONXzip8+SyE8QPWYuxx6z84xs9XjRC2 muSH5R4/YjXKPb53WweVb/cCYfyA1VhaH1/nPT/w8/KNn68e45vK8fixW/x89QjTKhiFmT/vCs/4 AQN60COgBz0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9 AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6DH/wGctBsHptJQqAAAAABJRU5ErkJggg== ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="ties5512.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ties5512.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAAP8AgIAA//+A AACAAID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADKvVWfAAAfq0lEQVR4nO2djZqjqBJAnenZ2b7x/d/3bidR+TOCFlIF53wziTFa IvF0IUEzzQCghal1AQBgBR8B9ICPAHrARwA94COAHvARQA/4CKAHfATQAz4C6AEfAfSAjwB6wEcA PeAjgB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPsozLfxMppeY d99Kh8pYMJ7aL9jkL3UcP6uwcB3qWZ5DH6diHwuEwUfLUM/yOAfvBx9LQuVkyLKIheXBx5ugnuWJ fFx1WpLmlqGW3Pecsc2aglBxnHlLv8vUa+Y65bgc/4XwAr4WX6ecLS1lcTJ6sCSIQpXKEx79k2fa 5Po4bQf81sR1hPTyYxAn4ePmaRg4LJwXMFg68Ya7saAwIAlVKk9w/rjmlt0502ZccHLpnj8m15qd tSZ/iWDZtXDzHG4pVYxwCWdbcxgTxKBS5Yl89LLZHB7v0ZRnz5aHdrKi1179ENfddrJgQQ50trqf mkEYalWe4Ogv9NFrCS4z5vmjPtV83JbAx1ugVuWJfAznf/bRTZGrBNHqIj5+CLgUZGudpgoBwlCr 8sT5MZrw34oN8n100mRirajDJWj9rgk2jLgXMFnQ9MZAGGpVnuD8MWzsvfOf1x70DQrz45og40aj u6FkmvPCuRGdgG77dNsDf0PxOrWqb2ioVXlCH7f85AjlnKq9ntfH6PxxdoTcXq7LfmyvuttyI3oF m9zvH53tbfG9vxlhExjkoFatkicE8tiCD8oquT4G7VVQDR+UVTIdQ0dT8EkB6AEfAfSAjwB6wEcA PeAjgB7wEUAPg/sYjmTz5yYmnNE34Ria+MXsrRJv1Vtmb+WP5Y6iH4Y4+91HsFq4+SmYmxVy8IMv xdhV4ozbjIzbe/uyj8mv6MvGhKaLu7v9aEPlRMWNdqd8UCs+xgxdJdtBFGSvZdRnOLEtsh/ycGZy CFvRsemX5/jvwekN7a3m/3m5Ehd8hq7FcDR1NDec8BeZvbHWToaIm6fRRtc/A04CjoeYe83pRAnT 0bcV/WHg/nDz5IjyyQ+6RvILMLkj1IP9OQwV1FVqdwdm9P2f1wMhaPLl+bhYtDbZvBfr0ol8Eq62 +hg0ktMBw0J40d0V5zmKGs12tuW+dIsQbN+tjNjHz6H8ukrt7sgMvvtzwqAiH+fgCA/Sz7JYpPu6 3fUhMSv2JyhhOnqyWO6GCt73lgxqLbU/uaFSSwd7OSSD775vw3KAvx8zfPReuBnC34QTPTp+U4pE U4mAXiGmdNS18PGG3JzkZ8xwdrGPh6Gckqd2d2QG3/3ZPdKv+Bi3weItxc+ZPoYBE4euIR/XvcHH mNF33z0KLvjot8+CjOavfsbHTwHj6CU+uhGDMsSreRUXTu35mC6zX1/4uDD27m/H0uKU+yKeCNbb 0ck/1OdwdT9TOC67ZqdlTQX0o4dH9uQ8eVHd2YmklrYlrjm/LvJDbbPj3R2ZoXd/clpTXhtqfRFO rCs6T9sqU+LFHK2+bXX2p+Zwo8noc7iMF33HxziqM3uZ6z6kiuD/SQh3J+3jTij3b1C0wMgMvfuB Ga9ZzovExLKi8+T5lDgGU6tvAZwtbK5MiejJgH5x530fo6jbbCdO+L6/kY8++ls/CuW/Hy4wMIPv foxohRwFKz76Gn9cHC21oYYD8FHv5geAGva5VcdiH9Gxd6hiAD3gI4Ae8BFAD/gIoAd8BNADPgLo AR8B9ICPAHrARwA94COAHvARQA/4CKAHfATQAz4C6AEfAfSAjwB6wEcAPeAjgB7wEUAP+AigB3wE 0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA8l Pk7T8/fu30/z+7FGqQDGpECnt36Lhes/ABACHwH0cNFHdAQQpNDHafPxef6IjwCCFPbnOPnx/TRN zttP/gegGVGBhClNcKGPQY6cHgC66dfHuEsHH0E7vfg4zZt++AhW6cXHeR0HMK06uuePz1etKxvg gG58zAnXurIBDsBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94COAHvARQA/4CKAH fATQAz4C6AEfAfSAjwB6wEcAPYzk4+/fv1tXN8BHRvLxv/z4+zdSgmIG8/HJb6wEpYzo4wukBH2M 6+MTpARVDO7jE5wELeDjCxIlaAAfHXASGoOPATgJDcHHBDReoRH4uAdOwv3g4ydwEu4FH4/ASbgP fMwBJ+Ee8DEXnIT64GMJOAl1wcdSUBLqgY8nIE1CJfDxJCgJFcDH85AmQRp8vAZKgiT4eBmMBDG6 8XH6j+1pfj/6i9SqRJIkCNGLj2/9FgvXf94yFesRJUECfBQDI+EyPfsYrl79/uQkSbhILz6+TxzX s8YpTo+3/F4ASsIVevExyI/vp2mNML25oUoxEk7TtY9Bjrzt93RIknCSfn2Mu3Tu/H0rjIQz4GMt MBLK6cXHcDzA7IwKWBe5uW4xEkrpxseccLfXLkZCGfhYF4yEEvCxNhgJ+eBjfTAScsHHO8BIyAMf 7wEjIQd8vAuMhGPw8T4wEo7AxzvBSPgMPt4LRsIn8PFuMBL2wcf7wUjYAx9bgJGQBh/bgJGQAh9b gZEQg4/twEgIwceWYCT44GNbEBJc8LExpEhwwMfmYCSs4KMCMBLe4KMKEBKe4KMOSJHwAz5qASMB HzWBkYCPmkDI0cFHVZAiBwcflYGRQ4OP6sDIgcFHhSDksOCjRkiRo4KPOkHIMcFHpZAih2QkH79a V3YZCDkgI/k4fdkykhQ5HkP5+HjYEpIUORyD+WhOSIwci9F8fBhrs5Iix2I4H0mRoJgBfSRFglp6 8XF68np+vY4DbN8/WhMSI0ehFx/fi0/b8xSt74wHMCYkKXIUBvXRXpsVI4egIx+nOfAxXN0fL2dM SFLkEHTq4/P88bOP9lJk6wJAffrxcfIfXjlyjTC98XbempAY2T1d+xjkyPj6DmNCkiK7pxsfp+1x nTz0kTYr6GJwH82lSNqsfdOZj+t4gNkZFbAukqwBUiTooRsfc8Lt1AFCghbw8WEuRdJm7Rd8fGJL SFJkt+DjC2spsnUBoA74uGBMSIzsEnxcIUVCc/DRASGhMfjoYkxIjOwOfPSgzQpNwccAhISG4GOI rRSJkH2BjzG2hMTInsDHBKRIaAQ+JkFIaAI+prElJEb2Aj7uQJsVGoCPuyAk3A4+7mNLSIzsAXz8 AG1WuBl8/AhCwq3g42cQEu4EHw8w1WblJNI6+HiIJSFJkcbBx2MQEu4CHzOgzQo3gY9ZWBKSFGkY fMwDIeEO8DETW23W1gWAk+BjNggJ1cHHfBASaoOPBSAkVAYfSzAlJEYaBB+LsCQkKdIg+FgG3axQ E3wsBSGhHvhYDEJCNfCxHISEWnz2cWqCdh8REmpx4KOsEHno9xEhoRL4eAqEhCp04+O7obu0d9+P /iKC9Wbpew9GBtihFx/f+i0Wrv+8ZURrzpCQpEgzdOXjfKePCAnyCPjo94mGbcScCHsbvehjuLqw jwgJ4lz3cQqWbOXj84/CetY4xelR3EeEBGm68fEp4ebj62nL28t3m7K1Z6pXp3UBIAMpH9/H/EuK 6T373XDcuj7z1CravLto6GOQI8Xz48NUikRIA8icP64LT2tLcfNxeyszXtnmnUU9H+MunRo+IiRI ItO/OjmyOSKO4CNCgiAZPv7ax1ty38f3N/SZDVaR8QDLNr1F6lQhQoIYgv05uz6GPT5ZAYtWyQxc qQ4tCYmRuhH2ce9prt1ezQpcqxINCUmK1I3keIDJ7Vh9txzv6l/NClytFvneA2ToZbxcVuCK9YiQ IAE+CoGQIAA+SoGQcB2LPibu7JEXuG5VIiRcBh/lQEi4ikUfl7dKS1fbR4SEqxj1sXCIwXul6rWJ kHANqz5qbK8+EBIuYtTH/NGw7jo31KcdIfFRI1Z9PBX4jgpFSLgAPgpjx0eEVIjw+NX1mqcLKuW2 V/X1rz5BSDiP+PVW3jWPp8jtz5kV9uf8gJBwmmo+nhcy8/uOqXgTN/mIkHAawftZBRPj+oiQcBbB +1l5N7aq7aPS7x/fICScQ/B+VuvEDT6q/f7xDULCKTJ8/HefhET3nD+eC3xjvSIknMFuf86JwHdW LELCCax+33Eq8K01i5BQjtHxAMr7c54gJBRjdLycBR8REoox6uO5wHdXLkJCIfhYE4SEMiz6+By6 aqC9+rAkJD6qAB/rgpBQgkUfTwduUL92fERIDeBjZRASCjDqo5n2KkJCCfhYHYSEbIz6eC5wozpG SMjFtI828iNCQjZy9weYpDJbb+3VB0JCLgI+Tu6TAPk+lgZuV80ICVkY9fFc4Ib1jJCQg0R7dVoe n/+WW3a8ptYrsd7RMiJ26SNCQg7iPq53fpu8V9tCGQGPN3/qJyCb+oiQkIFIf86WHOc1Oc5BRqzt 4/vFdm10HKCtjwgJx2T4+L1Pro+rJRk65rVXo7bvtD16hXEXaVzXCAlH3JIfK7RXo/cN+IiQcITM 94+RhZGPU5X2arSS52O4enMfERIOuMXHeZrcORkBDzcf9uUsp49rieL0iI8l4GMTTI+XC1eaNh/n LSu/XrxpXN0ICR/pxcf38r6PQY5sLeMPCAmfsOpj8vdYPR/jLh0NPiIkfMKoj9HvscbtVaU+IiR8 wKqPsWzbvdG3df3hOzp8REjYpxsfcwK3ruw3CAl7WPXR1vWPAQgJOxj1UfvvsX7GkI8IeS9WfTwV uHVlryAkpDHto9X2KkLCDiZ9XC+tKgzcurIdEBJSCP4e68WfYU1sdCfamWuRn+u1rmwXQ0Li431I /165gJDHPj4fyrekykeEhATSPgoImenjicCtK9sHISFC7v6r+FgKQkKIzPmjs/AdPp48gcTH8yDk Pcj0r663c8THEhASAjJ8/LOPt+RtPp4O3LqyIxASfCz255wO3LqyYxASPCx+33E6cOvKToCQ4GJx PMDpwK0rOwVCgoPJ8XJnA7eu7CQICRtGfTxVMJ0+IiRs4GN7EBIWrPrYxfePCwgJb/BRAwgJL4z6 eC5w68reByHhCT7qwJCQ+FgRqz4m709+FLh1ZX8CIeFh1sfo/uRZgVtX9kcQEuz66IyYzQ/curI/ YshHhKwGPqoBIUFiPPk6fnVfnDJtMjbf2fcdLxASxK+32nu3QJuczZu/v1wKhBweqz6eQb2PCDk8 sj5Oy9Q0z2sjdnpN7jZp9zd6NH61s/bqAyGHp46PrprOfEEfV+ELMOAjQg6ObH+O8zTPgY9z7hf4 454//oCQQ5Ph4999PGkCH6ellVrFR/v3J98DIUdG9n7IfpqslR+7ud9jGoQcmJo+Bvkxt/tldB8R cmCEfy9gbaQ+bdx8nHKjzRk+nsWKjwg5LneOl8PHXBByVKz62HN79YGQw3Kfj9n25H3/2LePCDko Zq/vyB5e4KzUurJLQMghsevjFL2/dSile5BM+YiQQ2LWxzlqr249u/7XLNsCrSu7DIQcEKM+bl+i OLM68xEhB8Sqj6nVQh/D1a35iJDj0amPqdNLez4i5HBY9TG636M3UHadMznLP2ld34Ug5GAY9TG+ 32PKxyBHWpPxYctHhBRAxMcCbTMWze1f9d5/jw9wfIy7dAz6iJCDIeFjyZ3Ca/m4zezLR4QcC6s+ psbLueMB1mtM3PdbV/YpEHIkBH18n9BtT7N3I6sPN2nd2+jRePKs0jnrtK7scyDkQAj4uGi2XH7s Pa0jTRcr8+IVbD4foz4i5EBI+jivxk3BHOcbiLx4R5s/ZapVHxFyHDJ8/Gef5zLLqdyBj86tAw60 ybBuLB8RchiE70++76Nse7X76x8DEHIQLvs4rc/B+eMct2Tx8TQIOQaSPgb9q/PSp7p+90B/znkQ cggEx8tN3tN58DEJQo6AVR8H+v5xASEHwKiPw50//oCQ/WP1+o6D99Mrta7sqyBk9xj1ce22LQrc urIvg5C9Y9HH3n+/4wMI2Tn4aAuE7BuLPp4O3LqyJUDIrsFHayBkz1j1MbqfVU7g1pUtA0J2jFEf 4/tZ5QRuXdlCIGS/CP4ea8ainzthpvBXOT5+/5g3GNZbqXVlC2HKR4QsooKP8UqT97wXdBEMH49A yG6x6uOo33e8QMheEfFxOZV73QHgdbmVc+3VKs60rZBcL7zlFePJ90DITpHxcfIt2yb9dmXkY7he dn48RUc+ImSnCOVHV7tp7w0/BUYC42MJCNklGT5+7eNr595iNbrF1RJuciZO+vjshx36/PEHhOwR yfwYvEr7uPM2PhaDkB0i3V6NTg4r+HiWznxEyA4RzY9L1+rrwVdzC/deMtXOzcyPGaVKrte6sqVB yO6wOF4OHxcQsjfw0TTGhMTII0z6OPD1yCG2hCRFHoGPxkHIrjDp49nArSu7CgjZEyP5+E/ryq4D QnbESD5O//Rp5JctIxHyAxZ9PB348ehTSGMpEiH3GczHR68psnUBikDIXUbzsVcjEbIPxvOx00Yr QnbB9d9jfX8T6A1RvaZNyeaLAi873WWKNCYkRiaRyI/TzvRJzvm4XOm8/CRzMDT9+WrbbYRsDkKm 6MXHt36Lhc7lW84yzn73mCIR0j5iPm4XWQX3spqDOXnhCjbvrpntY5dGIqR5JH0MLkLeXrpzMsMV bN5d0/MxXD0cL4eQjUHICGEf4yeno8d5lbfRIh/XK5yXVH3oY4cpkqE6xsnw8fc+zlJuGvQv/p/n 4HYAR2IlpvLY8uNSojXCckVIsPvdCWksRSJkQKX8OHs+BhkzJ1zB5t01fR+DHJm6vqPDFNm6AEUg pM8t7VX/xDIrXMHm3TUdH+MunfT1Vt0ZiZCGEe5f9X4rwG2v1s6P7zKc8LG/RitC2qWb8XLBeIC3 mV6E3euRe0uRxoTEyI1ufMwJvF8NCNkShFzBxxedpUiENAo+LvRlJELaBB83ELIdCPniwMcmtPKx rxSJkBb57GNj7vaxrxSJkAbBR5+eUiRC2gMfQzoyEiHNgY8xCNkIRgbgY4p+UqQxIUmR+JgEIRsx upAj+fi3oF66SZHGrlAeXciRfJz+jmlk6wKUMbaQQ/n4eJQI2U2jFSHtMJiPhUJ2YiRCmmE0Hx9F bdZeUqQ1Icc1cjgfx0yR9OoYYUAfS1NkJ0a2LkAZowo5oo+FKbKTRitCWmBMH0uF7MJIa0IOaeSg Pha2WftIkZxE6mdUH0mRBhhQyHF9LE6RPRiJkMoZ2MfSFNlFo9VYm3U4IYf2sVjILoxsXYAiRuvV GdvH0jZrF0baEnKwFDmSj39SFVAoZA+NVtqsehnJx+8/KSNJkdoZSciRfPz3+5sU+cKYkOMYOZKP 07//kiLf0GbVyVA+Ph7/fj9kUmQHRrYuQBGjCDmYj4+fNqtEiuyg0WpMyDGMHM3Hx7+kyAXarPoY zkdSpANCamNAH0mRG8aE7N/IEX18deskU2Rp9Zk3kjarLsb08afNmkyRxW1W+41WY0J2buSgPr7a rKTIH2wJ2XmKHNVH0RRp3EjarHoY10fBFGnfyNYFKKLnNms3Pk7/sT3N70d/kXDn/xNSKEVaP40k RSqhFx/f+i0Wrv+8ZaK9f7ZZSZE/GBOyVyN78fG9fKGPzzarWIq0baQtIXtNkT37GK6e/D1WwRRp 3EjarAro1Mfn+WOWjx9S5InqNC2ksRTZZZu1Jx+neXZ7caalV+f54k2qDp5CJow80WYlRd5Jh0J2 5OM0hz4GOTKdHx+vNqtcirRtZOsCFNFfiuzHx8l/SHTp7PoomyJtG2lLyO5SZDc+TtvjCR+fQoql SNOnkdbarH0Z2YuPr7PDbTzA7IwKWJf5WBOSbVZS5I10JWQvPmaF+1wVom1W00aSIpuBjw6iKRIj 76MfIfHRRTZF2j6NbF2AIrpJkfjoIdutQ4q8j06ExMeA770Uea5+TRvZugBF9JEi8TFkL0WebLNa NpIUeTv4GPMUUi5FWj6NtGVkBykSHxN8kyJXTAlpP0XiY5LdFDmekaTIO8HHNHsp8nyj1bCRrQtQ hG0h8XEP6RRp+DSSFHkb+LjLj5BS9/J4YjlFYuQ94OM+33spkkardswKiY+fEE+Rho0kRd4BPn7k Q4rESN3YFBIfD9hNkRipHJMpEh+PeAmJkS8wsi74eMj3forESOWYExIfM/iQIjFSN9ZSJD7m8ClF YqRubAmJj3l8SpEYqRpTKRIfM3kKiZEbGFkDfMzl+23kztsYqRkzQuJjPp9TJEZqxkqKxMcCvjEy BCNlwcciDhqtGKkZC0biYyEHKRIjNaPfSHws5ajRipGa0W4kPpaTYeRwVyxjpAz4eIaXkB+MHPAe AhgpAT6e4jvHyNF+YwAjr4OPJ8kw8qyS/5hVEiOvgo+nyTHy9C9jYWRtdBqJjxfINHKsJPllRkmN RuLjJTYjUXIDI0+DjxdZjPycJEdrt5pJktqMxMfLZBs5WpK0oeRvVUriowCOkSjpYMRITUkSH0X4 /v71nvps5Hklz6zVHjtJsnUJ3uCjENlGnlTScJI0oaSSZmtHPj6Xnv7j9RwHqOrjj5GZzdYBlWxd giw0GNmPj08DFwvXf94S1WvTTZIo6WAmSbYuQTc+TrMCH90kiZI+NpRs3Wztxsc59jFc/Q4fH05v K0oGoOQhnfr4bL028tFLkijp82XCyXZG9urj62laI0xv7qpXlNzHgpKtkmTXPgY58jYZn/xCyX1Q cod+fYy7dO718XGbkjadRMkU+FiXUMlKo3dsOmlDyVs315mP63iA5ZW3wK01u/DLU/IwTZ6/zQdK 1uHWJNmRj8fh7qtWn1jJGsPOraZJlHTAx3sIlMy4EmQkJ1FyAR/v4tdTyRvSpM2mK0o+wccb+fUr kSYPbvQxUJpESXy8nShNZjh5bksoWYW6SuLj/cRp8sDJodLk2EriYxviNFnRyVPrNcTAINdaSuJj M37d5iRpsgZVlMTHpuw5+fFnQUZxUn+a/C3uJD42J+Xk50Q5lpOti3CArJL4qAKc3GeoNImPajjn 5BjXhJhwUiIMPqpicbKwk+eElDgpjkSaxEd1/Crv5DnZev3HnJTdO4mPOilvvF5JlKakNOHkWSnx US8nnLwkpSEr1Tv5krLcSnzUzRknL/Xz2JHyS7+U5akSH/VzopPncVFKM1b2JiU+2uBMJ8/j4kh0 M1Z+GbAy00l8NMRu47XGKeUP9qxsXYiPZDiJj9ZIOXmcKv8OYqV6KQ+cxEebpJw8br8OYqV2KT84 iY+G+Y56eR4Z7ddBrFR+UrnTyYOP5tm38uNqA1nZuhC7xFLiYyekrDyWUsBKA1rqTpXeyAF87IqE lcft12tWLlqq9/JLtZZvKfGxQ1pYuXmpXEzNWv7+jY/dsmtlznnleS2NJEylWuJj5+yeV+Zp2buX 2rTExyH4XnBn/vmTIebf62L+o78lq0ZLfByL75SZf3LMFEiYjpk61fxq7iU+jsp3Ss0/Lun1JLx8 KE+a7bzER0gnzUDOyM6/Ai3ZJ4qT5tftYuIjOHx/J9PmD/t2ipnpqqlLztvExEfY47vYzr9yagZy arGztpf4CHkU2ilp5g/K7PxykIyLj3CGAjv/Bkhs/p8QiaBn+fqSsxMf4TpFuTP0U7pTqLGk1+zE R5Cm/LzzsWPpxYIokPQr5GB5fIS6fIc4733+RqVLSSNBfUl783H6j9dzHAAfVRAJulj65xPb+rdJ ep+vm5md+bhYuP7z3qxcq3CBtKUbH2X986eGpA5Hvoqpi48XqRGUgsYc+ZoyN91zJOZruqDXzBU+ RZPloo/h6hzmFmJeDvormyNf5UgWNOVopz4+zx/xsXZQ4wXNN/egtXxItri9+vh6mtYIE4AFhNSp wlUfgxxZZV9rBKWgFmLaKagUl3yMu3TG/lAoqIWg+HgRMx8KBbUQtDMf1/EAszMq4EK4jA0aiUlB TQTtzUcAqAQ+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNCDqI8VBs9P4nG3YLJlneY6BZWN KR44CiYU83k1n1RB/WuQ6lStDJLlSdxP53LISTruFkz2s1ivBhUuqGxMpzplAkfBpGp1Eiyoc03g 9ihctUKI+yiKcwMCWXmeD3Z8FAsZ/nmTiV7TR4FaTR9FslUrhW4f54o+VjjUtfs41/dRqsBrQUVq dQqeX9P9+1jp/NGbkIpaJfUIVsArnnClLoe57MnevO25rI/S54/r7QFeZ5EVjteriB6Tzh81sZjB s1jQSTTm5J7wSMV82ygacwu8vpSIuuy5VK1uTV+R0zzvKFr/FNU4Xq8i3l6t42OFs0f1Pr6CCTvu Tcg1rev46Me+Gi54MUh/ThUfK+goemejdzRjPgpGXdQRqlXnU8fHa7Fq+CivYzAlFFc46dRoAwf/ RQL6h7ZE2Fo++hF797HWeADRXOYEE/dRfDzALB5zCyxUqzXGA6wpTLY/Zwojdj4eAEAzFo51C2UE kMDCsW6hjACjgI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrARwA94KMilutO+FCG hY9eEQkf+XzGgs9bE++r8oIZMA583prYfHTvo+1ePavwEloQhA9XE6uPR/+hU/hsVTFNR07ygXUN H68q0j4uzdZZ5S1fQBA+XFXs5cf3e68nPrN+4bPVxXpTOc4fh4TPVhfTlgUdMcN+V+gVPlwAPeAj gB7wEUAP+AigB3wE0AM+AugBHwH0gI8AesBHAD3gI4Ae8BFAD/gIoAd8BNADPgLoAR8B9ICPAHrA RwA94COAHvARQA/4CKAHfATQAz4C6AEfAfSAjwB6+D+y8f1HtEkw4QAAAABJRU5ErkJggn== ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="ties5513.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ties5513.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAgIAA//+AAACA AID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABK2F9eAAAdn0lEQVR4nO3di5qjqrZAYbJ39akd3/+BT3eiCIgKOtE5cfzfWnVL Qi5Vo0FzcwMALdzdFwCAR4+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9Ajo QY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9NiU8/5+Gf18/5R7A8/n8P2Q OdLKJSo5Hm7Br6Kp5j0GZ1AyRPbI+xcGV+FX0VxhKlXH8H1/Pq4cN9tj5gB61INfRXN+Jvt+nIoI vxqSCW+IQkuOmZxqnvHiNew0UjgfzkcI0gxO7oKTzxcy+Ln0bYMEt3BzYY/h374Lf7I4IEwmOuY0 2KJHf7hfIPuPYYfT57TH+BLFgy/OH41wAzcX9OgnPRd/CA+Yv0hWpEENyQyaDuGSsaIOo8sSHs9l L1pmNLTD7dtc1GMw+y3mwGi5mMx2Lmohn2J6vHgVGlyUfI/RcZY9RxMtGuH2ba6ux5XVZ9rjfPRh u8f97Ud6VITbt7l0vTr/LM5iPCBYNuZCGY8UxbdyvLm+ovVq/qLFK2k0xo3cXDw/LjfSvgemW2m5 DbvsiMPyeIstvkxsyYlWL1o4PxJlc9y+zQX1+MVjsuDMHJAsRIewhWyP6Qp3nBfjZaYLzzg63pAc MKQ9RgtfNMIN3FzY4+CTCb4aggOmiJLQwmNGXyRND/MY0w+SjFx8rHlunA9x4RkuLwca4hYG9KBH QA96BPSgR0APegT0oEdAD3oE9KBHQA96BPR4eI/pQ8zin2a+mB9nlnmcd/rNEJ1kea7RcdZOvHm5 F6PvDnH0MTbJydKzd8lPi4Z8+B9fzrNvkuVjNvM/DQ8+3WNy8uB0xX+g+Yu7ev6LM6q3uLiLq1P3 D8qJi9K1R98k8x9RMnt9Pyy/mI+yPuTuD5NHo+6NuHa5g38gasYR6TH+5+XMuIg9+lZMH9u9+Gn6 RXyUIXrkdzBDLJenizP1/wwEE/D8sO3gcs3L6cwlzI8+nzB+MLgLjrB8rHoUeXoR4gvgglfWSq/P 7lDJbZW7ug/29Os/+D+EZMlX1uNUkV+yRd/4Y2fmk/RkvsdkkZwfML0Q0ejhCYdhMerix8F5hd+G FyE5//DGWPa4PVR8W+Wu7pM9/OoPmYKqehySv/Bk+pmOtsjdn6//kPnRsp/kEuZHz16s8IwqDo+O mdxquetTOlTu2Mm1fKSHX/24hukPfPxY0GP0TThDxGcRjL74+80lsvgqM2B0IVx+VH/hl2cUzknx jJn+uLrH3aGCS567uk/28Ks/hH/pZ3pcrsGW57T8XNhjOmDmT9dQj/7a0OPS069++Fdwosd4fZbM aPHJj/S4NeBy9JoewxGTy7A8WXTDpV+t9Zi/zPHtRY+TZ1/9+W9pair8ZvlFcrqVnOI/9SE9eTxT BC2HZedjzQ0Yj57+ZbvgUzRq+OPMpJavZXnLxbdF+VDzj5dX98keffVdsJqK1lD+m/QLf8Lg03wS l/lmWJx8Ptch/mpIzzQ7+pAeJxp9pcflqMGPp5+GH3IXIf4nIb06+R5Xhgr/DVoc4ckeffWTMr4/ Cr7JfDGdMPgU9ZT5G8ydfB4gOIe5FZcZPTtgfHGH9R4Xo84/DsZJD4/PZLPH+Nz3hooPT4/wYA+/ +kuiN8jeYNV/fTf/uvhraY1bOEGPes/+AbiFY5fmWN0jOfaOmxjQgx4BPegR0IMeAT3oEdCDHgE9 6BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3o EdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCjpkfnPu937/zn2gEA bKrIacrP+W8dOQKSanuiR6Cd+h6d/yr4BoCAqqA+243T5uNn+5EeAUEH58dgzepHcKP/AWaJlXXM ge3H6FMyR7o3YJjpHpe7dOgRphnqcVyoButVekRnDPUYPh5gPq2LRqBHmGapx5Lh7r49gTPoEdCD HgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMe AT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPTrr8T93357AGZ316AgSltEjoEdv Pb4JEoZ11yNBwjB6BPTor0eChF30COjRYY8ECbN67JEgYRU9Anp02SNBwqg+eyRI2ESPgB6d9kiQ MIkeAT167ZEgYVG3PRIkDKJHQI9+eyRI2NNxjwQJc+gR0KPnHgkS1tAjoEfXPRIkjLHUo/tr/jSM H+OjJFePIGGKoR7H/KYK/X/RcZKrR48wxVCP4/GreiRImGK8x/Tky/fTIUgYYqrHz4aj32p0y+mR HmGbqR6HcH4cPzk/ghsl15AgYYf1HpM5MvP+j/QIO0z3uNylk3s/VoKEGYZ6TO7vGEp7JEiYYajH 9PEAQ/CoAH+U3HWkR1hhqceS4bJXkiBhxCN6JEgYQY+AHs/okSBhw0N6JEiYQI+AHk/pkSBhQWc9 /qxeUXqEAZ316AgSlj2nR4KEfr31+GaChGEP6pEgoV53PRIkDKNHQI/+eiRI2EWPgB4d9kiQMOth PRIkVOuxRyZIWPW0HgkSmnXZI0HCKHoE9OizR4KETfQI6NFpjwQJk57YI0FCq157ZIKERY/skSCh VLc9EiQMokdAj357JEjYQ4+AHh33SJAw57E9EiQU6rlHJkhY89weCRL6dNbjn/jaESRs6axHFwdJ j7Cl7x4JErb01uO7ZoIkSCjTeY9MkDClux6ZIGFY7z0yQcKS/npkgoRdHfZIkDCLHpvdtEC1Hnsk SFhFjwQJPbrskQkSRvXZYxwkEySseEKPTJCwotMemSBh0iN6JEgY0WuPTJCw6Bk9EiRssNSj+2v8 9P28HCB4/ZyqCZIgoYKhHqf8nP/WLU4fvp4VK1aYY6jH6fhNeiRIaGCvR+e/Cr7xB4fXjQkS1hjs cdx8/Gw/yvVIkFDAWI9u3oycvvUjuNF85QgSxtjq0SVfuHQTMn59cnqEMaZ6dMlXy106cY8ECWMs 9ejmj016JEjczVCPbtyTM+3PGfxeneA4ydVjgoQphnosGi65ekyQMKXzHpkgYUrvPUZBMkFCuUf1 SJBQrvsemSBhyLN6JEjo1n+PlRMkQeJGD+uRCRKqPaBHJkiY8bQeCRKaPaFHJkhY8YgeCRJG0GMO QeIenfX435WryQQJEzrr0a0EyQQJEzrr8VdogiRI3KKzHt1akPQIC57SI0HCgu0eXSPtenyXBFnS I0HiBjs9ytaSGfaWHpkgoVR3PTJBwrAOe3wL7dIhSFyuvx6ZIGFXhz2uBskECe0EetzcY5od4aYe qydIgsTFzvcYvFZ45jR39MgECav67LFglw4TJBSS6vHz1WfZ6obxk3+/m3E9O69qW/fIihVGyWw/ +iOPb5Dqwh7ng4K3Ua06h3LT8x8LVqz0CH1k9q+6JDa1PRIkVCvo8bUuOuZ6j+Mbw/kFa/se5SZI gsSFBPfnrPaY7vG5s0cmSGgm3OPap+Hi9SoTJEySfDyAC3esjm9jfM/+1bfkfR4Eicv0+Hi5r4IV Kz1CmX57ZMUKe5T2mHspgaKRg6smN0ESJC7ScY9MkDBHaY/TQbUXoKhHJkhopbfHxb2WRSNHV05u giRIXEJxj6fXqyX3edAjNNHbY/o857KR42vHBAlbFPd4aOT42glOkASJC/Tdo+QuHYJEe4p7/Lda PbleZYKELcKPX50eqLq94Ve8P2c4tz/nTZCwRfz5VtFzHveH3by/w1XP0Mv3R97fpVPcI0GitWY9 7t3Tv3sOUj0yQcIOwdezSr443eP5+x8/mCBhh+DrWUUvbHW+R4n7H/+RnCAJEm0Jvp6V/0KoxyMy PRbc51HeI0GiqYIe/29dpivJ7cftUbInylxFJkiYoXV/jsTzrSYECSvU3t9xKMcLeiRINKT48QDZ M5o/jRut8dGyPTJBwgrNj5dLDh7zmyrM3j+Z71H0Pg+CRDt6exznwsVJD/XIihUmKO4xe3jS4+Lg lavJfR4wwW6P0xtpxQevXE0mSJiguMfcDtZk760LV7TTPSTZ67kfZEWPBIlG9PaY203rd/H4HpM5 cm1+FJ4gCRJtKO5x5XRBj8tdOqs9MkHCAks9BluU9T2+RHfpECSaUNxj+nod0/akX8YGjwrwx1m/ pqxYoZ/eHmVer2PGBAn9FPeYu79/d+SNq8oECfXkXh8gimf7hPf0KPugAIJEAwI9uvBTWTUl5yD3 fKuJ8ARJkBCnt0ep1+sIyN7nQY8QJ7FeddPH70NKxzvtv1/5Z2INy3vzN87h6IbrwR4JEjqI9zg/ 8yL6bj7SUNjjoSS3e5SeIAkSwkT258yT4+AnxyGaEat7lHy9jpnwfR70CGEFPf6uK+3RP6V/EeFa b216ZJcOdLtkflSzXhWfIAkSomTuf1xUuOjR6ehRfIIkSEi6pMfBufAn920/vtmlA9W0Pl7u+h4J EvfT2mOr9ar8BEmQkKO3x+/B4vOj/C4dgoQYzT02Wa8yQUIxtT0eeruAoh6ZIKGW0h6nlwKoHrnk Ou/v0qnskSAhRG2Px86/qEf5CZIgIUNtjw3nR/n7POgRMpT22HL78d8EKb1LhyAhQm2PQ7P9q+8W EyRBQoLmHocm9z9+MEFCJcH3Yy2fzsp7rFXaI7t0oJL0+5WXFVx3DhVKe2xwnwdB4jzpHitOUnz0 CsU9NpggCRKnyb3+qq0emSChkcz2Y3BkKz2u3+dBkLiNzP5V/3KOkj2m76dTdEHKr3mD+zwIEicV 9PjfddExhXuUfj+dVIsJkiBxjt79OS4YtFhFjxu7dFix4iZ67+9o3iMrVqij9/EAjV4/J9BigiRI nKH48XLy76eTajFBEiROUNzjoZGrrnzBLh1WrLjSo3vcmCBZseIOintsvv3YaIIkSBymt8f2+3Pe 7NKBMop7PDRy7fVnxQpN9PZ46Myre2TFCk309njJerXRBEmQOObxPW5MkKxYcTXFPR4auf4WKNil Q5C4iN4er9l+fLNihSICjyf3j19dGWH5c03r1c0JkiBxLfHnW60dujKsgh63Jkg2IXEpvT0ecqjH Nrt0CBL1ZHt001duGPwi1g3+vTjcYlgNPTaaIAkS1dr0GKYZ/Lyux/bPt5psTZAEiQvJ7s8JPg1D 0uPgwp/vn8N124/bu3SmIOkR7RX0+GddVFTSo3/HuKM97hwu2SMrVugg+3rI8TR5cn4svgThiQ7e DKxYoULLHpP5MTrm/jlcuV7dniBPrFgJElWE3y8geFvj76sZO19mbY8X7s9570yQBImLXPl4ucoe D53F4RuipEdWrGhMcY9uebDfUfSdi5cDHO+RIKHAdT0Ga8/C7cf4RENSYLhlOh/j+C3BihX30/v8 juX+VTe07HF7giRIXMFSj/ES1oX3oPgjnLgpiiZIgkRLinvM3N8x7cKdduCK9vh3gmy0YiVIFNLb Y+7+Dj8/BmtWFx3/r+M3BitW3Exxj1sn9D0mc+Sp+XFnxUqQaE5vj2vbj/GBoj2WTZAEiWa09jgt Plf25zTqsd2KlSBRQmuP+Yev+scDhN9FRzh5c2zv0iFINHa6x6mbeQ9LwWlKzuHQvwVne9yZIAkS bUnMj27l65ITqHn86mhngiRINKW3x2ufb+WxYsWNxHocH2063mP/+YGbn2kV/GTQ3SMrVtxIskc3 P2Zm+nLeAxocqHm9yooVdxLucfkpfvh3dY/Xz48EifsU9PizLt/j/CIB/v/4FVhVr1d3V6wEiWYa zY9D1GMyY9b0WHQBghNJ3CZ7E+QY5KEeCRJbLlmvxhuWyrcf322DpEdsEN6/6sL9q+F69ej2YyWZ HgkSN1H+eLnqkWVulcIeCRLCtPaYfTh5wchCNwtB4hZKe5xCvGX/6vvzTEiCxPW09njwEkj1uPfU 5Dc7WdECPa7YnSAJEvK09njzerVkxUqQEKe0x7v357xLVqwECWlae7z3/o6P/QmSuyEhTG2PB0cW vGkKVqwECVn0uK44SFasEEKPGwp6JEhIEumxIiobj18dlUyQBAlBMo8nL6/KVI8EiYvR4yaCxKUE exxfrmr+ND7zan7ZgMFcj0WbkAQJKQI9Bk9yDJ55PJcYfjTXY9EESZAQItnj4ItLXx7A+WNa65Eg caWCHv+z7nOc6ZE0Oz3ORzLVI0HiQufnRzd93O7R6Hr1XbgJ+QnyWI8ECe/8++n4z8n247Bcydrs sWyCJEgIkOwx2b86TPtUp6+Nzo8EicsIPl7ORZ8Kh7XQI0HiKvRY4m+PBIkL0GOJwgmSIHESz+8o QpC4BD2WIUhcYafHRuz1SJC4wnaP7ZnpsXSfDkHiBHos9SJINEePxUpXrKeCpMhno8dy5UH+Odoj U+TD0WOF4iDfBIlD6LEGQaIteqxSuk+HIHEIPVYp3slKkDiCHuvUBPmHIFGJHitVBPkmSFSix1oX BUmRj0SP1a4JkinykeixHkGiFXo8oCbI43tZCfKB6PGIuiDZq4NS9HhIVZDsZkUpejzmqiAp8lls 9Ti9qOv0gq6LAS7r8aogmSKfxVSP0TvWzS+DHh7julvuGyR7dSDJUo/+TetU9PgNkt2skGSpx2HZ Y3ryK3skSIiz2+P89jzhES698SqD/HP0fAjyMQz3OPg3zRq/GV14671+q+6IJEjssN5jMkdeOz/+ DbJqr86JICnyGUz3uNylc3WPlWvWH6ZIbKLHs9iIhBx7PfrHA/i3eQ2PcMNNSJAQY6vH/eHuuA3H vTrFG5FHi2Qjsn/0KOBVtxH5ZorECnoUQZAQQY8yLguSIrtGj0KqHhrw8z68EckU2TV6lFL10ICf N2tWZNCjnJo166kgKbJb9CioKkjWrFiiR0ljkEyROIgeRX336lywZmWK7BM9yqp6aMDPmzUrIvQo rWbN+u81A1izYkaP4mrWrJ8gmSIxoUd5NWvWz6vqECRG9NhCxZr159QUyZq1M/TYRO2alSkSH/TY xqtmivz3gSkSb3ps5xtk0RT5fWlWpkjQYzvTmrWgyLNBUmQv6LGd1zRF7hf5c27NSpG9oMeWximy ZNF6copk0doHemyqZor8fGSKfDZ6bKx8ihzfcIcp8snosbVX8X6dH6bIx6PH9l7Fd30wRT4dPV6h fIr8fmKKfCp6vETxfp3pXVtPTJEUaRg9XqR0v44PkkXrE9HjVUqnyJ/zRTJFmkWP16mdItmv8zz0 eKHSuz7mIJkiH4YeL1V418ePxBRJkQbR48WumyJZtBpEj1cr3K/DFPlI9Hi9wv06IlMkRdpCjzeo nyIp8iHo8Ra1U+SJRSubkZbQ4z0K7/pginwYerxL6V0f/iuKfAB6vE/hFDl/yX0f3aPHG5Xt1/kR KZIp0gR6vFXZfp0gSIrsGz3eq2y/zg9FPgQ93q1sv04YJEX2ix7vVz9FUmSv6FGBV9HbYUVBUmSf 6FGFsciaKZIie0SPShS9QZ1gkSSpEj2qcWDRymN2ekOPehxZtFJkX+hRk2nRunkkiuwYPepSMkVS ZL/oUZmiRWu6GXmuSJLUgx7VObQZeaZIJkk96FGh15siH8pgj+6fz+flAH30+HeKLCoy/cG5IklS AYs9+k9ucfpOegyK3DrSYoo8VSSTpAL0qNVYZOWilSJts9ejmz+7xck76pEin8hgj+Pm42f7sese 7yqSJO9jsMfgZG7aq/P5ZnT3TSrq9b6+SCbJ+9jrMTyZSzch+4rxnxdFPonpHpe7dPrr8UyRLFvN sddjsF59Ro/Hizw9SZLk1ez1OEz7cwa/Vyc47O7bs5ETRbJutcRgj5vD3X17NnO4SCZJS+jRjLuK JMkL0aMhc5FbSeaLJEkT6NGUqcjtSTJX5NlJkk3JS9CjMd8i95atK0UySWpHj+b8K3J/QzJbJElq R48GvYp27eSLFFi3kmQ79GhT0a6d1SJJUit6tKpo185KkSJJ0mQD9GhXsGtnPcmfZkkyTTZAj5aN u3Z2tiQ3kjx7AUhSGD3a9gr2tt6xbiVJWfRo3qvoLsmG61aSlEOPPfDr1p07QJomSZMC6LEP07r1 d++xrev3gdCkAvTYDb8puftuPK3ul3yzdD2LHnsybUpuT5Lv9aWrUJI0eRQ9dqZs3fpenyYlVq40 eRQ9difYlNw76kaT5y8HTR5Ajz36JvnenyTfq02KJEmTteixU6+xyf8eb1Jk5fptkigL0WPHxib/ TZP7Vf5koxRqkomyED12blq6/v4ejlIoSZosQI/9e81N/pYsXzNNSk2TLF530OMzpE0emCjFmmSi XEePzxE2eXCilG2SKBfo8Vler5e/f7K4yThKuSaZKBfo8YnGKP3itWT1Gv3gD4vXNujxsb5T5e/v XGXlU0NYvMqjx4f7TpW/v0VdNl+8Pr5KekSyVbm3im25eH38VEmPmPgqpy7Xq8xPlEyVp9EjYvkq c8dcedyA7FT5sCrpETlplWtT5crj68SrfEqX9Ih1r9cruGtkbapcfyS6XJW+S7kBVaJH7Juy3Jgq 159GKVpl71nSI4ot7rFMDs9PlO8GVXa7iqVHVAqqzE2Vqy9fN1YpmmV30yU94pDNqXK9yXeLybKj LOkRx21NlauL168WVXawiqVHnLUxVf7cUaXl6ZIeIeLEVDltWIp3aXC6pEcIWjxlZD5ob6p8z122 WsYaCJMeIW3riVwFVb6fHCY9oo2wSt/leNjPT1mXz1vJ0iNamh5xl83yXZrlcyZMesQVslmm02VN mG3uwLy9THrEhV5bq9ggzIqlbKNH/NyUJj3ievlVbOaey7JAO0qTHnGfZLqcw1x7VtdupdbTpEfc 7hVL09x7MZ+VSv/8aRPnf1KCY9Mj1HllLQJN/c6Whf750yrPTKAnKqVH2JCvtDTYzTybXN58pXvB 0iP6s4w1WQJvTp7NEo1lIzXYo/vr+3k5AD1iVbqJ6vchZbZAM4leUqm9HqcK/X/Rge1vMfQlrnN9 C3S9Uslg6bEI4zYeWNu4mURXK60Jdq9d4e23aid7TE+u7dfa27jmLrDsuPlKa4LdY7fHz/YjPV47 rrkLfPG4u8HGG65Lhnv8fnJ+BAeYJ9TVUWd7TObIVleHcRsPzLhtx213/kGPy1061m4ma+Oau8CM 2/r86fHGcc1dYMZtfv5+lR08KuDEcGXnybhtB2bctuNaOX8AM3oE9KBHQA96BPSgR0APegT0oEdA D3oE9KBHQA/RHts8Pt41GXoeUPwiu6HFTTGOKD1weOvKjb0YUGbc6SkYopc3foJSsxu68sJIjSX/ 1+1aDD0PKH6r++eFNuhGfODw1pUbezGg4I3shC9v8ITB+aP8DV16aZSOFQya3F6iYw8me5QcNf3X TjKcpj0K3cj5vy/xG7qU+h6Hxj22+RO30uNwTY+Cl9tfXrEb2SWfv1930WO77cfoC8mRW0054tu7 n0Hlb+Pp71t4azreBhPvscX2o395gO9WZJs/5tILIzJW8G+X5LDJZ9GBnfS4LtzCER14rFF4YP8X GGw9SY083QqCN/K8+hXbxIv+vvy/So3+mEsvjNhYzXpstPVopsfviOIDx6sP4eXSOKR4j/HwEkMm 3/SzP6dVj41ylH4No3FAoz0Kr4SnbuRu5OBvgR6LxmrUY5sck6/khpa/zOHiWvqXFv4vNmj8Ny21 Wboy/Pkx01E76LHh4wFazWPT+KLkdjVEo/qdDeKdB7tHpOaxNo8H8NOX/P4cl45q//EAgFlKQlBy MYB7KQlBycUAMNAjoAk9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60KNa09NP+BU9CL9s tTI98tvqHb9hvcan4SU/QM/4Des19xi+cHb4dNl7njOLdvh16uV73Psf3eC3qZhze03y6+sMv1DF 8j1Oy9bhrtd4QTv8OhVbmx/Hw76f+A32hN+mZv415dh+fAh+m5q5eRYMwkz3u6If/DoBPegR0IMe AT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4B PegR0IMeAT3oEdCDHgE96BHQ4/8B0S9c47NhvpwAAAAASUVORK5CYII= ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/vnd.ms-excel; name="smithtie6.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smithtie6.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAADoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFANMQzAdBAAAABgAAAOEAAgCwBMEAAgAAAOIAAABcAHAADAAATm9ybWFuIFBldHJ5ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAD0BBgACAAMA AQCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIA8AB4AIw3gyI4AAEAAAAB AFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAAAMQAaAMgAAAD/f5ABAAAAAAAA BQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAA AAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5AB AAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAQD/f7wCAAAAAgAABQFBAHIAaQBhAGwAMQAaAMgAAwD/ f7wCAAAAAgAABQFBAHIAaQBhAGwAMQAaAMgABQD/f7wCAAABAgAABQFBAHIAaQBhAGwAMQAaAPAA AQD/f7wCAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAQD/f7wCAAAAAAAABQFBAHIAaQBhAGwAHgQY AAUAEwAAIiQiIywjIzA7XC0iJCIjLCMjMB4EHQAGABgAACIkIiMsIyMwO1tSZWRdXC0iJCIjLCMj MB4EHgAHABkAACIkIiMsIyMwLjAwO1wtIiQiIywjIzAuMDAeBCMACAAeAAAiJCIjLCMjMC4wMDtb UmVkXVwtIiQiIywjIzAuMDAeBDUAKgAwAABfLSIkIiogIywjIzBfLTtcLSIkIiogIywjIzBfLTtf LSIkIiogIi0iXy07Xy1AXy0eBCwAKQAnAABfLSogIywjIzBfLTtcLSogIywjIzBfLTtfLSogIi0i Xy07Xy1AXy0eBD0ALAA4AABfLSIkIiogIywjIzAuMDBfLTtcLSIkIiogIywjIzAuMDBfLTtfLSIk IiogIi0iPz9fLTtfLUBfLR4ENAArAC8AAF8tKiAjLCMjMC4wMF8tO1wtKiAjLCMjMC4wMF8tO18t KiAiLSI/P18tO18tQF8tHgQLAKQABgAAMC4wMDAwHgQKAKUABQAAMC4wMDAeBAgApgADAAAwLjDg ABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAQAAAPX/ IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAA AAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA 9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAA APX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAAEAIAAAAAAAAAAAAAAAwCDgABQABQArAPX/IAAA+AAA AAAAAAAAwCDgABQABQApAPX/IAAA+AAAAAAAAAAAwCDgABQABQAsAPX/IAAA+AAAAAAAAAAAwCDg ABQABQAqAPX/IAAA+AAAAAAAAAAAwCDgABQABQAJAPX/IAAA+AAAAAAAAAAAwCDgABQABgAAAAEA IAAACAAAAAAAAAAAwCDgABQABwAAAAEAIAAACAAAAAAAAAAAwCDgABQACAAAAAEAIAAACAAAAAAA AAAAwCDgABQABwAAAAEAIwAAGAAAAAAAAAAAwCDgABQAAAADAAEAIwAAFAAAAAAAAAAAwCDgABQA AAAAAAEAIwAAEAAAAAAAAAAAwCDgABQACAAAAAEAIwAAGAAAAAAAAAAAwCDgABQABgADAAEAIwAA HAAAAAAAAAAAwCDgABQACAClAAEAIwAAHAAAAAAAAAAAwCDgABQAAACkAAEAIwAAFAAAAAAAAAAA wCDgABQABgCkAAEAIwAAHAAAAAAAAAAAwCDgABQAAAAKAAEAIwAAFAAAAAAAAAAAwCDgABQABwAD AAEAIQAAHAAAAAAAAAAAwCDgABQAAAADAAEAIQAAFAAAAAAAAAAAwCDgABQACAADAAEAIQAAHAAA AAAAAAAAwCDgABQABgADAAEAIQAAHAAAAAAAAAAAwCCTAgQAEIAD/5MCBAARgAb/kwIEABKABP+T AgQAE4AH/5MCBAAAgAD/kwIEABSABf9gAQIAAACFABkA5QwAAAACEQBBdmVyYWdlIFRpZWJyZWFr c4UAGwCAIQAAAAITAFRpZWJyZWFrZXIgUmVxdWlyZWSFAAwALzYAAAAABABEYXRhjAAEAAEAAgCu AQQAAwABBBcACAABAAAAAgACAPwA8AAkAAAAEAAAABYAAFNpbXVsYXRpb24gUGFyYW1ldGVyczoH AABUcmlhbHM6CAAAT3B0aW9uczoQAABUb3RhbCBUaWVicmVha3M6BgAAVm90ZXJzDAAAU21pdGgv L0JvcmRhCAAAQ29wZWxhbmQOAABTbWl0aC8vTWluaW1heAcAAFRpZGVtYW4HAABTY2h1bHplCAAA R29sZGZpc2gCAABTRAMAAFNTRB8AAEVsZWN0aW9ucyBSZXF1aXJpbmcgVGllYnJlYWtlcjoGAABU b3RhbDobAABBdmVyYWdlIFRpZWJyZWFrcy9FbGVjdGlvbjr/AAoECADrBwAADAAAAGAIAACBAAAA AAAAAAAAAAAAAAjDYgBW1G0wAAAAAAAAAgAAAAAAGMNiAImFETACAAAAAAAAAMTDYgBMhREwzBir AAAAAAAAAAAA4IERMAAAAAABAAAAAAAAAMTDYgAEAAAABAAAAAkQAAABAAAAsikVARLFYgAAAAAA AAAAAAEAoIMCAI8BIMRiAAAAAAAsAAAAAAAAAIjCYgCPKxAwAAAAAAAAAADMQMsBr/0PMMxAywEH AAAAKNCdMLzFYgB8YnECAQAAABa2DjAEf2QAAQAAACwAJAAAAAAAoOxiAAAAAAAMxGIAFbQOMAAA AAAEAAAAAAAAiIDFYgAAAAAAAAAAAAAAAAAEHBED6CA7AeggOwEAAAAAAAAAAGF6cDCqKRUBBAAA AArFYgAEAAAAAQAAAAQAAAAKxWIAqikVAQQAAAB5JBIwASE7AYgkEjD2IDsB6CA7AQEhOwEAAAAA AAAAACUAAAABAAAAJAAAACwAAAC0KRUBhPZTMLjEYgB0AAAAAAAAAAIAxzAAAMUwaQBhAAAAAAAA AAAABwAAAE8AcADhPG0wDgDHMNEAAAD6xGIA/AAAAAkAAADNFQQwAADFMOyjxzDRAAAA+sRiAP0A AAD6xGIA/MZiAOzqAjD6xGIAtCkVAQAAAAD8xmIAdAAAAAAAAACOjw8wAAAAAPjEYgAHAAAA//// /9RfFQE4x2IAAAAAAAcAUABlAHIAYwBlAG4AdAAAAAAAAAAwAF0AAAAQscsBAAAAAAAAAACTtQ4w AAAAAAAAAAAAAAAAAAAAACxZFQEBAAAAjMZiAAAAAAAEAAAAAQAAAPzunTAAAAAAWACHAIjGYgAB AAAA2RAAMJZqVDBScFQwwsgQMH4aqgBQAIcAZRAAMAIAAAAOAIcAEbLLAXiIDzAwAAAADgCHAAEA AAAIsssBAAAAAAgAhwD8AYcAAQAAAAEAAAARsssBAAAAAAEAAAAAAAAAMAAAAAAAAAAMxmIAiYUP MAEAAAAAAAAACwAAAAAAAAAGAocAOsdiADjHYgAIAIcAAQAAAAkAAADOWlQwAAAAAGUQADBwalQw 7ASqAEwAAADZEAAw7ASqAHBqVDBMAAAAzlpUMBbHYgAcx2IAAAAAAAAAAAAAAAAAoscQMAkEAAAA AAAAAAAAACcAAABY52IA84MPMKjGYgABAAAAxbn3v0SukoEBAAAAZk5wMEjXnTAnTnAwcRUAMIjG YgAEAAAALFkVAVBPywHwjn8CLFkVAVBPywGoaA8wLFkVAcxAywEIAIcAAAAAAPTGYgAIAAAAFwAA ABTHYgBsT8sBQMdiALq/EDA4x2IACAAAAAgAAAA4x2IA62wPMBcAAAAIAAAAKAIKAAAACQgQAAAG IADTEMwHQQAAAAYAAAAUAAUAAgAAJkEVAAoABwAAUGFnZSAmUIMAAgAAAIQAAgAAAKEAIgAAAABQ AQABAAEARAFuaW1hAAAAAAAA4D8AAAAAAADgP2h1MwACAAMAARACAAAAAhAQAAAAAAAAAAAAMAqr AjAK0wEzEAAAoAAEABMAFABkEAgAAAABAAAAAQADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAA pQAHADoAABUAAQANEBIAAAAHAVMAYwBoAHUAbAB6AGUAURATAAECAACkAAsAOwAAFgAeAAEAAQBR EBMAAgIAAAMACwA7AAAWAB4AAAAAAFEQCAADAQAAAAAAAAYQCAD//wAAAAAAADMQAABfEAIAAAA0 EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEAAAAzEAAAURAPAAACAAClAAcAOgAAFQACAA0QHAAA AAwBUwBtAGkAdABoAC8ALwBCAG8AcgBkAGEAURATAAECAACkAAsAOwAAFgAeAAIAAgBREBMAAgIA AAMACwA7AAAWAB4AAAAAAFEQCAADAQAAAAAAAAYQCAD//wEAAQAAADMQAABfEAIAAAA0EAAARRAC AAAANBAAAAMQDAABAAEACQAJAAEAAAAzEAAAURAPAAACAAClAAcAOgAAFQADAA0QCgAAAAMBUwBT AEQAURATAAECAACkAAsAOwAAFgAeAAMAAwBREBMAAgIAAAMACwA7AAAWAB4AAAAAAFEQCAADAQAA AAAAAAYQCAD//wIAAgAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEAAAAz EAAAURAPAAACAAClAAcAOgAAFQAEAA0QIAAAAA4BUwBtAGkAdABoAC8ALwBNAGkAbgBpAG0AYQB4 AFEQEwABAgAApAALADsAABYAHgAEAAQAURATAAICAAADAAsAOwAAFgAeAAAAAABREAgAAwEAAAAA AAAGEAgA//8DAAMAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAA AFEQDwAAAgAApQAHADoAABUABQANEBQAAAAIAUMAbwBwAGUAbABhAG4AZABREBMAAQIAAKQACwA7 AAAWAB4ABQAFAFEQEwACAgAAAwALADsAABYAHgAAAAAAURAIAAMBAAAAAAAABhAIAP//BAAEAAAA MxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAKUABwA6 AAAVAAYADRAIAAAAAgFTAEQAURATAAECAACkAAsAOwAAFgAeAAYABgBREBMAAgIAAAMACwA7AAAW AB4AAAAAAFEQCAADAQAAAAAAAAYQCAD//wUABQAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQ DAABAAEACQAJAAEAAAAzEAAAURAPAAACAAClAAcAOgAAFQAHAA0QEgAAAAcBVABpAGQAZQBtAGEA bgBREBMAAQIAAKQACwA7AAAWAB4ABwAHAFEQEwACAgAAAwALADsAABYAHgAAAAAAURAIAAMBAAAA AAAABhAIAP//BgAGAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQ AABREA8AAAIAAKUABwA6AAAVAAgADRAUAAAACAFHAG8AbABkAGYAaQBzAGgAURATAAECAACkAAsA OwAAFgAeAAgACABREBMAAgIAAAMACwA7AAAWAB4AAAAAAFEQCAADAQAAAAAAAAYQCAD//wcABwAA ADMQAABfEAIAAAA0EAAARRACAAAANBAAAEQQBAAOAAAAJBACAAIAJRAgAAICAQAAAAAA8f7//zn/ //8AAAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQAgAFAFEQCAAA AQAAAAAAADQQAAAkEAIAAwAlECAAAgIBAAAAAADx/v//Of///wAAAAAAAAAAsQBNACAQAAAzEAAA TxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAAJhACAAUAURAIAAABAAAAAAAANBAAAEYQAgABAEEQEgAA ACcBAAB4AgAAmwsAAHALAAAzEAAATxAUAAIAAgCaAAAALQIAAHsMAACQDAAAHRASAAAAAAAAAAAA AAAAAAAAAAAAADMQAAAgEAgAAQABAAEAAABiEBIAAAAAAAEAAAABAAAAAAAAAG8ANBAAAB0QEgAB AAAAAAAAAAAAAAAAAAAAAAAzEAAAHxAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAeAU4QAgCmADQQAAAlECAAAgIBAAAAAACLBgAAvQ4AAM4AAACXAAAAgQBNAAAAAAAz EAAATxAUAAIAAgAAAAAAAAAAACoAAAAWAAAAJhACAAoAURAIAAABAAAAAAAADRAQAAAABgFWAG8A dABlAHIAcwAnEAYAAwAAAAAANBAAACUQIAACAgEAAAAAADMAAACNBgAAZwAAAE0DAACBAk0AAABa ADMQAABPEBQAAgACAAAAAAAAAAAAFgAAAHUAAAAmEAIACgBREAgAAAEAAAAAAAANECYAAAARAUEA dgBlAHIAYQBnAGUAIABUAGkAZQBiAHIAZQBhAGsAcwAnEAYAAgAAAAAANBAAADUQAAAyEAQAAAAD ADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAAAQAAABYACAA0EAAAFBAUAAAAAAAAAAAA AAAAAAAAAAAAAAAAMxAAABgQAgAAACIQCgAAAAAAAAAAAA8AFRAUAEkNAAAKBgAARAIAAEwEAAAD AR8AMxAAAE8QFAAFAAIASQ0AAAoGAAAAAAAAAAAAACUQIAACAgEAAAAAAPH+//85////AAAAAAAA AACxAE0AAAAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAABREAgAAAEAAAAAAAA0EAAANBAA AAYQCAAAAAAA/f8AADMQAABfEAIAAAAHEAwAAAAAAAAA//8JAE0AChAQAP///wAAAAAAAQABAE4A TQALEAIAAABdEAIAAQAJEBQAAAAAAAAAAAAAAAAACAAIAGQAAAA0EAAANBAAADQQAAAlECAAAgIB AAAAAAB3BQAAUgAAALIEAABKAQAAgQBNADAQAAAzEAAATxAUAAIAAgAAAAAAAAAAAAcBAAAwAAAA JhACAAkAURAIAAABAAAAAAAADRB8AAAAPAFUAGkAZQBiAHIAZQBhAGsAcwAgAHAAZQByACAARQBs AGUAYwB0AGkAbwBuAAoAMgA1ACwAMAAwADAAIABUAHIAaQBhAGwAcwAsACAANgAgAE8AcAB0AGkA bwBuAHMAIABpAG4AIABTAG0AaQB0AGgAIABTAGUAdAAnEAYAAQAAAAAANBAAADQQAAAAAg4AAAAA AAkAAAAAAAgAAABlEAIAAgADAg4AAAAAAAAAAAAAAAAAGEADAg4AAAABAAAAAAAAAAAAGEADAg4A AAACAAAAAAAAAAAAGEADAg4AAAADAAAAAAAAAAAAGEADAg4AAAAEAAAAAAAAAAAAGEADAg4AAAAF AAAAAAAAAAAAGEADAg4AAAAGAAAAAAAAAAAAGEADAg4AAAAHAAAAAAAAAAAAGEADAg4AAQAAAAAA AAAAAAAAKEADAg4AAQABAAAAAAAAAAAAKEADAg4AAQACAAAAAAAAAAAAKEADAg4AAQADAAAAAAAA AAAAKEADAg4AAQAEAAAAAAAAAAAAKEADAg4AAQAFAAAAAAAAAAAAKEADAg4AAQAGAAAAAAAAAAAA KEADAg4AAQAHAAAAAAAAAAAAKEADAg4AAgAAAAAAAAAAAAAAOEADAg4AAgABAAAAAAAAAAAAOEAD Ag4AAgACAAAAAAAAAAAAOEADAg4AAgADAAAAAAAAAAAAOEADAg4AAgAEAAAAAAAAAAAAOEADAg4A AgAFAAAAAAAAAAAAOEADAg4AAgAGAAAAAAAAAAAAOEADAg4AAgAHAAAAAAAAAAAAOEADAg4AAwAA AAAAAAAAAAAASEADAg4AAwABAAAAAAAAAAAASEADAg4AAwACAAAAAAAAAAAASEADAg4AAwADAAAA AAAAAAAASEADAg4AAwAEAAAAAAAAAAAASEADAg4AAwAFAAAAAAAAAAAASEADAg4AAwAGAAAAAAAA AAAASEADAg4AAwAHAAAAAAAAAAAASEADAg4ABAAAAAAAAAAAAAAAWEADAg4ABAABAAAAAAAAAAAA WEADAg4ABAACAAAAAAAAAAAAWEADAg4ABAADAAAAAAAAAAAAWEADAg4ABAAEAAAAAAAAAAAAWEAD Ag4ABAAFAAAAAAAAAAAAWEADAg4ABAAGAAAAAAAAAAAAWEADAg4ABAAHAAAAAAAAAAAAWEADAg4A BQAAAAAAAAAAAAAAaEADAg4ABQABAAAAAAAAAAAAaEADAg4ABQACAAAAAAAAAAAAaEADAg4ABQAD AAAAAAAAAAAAaEADAg4ABQAEAAAAAAAAAAAAaEADAg4ABQAFAAAAAAAAAAAAaEADAg4ABQAGAAAA AAAAAAAAaEADAg4ABQAHAAAAAAAAAAAAaEADAg4ABgAAAAAAAAAAAAAAeEADAg4ABgABAAAAAAAA AAAAeEADAg4ABgACAAAAAAAAAAAAeEADAg4ABgADAAAAAAAAAAAAeEADAg4ABgAEAAAAAAAAAAAA eEADAg4ABgAFAAAAAAAAAAAAeEADAg4ABgAGAAAAAAAAAAAAeEADAg4ABgAHAAAAAAAAAAAAeEAD Ag4ABwAAAAAAAAAAAAAAiEADAg4ABwABAAAAAAAAAAAAiEADAg4ABwACAAAAAAAAAAAAiEADAg4A BwADAAAAAAAAAAAAiEADAg4ABwAEAAAAAAAAAAAAiEADAg4ABwAFAAAAAAAAAAAAiEADAg4ABwAG AAAAAAAAAAAAiEADAg4ABwAHAAAAAAAAAAAAiEADAg4ACAAAAAAAAAAAAAAAmEADAg4ACAABAAAA AAAAAAAAmEADAg4ACAACAAAAAAAAAAAAmEADAg4ACAADAAAAAAAAAAAAmEADAg4ACAAEAAAAAAAA AAAAmEADAg4ACAAFAAAAAAAAAAAAmEADAg4ACAAGAAAAAAAAAAAAmEADAg4ACAAHAAAAAAAAAAAA mEBlEAIAAQADAg4AAAAAAAAA3nGKjuTyrz8DAg4AAAABAAAAdY4B2evdvz8DAg4AAAACAAAAaNDQ P8HF0j8DAg4AAAADAAAAbHh6pSxD1D8DAg4AAAAEAAAAwoanV8oy1D8DAg4AAAAFAAAA+aBns+pz BEADAg4AAAAGAAAAOdGuQspPEEADAg4AAAAHAAAAXtcv2A3bDEADAg4AAQAAAAAAXb9gN2xblD8D Ag4AAQABAAAAejarPldbsT8DAg4AAQACAAAAVryReeQPxj8DAg4AAQADAAAAZ341BwjmyD8DAg4A AQAEAAAAti3KbJBJ1j8DAg4AAQAFAAAAl/+Qfvs6AUADAg4AAQAGAAAAg0wychb2BUADAg4AAQAH AAAACcTr+gW7A0ADAg4AAgAAAAAAcv4mFCLgcD8DAg4AAgABAAAABaipZWt9oT8DAg4AAgACAAAA a4Ko+wCktj8DAg4AAgADAAAAwOyePCzUuj8DAg4AAgAEAAAAvalIhbGF2D8DAg4AAgAFAAAAaYzW UdUE9z8DAg4AAgAGAAAAahg+IqZE+j8DAg4AAgAHAAAAMxtkkpGz+D8DAg4AAwAAAAAAi+B/K9mx UT8DAg4AAwABAAAAERlW8UbmkT8DAg4AAwACAAAAD9b/OcyXpz8DAg4AAwADAAAApyIVxhaCrD8D Ag4AAwAEAAAAX5hMFYxK2j8DAg4AAwAFAAAARYE+kSdJ6z8DAg4AAwAGAAAAmrZ/ZaVJ7T8DAg4A AwAHAAAAtAJDVrd67j8DAg4ABAAAAAAAD9b/OcyXNz8DAg4ABAABAAAAO99PjZdugj8DAg4ABAAC AAAAsmMjEK/rlz8DAg4ABAADAAAAVyHlJ9U+nT8DAg4ABAAEAAAAHjNQGf8+2z8DAg4ABAAFAAAA NC4cCMkC3j8DAg4ABAAGAAAADkqYaftX3j8DAg4ABAAHAAAAEsKjjSPW4j8DAg4ABQAAAAAAaR1V TRB1Hz8DAg4ABQABAAAAATW1bK0vcj8DAg4ABQACAAAAx7q4jQbwhj8DAg4ABQADAAAA6rKY2Hxc iz8DAg4ABQAEAAAAsfm4NlSM2z8DAg4ABQAFAAAAS+XtCKcFzz8DAg4ABQAGAAAAR6zFpwAYzz8D Ag4ABQAHAAAA/N6mP/uR2j8DAg4ABgAAAAAA8WjjiLX4BD8DAg4ABgABAAAABcB4Bg39Yz8DAg4A BgACAAAAsmMjEK/rdz8DAg4ABgADAAAA1VsDWyVYfD8DAg4ABgAEAAAA3xXB/1ay2z8DAg4ABgAF AAAAKuPfZ1w4wD8DAg4ABgAGAAAAZB75g4Hnvj8DAg4ABgAHAAAAlIeFWtO80z8DAg4ABwAAAAAA AAAAAAAAAAADAg4ABwABAAAAGhcOhGQBUz8DAg4ABwACAAAAYTJVMCqpYz8DAg4ABwADAAAAsmMj EK/rZz8DAg4ABwAEAAAAEk4LXvQV3D8DAg4ABwAFAAAAQ1a3ek56rz8DAg4ABwAGAAAAS8gHPZtV rz8DAg4ABwAHAAAAJo3ROqqa0D8DAg4ACAAAAAAAAAAAAAAAAAADAg4ACAABAAAAS7A4nPnVPD8D Ag4ACAACAAAAD9b/OcyXVz8DAg4ACAADAAAA5SfVPh2PWT8DAg4ACAAEAAAAGLK61XPS2z8DAg4A CAAFAAAAm8k329yYnj8DAg4ACAAGAAAAADrMlxdgnz8DAg4ACAAHAAAATzv8NVmjzj9lEAIAAwA+ AgoACAAHAAAATzv8NaAABAATABQACgAAAAkIEAAABiAA0xDMB0EAAAAGAAAAFAAFAAIAACZBFQAK AAcAAFBhZ2UgJlCDAAIAAACEAAIAAAChACIAAAAAUAEAAQABAEQBzj9lAAAAAAAAAOA/AAAAAAAA 4D9FADMAAgADAAEQAgAAAAIQEAAAAAAAAAAAADAKqwIwCtMBMxAAAKAABAATABQAZBAIAAAAAQAA AAEAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAjAAEADRASAAAABwFTAGMAaAB1 AGwAegBlAFEQEwABAgAACgALADsAACQALAABAAEAURATAAICAAADAAsAOwAAJAAsAAAAAABREAgA AwEAAAAAAAAGEAgA//8AAAAAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQAB AAAAMxAAAFEQDwAAAgAAAAAHADoAACMAAgANEBwAAAAMAVMAbQBpAHQAaAAvAC8AQgBvAHIAZABh AFEQEwABAgAACgALADsAACQALAACAAIAURATAAICAAADAAsAOwAAJAAsAAAAAABREAgAAwEAAAAA AAAGEAgA//8BAAEAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAA AFEQDwAAAgAAAAAHADoAACMAAwANEAoAAAADAVMAUwBEAFEQEwABAgAACgALADsAACQALAADAAMA URATAAICAAADAAsAOwAAJAAsAAAAAABREAgAAwEAAAAAAAAGEAgA//8CAAIAAAAzEAAAXxACAAAA NBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAAAAAHADoAACMABAANECAA AAAOAVMAbQBpAHQAaAAvAC8ATQBpAG4AaQBtAGEAeABREBMAAQIAAAoACwA7AAAkACwABAAEAFEQ EwACAgAAAwALADsAACQALAAAAAAAURAIAAMBAAAAAAAABhAIAP//AwADAAAAMxAAAF8QAgAAADQQ AABFEAIAAAA0EAAAAxAMAAEAAQAJAAkAAQAAADMQAABREA8AAAIAAAAABwA6AAAjAAUADRAUAAAA CAFDAG8AcABlAGwAYQBuAGQAURATAAECAAAKAAsAOwAAJAAsAAUABQBREBMAAgIAAAMACwA7AAAk ACwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wQABAAAADMQAABfEAIAAAA0EAAARRACAAAANBAAAAMQ DAABAAEACQAJAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAIwAGAA0QCAAAAAIBUwBEAFEQEwABAgAA CgALADsAACQALAAGAAYAURATAAICAAADAAsAOwAAJAAsAAAAAABREAgAAwEAAAAAAAAGEAgA//8F AAUAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAAADEAwAAQABAAkACQABAAAAMxAAAFEQDwAAAgAA AAAHADoAACMABwANEBIAAAAHAVQAaQBkAGUAbQBhAG4AURATAAECAAAKAAsAOwAAJAAsAAcABwBR EBMAAgIAAAMACwA7AAAkACwAAAAAAFEQCAADAQAAAAAAAAYQCAD//wYABgAAADMQAABfEAIAAAA0 EAAARRACAAAANBAAAAMQDAABAAEACQAJAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAIwAIAA0QFAAA AAgBRwBvAGwAZABmAGkAcwBoAFEQEwABAgAACgALADsAACQALAAIAAgAURATAAICAAADAAsAOwAA JAAsAAAAAABREAgAAwEAAAAAAAAGEAgA//8HAAcAAAAzEAAAXxACAAAANBAAAEUQAgAAADQQAABE EAQADgAAACQQAgACACUQIAACAgEAAAAAAPH+//85////AAAAAAAAAACxAE0AIBAAADMQAABPEBQA AgACAAAAAAAAAAAAAAAAAAAAAAAmEAIABQBREAgAAAEAAAAAAAA0EAAAJBACAAMAJRAgAAICAQAA AAAA8f7//zn///8AAAAAAAAAALEATQAgEAAAMxAAAE8QFAACAAIAAAAAAAAAAAAAAAAAAAAAACYQ AgAFAFEQCAAAAQAAAAAAADQQAABGEAIAAQBBEBIAAABtAQAAeAIAAFULAABwCwAAMxAAAE8QFAAC AAIAmgAAAC0CAAB7DAAAkAwAAB0QEgAAAAAAAAAAAAAAAAAAAAAAAAAzEAAAIBAIAAEAAQABAAAA YhASAAAAAAABAAAAAQAAAAAAAABvADQQAAAdEBIAAQAAAAAAAAAAAAAAAAAAAAAAMxAAAB8QKgAA AAAAAAAAAAAAAAAAAPA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAFOEAIACQA0EAAAJRAgAAIC AQAAAAAAsAYAAL0OAADOAAAAlwAAAIEATQAAAAAAMxAAAE8QFAACAAIAAAAAAAAAAAAqAAAAFgAA ACYQAgAKAFEQCAAAAQAAAAAAAA0QEAAAAAYBVgBvAHQAZQByAHMAJxAGAAMAAAAAADQQAAAlECAA AgIBAAAAAAAzAAAAZAYAAGcAAACgAwAAgQJNAAAAWgAzEAAATxAUAAIAAgAAAAAAAAAAABYAAACA AAAAJhACAAoAURAIAAABAAAAAAAADRAqAAAAEwFUAGkAZQBiAHIAZQBhAGsAZQByACAAUgBlAHEA dQBpAHIAZQBkACcQBgACAAAAAAA0EAAANRAAADIQBAAAAAMAMxAAAAcQDACAgIAAAAAAAAAAFwAK EBAAwMDAAAAAAAABAAAAFgAIADQQAAAUEBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAzEAAAGBACAAAA IhAKAAAAAAAAAAAADwAVEBQASQ0AAAoGAABEAgAATAQAAAMBHwAzEAAATxAUAAUAAgBJDQAACgYA AAAAAAAAAAAAJRAgAAICAQAAAAAA8f7//zn///8AAAAAAAAAALEATQAAAAAAMxAAAE8QFAACAAIA AAAAAAAAAAAAAAAAAAAAAFEQCAAAAQAAAAAAADQQAAA0EAAABhAIAAAAAAD9/wAAMxAAAF8QAgAA AAcQDAAAAAAAAAD//wkATQAKEBAA////AAAAAAABAAEATgBNAAsQAgAAAF0QAgABAAkQFAAAAAAA AAAAAAAAAAAIAAgAZAAAADQQAAA0EAAANBAAACUQIAACAgEAAAAAAHcFAABSAAAAsgQAAEoBAACB AE0AMBAAADMQAABPEBQAAgACAAAAAAAAAAAABwEAADAAAAAmEAIACQBREAgAAAEAAAAAAAANEIwA AABEAUUAbABlAGMAdABpAG8AbgBzACAAUgBlAHEAdQBpAHIAaQBuAGcAIABUAGkAZQBiAHIAZQBh AGsAZQByAAoAMgA1ACwAMAAwADAAIABUAHIAaQBhAGwAcwAsACAANgAgAE8AcAB0AGkAbwBuAHMA IABpAG4AIABTAG0AaQB0AGgAIABTAGUAdAAnEAYAAQAAAAAANBAAADQQAAAAAg4AAAAAAAkAAAAA AAgAAABlEAIAAgADAg4AAAAAAAAAAAAAAAAAGEADAg4AAAABAAAAAAAAAAAAGEADAg4AAAACAAAA AAAAAAAAGEADAg4AAAADAAAAAAAAAAAAGEADAg4AAAAEAAAAAAAAAAAAGEADAg4AAAAFAAAAAAAA AAAAGEADAg4AAAAGAAAAAAAAAAAAGEADAg4AAAAHAAAAAAAAAAAAGEADAg4AAQAAAAAAAAAAAAAA KEADAg4AAQABAAAAAAAAAAAAKEADAg4AAQACAAAAAAAAAAAAKEADAg4AAQADAAAAAAAAAAAAKEAD Ag4AAQAEAAAAAAAAAAAAKEADAg4AAQAFAAAAAAAAAAAAKEADAg4AAQAGAAAAAAAAAAAAKEADAg4A AQAHAAAAAAAAAAAAKEADAg4AAgAAAAAAAAAAAAAAOEADAg4AAgABAAAAAAAAAAAAOEADAg4AAgAC AAAAAAAAAAAAOEADAg4AAgADAAAAAAAAAAAAOEADAg4AAgAEAAAAAAAAAAAAOEADAg4AAgAFAAAA AAAAAAAAOEADAg4AAgAGAAAAAAAAAAAAOEADAg4AAgAHAAAAAAAAAAAAOEADAg4AAwAAAAAAAAAA AAAASEADAg4AAwABAAAAAAAAAAAASEADAg4AAwACAAAAAAAAAAAASEADAg4AAwADAAAAAAAAAAAA SEADAg4AAwAEAAAAAAAAAAAASEADAg4AAwAFAAAAAAAAAAAASEADAg4AAwAGAAAAAAAAAAAASEAD Ag4AAwAHAAAAAAAAAAAASEADAg4ABAAAAAAAAAAAAAAAWEADAg4ABAABAAAAAAAAAAAAWEADAg4A BAACAAAAAAAAAAAAWEADAg4ABAADAAAAAAAAAAAAWEADAg4ABAAEAAAAAAAAAAAAWEADAg4ABAAF AAAAAAAAAAAAWEADAg4ABAAGAAAAAAAAAAAAWEADAg4ABAAHAAAAAAAAAAAAWEADAg4ABQAAAAAA AAAAAAAAaEADAg4ABQABAAAAAAAAAAAAaEADAg4ABQACAAAAAAAAAAAAaEADAg4ABQADAAAAAAAA AAAAaEADAg4ABQAEAAAAAAAAAAAAaEADAg4ABQAFAAAAAAAAAAAAaEADAg4ABQAGAAAAAAAAAAAA aEADAg4ABQAHAAAAAAAAAAAAaEADAg4ABgAAAAAAAAAAAAAAeEADAg4ABgABAAAAAAAAAAAAeEAD Ag4ABgACAAAAAAAAAAAAeEADAg4ABgADAAAAAAAAAAAAeEADAg4ABgAEAAAAAAAAAAAAeEADAg4A BgAFAAAAAAAAAAAAeEADAg4ABgAGAAAAAAAAAAAAeEADAg4ABgAHAAAAAAAAAAAAeEADAg4ABwAA AAAAAAAAAAAAiEADAg4ABwABAAAAAAAAAAAAiEADAg4ABwACAAAAAAAAAAAAiEADAg4ABwADAAAA AAAAAAAAiEADAg4ABwAEAAAAAAAAAAAAiEADAg4ABwAFAAAAAAAAAAAAiEADAg4ABwAGAAAAAAAA AAAAiEADAg4ABwAHAAAAAAAAAAAAiEADAg4ACAAAAAAAAAAAAAAAmEADAg4ACAABAAAAAAAAAAAA mEADAg4ACAACAAAAAAAAAAAAmEADAg4ACAADAAAAAAAAAAAAmEADAg4ACAAEAAAAAAAAAAAAmEAD Ag4ACAAFAAAAAAAAAAAAmEADAg4ACAAGAAAAAAAAAAAAmEADAg4ACAAHAAAAAAAAAAAAmEBlEAIA AQADAg4AAAAAAAAA3nGKjuTyrz8DAg4AAAABAAAArBxaZDvfvz8DAg4AAAACAAAA2qz6XG3F0j8D Ag4AAAADAAAAbHh6pSxD1D8DAg4AAAAEAAAAwoanV8oy1D8DAg4AAAAFAAAA0LNZ9bna6j8DAg4A AAAGAAAAHqfoSC7/7z8DAg4AAAAHAAAAzqrP1Vbs7z8DAg4AAQAAAAAAOPjCZKpglD8DAg4AAQAB AAAAejarPldbsT8DAg4AAQACAAAAjErqBDQRxj8DAg4AAQADAAAATDeJQWDlyD8DAg4AAQAEAAAA m+Ydp+hI1j8DAg4AAQAFAAAAVTAqqRPQ6j8DAg4AAQAGAAAAmpmZmZmZ7z8DAg4AAQAHAAAA1sVt NIC37j8DAg4AAgAAAAAACRueXinLcD8DAg4AAgABAAAA3+ALk6mCoT8DAg4AAgACAAAA/mX35GGh tj8DAg4AAgADAAAAwOyePCzUuj8DAg4AAgAEAAAA2PD0SlmG2D8DAg4AAgAFAAAAINJvXwfO5z8D Ag4AAgAGAAAAYcPTK2UZ7D8DAg4AAgAHAAAA5/up8dJN6j8DAg4AAwAAAAAAL26jAbwFUj8DAg4A AwABAAAA7FG4HoXrkT8DAg4AAwACAAAAfPKwUGuapz8DAg4AAwADAAAAFD/G3LWErD8DAg4AAwAE AAAAX5hMFYxK2j8DAg4AAwAFAAAAqMZLN4lB4j8DAg4AAwAGAAAA8IXJVMGo5D8DAg4AAwAHAAAA klz+Q/rt4z8DAg4ABAAAAAAALUMc6+I2Oj8DAg4ABAABAAAAO99PjZdugj8DAg4ABAACAAAAZ9Xn aiv2lz8DAg4ABAADAAAADJOpglFJnT8DAg4ABAAEAAAAkQ96Nqs+2z8DAg4ABAAFAAAAXdxGA3gL 2D8DAg4ABAAGAAAASOF6FK5H2T8DAg4ABAAHAAAAJLn8h/Tb2z8DAg4ABQAAAAAALUMc6+I2Gj8D Ag4ABQABAAAAL26jAbwFcj8DAg4ABQACAAAAx7q4jQbwhj8DAg4ABQADAAAAU5YhjnVxiz8DAg4A BQAEAAAAlrIMcayL2z8DAg4ABQAFAAAALbKd76fGyz8DAg4ABQAGAAAAJzEIrBxazD8DAg4ABQAH AAAAak3zjlN01D8DAg4ABgAAAAAAAAAAAAAAAAADAg4ABgABAAAAYTJVMCqpYz8DAg4ABgACAAAA 4JwRpb3Bdz8DAg4ABgADAAAAbHh6pSxDfD8DAg4ABgAEAAAA+1xtxf6y2z8DAg4ABgAFAAAAqFfK MsSxvj8DAg4ABgAGAAAAcT0K16NwvT8DAg4ABgAHAAAAOwFNhA1Pzz8DAg4ABwAAAAAAAAAAAAAA AAADAg4ABwABAAAAYTJVMCqpUz8DAg4ABwACAAAAYTJVMCqpYz8DAg4ABwADAAAA4JwRpb3BZz8D Ag4ABwAEAAAA9wZfmEwV3D8DAg4ABwAFAAAAVHQkl/+Qrj8DAg4ABwAGAAAAuB6F61G4rj8DAg4A BwAHAAAAXW3F/rJ7yj8DAg4ACAAAAAAAAAAAAAAAAAADAg4ACAABAAAALUMc6+I2Oj8DAg4ACAAC AAAAx7q4jQbwVj8DAg4ACAADAAAALUMc6+I2Wj8DAg4ACAAEAAAAio7k8h/S2z8DAg4ACAAFAAAA JXUCmggbnj8DAg4ACAAGAAAAxY8xdy0hnz8DAg4ACAAHAAAAC0YldQKayD9lEAIAAwA+AgoACAYH AAAAC0YldaAABAATABQACgAAAAkIEAAABhAA0xDMB0EAAAAGAAAACwIYAAAAAAAAAAAALgAAAHE4 AAAVSwAAblMAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHSTWJQP18AAgABACoAAgAA ACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAAABUAAACDAAIAAACEAAIA AABNAH4BAABIAFAAIABMAGEAcwBlAHIASgBlAHQAIAA2AFAALwA2AE0AUAAgAC0AIABFAG4AaABh AG4AYwBlAGQAAAAAAAAAAAREANQAqAADDwAAAQABAPYE+AIAAAEABwD8/wIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACkAAAAPyfOZ AAABAAEAAQAAAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAALgCjBQAAAAAAAAD/AAIAAAABAgBYAgAAAAECAAMAAAAAAAAAAA4A+AL2BAAAhwAAAAACAAQA rwQHAAAAsAQBAAAAsQQCAAAAtQQEAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAApAKEAIgABAGQAAQAB AAEAAgD8/wAAAAAAAAAA4D8AAAAAAADgPwEAVQACAAgAfQAMAAAAAACSCCIAAgACAH0ADAABAAEA SQgaAAYAAgB9AAwAAgACANsMGgAGAAIAfQAMAAMAAwBJBxoABgACAH0ADAAEAAQASQ8aAAYAAgB9 AAwABQAFALYJGgAGAAIAfQAMAAYABgAACBoABgACAH0ADAAHAAcAAAkaAAYAAgB9AAwACAAIAG0I GgAGAAIAkAATAAEABgUAAFJvdyAxOABSb3cgOAAAAg4AAAAAAC4AAAAAAAkAAAAIAhAAAAAAAAkA /wAAADxsgAEWgAgCEAACAAAACQD/AAAAAAAAAQAACAIQAAMAAAAJAP8AAAAAAAABYgAIAhAABQAA AAkA/wAAAGIAgAEWAAgCEAAHAAAACQD/AAAAYgCAAReACAIQAAgAAAAJAP8AAABiAAABAAAIAhAA CQAAAAkA/wAAAGIAAAFiAAgCEAAKAAAACQD/AAAAYgAAAWIACAIQAAsAAAAJAP8AAAAAAAABqgAI AhAADAAAAAkA/wAAAAAAAAEAAAgCEAANAAAACQD/AAAAAAAAAQAACAIQAA4AAAAJAP8AAAAAAAAB AAAIAhAADwAAAAkA/wAAAAAAAAEAAAgCEAAQAAAACQD/AAAAcQIAAQAACAIQABEAAAAJAP8AAAAA AIABFQAIAhAAEwAAAAkA/wAAAAAAgAEWAAgCEAAVAAAACQD/AAAAYgCAARcACAIQABYAAAAJAP8A AAABMAABAAAIAhAAFwAAAAkA/wAAAAAAAAEAAAgCEAAYAAAACQD/AAAAAAAAAQAACAIQABkAAAAJ AP8AAABiAAABYgAIAhAAGgAAAAkA/wAAAGIAAAECAAgCEAAbAAAACQD/AAAAAAAAAQAACAIQABwA AAAJAP8AAACqAAABAAAIAhAAHQAAAAkA/wAAAGwAAAEAAAgCEAAeAAAACQD/AAAAAAAAAQAACAIQ AB8AAAAJAP8AAAAAAIABFQD9AAoAAAAAACEAAAAAAL4AFgAAAAEAGAAYABgAGAAYABgAGAAYAAgA /QAKAAIAAAAiAAEAAAB+AgoAAgABABkAAGrYQP0ACgADAAAAIgACAAAAfgIKAAMAAQAaAAAAGED9 AAoABQAAACEAAwAAAL4AFgAFAAEAGAAYABgAGAAYABgAGAAYAAgA/QAKAAcAAAAjAAQAAAD9AAoA BwABABsACQAAAP0ACgAHAAIAGwAFAAAA/QAKAAcAAwAbAAwAAAD9AAoABwAEABsABwAAAP0ACgAH AAUAGwAGAAAA/QAKAAcABgAbAAsAAAD9AAoABwAHABsACAAAAP0ACgAHAAgAGwAKAAAAvQA8AAgA AAAiAAAAGEAZAABgmEAZAABQqEAZAAClvEAZAADrvkAZAADSvkAZAGA170AZAMDj+EAZAOAD9kAI AL0APAAJAAAAIgAAAChAGQAAEH9AGQAAfJpAGQAA1bBAGQAA/7JAGQAAAcFAGQCgSupAGQBQwfBA GQBAG+5ACAC9ADwACgAAACIAAAA4QBkAAMBZQBkAALCKQBkAAEahQBkAAHikQBkAgLXCQBkA4I/h QBkAgArkQBkAgNjiQAgAvQA8AAsAAAAiAAAASEAZAAAAO0AZAABQe0AZAAAAkkAZAADAlUAZAAAP xEAZAEDR1EAZAEBY1kAZAABB10AIAL0APAAMAAAAIgAAAFhAGQAAACJAGQAAIGxAGQAAQIJAGQAA UIZAGQCAycRAGQCA5cZAGQCAJsdAGQAAvsxACAC9ADwADQAAACIAAABoQBkAAAAIQBkAAMBbQBkA AIBxQBkAAOB0QBkAgATFQBkAAKu3QBkAALm3QBkAgEXEQAgAvQA8AA4AAAAiAAAAeEAZAAAA8D8Z AACATkAZAABAYkAZAACgZUAZAIAhxUAZAADAqEAZAACUp0AZAAAevkAIAL0APAAPAAAAIgAAAIhA GQAAAAAAGQAAAD1AGQAAAE5AGQAAQFJAGQCAbcVAGQAABJhAGQAA6JdAGQAAVrlACAC9ADwAEAAA ACIAAACYQBkAAAAAABkAAAAmQBkAAABCQBkAAIBDQBkAADrFQBkAAFiHQBkAAPCHQBkAAGC3QAgA /QAKABEAAAAkAA4AAAAGABsAEQABABwAAAAAAAAwoUAIABEACP8FAAERAAEAvAQXABEAEQABCAAH DQAt9////wDAAMAZEC4HBgAjABEAAgAcAAAAAAAAh7lAAADAAMD9DQAlCAAQAALAAsAZEC4HBgAb ABEAAwAcAAAAAACAd89ACAARAAL/BQABEQABAAYAGwARAAQAHAAAAAAAwLLRQAgAEQAH/wUAAREA AQAGABsAEQAFABwAAAAAALAY9kAIABEABP8FAAERAAEABgAbABEABgAcAAAAAAAwNAhBCAARAAP/ BQABEQABAAYAGwARAAcAHAAAAAAAcHYPQQgAEQAB/wUAAREAAQAGABsAEQAIABwAAAAAANitD0EI ABEABv8FAAERAAEA/QAKABMAAAAhAA8AAAC+ABYAEwABABgAGAAYABgAGAAYABgAGAAIAP0ACgAV AAAAIwAEAAAA/QAKABUAAQAdAAkAAAD9AAoAFQACAB0ABQAAAP0ACgAVAAMAHQAMAAAA/QAKABUA BAAdAAcAAAD9AAoAFQAFAB0ABgAAAP0ACgAVAAYAHQALAAAA/QAKABUABwAdAAgAAAD9AAoAFQAI AB0ACgAAAH4CCgAWAAAAIgAAABhABgAhABYAAQAeAN5xio7k8q8/AAAfAAj/CwBECAABwEQCAAEA BgYAGwAWAAIAHgB1jgHZ692/PwgAFgAD/gUAARYAAgC8BBUAFgAWAAIIAAcLAEzy/wDARAIAAQAG BgAbABYAAwAeAGjQ0D/BxdI/CAAWAAT/BQABFgACAAYAGwAWAAQAHgBseHqlLEPUPwgAFgAF/wUA ARYAAgAGABsAFgAFAB4AwoanV8oy1D8IABYABv8FAAEWAAIABgAbABYABgAeAPmgZ7PqcwRACAAW AAf/BQABFgACAAYAGwAWAAcAHgA50a5Cyk8QQAgAFgAI/wUAARYAAgAGABsAFgAIAB4AXtcv2A3b DEAIABcAAv8FAAEWAAIAfgIKABcAAAAiAAAAKEAGABsAFwABAB4AXb9gN2xblD8IABgAAf8FAAEX AAEAvAQVABcAHgABCABACwBM8v8AwEQCAAEABgYAGwAXAAIAHgB6Nqs+V1uxPwgAFwAD/wUAARcA AQAGABsAFwADAB4AVryReeQPxj8IABcABP8FAAEXAAEABgAbABcABAAeAGd+NQcI5sg/CAAXAAX/ BQABFwABAAYAGwAXAAUAHgC2LcpskEnWPwgAFwAG/wUAARcAAQAGABsAFwAGAB4Al/+Qfvs6AUAI ABcAB/8FAAEXAAEABgAbABcABwAeAINMMnIW9gVACAAXAAj/BQABFwABAAYAGwAXAAgAHgAJxOv6 BbsDQAgAGAAC/wUAARcAAQB+AgoAGAAAACIAAAA4QAYAGwAYAAEAHgBy/iYUIuBwPwgAGQAB/wUA ARcAAQAGABsAGAACAB4ABaipZWt9oT8IABgAA/8FAAEXAAEABgAbABgAAwAeAGuCqPsApLY/CAAY AAT/BQABFwABAAYAGwAYAAQAHgDA7J48LNS6PwgAGAAF/wUAARcAAQAGABsAGAAFAB4AvalIhbGF 2D8IABgABv8FAAEXAAEABgAbABgABgAeAGmM1lHVBPc/CAAYAAf/BQABFwABAAYAGwAYAAcAHgBq GD4ipkT6PwgAGAAI/wUAARcAAQAGABsAGAAIAB4AMxtkkpGz+D8IABkAAv8FAAEXAAEAfgIKABkA AAAiAAAASEAGABsAGQABAB4Ai+B/K9mxUT8IABoAAf8FAAEXAAEABgAbABkAAgAeABEZVvFG5pE/ CAAZAAP/BQABFwABAAYAGwAZAAMAHgAP1v85zJenPwgAGQAE/wUAARcAAQAGABsAGQAEAB4ApyIV xhaCrD8IABkABf8FAAEXAAEABgAbABkABQAeAF+YTBWMSto/CAAZAAb/BQABFwABAAYAGwAZAAYA HgBFgT6RJ0nrPwgAGQAH/wUAARcAAQAGABsAGQAHAB4AmrZ/ZaVJ7T8IABkACP8FAAEXAAEABgAb ABkACAAeALQCQ1a3eu4/CAAaAAL/BQABFwABAH4CCgAaAAAAIgAAAFhABgAbABoAAQAeAA/W/znM lzc/CAAbAAH/BQABFwABAAYAGwAaAAIAHgA730+Nl26CPwgAGgAD/wUAARcAAQAGABsAGgADAB4A smMjEK/rlz8IABoABP8FAAEXAAEABgAbABoABAAeAFch5SfVPp0/CAAaAAX/BQABFwABAAYAGwAa AAUAHgAeM1AZ/z7bPwgAGgAG/wUAARcAAQAGABsAGgAGAB4ANC4cCMkC3j8IABoAB/8FAAEXAAEA BgAbABoABwAeAA5KmGn7V94/CAAaAAj/BQABFwABAAYAGwAaAAgAHgASwqONI9biPwgAGwAC/wUA ARcAAQB+AgoAGwAAACIAAABoQAYAGwAbAAEAHgBpHVVNEHUfPwgAHAAB/wUAARcAAQAGABsAGwAC AB4AATW1bK0vcj8IABsAA/8FAAEXAAEABgAbABsAAwAeAMe6uI0G8IY/CAAbAAT/BQABFwABAAYA GwAbAAQAHgDqspjYfFyLPwgAGwAF/wUAARcAAQAGABsAGwAFAB4Asfm4NlSM2z8IABsABv8FAAEX AAEABgAbABsABgAeAEvl7QinBc8/CAAbAAf/BQABFwABAAYAGwAbAAcAHgBHrMWnABjPPwgAGwAI /wUAARcAAQAGABsAGwAIAB4A/N6mP/uR2j8IABwAAv8FAAEXAAEAfgIKABwAAAAiAAAAeEAGABsA HAABAB4A8WjjiLX4BD8IAB0AAf8FAAEXAAEABgAbABwAAgAeAAXAeAYN/WM/CAAcAAP/BQABFwAB AAYAGwAcAAMAHgCyYyMQr+t3PwgAHAAE/wUAARcAAQAGABsAHAAEAB4A1VsDWyVYfD8IABwABf8F AAEXAAEABgAbABwABQAeAN8Vwf9Wsts/CAAcAAb/BQABFwABAAYAGwAcAAYAHgAq499nXDjAPwgA HAAH/wUAARcAAQAGABsAHAAHAB4AZB75g4Hnvj8IABwACP8FAAEXAAEABgAbABwACAAeAJSHhVrT vNM/CAAdAAL/BQABFwABAH4CCgAdAAAAIgAAAIhABgAbAB0AAQAeAAAAAAAAAAAACAAeAAH/BQAB FwABAAYAGwAdAAIAHgAaFw6EZAFTPwgAHQAD/wUAARcAAQAGABsAHQADAB4AYTJVMCqpYz8IAB0A BP8FAAEXAAEABgAbAB0ABAAeALJjIxCv62c/CAAdAAX/BQABFwABAAYAGwAdAAUAHgASTgte9BXc PwgAHQAG/wUAARcAAQAGABsAHQAGAB4AQ1a3ek56rz8IAB0AB/8FAAEXAAEABgAbAB0ABwAeAEvI Bz2bVa8/CAAdAAj/BQABFwABAAYAGwAdAAgAHgAmjdE6qprQPwgAHgAC/wUAARcAAQB+AgoAHgAA ACIAAACYQAYAGwAeAAEAHgAAAAAAAAAAAAgAFgAB/wUAARcAAQAGABsAHgACAB4AS7A4nPnVPD8I AB4AA/8FAAEXAAEABgAbAB4AAwAeAA/W/znMl1c/CAAeAAT/BQABFwABAAYAGwAeAAQAHgDlJ9U+ HY9ZPwgAHgAF/wUAARcAAQAGABsAHgAFAB4AGLK61XPS2z8IAB4ABv8FAAEXAAEABgAbAB4ABgAe AJvJN9vcmJ4/CAAeAAf/BQABFwABAAYAGwAeAAcAHgAAOsyXF2CfPwgAHgAI/wUAARcAAQAGABsA HgAIAB4ATzv8NVmjzj8IABcAAf8FAAEXAAEA/QAKAB8AAAAkAA4AAAAGACMAHwABAB8AuUkMAiuH tj8IAC0ABf8NACUWAB4AAcABwBkQLgcGACMAHwACAB8AXinLEMe60D8AAB8AAf8NACUWAB4AAsAC wBkQLgcGACMAHwADAB8A5X6HokCf5D8IAB8AAv8NACUWAB4AA8ADwBkQLgcGACMAHwAEAB8AGeyG bYsy5z8IAB8AA/8NACUWAB4ABMAEwBkQLgcGACMAHwAFAB8ALedSXFX2DEAIAB8ABP8NACUWAB4A BcAFwBkQLgcGACMAHwAGAB8AKJtyhXe5H0AIAB8ABf8NACUWAB4ABsAGwBkQLgcGACMAHwAHAB8A V3OAYI6eJEAIAB8ABv8NACUWAB4AB8AHwBkQLgcGACMAHwAIAB8AGLfRAN7CJEAIAB8AB/8NACUW AB4ACMAIwBkQLgfXADoA5REAAAgCKAAcABwAKAB+AEAAQABAAEAAQABAAEAAQABAACkBKAB+ACUB HwEGAQYBBgEGAQYBBgEGAQgCEAAhAAAACQD/AAAAPGyAARaACAIQACMAAAAJAP8AAAAAAIABFwAI AhAAJAAAAAkA/wAAAAAAAAFiAAgCEAAlAAAACQD/AAAAYgAAARYACAIQACYAAAAJAP8AAABiAAAB F4AIAhAAJwAAAAkA/wAAAGIAAAEAAAgCEAAoAAAACQD/AAAAYgAAAWIACAIQACkAAAAJAP8AAABi AAABYgAIAhAAKgAAAAkA/wAAAAAAAAGqAAgCEAArAAAACQD/AAAAAAAAAQAACAIQACwAAAAJAP8A AAAAAAABAAAIAhAALQAAAAkA/wAAAAAAgAEVAP0ACgAhAAAAIQANAAAAvgAWACEAAQAYABgAGAAY ABgAGAAYABgACAD9AAoAIwAAACMABAAAAP0ACgAjAAEAGwAJAAAA/QAKACMAAgAbAAUAAAD9AAoA IwADABsADAAAAP0ACgAjAAQAGwAHAAAA/QAKACMABQAbAAYAAAD9AAoAIwAGABsACwAAAP0ACgAj AAcAGwAIAAAA/QAKACMACAAbAAoAAAB+AgoAJAAAACIAAAAYQAMCDgAkAAEAIADecYqO5PKvPwMC DgAkAAIAIACsHFpkO9+/PwMCDgAkAAMAIADarPpcbcXSPwMCDgAkAAQAIABseHqlLEPUPwMCDgAk AAUAIADChqdXyjLUPwMCDgAkAAYAIADQs1n1udrqPwMCDgAkAAcAIAAep+hILv/vPwMCDgAkAAgA IADOqs/VVuzvP34CCgAlAAAAIgAAAChAAwIOACUAAQAgADj4wmSqYJQ/AwIOACUAAgAgAHo2qz5X W7E/AwIOACUAAwAgAIxK6gQ0EcY/AwIOACUABAAgAEw3iUFg5cg/AwIOACUABQAgAJvmHafoSNY/ AwIOACUABgAgAFUwKqkT0Oo/fgIKACUABwAgAAGwWEADAg4AJQAIACAA1sVtNIC37j9+AgoAJgAA ACIAAAA4QAMCDgAmAAEAIAAJG55eKctwPwMCDgAmAAIAIADf4AuTqYKhPwMCDgAmAAMAIAD+Zffk YaG2PwMCDgAmAAQAIADA7J48LNS6PwMCDgAmAAUAIADY8PRKWYbYPwMCDgAmAAYAIAAg0m9fB87n PwMCDgAmAAcAIABhw9MrZRnsPwMCDgAmAAgAIADn+6nx0k3qP34CCgAnAAAAIgAAAEhAAwIOACcA AQAgAC9uowG8BVI/fgIKACcAAgAgAAEA/D8DAg4AJwADACAAfPKwUGuapz8DAg4AJwAEACAAFD/G 3LWErD8DAg4AJwAFACAAX5hMFYxK2j8DAg4AJwAGACAAqMZLN4lB4j8DAg4AJwAHACAA8IXJVMGo 5D8DAg4AJwAIACAAklz+Q/rt4z9+AgoAKAAAACIAAABYQAMCDgAoAAEAIAAtQxzr4jY6PwMCDgAo AAIAIAA730+Nl26CPwMCDgAoAAMAIABn1edqK/aXPwMCDgAoAAQAIAAMk6mCUUmdPwMCDgAoAAUA IACRD3o2qz7bPwMCDgAoAAYAIABd3EYDeAvYP34CCgAoAAcAIAABwENAAwIOACgACAAgACS5/If0 29s/fgIKACkAAAAiAAAAaEADAg4AKQABACAALUMc6+I2Gj8DAg4AKQACACAAL26jAbwFcj8DAg4A KQADACAAx7q4jQbwhj8DAg4AKQAEACAAU5YhjnVxiz8DAg4AKQAFACAAlrIMcayL2z8DAg4AKQAG ACAALbKd76fGyz8DAg4AKQAHACAAJzEIrBxazD8DAg4AKQAIACAAak3zjlN01D+9ABIAKgAAACIA AAB4QCAAAAAAAAEAAwIOACoAAgAgAGEyVTAqqWM/AwIOACoAAwAgAOCcEaW9wXc/AwIOACoABAAg AGx4eqUsQ3w/AwIOACoABQAgAPtcbcX+sts/AwIOACoABgAgAKhXyjLEsb4/fgIKACoABwAgAAEA J0ADAg4AKgAIACAAOwFNhA1Pzz+9ABIAKwAAACIAAACIQCAAAAAAAAEAAwIOACsAAgAgAGEyVTAq qVM/AwIOACsAAwAgAGEyVTAqqWM/AwIOACsABAAgAOCcEaW9wWc/AwIOACsABQAgAPcGX5hMFdw/ AwIOACsABgAgAFR0JJf/kK4/fgIKACsABwAgAAEAGEADAg4AKwAIACAAXW3F/rJ7yj+9ABIALAAA ACIAAACYQCAAAAAAAAEAAwIOACwAAgAgAC1DHOviNjo/AwIOACwAAwAgAMe6uI0G8FY/AwIOACwA BAAgAC1DHOviNlo/AwIOACwABQAgAIqO5PIf0ts/AwIOACwABgAgACV1ApoIG54/AwIOACwABwAg AMWPMXctIZ8/AwIOACwACAAgAAtGJXUCmsg//QAKAC0AAAAkAA4AAAAGABsALQABAB8Au0kMAiuH tj8IAC0ACP8FAAEtAAEAvAQXAC0ALQABCAAHDQAt9////wDAAMAZEAAHBgAjAC0AAgAfAF8pyxDH utA/AAARAAX/DQAlJAAsAALAAsAZEAAHBgAbAC0AAwAfAFdbsb/snuQ/CAAtAAL/BQABLQABAAYA GwAtAAQAHwAzMzMzMzPnPwgALQAH/wUAAS0AAQAGABsALQAFAB8AZtXnaiv2DEAIAC0ABP8FAAEt AAEABgAbAC0ABgAfAGJ/2T15WA5ACAAtAAP/BQABLQABAAYAGwAtAAcAHwCiRbbz/VQRQAgALQAB /wUAAS0AAQAGABsALQAIAB8AMnctIR80E0AIAC0ABv8FAAEtAAEA1wAcABsIAADcACgAfgCeAJoA ngCaAJoAngCQAJAAlAA+AhIAtgAAAAAAQAAAAAAAAAAAAAAAHQAPAAMpAAkAAAABACkAKQAJCQoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez 2TAAAACcAAAABgAAAAEAAAA4AAAABAAAAEAAAAAIAAAAWAAAABIAAABwAAAADAAAAIgAAAATAAAA lAAAAAIAAADkBAAAHgAAAA0AAABOb3JtYW4gUGV0cnkAAHgAHgAAAA0AAABOb3JtYW4gUGV0cnkA AHgAHgAAABAAAABNaWNyb3NvZnQgRXhjZWwAQAAAAIB7D4obg8ABAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN 1ZwuGxCTlwgAKyz5rkwBAAAIAQAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAAZAAAAAsAAABsAAAA EAAAAHQAAAATAAAAfAAAABYAAACEAAAADQAAAIwAAAAMAAAAywAAAAIAAADkBAAAHgAAAAEAAAAA AGUAAwAAAGoQCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAADAAAABQAAAERh dGEAEgAAAEF2ZXJhZ2UgVGllYnJlYWtzABQAAABUaWVicmVha2VyIFJlcXVpcmVkAAwQAAAEAAAA HgAAAAsAAABXb3Jrc2hlZXRzAAMAAAABAAAAHgAAAAcAAABDaGFydHMAAwAAAAIAAAAAAACYAAAA AwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQA AEEAAABOAAAAewA4AEYARgA2ADAAMgBFADEALQBFAEUARABCAC0AMQAxAEQANAAtAEEANwAwAEYA LQAwADAANQAwAEIAQQA4AEYAMQA0AEQAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA/v///ysAAAAs AAAALQAAAC4AAAAvAAAAMAAAADEAAAD+////MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAAP7/ ///9/////v////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////UgBv AG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAABYABQH//////////wIAAAAgCAIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAYMEhUSGDwAH+ ////AAAAAAAAAABXAG8AcgBrAGIAbwBvAGsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC7UwAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQA aQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAAMAAAD/////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAAAAABAAAAAAAAA= ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="smithtie6.csv" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="smithtie6.csv" Simulation Parameters:,,,,,,,, Trials:,"25,000",,,,,,, Options:,6,,,,,,, Total Tiebreaks:,,,,,,,, Voters,Schulze,Smith//Borda,SSD,Smith//Minimax,Copeland,SD,Tideman,Goldfish 6,"1,560","3,112","7,333","7,915","7,890","63,915","101,948","90,174" 12,497,"1,695","4,309","4,863","8,706","53,845","68,629","61,658" 24,103,854,"2,211","2,620","9,579","35,967","41,044","38,596" 48,27,437,"1,152","1,392","10,270","21,317","22,881","23,812" 96,9,225,584,714,"10,643","11,723","11,853","14,716" 192,3,111,280,334,"10,761","6,059","6,073","10,379" 384,1,61,146,173,"10,819","3,168","3,018","7,710" 768,0,29,60,73,"10,971","1,537","1,530","6,486" "1,536",0,11,36,39,"10,868",747,766,"5,984" Total:,"2,200","6,535","16,111","18,123","90,507","198,278","257,742","259,= 515" Average Tiebreaks/Election:,,,,,,,, Voters,Schulze,Smith//Borda,SSD,Smith//Minimax,Copeland,SD,Tideman,Goldfish 6,0.0624,0.1245,0.2933,0.3166,0.3156,2.5566,4.0779,3.6070 12,0.0199,0.0678,0.1724,0.1945,0.3482,2.1538,2.7452,2.4663 24,0.0041,0.0342,0.0884,0.1048,0.3832,1.4387,1.6418,1.5438 48,0.0011,0.0175,0.0461,0.0557,0.4108,0.8527,0.9152,0.9525 96,0.0004,0.0090,0.0234,0.0286,0.4257,0.4689,0.4741,0.5886 192,0.0001,0.0044,0.0112,0.0134,0.4304,0.2424,0.2429,0.4152 384,0.0000,0.0024,0.0058,0.0069,0.4328,0.1267,0.1207,0.3084 768,0.0000,0.0012,0.0024,0.0029,0.4388,0.0615,0.0612,0.2594 "1,536",0.0000,0.0004,0.0014,0.0016,0.4347,0.0299,0.0306,0.2394 Total:,0.0880,0.2614,0.6444,0.7249,3.6203,7.9311,10.3097,10.3806 Elections Requiring Tiebreaker:,,,,,,,, Voters,Schulze,Smith//Borda,SSD,Smith//Minimax,Copeland,SD,Tideman,Goldfish 6,6.24%,12.45%,29.33%,31.66%,31.56%,83.92%,99.99%,99.76% 12,1.99%,6.78%,17.24%,19.45%,34.82%,83.79%,98.75%,95.99% 24,0.41%,3.42%,8.84%,10.48%,38.32%,74.39%,87.81%,82.20% 48,0.11%,1.75%,4.61%,5.57%,41.08%,57.05%,64.56%,62.28% 96,0.04%,0.90%,2.34%,2.86%,42.57%,37.57%,39.50%,43.53% 192,0.01%,0.44%,1.12%,1.34%,43.04%,21.70%,22.15%,31.96% 384,0.00%,0.24%,0.58%,0.69%,43.28%,11.99%,11.50%,24.46% 768,0.00%,0.12%,0.24%,0.29%,43.88%,5.97%,6.00%,20.69% "1,536",0.00%,0.04%,0.14%,0.16%,43.47%,2.94%,3.04%,19.22% Total:,0.0880,0.2614,0.6444,0.7250,3.6202,3.7932,4.3330,4.8009 =0D ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="smithtie61.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smithtie61.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAAP8AgIAA//+A AACAAID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADKvVWfAAAb80lEQVR4nO3di3absLZAUZ24PafX/P//3vgB6AkSbKGNtOYYbRwb Ky7JqsDGxEwAtDCtHwCABT0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COg Bz0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60OP1zOL3onP9/j2Pf7Hkvc2x gVED34fr6erR0KMifB/aiAVQqcede5OiJnwz2vhW8Plg5g/OpfWG6TvBTfZfZglpvd/kDxDp0V7U zAMtN1kPhB+NBljpbdi1rLU5lyI3LFud66LuJ94AU9iju6ixe3S/PEG2wDpvw6plmfSM+5d9w3ph mcHW1Oz72UPNN0Zqtpbf/vK4Fuu8DadH5/kW+5I9zdkTprs5ad8veOom6NFfwq3eu4SLsc7bKOtx XcLu0ykq3aPzNelRN9Z5G/726npdJAh7drO3Uk38ftNmj/719KgJ67wNd34Md+A+N4a7ePauY2z/ 0XjZRebHnP1H7564Cuu8DavHZdvT3j793urdYLdjz4/OfqX7XIy3/+jugs5DWTet96bHBljnbdg9 Tksh1qXJumFpxp4bnf1H490j3aOz6HLFmqj9qMT/1djDOr8/wukH38r7o8d+8K28P3rsB99KQA96 BPSgR0APegT0oEdAD3oE9KDH0/wD0NxrIxesg2bC47/9T5wvY9xPg0WSdw7G2h3fWTQ2cGR5fphO YxWeZR31GRSXuvlAj/7ybv3r/Y72GBtwXjQ2cGR5Xgc9j1V40noEtjd7zQeG+hfWRdJDpq70+o31 eJB3bOvW104uT4/nsQpP8g8FD671L7iLTM6B4tbbK4LN0/CLLv8NWBNweGS4szk9+ffzJmh7wOXB LAPHl5+cr49TWIEi5p/aYP7K6HGuaNkCdD5xvoB3X/9uS4/eRnIwoHWFtQU9rRft+y0DJ5afliXp 8TRWoIToD3x2j8sA1gV/E9Ht0+tq+StyVTC6cz97C9iaSK0Brfsml7e/BE5hFQow3g9t4faq/Yk9 P0a+hJO7XUEQdHjJ+9qRB2Qll/rPIbq8Na/jHFbhef5P+mT98Jb06Pxce1t/7t0P9OgMGO1x/pfk 9rguT49iWIWn2ZttZ3p0NhGnyIx2rkd7wLBH69Fk9egv7/3jcBCr8Kz1J9Taolw+CS9490vkZCVg Le796M/znj+xeVeFA8Z6tMaa0g8murz7/whOYBWeZD8Tae2AWZ/4F5Y7Wh+C7b5gI9C9+/pVJ/fS 5H/RYPT1CutRuMPYf833TS8/OV8fp7ACT/LK+FxlfRK5MN/R+uD0tCY1eQF4X3cewJ6V10Qio9vT q9fXenvYozNwsLy3VYAzWIEViK7UvcFooCd8MyugRxzEN1PepTnSY1f4ZgJ60COgBz0CetAjoAc9 AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COgBz0C etAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COgBz0CetAjoAc9AnoU9jgvbl7E HwwwuLKolgZpEaiAHgE9isIy8+LkCNRwsEd2H4EKSqoykzM/Os/t/Po/QCnZaCo61mNwV/ME1Oqy R+NtpdIjbqLLHq3Fne3V9+XWaxxI67rH9x/v+Rx6hGLd9pgcpvUaB9LoEdCDHgE96BHQgx4BPegR 0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQ gx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT3oEdCDHgE96BHQgx4BPegR0IMeAT2G6/HR eo0DacP1aAgSetEjoEe3Pc6Lm1/O9U+ChFq99jhHaPy70iMUG7BHgoRanfZopo0eCRJa0SOgR589 minao/kiSCg1VI/vy+9/NkFCpS57/MyC673oETfRZY/W4okeCRIqdd3j+09wPMAbPUKjbntMDvP9 hxMkFBq2R4KEQvQI6DFujwQJfegR0GPgHgkS6ozcI0FCG3oE9Bi6R4KEMmP3SJDQhR4BPQbvkSCh Cj0CeozeI0FCk+F7JEgoQo/0CD3okSChBz0SJPSgR3qEHvT4JEioQY9PeoQa9PhCkNCBHt8IEirQ 4xs9QgV6/CBIaECPH/QIDejxiyChAD3OCBLt0eOMHtEePS4IEs3R44og0Ro9rugRrdGjhSDRGD1a 6BGN0aONINHWcD3+bK4OgkRTw/VoNoOkRzRFjy6CREvj9fhkgoRaA/ZIkFCrzx7NL+uifdfX86sE CaW67NFYy/t3o0co1mWP9vKxHgkSSvXeY3Cvz/EABAmVOu1x2Wf0dx/n43O2gqRHtNJpj5MzPzrP 7fx6MkFCp957DO46H7/KBAmFhu2RIKFQlz1aG6nO9ur78vwvZ4sV+nTZ43w8gFkvrjct/3QmSKjT Z49bw6z/doKENiP3SJDQhh4T6BENDN0jQUKZsXvcCpIecT16TCJIXG7wHgkSqozeI1us0GT4HgkS itAjPUIPeiRI6EGPBAk96PG5FSQ94lL0+GSChBr0+EKQ0IEe39hihQr0+MYECRXo8YMJEhrQ4xdB QgF6nBEk2qPHGT2iPXpcECSao8dVMkh6xEXo0UKQaIweLWyxojF6tDFBoi16dBAkmqJHB1usaIoe XUyQaIkePQSJhujRlwqSHlEfPfqYINEOPQYIEs3QY4gtVrRCjyEmSLRCjxEEiUboMYYtVrSx3aNp rk2PBIk2dnqUaeA4esRQ6DGOINFCnz1aW7ruRm92jwSJFrrs0azLWxe/t+WumUSQ9IiKuuzRWl68 R4JERQI9bj4PerLohj0yQeJ653u0fu4j92nU4/I/xIkeCRKX67THKTo/zi9qZq4btlhxNakevz/u 78+/H95/zLo96z3RWRBV9mMJ73pmfmSCxNVk9h+Xhd/5zSHOH5ZPymfLtj0SJC4m8/yqsWKzQmzV o8jrHW8EiUtl9PifNGfJdI+fv/xX5rPLCi7u382s28wHjwf4oEdcSvD5nGSP/jM+BZodLzcjSFxJ uMfUh+n6/cfUiIUrKB4kPaIKyeMBjP3E6ndDsd3zq6kRS9cQQeI6/R4vlxqxdA2xxYrr0OMuJkhc hh73ESSuQo/72GLFVegxAxMkLkKPOQgS16DHLASJS9BjFnrEJbro8fuukrwRj60ngsQVeujRmOCo 8Y0RD64ogsQFuujxk2TmiAdXFD3iAvLns7LuZ+zPzeT/BoCMr5LZozHZ/3cc7ZEgcQH58+dYV/s9 JsY83aMxJnsH8nCPBIn6LunRfm9yhR5LpscTPRIkqhM8n9V3s3HZNp2vifS4nPlq2fNLPB+Tu/+Y +VgneoRqkuezMpN1MiszrfPW3KMxzlskl/dHelu38Qew+fxq/psrT/RIkKhN+HxW60zofuaeJyB6 /fEei07Nc6ZHgkRlGT3+L81Z8lSPiaLyesw/GuBkj/Eg6RFS5M+fc6jH49ursV+lvPlwT60uJkhU dUGPS2vbPR6cH6/tkSBRleDxAGFefo+RM18tp0qNH2CTub1a4GSPbLGiph6Olysb8ewaI0jU00WP F26vssWKmnro8cr9xycTJCrqosfk07Oxhc+vM4JELZ30aK7skSBRSx89XvB+ZBu7kKikhx6Tr15G l5VYa0yQqKOLHotGFFltBIkq6PEYgkQNXfRo8k+fI9VjNEh6xEk99HjR+TpcTJCoQPj3sc6/ePXA r17dewDbz69e+nrHG0FCnvD7O9YLMkEq7pEtVsir1qNMkBqPl1sQJKSJns/KuXBdj9edr8PFFiuk CZ7Paj2xVf59d8cufCwZIwquPIKEMMHzWS0XLt9ejTwe6xG5c+ffv4Jrjy1WyMro8V9apIkW+4/R K0z8RvOULJIgIarf53OSPT4liyRISOri9Y6NHsO58/3P/iuVJD1CUg/HA2zdNXgsy/M5QkUSJAT1 cLzc1j2duXo+M+T33y5TJEFCThc9pn8DZfiJ83qHyGZrJEh6xDE99BjZf3QXTvb4lJgkmSAhpose g9uNe2mrR4EiCRJSeuhxMt7N83w5P7nkLBtZCWc3WwkSQm7fo9Dv7zhXJLuQkEGPs1NFEiRE3L7H 4hHT6+LMZitBQgI9Og4XSY+Q0EWPkuezOlokQUJADz0Kn8/q4GYrQeI8yeNXg/s5ZwxYpzBjD7z9 JXJffzTZ/3dkvR/5UJEEidME398RXu33OB/inVeON+yVPR4rMgySHlHmkh6/l6v1WOV8Vgc2WwkS J4mez8rM0Znpe3yMWY5XM/MWq1nmM7Nev9RqljN++Ee6lR1Pnl62YOWUFskWK04SPJ/VHNW6+bgc szbFelwXdT5zdjavfr3DV1gkQeIcwfNZOeV5nzlJOgu4t0+Trh5Li2SLFadk9PgnzVlSpMflXANB hIke3y91VD0fclGRBIkzhM+fc7bH8u3V+j2WFUmQOOGCHp0nZ4IFwjvq2l79KCgyCJIekU3weIAw q/IeJ2Psa3Lmx5yHaC9/cEVlF8kEieNuf7zcVT3mF0mQOIweC2QWSZA46v49Sr0fOUveQTvsQuIg eiyVUyRB4pj791g64vl1llEkQeIQejxit0h6xCH0eMxekQSJI27fY/GIUmuOICGPHg/bmSIJEuXo 8YSyIOkRu+jxjO0pkiBRSqLHrdf+orfkp6W8x50iCRKFJI4n31rwkh4lz79abCNIdiFRqNr5rLZG EO5R+PyrpTamSCZIlBE8n9VyLqrgzFTe9eI9Lu/ayhmxwkokSAgRPb+c/cbH8I2Oy2cFJ3y8R48E CSEVegw+xK7PlL29et3x5FHpbVaCRIGMHv+b5nTihej/iuJ6PVY7/2qJ3CDpERvkz5+zMzHW6LFE rR4JEgIEX+/Y2H+sPD+WqNYjQeI8yeMB0s+v2iEWbFuW7T/mDVuvx+ROJLuQyCV/vJzQPBYMltFj 1uZ1zbWZFyQ9IqWHHp0t5t0Rq65OgsQpPfToPKO0O2Ld9ZnYZiVIZOnh/R3LxqqCHlNTJEEiRw89 TkGO1r6kv1tZvUeCxHFd9Bi9l/Evfm+rv07j26xukPSImC57tJZv0WNiiiRI7Oqix+iLHS17jAbJ Fit29dBj/MXHpj1Gt1kJEnu66DH24qOxPtjP7bxcsmZ3g6RHBDrpMXixw9gfG8yPT4LEAZK/j7Xo yNQ8uccDBK9qOBfa9EiQKCb8fivpGTX7eLlEjk17JEiUku5ROMiDrz8Gb4a2brty7RIkygifr6NJ j0Vf8tIeY0+zOkHSIxwy+4/WwvToIkgUkHl+dXnrcZse25/PagNBIl9Gj3/TnCXpMS4Ikl1IpHT5 fM7miNev4+0g6RGrLl7vKBqxwUomSGTq4XiAtr9PJwdBIk8Xx8u1/X06OQgSWbro0dp93R+xzXom SOSgx4sERwbYQdIjPrroUffrHTOCxK4eelTx+3QyECT2dNFj0YgNVzZBYkcPPRa9ytKyR4LEjj56 LHjhs2mPBIltPfRYVGTbHv0g6RGOPnqc8jdaG/dIkNjSR4/3mR8JEltO9zi/+Gey71Git/3HF4JE ksjvRy6+R7bOnl/98A7VIUgseujxc/NdtldfCBJxYj1+3nE1n9LtfcX7FG+fG61rinS4//hGkIiS 7PGb3/dcOmb91L4mr5rIA0jes+ToVS09EiSihHsMP1hP9FifZdez+1gKfjXyZ/nWa/yLIBGR0eMj zVrKngaN8Xp0rymQ0+PWrZHlW6/xWTJIehxYpflxcnr0ZswC/c6PBImIS7ZX3R3LEt3uP74QJHzC z6/OJ7aanB6/T7xW6nG64fOrHwQJTx/Hy003e/1x5h4ZQJDopsfsEVuvcRdBwkaPjblBrkUS5JDo sbXUTiRBjogemyNILOixPYLEjB4VIEh80aMGBIkPelSBIPFGjzqkjgwgyLHQoxYECaHjV92DR+33 d1g3HOppoB4JEjK/H9lb0n0DctlYGw+g7P7L0v6h5np7JEgI9GicD5OOHtcE/bsp7jERJD0ORKzH TwXOG6xM5PxWhQ72aKZb9kiQw5Ps0Xr38WSdymq+uuRd/JEHcGx7NbiX6h4TR5cT5DBkenTOj+Nf sp/fKSjKfwAHe/Tfqay7x8TrHgQ5iowef9Ksn/x0j975Ag5lVXxfZ3504vzVeqVvIsiRST6fk+rR ubXM+edX/U90x/hCkAOTfL1jY3uVHgsQ5LhEjwewn1+1T02uZXv1fbn1Gs9AkMPq9Xi5ddK+1/M5 H86zOvPTrAQ5gF57TI/Yeo3niU2RBNk/elSKIIdEj1oR5IjoUS13J/LzgSA7t9NjcwP36E6RBDmE 7R41GbDHZ+RpVoLsGj2qFtlmJcie0aNykSApsl/0qB07kSOhR/XsbVZ2IjtHjzfATuQw6PEOCHIU 9HgL4TYrQXaJHm8imCIJskf0eBfBsQEE2SF6vI3g2ACC7A893kgQJEX2hh7vhG3W3tHjrQRviiTI vtDjvQRn1iHIrtDj3fhTJEH2hB5vhyA7Ro/342+zEmQ/6PGOvCmS1z26QY+35P9eOoLsBD3ek/97 6QiyD/R4V94USZBdoMfbcoJ8/rAT2QN6vK+/TJHdocc786fIRg8DYujx1rwgfxKL4S7o8d7+ekU2 ehgQQo93xxTZE3q8PTdIpshbo8f787dZKfK+6LEHbpAPgrwteuyCO0U+mCLvih47wRTZBXrsBVNk D+ixH26QFHlHvfa4LG1+OTe0XuMVeVMkL33cT6c9Lg0a/6499+hPkbz0cTt99mimQXt0p8gHU+Td 9NnjNGyPTJH3Ro/dCaZIiryPoXo0X61Xem3eFMlG630M1eP7cus1fgV3iuSQ1vugxz5526xMkTdB j51iirylrnt8/TXS8QAuu8gHRd5Drz2mh2m9xi/kTZFstOpHjz1zpsgnU6R+9Ng3b5uVIpWjx875 UyRFqkaP3bOKfFCkcvQ4AH+KpEi16HEEwRRJkUrR4xiCKZIiVaLHQYRTJEUqRI/DsIv8fqRIbehx IOEUSZHK0ONIIlMkRapCj2NZi3xQpEL0OBqryOU6itSCHsezFPmgSG3ocURrket1FKkBPY5pLvJB karQ46iWIq3rKLI1ehzXt8gHRepBjyOjSG3ocWwUqQs9ji5eJEm2QY+IFckk2QY9IlkkSV6OHvES LZIkL0eP+IgXyXbrtegRs2SRJHkZesQqUSRJXoYeYUsVyXbrNegRro0iSbI6eoQvWSRJVkePCP39 JBkpkiTrokdEpYskyYroEQkbRZJkLfSIpM9ma7xIkqyCHrFlq0iSlEeP2LZZJEkKo0fseW+2Jot8 JUmTUugRGT5FJpNkmpRCj8iyvdn6ZJqU0WeP5pd10b4rPR61s9n6QpJnddmjsZb370aPJ+xttj6Z Jk+iR5TImCRp8oTeewzuRY9nvZLcK/LTJFEW675Hb/eRHiW8i9xNkijLdd+jfVfz1XqldyBvknwj ygK99xjclRil/CaZWeSTKHPRI457FZmdJFFm6L1HP016lFU0Sb79UOWGLnucjwcw68X1ptZrvDuF k+QHUcb12ePWMK3XeI8OJclUGUGPEFG83br4aZblf/WhR+Ta+1l6TZLHfxK/WR4foFzrFRpBj6MT /fE9tt1qazdbqkCPXWswSRzebnWMmiU93p6+LbLTk+RiuCzp8Rb0NbfjIdfkc6Qs6VGN2zW3RzTJ lwGypMdLddfcDvEkX3rOkh7FjdbcDtktV8tPj13S4yE0V6RWkm9ddUmPSTQnqdo0ufjpIczBe6S5 K9Vv8u3OXQ7XI821dVGTL3fscrgeX/Pjn7fWq35cFzb58mO58MseMmSPH1TZ0sVNzn5+dNc5XI// ftkrgCrbeTSKcqGvzuF6fM2P/z6s1UCVzbRucvXja/AYhuzxK8iSKhvR06QjCLR+pCP3+OVnSZVN KG0yEI1UrFd6nHlZUmUDd2lyy16v2+XSo8fN8g9ZXq35kzyXiTVKj3Fk2dQ4UXrocRNZNvQYsEp6 zEGW7YwVJT0WIMtWPlPl63fBdo4ey0WzpMv6HnOWf7stkx4Pi75AQpf12Vn2ViY9nvXvX3y+JMzK Hj12SY9i/nll0uU1/C5vHSY9VvDPSZMur/HoYcKkx7qsMv9Yrn0Qg7lzl/R4FWfS/POHOqsLNmRv UOZwPf5v1nClp/Y0qbOKR7Alq7fM4Xpc5sf/+Vqs/n9+mk/qrChWpq40x+0x0DjQSJkv1FnFQ+mk SY9prfr857Fuok550UmzVZz0mK/VBOr3uUT6x3fRA+rVw9OgTno8IQj0wm3caKRBoER6ht/nEmm9 Lzlcj/9Z1VifkURVRkqoR0UjFRu9zx7Nr/Di5/P13/6fGLE1a1EY6euGZKi0Wkos0i57NOvy1sXv bTsrZPRIv2j1vGikO73SY46dSOX2SaORivWaeS6vpO9iW61KFFvjECqNY8YaFdoru0DLHqOikYpN qvHHudermOhX3+t1f5c1q1yN7Vw2plwwlanr0VqJ0Wv3et0ut/EPUIXET5bb1snVmW2oHg2gnGw0 FUnNj3KPiDHrjHmTh3mbMeugx1HGvMnDvM2YddDjKGPe5GHeZsw6DhwPYNaLh4bJ/nKMqXzIoces 4z6PFOgfPQJ60COgBz0CetAjoAc9AnrQI6AHPQJ60COgh0iP8kfQG/Fh18FEH2rsYKVzA34PgpIb 016XMsMGg50fc34bhtjjXO4uPXBdEg8uOJr1/IjzcXliw66DiX4/3t/pZWiJAT9/CY5pr0uZYYPB hFapEXyc60NyjriW/1EVJtajJDN5a1Ns3OlOPQoN6P/fJhVPtR4FVmn8J0hyvVaissepYo+i3xMz qe9xqt+j0MNdHqfIKjXex8/lQXqss//oXJAaVb5H0X2Sz3iiq3T+ORfcf3b3xUR7lN5/XE4P8NmL lP9RlSXSo/U/m5DY/24igxrJMY29zyM15rdGuTGXn0ZrT0pi1PnfLbRK1y1fkd085ydo+Z+owo+q LLk1KTCQN2SVvUftPX4GkxzT3daQm3Wr9OgOfXY475ORns+p0WOFHCXPbvQd7FY9Cm5Yz+3IrFLr O06PAmNU6FE+R++SzLDC0474mMb7IzKg+7MtsUuaGPrceP6IQ/RY6XiAGnPZPLYYmScf7AGXZx8k E7eeJpGYy+SPB1imMNnnc4w/4gjHAwBK3e7H+3YPGMh3ux/v2z1goGP0COhBj4Ae9AjoQY+AHvQI 6EGPgB70COhBj4Ae9AjoQY+AHvTY2vyuE74ToMf2Ij3yTRkW3/rmvu/L867AkPjWN7f2aJ9J237/ rPY30UIM3+fmlh73/qB/fJvbM2avSb5Lo+A73V68x3mzddJ/0heI4fvcXmp+/N72+cA3agh8mxVY zinH/uPo+DYrYNZZ0ArTf94VA+D7DOhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI 6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPgB70COhBj4Ae9AjoQY+AHvQI6EGPgB7/D0SFM1offtzb AAAAAElFTkSuQmCC ------=_NextPart_000_0160_01C082FF.D567E0C0 Content-Type: application/octet-stream; name="smithtie62.png" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smithtie62.png" iVBORw0KGgoAAAANSUhEUgAAA48AAAJvCAMAAADshBQLAAADAFBMVEUAAAAAAIAAAP8AgIAA//+A AACAAID/AP///wCAgIDAwMD///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAADKvVWfAAAgAElEQVR4nO3djXqbuBZAUZo0t53y/u97E/MnCYEldCQdSXt/M43j YOyBrBFgTKeZiLQ01X4BRLSHRyI94ZFIT3gk0hMeifSERyI94ZFIT3gk0hMeifSERyI94ZFIT3gk 0hMeifSERyI94ZFIT3gk0hMeifSERyI94ZFIT3gk0hMeifSERyI94ZFIT3gk0hMe5Zu2fm76p5gv f+SfVcCE51vXL2yyp3o//6AXS+mxnOV763GK9hgBBo8tx3KWz/jlvfEYM6uQETJujpGvB4+FYjnL d/K4c9oGzWOE2sa+1x3HXZMzq/N85mP43W4td+63DMvn/0NYM1wm328Zz7S9FmNEd6Yk0Vik8rm/ /ZMlbTI9Tscv/LGJa4C0xkdnPh6Ph1N3xu6Ls2boTO35gflkzoshyVik8jn7j/vYcnnPdIhzdi7N /Ufvo2bjUZM9hTPt/uLm2X0m38twpzCea3bnSWKxUOU7ebRGs9n9fT/dsvQc49DFqGhtr97M13xu 7wtzxkDjWa+HZhKOpSqf89sf6dHaEtzumOdbPtk8HlPgsUgsVflOHt377z2aQ+SO4PRwEY83M9xe yLF16nsRJBxLVb7z+Hi6Yf/oLMj2aAyTnkedDrg4W7/7AOvO8WqG3hfqfzISjqUqn7P/6G7sreOf tT1oC3LHx32APG80mk/kHeas2ZlzNGZobp8e/wX2E50fk2vxDR1LVT7X4zE+GaCMXbXl6/7naf9x NkAe3+7T3m6vms9lztF6YZP5/qPxfMf8rf9nuJvAJBdLtdXCQICnrVhRrRbq0dleJdWxolot0Bgc m4o1RaQnPBLpCY9EesIjkZ7wSKQnPBLpCY/JuWfD2fd6bhhn8Ljn4Zy/sZ5msr89TXL54NO83s7f mtQ3Y8/0/DIlxyJMzTj38yTu6scPPLrTe95XDD+v1DPR1XkD9tmrt9PzNmd6LMLEjrOrndFrO3PU vXFMcj3Lqzsdvz6PD3NOtL177svp8ZgeizAx94zs073uDXuS2Tpf+8B93jw9P+n+vwFjAD6fpm5t Ts/u45wB2pzh/mL2Gfunn63np6RYgCJtv7Wn8SvA46Zo3wK0vrGewHms+7Ddo7ORfJqhcYexBT0f N83H7TO+mH7ep8RjcixAiby/8MEe9xkYN9xNRNun42r/w3PXae7W48wtYGMgNWZoPPZyevMpKCkW oUCT80sbub1qfmOOj56nsLibCk6gz7ec5/a8IIPc1f8cvNMb4zqlxSJMz/1Nn41f3hiP1u+1s/Vn P/yBR2uGXo/bf0mox2N6PIrFIkzO3GxL8WhtIs6eES3NoznDs0fj1QR5dKd3/uPoYSzC1I7fUGOL cv/mfMN53AUng4AxufOrv4177sDm3HWeoc+jMa/5+sV4p7f/P0IJsQgTM49EGjtgxjfujf2BxpfT dt9pI9B++PGss31rdp/0NPfjDuNV2LMx/9geez39bD0/JcUCTMyRsdxlfOO5sT3Q+GJ5OkjNDgDn ebcZmKPyQcQzd3N4dXwdPz97tGZ8mt7ZKqCUWIAZEl2o72aGgZ5iZWYIj/QwVqZ8RTnisatYmUR6 wiORnvBIpCc8EukJj0R6wiORnvBIpCc8EukJj0R6wiORnvBIpCc8EukJj0R6wiORnvBIpCc8EukJ j0R6wiORnvBIpCc8EukJj0R6wiORnvBIpCc8EukJj0R6wiORnvBIpCc8EukJj0R6wiORnvBIpCc8 EukJj0R6wiORnvBIpKc4j6+pp+n1V9avX9a/vx7XROlFOVocLg/bFO7/EFFqMZAWhHgkylX89qrP IxyJJEr2+NqIxSORROkely/TPqOf4zyfcf1HlDUpLtkT8uiMkR/f/QvvLDTiwUTvGsvj+ZDO9L0M PpaeLUBQkmB43EtQiUmSqWeP7vkA253WdO4CeTxYYpLS69Vj8FwvlsszlpCktPB4WzxLSFJCeAzp 4yMGJiLpaXiMKlAlgyQ9C48PCjGJSHoQHh/23iSDJEWHx4QCSKbMnsYLj2m9GyYZJCkmPKb3lqTA c9AY4VGke5IMkhQYHqVikKT08CjXu0FS8Kmo0/AoGiIpKTwKdztIIpLuw6N89yIhSdfhMUdsttKz 8JgnRNKT8JgrRFJ8eMwXb0hSbHjM2JtTBHI+NbUZHrPGEElR4TFvDJEUEx5zxxBJ4eExe/efWQYk GeExf2yzUmh4LBHbrBQWHovEEElB4bFQDJEUEB5LxRBJ78NjuTijld6Fx5Kx0Ur34bFobLTSbXgs HEMk3YTH0jFE0nV4LB8g6aquPU7fHV/m9U97khoLnQOtdFHPHld+m8L9H2uaOoudIZK84bFOgCRf o3l051LL45tt1mIvg3TVu8fp8Pjaf1Tj8X6IZCdy0Hr2+HMgxxgf1y/TZPz4Va1lzzYruXXtcXmY 7dEZIyuOj2yz0qmxPJ4P6VT1+GabtdirIDX17HGaD35KPQKSrHr2OO/nAUw7R3P/8fVd7RUASDLq 2mPIXGuvgDd/O12510EawmP9GCJpC48KAiSt4VFDgKQlPKoIkPQKjzq6PapT7mVQ5fCoJUASHvV4 BCThUZFHQBIea68As5udSECOER5VBcjBw6OuADl2eFQWIIcOj9oC5MjhUV2AHDg86guQ44ZHhQFy 2PCoMUCOGh5VdgkSj32HR50Bcszw+L6vN2VZMZfnzgGy5/B4Vbi3TCwBOWB43Eoe9cRRAnK8Rvco vdUpahKQwzW6xxzHc+RMXoDEY7fhMU9CJAE5WHjMlghJQI4VHnMmIBKQQ4XHvKUPkoAcKTxmL1Uk IAcKjwVKHCQBOU54LFOSSD9IPHYYHkuVIhKQo4THciWIBOQg4bFkz0UCcoy69jh9d3yZ1z/tSQov 78ciATlEPXtc+W0K93+saYov8aciATlCeCzfQ5FekHjsq9E8unOpc72OZyIB2X89e1x3HPe9xuk8 PFa7fs4jkYDsvp49OuPj+mXaZzSt1VnyT0QCsveG8+iMkTWvL/dAJCA7byyP50M6da/3GC8SkH2H x7pFi/SBxGM39ezRPR9gNs4K2CepvQL+AZKOuvYYMtfaKyB+iARkx+FRQXEi2YXsODyqKEokA2S/ 4VFJgKR/eFTjMWqIBGSv4VFPESIB2Wl41FS4SA9IPHYQHnUFyLHDo7KCh0hA9hge1QXIgcOjvkKH yDNIPLYeHjUGyFHDo8rCQLLF2l141FnYNisgewuPWnsIEo9Nh0e1BQ2RgOwrPCoOkMOFR82FDJGA 7Ck86u4JSDy2Gx6VB8ihwqP2ArZZAdlNeNRfPEg8thoeGwiQw4THFnq/zQrIPsJjG70DyS5kH+Gx kWJB4rHJ8NhKgBwhPDbTu51IQHYQHhsqDiQeGwyPLQXI3sNjUwGy8/DYVoDsOzw2VhRIPLYWHlvr zWFWQDYdHtsLkP3Ws8fp1fJ1+f48nxY93oNkF7Lleva4Pmo6vk6n2TTpMQYkHpsKj00GyE7r3OM0 Ox7duTTqEZCdNpDH1/5jLx4jQOKxofr2ONl/LGPkPqNprfY6eBYge2w4j84Y2SjGnwDZYV17nI4/ 95v9eARkh+Gx4W5P1TFB4rGVBvC4nw8wG2cF7JPUXgFpAbKzuvYYMtfaKyAxQPYVHhsvECQe2+je 41Q9PL7rBiQDZHO98ZjFQER4fB8gOwqP7QfIfsJjB4WBxGMD4bGHANlLeOyimzMDANlSAh5vj4Mm KsJjaCEg8ai+dI/GqS+ex+CxVIDsITx2EyA7SMrj69a0fPx32j4FvJ6+vW7PTlM8KTxGdAmSXchm ktl/3Cee9k/hHx6PH8WbwmNMASDxqDuZ46uTgc2AiMfCAbL1Ajz+us6a8trj+jmnBxuseIwLkI0n eDzn0qN7xCeGS9xrefAEtVeAcO9B4lFzwh6vvsxsrxYKkE0neT7AZB5YXT+Vz/HV0gGy5ThfrrsA 2XB47K8rkHjUHx47DJDN1rxH36U9Yp6g9grIEiBbDY9d9g4kHpXWvMftRw9faqceAdloPXhMON+g W4+AbLMuPLK96gmQLdaDx2enxq4Prb0C8vUGJB411oXHlCeovQIydgGSAVJxeOw4QDaX/PWsjMdN 5vfTfLWb9+bIacBU08TxVV/3IPGoL/nr5xh3ux4v5pnq8aWc4zm+ANlYRTyerhUQ/Cyh73dMYa/V 89jaKyBzgGwrwetZLWPUfk2rabvH43G/8tVr+psPY+ExNUA2leT1rFaNB4/J+EDy9kFI63vzi/fJ eP8xuVuQeFSW8PWsjpHQ/s6+ToD3/uceef/xNkA2VIDHP9dZUyZ5vBCV9n7HcWGCZbN533g2Jqm9 AgoEyHaSv37OI49p26t390/bF/9u5ggeL0DiUWEFPO7W7j0+Hx9vPc54BGQ7CZ4PcOblevRc+erY ppQ/nuPz6E41hkdAtlIP58tde9wucbfto57nMojHO5B4VFQPHi8ffIzPxlh5wN0uLFB7HRQJkE3U tcflD9ujM0aOgfEnQLZQ8x6n6X7/0fJ4PqQzjscbkHhUEx7HCZD6a97j7aPt8wG2A7rWJLVXQMFu zgsApJK69hjyBLVXQMmuQeJRST145Hzy0ACpPTwOFbuQyuvBY9IT1F4BhbsEiUcV9eOR8TEoQKpO +O9j3Y9nCklme1U8QGpO+PMdxw0ZkBEeHz5B7RVQviuQeFRQNo8yINl/zBAg9SZ6PSvrBh7VBki1 CV7ParZOgynoMeWvgBzSIyDVJng9q/0GHtV3ARKPtQvw+Pc6j5Ya+4/T/Y9vn6D2CqgUIHXWw/Gc lOcb1SMgddbP+x14jMsLkl3IyvVwPgDXQ36UHyQeq9bP+XIPn6D2CqgXW6wKw+O4AVJfXXic+PtY H3V3VVaqUg8eX3uPHM95ECC11YVH4/Bu9BPUXgF1A6Sy8Dh2gNRVFx55//F5XpCfgKxUDx55/zEl QGqqC48pT1B7BdQPkIrqxyPbq0/zgfxkH7JK7XtctlXZf0zICxKPNZI8f/X0OOuKAcdb9tbB0Pun eO8x4bOPr4fXXgEaYotVTYKf7zjf7XpcJ42gE+AxdpbOw2uvABUBUktFPK63M3oMn6P78NorQEfs QipJ9HpW04Zu/5vCp53LtG2xbn8l6rRf3MN44LofuGPGY6EAqSPB61ltqI7TZabpoHX2eExqfWft bEbsP3I8JylAqkjwelaWPOc7i6Q1gf3zecZjpQCpoQCPv6+zphTxuF9r4ITw+Tbp7X9h7RWgJw/I T05lLZzw9XNSPcZvryaGxyNA1q+AR+vgzGmC8wPxWCtAVk/wfIAzq3iP8zSZ9+CxbGeQPxfvAGS5 2j9f7u7R+7l0C26X+IxHJ0BWrgePlz8xtnmt3VZzktorQFmArBseyQqQVevC48X7j+Z7JhtGdyo8 up1Avq7/CMgyde1x3X3cHj2dh0c8ngNkxXrwePvgyTpQu72fsnyzVnsdaAuQ9erZ4/ow26MzRoLx nH8XEpAl6sLj3fXJLY/nQzp49OQfIAFZoB48Xl2f/Ly9isewAFmrLjz63sh4/eD4+++OWdhw8egN kJXq2mPIE9ReAUpzQa5/6RUgMyfh8e6zh96fhNNJer8j6AlqrwCtAbJKEueT301YwiPXJ88RIGuU 7XpWd3OQ9pgQHi8DZIUEr2e1X4vqdGUq537x7dXg1+p5bO0VoDgH5Pb3JgMyY6LXl9vPf5mO7zz3 R2xbBu4/3u/D3j5B7RWgOUAWL4PH0xff/aFcgl4L+4+ZAmTpAjz+7zrLiQPxOJnbuJXHI9cnz5UN cvMIyGzJXz/nzcAo7ZHrPWYNkGUTfL/jZv8x4/iIx7wBsmiS5wNcH181IUbR4f2O6gGyZPLny4m6 wWP9LJC7R0BmqQuPbK9mDZDl6sEj+495u9hiBWSG+vh8R9xBIuuxtVdACwGyWJ14nPCYs4stVkCK 14fHuIO21mNrr4A2AmShevAYeU6s/dDaK6CRAFmmLjymPEHtFdBKJkjDIyBlwyOFdQkSkYJ14fHu eo/vnqD2CminK5AMkYL14PHqeo9BT1B7BTQUIPMn+fexPv8UYsgLuD++yvsdBTJAWh47BnnzYcOr kp5P+PNW0iMqHlXVNUgpXElwpT0Kg+R8OV31AlJ8XJN6EcLX66jiket1FOvSozaQObcpcyaz/2hM XMNjyhPUXgGNdQMyQWTwJl5wz19L3WSOr+4fPa6zvZryBLVXQGtdgzwPkd3rkS/A49d11pR4HCIX pMHqA2apcTyHIvvavX266JTtRDZYF+934DFz9rB3jJDuFisnz6XWw/kASU9QewWo7WbD8wYkQ2Ra PZwvl/QEtVeAssJ2/gCZqy488v5jYtGHYHaQZ4+ATKkHj+w/PivlQOgtSEQ+rguPNz/fdmxftz1H nMbzKPR2xB1IhsjH9eDx5vJy+4WuJuMfa4LaK6BY0m8KAjJHzXu8//s78CjucA+QGerb4/4Xh+wY 3an69Zj/JJl7kIh8UvMe3zzcPE/Bd5XW/jwWPFltA+nzyBD5qK49Gluo03HP8QGxtdrrQKgKJ40C UrouPF5dz8rn0Rkju8BY7ezt2y1Wtlkf1IPHq+tZrbuVhsfzIZ3GPdb+HMUbkIiMLdnjZP7WVzqf 3Hfg1PpZhx5rS1x7B5KN1rhE/n7k6EcEJ+Hx+Ms9jLMC9p/XXgHxKZG49h4kIiPqwuMo58vpkrj2 FiRDZERiHtc3FNbx6HXHtB/NNO+J4xL0Wvo/n1ylxLX7g6w/MUQGJ+lxOt7i224em5LGD2O4xL6W 2PR7VCxx7T1IRIYm7PH8xXznL3iOvhcwoEf9FJcCQLLRGlaAx8/rjKnMYXCaHI/2PTFcvDetKaYu 9x9bobgUBBKRAWUaH2fLozNixnB5+1r689gWxaUQkAyRARXZXrV3LKO4xL6W2FR51HzU5k1hIBH5 LuHjq9uFrWbL43rgNc/4GDfD08Nrr4C1diWuBYFE5LuaP1+ufY/NU1wKA8lG6314rFknFJdWkG88 MkTe1r7H2+sDvH+CWgu+K4pLgSAReRMey9chxaVQkIi8rH2PiU9QdnF3S3EpGCS7kRfhsVSdU1yK AIlIX3jMX8NvK0YXDhKRvpr3mPoEeRfvQBLXIkAi8hweczUexaUYkOxGuuExQ6NSXFpAhnlkiHTC o2xjU1yKAolIK5HzV+03/8zPdxg/eOSpIY8jHbV5UxxIRBpJ/P3IzpT2B5Dj5nXzAhR7RKJTJEh2 I/fSPU7Wl3ksjwyK/qJBInJJzOPr5vFBq58PWE2e61vFcol7LfE994jEu2JBInJJ0qPx6ePZuJTV drc7YAZxiXst8T3xyKAYUDRIRP4k49G6Po57yzy+E80l7rXEF+kRicHFg0RkkMeP6wwn1x6d6wXE cfHeFCzYI4NibA9AIlLyeM6VR+unkVziXkt8IR6R+KwnIEc/1Cr5fsfN9mqrHqGY0jOQQ4sUPR/A PL5qXpq8xe1Vtk8FegRyaJGcL3cOiWJ9vUTGghxYJB7NGBTFW0AiMjA8riExU8+2WUcVObrH3wyK uXsKckiRo3tEYv4egxxQ5BuP1cvt8Xt79XftddB9z0EOJ/Leo6YeeFxBb66n/Z1SY5LvZfAbkZl7 eJj11Vgie/a48tsUWicM7dO8lgIgc5cAciiRPXtcHxbgEZDZSwE5kMjRPLpz2d7vYJs1d0kghxHZ t8dp/9Dlsh95nstxPgAgM5cGchCRfXuczfFx/XIcs92O4a6LgiEyc4kghxA5nEdnjLTOlwNk3l6H WRNADiByLI/nQzr2+asMkZlLBdm9yJ49Ou93zD6Pf53lAci8vUAi8rKePbrnA8zGWQH7JH8dkYDM W+pO5L8fkf2S7NpjyFz//XNBIjJrAiA7HiTx+A2SIbJkIiB7FYnHnxgiS5Z8mHWpy81WPL7isE7R ZED2OEjicem0zYrInKUfZl3rTSQetxgiSyazE/lTX5uteNxjiCyZHMiuBkk8GjFEFkwSZD+DJB7N GCILJnSYdasPkni0Y4gsmCzILrZb8eh0AonIfIkdZt1qfpDEo5u7zcoQmTHRnciltkni8RxDZLky gGx6uxWPnhgiy5UFZLuDJB69MUQWS/gw616bJPHojyGyXJlANkkSj1cxRBZL/DDrUWsk8XgZQ2Sx 8uxErjUlEo83MUSWKtdO5FJDgyQe72KILFZWkO2QxON9DJGlygyyEZJ4fBNDZKl+tlkzHdXZ+lBv Eo9vY4gsVfYh8ifdJPH4PobIUhUBqZokHkNiiCzUa5u1xBNp3XLFY1AMkaUqBfKfzmESj4ExRBaq IEiFwyQeQ2OILNT3Nmvmw6x2H5pQ4jE8hshCFR0ilz6UqMRjRAyRhaoA8lV9lHiMiiGyTD/brLWe uypKPMbFEFmowjuRbrVQ4jE2hsgy1dpmNaqwU4nH6Bgiy1Rzm9WsKEo8PoghskyVt1nNSg2VXXuc vju+zOuf9iSPltp5iERkjrQMkVsf2Vn27HHltync/7GmebjcXJBstOZJGciljCp79rg+LItHhshC fX2p2WZ1+vjIMFyO5tGdy2OPDJGl+hZZ+yXc9yEocyCPr/1HQY8MkaXSDnIvXWbvHqd5No/iTNtR ndc3a8+XP0NkmdRus172VGbnHqfZ9eiMkSnj4z+GyGI1M0Se+nC6n7pvj5P9h+eQTqJHzg4oVbsg nVyfttGuPU7Hn9k8cnZAqZrbZg3vkNmzx2Xv8DgfYDbOCtinEViabLSWqZsh8qaePQbNVWQpstFa pv5B4lEmhsgidbzNuoRHodhoLVPnIvEoFhutZepaJB4FY4gsU8cg8SgZG61l6neIxKNsbLSWqVeR eJSOIbJMfYrEo3hstBaqR5B4zBAbrWXqcIjEY5ZckQyReepOJB4zhcgydSYSj9lCZJk+v2q/AsHw mDEO7BTpsyOReMwZh1rL1I9IPOYNkWXqRSQec4fIMvUhEo/5Q2SZehCJxxIhskzti8RjmRBZptZF 4rFUiCxT2yLxWC5ElqllkXgsGSLL9C2yUZJ4LJtHJCQz1KpIPJbuJJJBMkttisRj+RBZphZF4rFG PpGQlO9HZFsk8Vins0gGyRx9fv5rSiQea/WXzdYitSVydI9//lRc+Gy2FqklkaN7nP79qUmSzdYi tSMSj9/VJMlma5FeIhsgicelPxVNIrJEPxe+0i8Sj0f1SLIjWaJFpG6SeLSqRpLN1hK9Lg6pWmTn Hl8Pmr5bvp7nc36/oyJJ9x5EivepfJDs2+NL4KZw/8eawrdQapFEZIlUD5Jde5zmZx7/VSN53mxF pHyKB8muPc5nj+5cbs7PqUbSuYNDOxnSOkgO5PG19Rrh8V+td0F8gyQkpdM5SI7kcfky7TOa1u6X UCWS7j2QlG8dJDWRHM6jM0YGnU9eg6T3DRBICvepjeRYHs+HdEI/31GH5OkuRIqniyQeg6uwM8kg WSRFJAfwuJ8PsH1nTRC3uGqQPN0FSfm0kOzc4/u5Ri+x4sOkZ5CEZIZUkMTjkyqQ9G24YlK4+iTx +DCGyT6rTBKPCSkhiUnZPiueKoDHtEoPk74tV4ZJ+V4mK5DEY3oMk332Y7I0STyKpOEADyYztJgs 93x4lKrGAR5MluhlstBz4VGy4qcLYLJQn8tBnuzhUbjyZ9VhslQFTOIxQ5jst8wm8ZipP1X2J71n 8YBSuIwmR/f469evTEv2pzoDJSgLlMnk6B6/x8df+U3WQOm55gcoZctgEo+vMpusgdI7VIJSOuED r3jcy22yytWxQFkiOZR4tCpiEpRdJoISj6eym6xzGUlQlugzUSUevZUxCco++/p8zBKPl+U3uaCs s/nqqPyNSuG+vp6wxONtBUzWVWmz/A1L4b4iWeLxbUVM1lJ5M1jCUqqvr2CWeAzqVyGUdVX6WeJS pi+T5dVEeAyvlMlqKv0scSna/WCJx7jKmayn8oIlLgX7umCJx/hKmtxUVhwtGS/zdWKJx2eVNfnT nz/VZP71y8SlVAdLPD6v2EEeJ20yf/9GpkjfJPGYWC2Ur5DZW3iUqCrKV3/+VLP596/HJjKfhUex 6qNc+/Onms6/f086kRkTHmX7pUbllh6dv39j8114zNEvfSzX/riVe2oL5+/f6PSFx4ypVWl0AlrG 6F90esNj9n790jtc+vMZzYr0TudYQEfwOH23fD3Pp4DHvV/tyTQqZ/Sv2wlov0YH8Lgp3P+xflhl qf9yqvIiBPIOpDm53hvtgCsepXt6Ruy1UR2v8cEc33C9h5v2Gt9wFYKbYTmmISmYjEd3Lnp/131G pYZUbf/VwXCThmHva0yCi8enD/z5YzoPj4o9vpnjG673cJv9r/aWpjm0YLhJjeRx+TLtM5qItJXK pFhCHp0xUv6/nzkyR01zzJWEx/MhnRaWKHNkjvrCI3NkjnpKPx9gNs4KSJ/r5bMxR+aoaI65aueV EvUfHon0hEciPeGRSE94JNITHon0hEciPeGRSE94JNJTDo/SJ9RPwjM9ZiX4Mqc5x2uUm6O5ECXm eppV6hy3D2IIvUb780YZFmieMrw4z/V00uY3yc70mJXgqtk/BSr6GuXmaC5EibmeZiWyLCex12h8 /u/4U3KBZiqXR8nZOYtWaK5zKx5l5uf+T02GTyaPycvS/0sjuEBzpd/jnM2j9O+7Yo9zbo8ir3V/ jQLLcnK+LrfH9Jhj/9G6ITNP+fFHdG9vmiQX5fa7LrbrbO+PCXqU3X/cLw+w7EVK/25Kl8Oj8b85 mRk6X4VmOcnNcTJ3fWTmuGoUm+P+O2nsT6XPc/tPFlmWx3avwI6e9Uuz/z9I/HdTulzbqxk8iu89 ava4zEp6C3i/ITXPDB7tGafNzPlm4OM58h7FOcpd6GidVTsexbaBNz0Sy9JYzXiUnqW4R2mOzi2J mQrryTJHKY5nNuk7pBczTpmbO78RPWY5H0B+NNvmLJTEMQhzdvtBCLGxbJ+rzGgmfT7APohJHs+Z 3PkNeD4AkSnJ604AAAELSURBVJaa+/Vu7gUThdfcr3dzL5io4/BIpCc8EukJj0R6wiORnvBIpCc8 EukJj0R6wiORnvBIpCc8EukJj1raPnLCGhk51r6WPB5ZOcPFKlfT+vk85w4aKla5mg6P5hW1zc/R av8wLSXH+lXT7vHdv9RvrF49TdM7k6yt3mMN68nvcdtsnfVf/IWSY/3q6Wp8XH+2fGGFdR2rV1H7 ReXYfxw1Vq+ipmMUNGC6x12p41i/RHrCI5Ge8EikJzwS6QmPRHrCI5Ge8EikJzwS6QmPRHrCI5Ge 8EikJzwS6QmPRHrCI5Ge8EikJzwS6QmPRHrCI5Ge8EikJzwS6QmPRHrCI5Ge8EikJzwS6en/xDIm vAnsrIcAAAAASUVORK5CYII= ------=_NextPart_000_0160_01C082FF.D567E0C0-- From nkklrp@hotmail.com Mon Jan 29 04:18:37 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20207 invoked from network); 29 Jan 2001 04:18:37 -0000 Received: from f80.law10.hotmail.com (HELO hotmail.com) (64.4.15.80) by qmail.accesscomm.ca with SMTP; 29 Jan 2001 04:18:37 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 28 Jan 2001 20:18:35 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 29 Jan 2001 04:18:34 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Possible misunderstanding of definition Date: Mon, 29 Jan 2001 04:18:34 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jan 2001 04:18:35.0102 (UTC) FILETIME=[8BE76FE0:01C089AA] X-Evolution: 0000009d-0010 Norm made some claims about the properties of Cloneproof SSD, claims which were based on a misunderstanding to that method's definition. So let me clarify the definition: Cloneproof SSD definition: Drop the weakest defeat that's among the current Schwartz set. Repeat till there are no cycles in the current Schwartz set. (The current Schwartz set is the Schwartz set based on undropped defeats. Only undropped defeats are considered in determining the current Schwartz set). [end of definition] But my proposal of Cloneproof SSD also includes the same add-on iterative tiebreaker that Schulze's method uses: If Cloneproof SSD returns a tie, by undefeating more than 1 option, then drop the other options and repeat Cloneproof SSD with only those options that were in the tie. Norm's statements seemed based on an assumption that Cloneproof SSD meant: Within the initial Schwartz set, simultaneously drop each cycle's weakest defeat. If this undefeats more than 1 option, then start over, re-applying the above rule among the options that were undefeated. That method has been called "DCD", and "IBCM". Cloneproof SSD is nothing like DCD. If Norm mistook Cloneproof SSD for DCD, and says that means that Cloneproof SSD's definition is complicated and easily misunderstood, then I reply that my definition of Cloneproof SSD, in this letter, doesn't lend itself to being mistaken for the DCD definition, and isn't complicated or easily misunderstood. Check again the Cloneproof SSD definition in this letter. It's brief & simple. If it's argued that Cloneproof SSD's stopping rule isn't quite as simple as that of ordinary SSD, I reply that it's still simple and natural. We avoid clone problems by solving all the cycles in the current Schwartz set. I recommend Cloneproof SSD because there's value in having a definition that immediately makes sense and has obvious motivation & justification. According to Markus Schulze, the proponent of Schulze's method, Cloneproof SSD and Schulze's method are just 2 definitions of the same method, always producing the same results. Which definition sounds less arbitrary? Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Tue Jan 30 06:55:36 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 29767 invoked from network); 30 Jan 2001 06:55:36 -0000 Received: from f110.law10.hotmail.com (HELO hotmail.com) (64.4.15.110) by qmail.accesscomm.ca with SMTP; 30 Jan 2001 06:55:36 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 29 Jan 2001 22:55:32 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Tue, 30 Jan 2001 06:55:32 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Cloneproof SSD & Norm's misdefinition of it. Date: Tue, 30 Jan 2001 06:55:32 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Jan 2001 06:55:32.0915 (UTC) FILETIME=[A3C56830:01C08A89] X-Evolution: 0000009e-0010 Debian Voting System Committee: I haven't received any correspondence from the committee for a week or two at least. There hasn't been a stoppage anything like this, even during the Holidays. So I don't know what's going on. Maybe my e-mail address accidentally got deleted from the committee's Cc line, and so that would admit the possibility that I've missed some committee correspondence. Norm has posted some misstatements based on a misdefinition, to the EM mailing list, and not sure whether or not it was sent here too, I sent a brief reply to you yesterday. Today I'm sending the conclusion of that reply: When I first defined Cloneproof SSD, here & elsewhere, the first thing I said was, "SSD can be made cloneproof by changing its stopping rule." That should have been clue #1 that Cloneproof SSD is just SSD with a different stopping rule. Then, I stated the definition of Cloneproof SSD. It was identical to SSD's definition, except that the stopping rule was different. That should have been clue #2 that Cloneproof SSD is just SSD with a different stopping rule. But, in spite of those 2 clues, Norm has written his own, wildly different definition of Cloneproof SSD. Since it's my proposal, let's just use my definition, ok? Norm apparently does understand the definition of SSD, because he agrees that, when there are no pairwise ties, it's equivalent to Schulze's method. But if he understands SSD's wording, how come he gets so all confused by Cloneproof SSD's definition, which is identical except for a different stopping rule? Even after I spelled it out that Cloneproof SSD is SSD with a different stopping rule? But Norm invented a wildly different method which he calls Cloneproof SSD. Norm, I encourage you to invent whatever you want to, but please use an original name for your inventions. And would you be so kind as to let me be the one who decides what is my definition of a method that I propose? As I said, Markus Schulze, the proponent of Schulze's method, says that Cloneproof SSD and Schulze are equivalent, always producing the same winner(s), or the same win-probabilities. Norm, you said you were going to test for that equivalence with your simulations. I take it that you've done that testing for your very own "Cloneproof SSD", which isn't mine. Now, why don't you start over, and, this time, test for Cloneproof SSD, as I define it, to test for that equivalence. Yes or No: Can you find an example where Cloneproof SSD fails a criterion that Schulze passes, or is less decisive than Schulze? Yes or No: Can you find an example where the 2 methods produce different winner-sets, or different win-probabilities? I've written a demonstration that the Cloneproof SSD & Schulze are equivalent. I'll post it later. But there's nothing un-obvious about the demonstration. Assume that a certain candidate is a Schulze winner (not necessarily the only one), and ask whether that candidate can fail to be undefeated after Cloneproof SSD has gotten a current Schwartz set containing no cycles. Then assume that a candidate is not a Schulze winner, and ask whether that candidate can be undefeated at that time. But I'll send my demonstration of that later. Can we dispense with wasting people's time by defining & discussing Reverse Tideman, DCD, IBCM, & Peyton Young's method? I don't want to waste the letter kilobytes needed to demonstrate that none of those , iterated or otherwise, is Cloneproof SSD. When talking about Cloneproof SSD & its properties, I'm going to have to insist that we only use my own definition, by my own wording. So then Norm shows that his method, which he calls "Cloneproof SSD", but which I'll call Petry's method, fails Monotonicity. If you want to show that Cloneproof SSD fails a Criterion, Norm, show that by using _my_ definition of Cloneproof SSD. Applying Cloneproof SSD to Norm's Monotonicity example, it doesn't fail Monotonicity. In the 1st election, it chooses C. In the 2nd election, when some voters have changed their ballots by voting A over C, that changes the winner from C to A. Now, since Cloneproof SSD's definition is so brief, and since it's been misunderstood, can I repeat it? Cloneproof SSD is SSD with a new stopping rule: We don't stop until there are no cycles in the current Schwartz set. Otherwise it's the same as SSD. I'll restate it here: Drop the weakest defeat that's among the current Schwartz set. Repeat till there are no cycles in the current Schwartz set. (The current Schwartz set is the Schwartz set based only on undropped defeats). [end of definition] As I said, I'd use that with the same add-on iterative tiebreaker that you use with Schulze: If the method produces a tie by undefeating more than 1 option, then drop everything but the undefeated options and re-apply the method to that set of options. Quit when that doesn't reduce the size of the set of undefeated options. Now Norm, is that clear? That definition is not complicated. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From aj@azure.humbug.org.au Tue Jan 30 07:28:06 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 16297 invoked from network); 30 Jan 2001 07:28:06 -0000 Received: from azure.humbug.org.au (203.24.22.40) by qmail.accesscomm.ca with SMTP; 30 Jan 2001 07:28:06 -0000 Received: from aj by azure.humbug.org.au with local (Exim 3.12 #1 (Debian)) id 14NVCV-0007Di-00; Tue, 30 Jan 2001 17:27:39 +1000 Date: Tue, 30 Jan 2001 17:27:39 +1000 From: Anthony Towns To: MIKE OSSIPOFF Cc: moth@debian.org, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Message-ID: <20010130172739.A27685@azure.humbug.org.au> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Tue, Jan 30, 2001 at 06:55:32AM -0000 Organisation: Lacking X-PGP: http://azure.humbug.org.au/~aj/aj_key.asc X-Evolution: 0000009f-0030 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 30, 2001 at 06:55:32AM -0000, MIKE OSSIPOFF wrote: > Debian Voting System Committee: > I haven't received any correspondence from the committee for a week > or two at least. Personally, I haven't had anything to say. Schulze/Cloneproof SSD seem fine to me (as do most of the similar ones to be honest). Cheers, aj --=20 Anthony Towns I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUBOnZs6+RRvX9xctrtAQFw+AQAgcxBe8w2LA6nlNMEua+iyYhiVcN1HB1Z 9p4/AtQlBIK6baDwe9gPF7vnDLoccbAkRlo6zH7vYD8K3VyHVtV5RT9pbPOn/Gfl e1KtC5MayuzfvHVg/AUcNVJIDxUOuJHlTakOOG8a+o+jd++IlU8YZaxBwPUuagQu NIOVRsms88o= =1Q4L -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From moth@debian.org Tue Jan 30 07:59:40 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28040 invoked from network); 30 Jan 2001 07:59:40 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 30 Jan 2001 07:59:40 -0000 Received: (qmail 30663 invoked by uid 1000); 30 Jan 2001 07:59:19 -0000 Date: Tue, 30 Jan 2001 02:59:19 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Message-ID: <980840154.9cff29ca@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Tue, Jan 30, 2001 at 06:55:32AM -0000 X-Evolution: 000000a0-0010 On Tue, Jan 30, 2001 at 06:55:32AM -0000, MIKE OSSIPOFF wrote: > Debian Voting System Committee: > > I haven't received any correspondence from the committee for a week > or two at least. Other than mail today, and your email, the last messages I've received from the committee are Norm's as of Jan 20. Basically: it looks like most of your assertions about the correctness of cloneproof ssd are correct. Still, I'm dubious about a few issues: [1] The computational complexity issue -- since most elections have a condorcet winner, I'll guess that we're talking 3rd and 5th power in size of schwartz set (as opposed to number of candidates). [2] "natural and intuitive for people who haven't studied voting systems" issue -- for cloneproof ssd to be more intuitive than schwartz, a person must have enough background to in voting theory to understand terms such as "weakest defeat" and "current schwartz set". For a person with no background in such issues, dropping an option from consideration has something going for it which manipulating an abstract data structure [pairwise totals] does not: at each stage of progress, what's being represented is directly related to what was on the ballots. [3] Personally, I'd love to see a proof that cloneproof ssd is equivalent to schwartz. [I think I'd understand both better after studying such a proof.] [None of this is very definitive, so I've been working through Norm's code, trying to make sure I understand what it's doing, with an eye towards performing my own simulations. Which is why I've been silent.] Thanks, -- Raul From nkklrp@hotmail.com Wed Jan 31 01:43:59 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 8952 invoked from network); 31 Jan 2001 01:43:59 -0000 Received: from f53.law10.hotmail.com (HELO hotmail.com) (64.4.15.53) by qmail.accesscomm.ca with SMTP; 31 Jan 2001 01:43:59 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 30 Jan 2001 17:43:56 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 31 Jan 2001 01:43:56 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Date: Wed, 31 Jan 2001 01:43:56 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jan 2001 01:43:56.0453 (UTC) FILETIME=[46397550:01C08B27] X-Evolution: 000000a1-0010 > > I haven't received any correspondence from the committee for a week > > or two at least. > >Other than mail today, and your email, the last messages I've >received from the committee are Norm's as of Jan 20. Ok, I was getting needlessly concerned that something was wrong. If Norm didn't send to this committee a copy of his EM posting, then of course it was improper of me to reply to it here; but I didn't know. > >Basically: it looks like most of your assertions about the correctness of >cloneproof ssd are correct. Still, I'm dubious about a few issues: > >[1] The computational complexity issue -- since most elections have a >condorcet winner, I'll guess that we're talking 3rd and 5th power in >size of schwartz set (as opposed to number of candidates). Yes, I think that's what Markus meant. > >[2] "natural and intuitive for people who haven't studied voting systems" >issue -- for cloneproof ssd to be more intuitive than schwartz, a person >must have enough background to in voting theory to understand terms such >as "weakest defeat" and "current schwartz set". For a person with no >background in such issues, dropping an option from consideration has >something going for it which manipulating an abstract data structure >[pairwise totals] does not: at each stage of progress, what's being >represented is directly related to what was on the ballots. My girlfriend had no prior experience with voting systems when I asked her about SSD. I made a diagram while I spoke. I made some dots on a paper to represent candidates. And then I drew a roughly circular or elliptical closed curve, and said "All the candidates in here are unbeaten by anyone outside of there." Then I drew a smaller ellipse inside that one, and said "And these candidates aren't beaten by anyone outside this inner set. Both of these are unbeaten sets, and that inner one is an innermost unbeaten set (It doesn't have a smaller one within it)." I'd previously told here that Smith beats Jones if more people rank Smith over Jones than vice-versa, so she knew what I meant by "beat". I said that if everyone is beaten by someone, then no matter whom we elect, we're going to have to disregard the fact that the people have said they like someone else better. So it makes sense, then, to at least overrule the fewest possible, by disregarding the defeat with least support. But these candidates outside of that inner set all have defeats, from within that set, that aren't contradicted by other defeats going the other way--they're beaten fair & square. It's the defeats _within_ that innermost unbeaten set that are in mutual conflict for choosing a winner, and so it's among those defeats that we should drop the defeat with the least support. In that way, I defined & explained SSD in a way that was easily understood by someone with no prior exposure to voting systems. She didn't like SD because of the cycles, which sounded very counterintuitive when I mentioned them. As Norm pointed out, my Cloneproff SSD definition mentions cycles, but Cloneproof SSD isn't for a public proposal. It's for committees like Debian and its smaller committees, such as the technical committee. > >[3] Personally, I'd love to see a proof that cloneproof ssd is equivalent >to schwartz. [I think I'd understand both better after studying such >a proof.] That will be along tomorrow for sure. I'd send it right now, but someone wants me to get off the computer and go somewhere right now. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From npetry@accesscomm.ca Wed Jan 31 05:31:14 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4095 invoked from network); 31 Jan 2001 05:31:14 -0000 Received: from static24-72-22-210.reverse.accesscomm.ca (HELO mandos.accesscomm.ca) (24.72.22.210) by qmail.accesscomm.ca with SMTP; 31 Jan 2001 05:31:14 -0000 Message-ID: <003d01c08b46$e1646ac0$d2164818@mandos.accesscomm.ca> From: "Norman Petry" To: "Steve Greenland" , "Rob Lanphier" , "Norman Petry" , "Mike Ossipoff" , "Buddha Buck" , "Anthony Towns" , "Raul Miller" Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Date: Tue, 30 Jan 2001 23:30:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Evolution: 000000a2-0010 Yesterday, Mike Ossipoff wrote: > >But Norm invented a wildly different method which he calls Cloneproof >SSD. Norm, I encourage you to invent whatever you want to, but please >use an original name for your inventions. And would you be so kind as >to let me be the one who decides what is my definition of a method >that I propose? > etc. Mike seems to be implying that I was attempting to redefine his proposed method in order to level false criticisms against it. I honestly don't know why he should think I would want to do that. Mike is certainly correct that I had misunderstood what he had intended in his cloneproof SSD proposal. However, this was simply an honest misunderstanding -- I was not attempting to misrepresent him. When I began looking at Cloneproof SSD, I referred to the definition that Mike had supplied, which was: "Drop the weakest defeat that's among the Schwartz set. Repeat till there are no cycles in the Schwartz set. Whoever is unbeaten at that time wins." The way I interpreted this was: 1. Calculate the Schwartz set, S. 2. Drop the weakest defeat in S (if there is more than 1 equal, drop them all) 3. Repeat (2), until there are no cycles among candidates in S. Mike's intended method was: 1. Calculate the Schwartz set, S. 2. Drop the weakest defeat in S (if there is more than 1 equal, drop them all) 3. Repeat (1), until there are no cycles among candidates in S. I believe that the definition that Mike supplied was unclear, and that the my (admittedly incorrect) interpretation of Cloneproof SSD is also described by the definition he supplied. The problem is that it is not obvious what exactly is being repeated -- is it the dropping of weakest defeats, or the calculation of Schwartz sets? Even with Mike's clarified definition, I don't think it is obvious. Others may disagree, of course. In any case, the analysis of "Cloneproof SSD" that I posted was incorrect, since it does not pertain to the method Mike intended. It is I believe an accurate analysis of "Iterated Schwartz//Young", but that of course is unimportant, since no one is seriously proposing such a method (I certainly have no wish to do so ;-) > >Norm, you said you were going to test for that equivalence with your >simulations. I take it that you've done that testing for your very >own "Cloneproof SSD", which isn't mine. Now, why don't you start over, >and, this time, test for Cloneproof SSD, as I define it, to test for >that equivalence. > After receiving your reply on Sunday ("Possible misunderstanding of definition"), I did precisely this. I applied both the Schulze method and my revised implementation of Cloneproof SSD to a series of 'Smith Matrices', and could not discover *any* difference in results over a great many trials with a large number of candidates (25,000 trials, 15 candidates). Therefore, I think it is safe to say that Cloneproof SSD is equivalent to Schulze, and therefore has the same properties as that method (Clone Independence, Monotonicity, etc.) A *proof* that the methods are equivalent would be better, of course, but I have no doubt that Cloneproof SSD is the same as the Schulze beatpath method (at least, as I had always understood it -- more on this later). >Yes or No: Can you find an example where Cloneproof >SSD fails a criterion that Schulze passes, or is less decisive than >Schulze? Yes or No: Can you find an example where the 2 methods produce >different winner-sets, or different win-probabilities? No. The methods are equivalent, provided that the 'beatpaths' used in Schulze's method are constructed using pairwins only. I had always interpreted Schulze's method in that way -- that is, a 'beatpath' is composed only of 'beats' (pairwise victory vote totals). However, in a recent message to EM, Markus clarified that his concept of beatpaths can actually contain tied values as well. With that interpretation, the two methods *are* slightly different. Here's what Markus wrote on that subject: >From: Markus Schulze >To: election-methods-list@eskimo.com >Date: January 21, 2001 12:29 PM >Subject: Re: [EM] Cloneproof SSD [...] > >The winner of the Schwartz set heuristic and the winner of the >beat path heuristic can differ only when there is at least one >pairwise tie. > >Example: > > A:B=50:50 > A:C=35:25 > B:C=40:60 > >The Schwartz set heuristic would choose candidate A because >candidate A is the unique Schwartz winner. The Schwartz set >heuristic treats all pairwise ties in the same manner. > >The beat path heuristic would choose candidate C because beat >paths must be able to contain pairwise ties. Otherwise it would >be possible that there is neither a beat path from candidate X >to candidate Y nor from candidate Y to candidate X. > I had never noticed this detail before, and wondered if Markus had changed the definition of his method. However, looking at his earliest description of the beatpaths, this is in fact the definition that he used. On Sat, 04 Oct 1997 he wrote (EM, "Re: Condorect sub-cycle rule"): ***** What are beat-path-defeats? A defeats B M:N via a beat-path means: M is the highest number with X >> Y means, that the number of voters, who prefer X to Y, is LARGER THAN OR EQUAL TO [emphasis added] the number of voters, who prefer Y to X, and that X gets at least M votes in the pairwise comparison of X versus Y. The following statement is valid: A >> B or there is a set of candidates C[1],...,C[s] with A >> C[1] >> ... >> C[s] >> B. N is the highest number with X >> Y means, that the number of voters, who prefer X to Y, is larger than or equal to the number of voters, who prefer Y to X, and that X gets at least N votes the pairwise comparison of X versus Y. The following statement is valid: B >> A or there is a set of candidates D[1],...,D[t] with B >> D[1] >> ... >> D[t] >> A. And M > N. ***** A more accurate description for Markus' concept would be 'beatOrTiePath', but that's a bit clumsy, I suppose. My previous testing of Schulze used pairwins only, so the result of changing the method to allow for ties in the beatpaths will yield slightly different results than Cloneproof SSD. Markus argues that by allowing ties in beatpaths, the method does a bit better job at minimising the number of voters who may be dissatisfied with the choice of winner. In that example, option A is opposed by at most 50 voters, whereas option C is only opposed by 40, and therefore it is better to pick C. I have modified my simulator to correct for the revised definition of Schulze, and will post some results showing what change (if any) this has on the method. Markus claims that allowing ties (or wins) in beatpaths is all that is necessary to guarantee that the method satisfies the Smith criterion (or LIIAC). Since Smith allows pairties, this sounds correct to me, but I haven't tested the revised implementation for Smith compliance. I would guess that all of Mike's strategy-free criteria would still be met as well (how could one hope to manipulate an election outcome by relying on pairwise ties?), but perhaps Mike is in a better position than I am to comment on that. >Can we dispense with wasting people's time by defining & discussing >Reverse Tideman, DCD, IBCM, & Peyton Young's method? I don't want to >waste the letter kilobytes needed to demonstrate that none of those >, iterated or otherwise, is Cloneproof SSD. When talking about Cloneproof >SSD & its properties, I'm going to have to insist that we only use >my own definition, by my own wording. > >So then Norm shows that his method, which he calls "Cloneproof SSD", >but which I'll call Petry's method, fails Monotonicity. > >If you want to show that Cloneproof SSD fails a Criterion, Norm, >show that by using _my_ definition of Cloneproof SSD. > The tone of these comments is needlessly belligerent. I simply misunderstood your proposal, and thought that my analysis *did* apply to the method you were writing about. [...] >Cloneproof SSD is SSD with a new stopping rule: We don't stop until >there are no cycles in the current Schwartz set. Otherwise it's the >same as SSD. I'll restate it here: > >Drop the weakest defeat that's among the current Schwartz set. Repeat >till there are no cycles in the current Schwartz set. > >(The current Schwartz set is the Schwartz set based only on undropped >defeats). > >[end of definition] > >As I said, I'd use that with the same add-on iterative tiebreaker that >you use with Schulze: If the method produces a tie by undefeating more >than 1 option, then drop everything but the undefeated options and >re-apply the method to that set of options. Quit when that doesn't >reduce the size of the set of undefeated options. > >Now Norm, is that clear? That definition is not complicated. > I agree it's not complicated (presupposing one understands the Schwartz-set concept), but no, it still isn't very clear, for reasons explained above. I do now understand what you mean, though. -- Norm Petry From robla@eskimo.com Wed Jan 31 09:22:57 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 27363 invoked from network); 31 Jan 2001 09:22:57 -0000 Received: from mx1.eskimo.com (204.122.16.48) by qmail.accesscomm.ca with SMTP; 31 Jan 2001 09:22:57 -0000 Received: from eskimo.com (robla@eskimo.com [204.122.16.13]) by mx1.eskimo.com (8.9.1a/8.8.8) with ESMTP id BAA14552; Wed, 31 Jan 2001 01:22:42 -0800 Received: from localhost (robla@localhost) by eskimo.com (8.9.1a/8.9.1) with SMTP id BAA21955; Wed, 31 Jan 2001 01:22:42 -0800 (PST) X-Authentication-Warning: eskimo.com: robla owned process doing -bs Date: Wed, 31 Jan 2001 01:22:41 -0800 (PST) From: Rob Lanphier To: Anthony Towns cc: MIKE OSSIPOFF , moth@debian.org, npetry@accesscomm.ca, stevegr@debian.org, bmbuck@14850.com Subject: Re: Cloneproof SSD & Norm's misdefinition of it. In-Reply-To: <20010130172739.A27685@azure.humbug.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Evolution: 000000a3-0010 On Tue, 30 Jan 2001, Anthony Towns wrote: > On Tue, Jan 30, 2001 at 06:55:32AM -0000, MIKE OSSIPOFF wrote: > > Debian Voting System Committee: > > I haven't received any correspondence from the committee for a week > > or two at least. > > Personally, I haven't had anything to say. Schulze/Cloneproof SSD seem > fine to me (as do most of the similar ones to be honest). Same here. I'm largely silent on these issues both from lack of time to meaningfully participate, and a general sense, in skimming the messages, that things are going pretty well. Concorde isn't state-of-the-art, but many of the methods that we discuss are (Tideman, SSD, Cloneproof SSD, etc.) Hopefully, after another five years of debating this on EM (and hopefully attracting some more formal research to this area), we'll have moved the state of the art forward, and we can talk about another rev of the constitution if the Debian project feels that keeping up with the Jones's is a worthy goal. So, it's great to hear that Raul is poring over Norman's code. I think just about everyone on the committee has a better understanding of the nuances associated with the methods than I do. Not that I'm asking to be taken off the committee, mind you, just confessing that I'm the last person to ask. The most interesting product of this committee from my perspective, is a rigorous legal definition of a state-of-the-art voting method. So, I'm just hoping the group can come to some sort of consensus on a recommendation, so that the work of actually defining the method can move forward. Rob Lanphier robla@eskimo.com http://www.eskimo.com/~robla From stevegr@debian.org Wed Jan 31 13:19:43 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5210 invoked from network); 31 Jan 2001 13:19:43 -0000 Received: from 206.180.143.9.adsl.hal-pc.org (HELO molehole.moregruel.net) (206.180.143.9) by qmail.accesscomm.ca with SMTP; 31 Jan 2001 13:19:43 -0000 Received: from speedy.private [192.168.1.2] (postfix) by molehole.moregruel.net with esmtp (Exim 3.12 #1 (Debian)) id 14NxAg-0003Ky-00; Wed, 31 Jan 2001 07:19:38 -0600 Received: by speedy.private (Postfix, from userid 1000) id 784A34709; Wed, 31 Jan 2001 07:19:34 -0600 (CST) Date: Wed, 31 Jan 2001 07:19:33 -0600 From: Steve Greenland To: Rob Lanphier Cc: Anthony Towns , MIKE OSSIPOFF , moth@debian.org, npetry@accesscomm.ca, bmbuck@14850.com Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Message-ID: <20010131071933.A18417@molehole.moregruel.net> Reply-To: Steve Greenland References: <20010130172739.A27685@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from robla@eskimo.com on Wed, Jan 31, 2001 at 01:22:41AM -0800 Organization: Not my strong point Mail-Copies-To: never X-Evolution: 000000a4-0010 On 31-Jan-01, 03:22 (CST), Rob Lanphier wrote: > On Tue, 30 Jan 2001, Anthony Towns wrote: > > On Tue, Jan 30, 2001 at 06:55:32AM -0000, MIKE OSSIPOFF wrote: > > > Debian Voting System Committee: > > > I haven't received any correspondence from the committee for a week > > > or two at least. > > > > Personally, I haven't had anything to say. Schulze/Cloneproof SSD seem > > fine to me (as do most of the similar ones to be honest). > > Same here. I'm largely silent on these issues both from lack of time to > meaningfully participate, and a general sense, in skimming the messages, > that things are going pretty well. And I pretty much agree with what Rob said. It's going well, and I don't have much to add. Steve -- Steve Greenland From nkklrp@hotmail.com Sat Jan 27 04:31:37 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 4086 invoked from network); 27 Jan 2001 04:31:37 -0000 Received: from f123.law10.hotmail.com (HELO hotmail.com) (64.4.15.123) by qmail.accesscomm.ca with SMTP; 27 Jan 2001 04:31:37 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Jan 2001 20:31:34 -0800 Received: from 207.111.205.34 by lw10fd.law10.hotmail.msn.com with HTTP; Sat, 27 Jan 2001 04:31:34 GMT X-Originating-IP: [207.111.205.34] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Why I recommend Cloneproof SSD Date: Sat, 27 Jan 2001 04:31:34 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jan 2001 04:31:34.0460 (UTC) FILETIME=[079C87C0:01C0881A] X-Evolution: 000000a5-0010 Cloneproof SSD meets the same criteria that Schulze meets. Markus Schulze, the proponent of Schulze's method, says that Cloneproof SSD and Schulze's method always produce the same outcome. They're 2 different ways of defining the same method. So then, what differences are there between Cloneproof SSD and Schulze?: Advantage of Cloneproof SSD: Cloneproof SSD has natural & obvious motivation & justification. Schulze's rule doesn't have that. Let me re-state the definition of Cloneproof SSD: Drop the weakest defeat that's among the current Schwartz set. Repeat till there are no cycles in the current Schwartz set. Apply the same add-on itterative tiebreaker that's used with Schulze. That is: If, at the end of the count, more than 1 option is undefeated, then eliminate all the defeated options, and re-apply the count to those remaining. Repeat this procedure till there's a single undefeated option or until the the procedure fails to reduce the size of the set of undefeated options. In the latter case, randomly choose a ballot from the election, and declare as winner the undefeated option that's ranked highest on that ballot. (Instead of a random ballot, the rules could specify the use of a ranking prepared by someone such as the DPL. But the random ballot is more democratic). [end of definition] Only the brief 1st paragraph of that definition is different from Schulze. That brief paragraph replaces a much less brief Schulze wording. It's obvious that there's something special about the Schwartz set, and that the defeats among the Schwartz set are the only ones that are actually in mutual conflict as regards choosing a winner. And it's obvious that if we don't have an obvious Condorcet winner, because everything is defeated, then anything we choose will violate public wishes. Whatever we choose, the voters have collectively said that something else is better. So, since we have to disregard or overrule one of those defeats, it's obvious that it's better to overrule the weakest defeat among those defeats that are in conflict for choosing a winner. So we drop the weakest defeat that's among the Schwartz set. Schulze isn't obvious. Tell someone that we find beatpaths, sequences of defeats, between candidates, and compare each pair of candidates according to which has a stronger beatpath to the other. The person will reply that that sounds plausible, but will wonder "Why that plausible procedure instead of the many other plausible procedures that could be written?" You could say that each beatpath is half of a cycle, and with the two half-cycles disagreeing on which candidate is better than the other, we consider which is stronger. But what's obvious about how we measure the strength of a beatpath? The analogy with a chain's weakest link isn't valid. A chain breaks at one link, its weakest link. But say a beatpath consists of 2 defeats: 53 to 47 and 51 to 49. 54:49 is the weakest defeat, but are you sure that 53:47 doesn't have about an equal effect on the conclusion that the beatpath is right? The chain analogy is no good with a beatpath. There's no natural justification for how Schulze measures beatpath strength. Advantage of Schulze: Markus Schulze says that Schulze is more computationally efficient than Cloneproof SSD. He says that Schulze's computing time varies as the 3rd power of the number of candidates, and that Cloneproof SSD's computing time varies as the 5th power of the number of candidates. If we used a handcount, then that would be a compelling consideration.] But a computer will be used. What, Cloneproof SSD might take 90 seconds instead of 10 seconds? So what? Of course there's something appealing about a more efficient procedure. The less efficient procedure is doing something in a roundabout way. The less roundabout more efficient procedure look more elegant, in that regard. Norm said that Schulze's implementation code is more elegant, maybe for that reason. [conclusion of advantages of the 2 procedures] I'm appealing to your social sense. Cloneproof SSD's natural & obvious motivation & justification makes it a good public proposal. Schulze, without that advantage, is a poor public proposal. If you're proposing a voting system that has precedent with the well-known international Debian organization, then you have a big acceptance advantage. "Debian uses this, and they like it." I remind you that the public enaction of a good voting system be to the advantage of you, and me, and everyone in Debian, and everyone not in Debian. Everyone, really. Once a good voting system gets some public use, it's in a position to spread to more public applications. If you noticed how I & others let Gore lose because we voted for Nader, and if you've heard Nader-preferring voters telling why they'rea afraid to vote for Nader, for fear that they'll let Bush win, then you know why voting reform matters. It's often pointed out that the public is much more humane & progressive than their representatives. That's because people feel forced for vote for a lesser-evil. They vote for someone they don't like, to defeat someone even worse. With people voting for disliked candidates, it's no surprise that we get officeholders who aren't as good as what people would like. Additionally, of course, Cloneproof SSD's better obviousness & naturalness makes it easier to propose in Debian too. Schulze is one more plausible proposal, in addition to many. Cloneproof SSD is a compellingly obvious procedure. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From stevegr@debian.org Thu Feb 8 16:20:50 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9692 invoked from network); 8 Feb 2001 16:20:50 -0000 Received: from 206.180.143.9.adsl.hal-pc.org (HELO molehole.moregruel.net) (206.180.143.9) by qmail.accesscomm.ca with SMTP; 8 Feb 2001 16:20:50 -0000 Received: from speedy.private [192.168.1.2] (postfix) by molehole.moregruel.net with esmtp (Exim 3.12 #1 (Debian)) id 14QtoJ-0005jc-00; Thu, 08 Feb 2001 10:20:43 -0600 Received: by speedy.private (Postfix, from userid 1000) id 8CA0D4709; Thu, 8 Feb 2001 10:20:41 -0600 (CST) Date: Thu, 8 Feb 2001 10:20:41 -0600 From: Steve Greenland To: MIKE OSSIPOFF , moth@debian.org, npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: cloneproof ssd defeat strength Message-ID: <20010208102041.A8868@molehole.moregruel.net> Reply-To: Steve Greenland References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: ; from nkklrp@hotmail.com on Thu, Feb 08, 2001 at 04:33:33AM -0000 Organization: Not my strong point Mail-Copies-To: never X-Evolution: 000000a8-0010 On 07-Feb-01, 22:33 (CST), MIKE OSSIPOFF wrote: > As Norm pointed out, the defeat-opposition tiebreaker adds some > decisiveness. So it's a question of whether that extra decisiveness, > plus the better plausibility, is worth the added wording. Will > people like it more because of the greater plausibility, or will > they like it less because of the longer definition. As a non-EM expert, I think the longer definition is actually better, because it is more complete (it immediately answers the question "what if two defeat strengths are equal?") Brevity is good, but not at the expense of clarity and complleteness. Of course, if it hurt the quality of the method, one wouldn't want to use defeat-opposition, but you'd improve the definition by adding "If two defeats are equally weak (by the defeat-strength criterion), then both are dropped." But using defeat-opposition as a tiebreaker appears to improve the method, so I think we should include it. Steve -- Steve Greenland From stevegr@debian.org Mon Feb 12 14:34:28 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20597 invoked from network); 12 Feb 2001 14:34:28 -0000 Received: from 206.180.143.9.adsl.hal-pc.org (HELO molehole.moregruel.net) (206.180.143.9) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 14:34:28 -0000 Received: from speedy.private [192.168.1.2] (postfix) by molehole.moregruel.net with esmtp (Exim 3.12 #1 (Debian)) id 14SK3c-0000Pr-00; Mon, 12 Feb 2001 08:34:24 -0600 Received: by speedy.private (Postfix, from userid 1000) id 5A6934709; Mon, 12 Feb 2001 08:34:19 -0600 (CST) Date: Mon, 12 Feb 2001 08:34:19 -0600 From: Steve Greenland To: Raul Miller Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <20010212083419.A747@molehole.moregruel.net> Reply-To: Steve Greenland References: <981958773.7cc6f418@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <981958773.7cc6f418@debian.org>; from moth@debian.org on Mon, Feb 12, 2001 at 01:36:36AM -0500 Organization: Not my strong point Mail-Copies-To: never X-Evolution: 000000a9-0010 On 12-Feb-01, 00:36 (CST), Raul Miller wrote: > > But I'm trying to ask about a combination of simple condorcet and > cloneproof ssd. Allow me to propose this formally: > > > cloneproof ssd, but the matter goes to revote if it can't be expressed as > a simple condorcet winner by arbitrarily introducing specific preferences > on truncated ballots. > Ick. A couple of problems with this. A: it sounds hard to implement, if I understand correctly: take all the truncated ballots, and try arbitray combinations of votes for those truncations until there is a winner. Yuck. What if different combinations produce different winners? Who gets to choose? B: If I truncate a ballot, it's because I think all the remaining choices are equally bad, and my understanding of pairwise methods is the best way to vote against a choice is to leave it unranked. (Or is that true only of some of the methods?) C: The premise doesn't even sound right. If there is no CW, then your method is a whole new way of producing a winner, not cloneproof SSD. I understand your objection to dropping a choice that people have voted for, but you're doing that anyway when you have any kind of election, unless the winning choice is unanimous. > The observations behind this are: > > ... > [2] some people change their opinions during discussion > [3] new ideas and solutions come up in discussion But our current technique allows revoting, which takes care of [2], and [3] should have been dealt with before the call for voting. If a truly new desirable choice comes up after the ballot has been issued, then there should be sufficient people (re-)voting "Further Discussion" to cause a new vote with the new option. Steve -- Steve Greenland From stevegr@debian.org Mon Feb 12 17:03:55 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 3757 invoked from network); 12 Feb 2001 17:03:55 -0000 Received: from 206.180.143.9.adsl.hal-pc.org (HELO molehole.moregruel.net) (206.180.143.9) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 17:03:55 -0000 Received: from speedy.private [192.168.1.2] (postfix) by molehole.moregruel.net with esmtp (Exim 3.12 #1 (Debian)) id 14SMOF-0000QH-00; Mon, 12 Feb 2001 11:03:51 -0600 Received: by speedy.private (Postfix, from userid 1000) id E97584709; Mon, 12 Feb 2001 11:03:50 -0600 (CST) Date: Mon, 12 Feb 2001 11:03:50 -0600 From: Steve Greenland To: Raul Miller Cc: Steve Greenland , MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <20010212110350.A911@molehole.moregruel.net> Reply-To: Steve Greenland References: <981958773.7cc6f418@debian.org> <20010212083419.A747@molehole.moregruel.net> <981989701.0eb91514@debian.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <981989701.0eb91514@debian.org>; from moth@debian.org on Mon, Feb 12, 2001 at 10:07:33AM -0500 Organization: Not my strong point Mail-Copies-To: never X-Evolution: 000000aa-0010 On 12-Feb-01, 09:07 (CST), Raul Miller wrote: > I'm using cloneproof ssd to pick the winner, I'm using straight condorcet > to check the winner. > Just to make sure I understand your proposed sequence: 1. Find the winner X according to Cloneproof SSD. 2. If (1) required dropping weakest defeats to break cycles, then check by adding X as the lowest ranked option to any ballots that did not previously rank X and confirming that X is now the "pure" CW. 3. If (2) is not true, re-run the election (probably with choices from the original Schwartz set plus (possibly) one or more new options). > My objection is to dropping a choice which more people prefer than the > winner. In the interests of defeating strategy, I'm willing to do > something arbitrary about ballots which express no preference about > either of those options (the winner, and whatever more people prefer > than the winner). But Norm and Mike assert that Cloneproof SSD is relatively immune to strategy, and I guess I don't see why arbitrarily adding votes to previously truncated ballots is better than arbitrarily dropping the weakest defeat and accepting that result. Except perhaps that your scheme will *strongly* discourage truncation. If that's the real intent, then we should just forbid truncated ballots and be done with it. Even if your scheme does turn out to be a good (by the various criteria we've been using to judge EMs), there's something emotionally distasteful about modifying submitted ballots (even in a "we're just checking" mode). I think there's enough paranoid people in Debian to suspect ulterior motives in your approach (which, I want to emphasize, I *don't* suspect), which will tend to raise acrimony when the time comes to actually get this approved. Steve -- Steve Greenland From moth@debian.org Wed Jan 17 00:13:13 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5637 invoked from network); 17 Jan 2001 00:13:13 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 17 Jan 2001 00:13:13 -0000 Received: (qmail 11141 invoked by uid 1000); 17 Jan 2001 00:12:56 -0000 Date: Tue, 16 Jan 2001 19:12:56 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Tideman Schwartz set failure example Message-ID: <979690317.f61078aa@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Jan 15, 2001 at 02:59:25AM -0000 X-Evolution: 000000ab-0010 On Mon, Jan 15, 2001 at 02:59:25AM -0000, MIKE OSSIPOFF wrote: > Uh...Where did I say that I was advocating that? Did I mention Norm's > simulation when I asked him if choosing outside the Schwartz set > can cause a strategy problem? I'm sorry -- I presumed it. My thought was that since you were indicated that you were ignoring various criteria you were doing so on the basis of Norm's simulation results. Thanks, -- Raul From moth@debian.org Wed Jan 17 00:14:11 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 7316 invoked from network); 17 Jan 2001 00:14:11 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 17 Jan 2001 00:14:11 -0000 Received: (qmail 11181 invoked by uid 1000); 17 Jan 2001 00:13:54 -0000 Date: Tue, 16 Jan 2001 19:13:54 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Tideman Schwartz set failure example Message-ID: <979690418.ae699bd0@debian.org> References: <005b01c07f82$1e0e3ee0$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005b01c07f82$1e0e3ee0$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Tue, Jan 16, 2001 at 12:03:56AM -0600 X-Evolution: 000000ac-0010 On Tue, Jan 16, 2001 at 12:03:56AM -0600, Norman Petry wrote: > If you like, I can send you a copy of my simulator (it's GPLed Python > code), so you can experiment with it by incorporating these models. That would be great. Thanks, -- Raul From moth@debian.org Thu Feb 1 08:02:44 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 28917 invoked from network); 1 Feb 2001 08:02:44 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 1 Feb 2001 08:02:44 -0000 Received: (qmail 6459 invoked by uid 1000); 1 Feb 2001 08:02:22 -0000 Date: Thu, 1 Feb 2001 03:02:22 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Message-ID: <20010201030222.A5965@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Thu, Feb 01, 2001 at 06:51:29AM -0000 X-Evolution: 000000ad-0010 On Tue, Jan 30, 2001 at 11:30:10PM -0600, Norman Petry wrote: > >"Drop the weakest defeat that's among the Schwartz set. Repeat till there > >are no cycles in the Schwartz set. Whoever is unbeaten at that time wins." > > > >The way I interpreted this was: > > > >1. Calculate the Schwartz set, S. > >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them > >all) > >3. Repeat (2), until there are no cycles among candidates in S. ^^^ > >Mike's intended method was: > > > >1. Calculate the Schwartz set, S. > >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them > >all) > >3. Repeat (1), until there are no cycles among candidates in S. ^^^ On Thu, Feb 01, 2001 at 06:51:29AM -0000, MIKE OSSIPOFF wrote: > Excuse me, but what you say was my intention is identical with what > you say was your interpretation. Not exactly, though I think he should have said 3. Repeat (1,2), until there are no cycles among candidates in S. > Do you have a problem with: "Eliminate the candidate who, among > the uneliminated candidates, has fewest votes. Repeat till a candidate > has a majority of the votes"? I think he had a problem with the question of "which schwartz set". Cloneproof SSD eliminates a "pairwise beat", which may result in the elimination of a candidate when the schwartz set is refigured. I seem to recall that you had a definition of cloneproof ssd where you said "current schwartz set", but the definition Norm included (quoted at the top of this message) doesn't even have that. In any event, if we go with cloneproof ssd, we would either need to make sure to provide a gloss which defines "current schwartz set" [as well as other terms] or the definition would have to be changed to explicitly spell out that the schwartz set is refigured based on a beats matrix where the votes in favor tally for the weakest beat have been zeroed out. We would also need make sure it's explicit what to do where the weakest beat has multiple instances. [I hesitate to call this a tie.] Thanks, -- Raul From moth@debian.org Thu Feb 1 08:25:27 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20169 invoked from network); 1 Feb 2001 08:25:27 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 1 Feb 2001 08:25:27 -0000 Received: (qmail 6998 invoked by uid 1000); 1 Feb 2001 08:25:06 -0000 Date: Thu, 1 Feb 2001 03:25:06 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Message-ID: <981014905.06006c89@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Wed, Jan 31, 2001 at 01:43:56AM -0000 X-Evolution: 000000ae-0010 On Wed, Jan 31, 2001 at 01:43:56AM -0000, MIKE OSSIPOFF wrote: > My girlfriend had no prior experience with voting systems when I asked > her about SSD. I made a diagram while I spoke. I made some dots on > a paper to represent candidates. And then I drew a roughly circular > or elliptical closed curve, and said "All the candidates in here are > unbeaten by anyone outside of there." Then I drew a smaller ellipse > inside that one, and said "And these candidates aren't beaten by > anyone outside this inner set. Both of these are unbeaten sets, > and that inner one is an innermost unbeaten set (It doesn't have a > smaller one within it)." This sounds like a definition of condorcet. > I'd previously told here that Smith beats Jones if more people rank > Smith over Jones than vice-versa, so she knew what I meant by "beat". > > I said that if everyone is beaten by someone, then no matter whom we > elect, we're going to have to disregard the fact that the people > have said they like someone else better. So it makes sense, then, > to at least overrule the fewest possible, by disregarding the defeat > with least support. But these candidates outside of that inner set > all have defeats, from within that set, that aren't contradicted by > other defeats going the other way--they're beaten fair & square. > It's the defeats _within_ that innermost unbeaten set that are > in mutual conflict for choosing a winner, and so it's among those > defeats that we should drop the defeat with the least support. Note that the "disregard the fact that the people have said they like someone else better" is ambiguous. You could mean: [1] Eliminate from the ballots the preferences cast in favor of the candidate on the positive side of the weakest defeat. or [2] Eliminate from the pairwise tally matrix, the cell which represents that weakest defeat (without eliminating any other votes in favor of that candidate). Intuitively, I understand that you mean [2]. [But only because I've played with the mechanics of the pairwise vote tally matrix.] > In that way, I defined & explained SSD in a way that was easily > understood by someone with no prior exposure to voting systems. > > She didn't like SD because of the cycles, which sounded very > counterintuitive when I mentioned them. I think that this means that you didn't have a very good definition of what a cycle was. Which implies that you didn't talk about how you could have more than one candidate in the innermost unbeaten set. Which implies that she didn't understand what you meant by "disregard the fact that the people have said they like someone else better". Thanks, -- Raul From moth@debian.org Sun Feb 4 13:34:55 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 16205 invoked from network); 4 Feb 2001 13:34:55 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 4 Feb 2001 13:34:55 -0000 Received: (qmail 31399 invoked by uid 1000); 4 Feb 2001 13:34:34 -0000 Date: Sun, 4 Feb 2001 08:34:34 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: cloneproof ssd Message-ID: <981292831.c68b486b@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Feb 04, 2001 at 03:08:49AM -0000 X-Evolution: 000000af-0010 I'll say this for cloneproof ssd: it's much easier to write code for than schulze. Basically, you need a routine to find the schwartz set[*], and you need a routine to zero out the weakest defeat. Then: find schwartz, and do eliminate followed by schwartz until it convertes on a result. However, it occurs to me that we've not defined "weakest defeat". Is "weakest defeat": [1] The smallest tally which beats another option. [2] The biggest tally which is beaten by another item. [no, but:] [3] the combination of the smallest tally which beats another item with the biggest telly which is beaten by that small tally. [probably yes.] I'll agree that the cases where [1] is different from [3] are vanishingly small. And, I'll agree that [1] is simpler to implement. However, [3] seems more justifiable. But is it? -- Raul From moth@debian.org Sun Feb 4 13:47:19 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 5403 invoked from network); 4 Feb 2001 13:47:19 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 4 Feb 2001 13:47:19 -0000 Received: (qmail 31578 invoked by uid 1000); 4 Feb 2001 13:46:59 -0000 Date: Sun, 4 Feb 2001 08:46:59 -0500 From: Raul Miller To: Norman Petry Cc: Steve Greenland , Rob Lanphier , Mike Ossipoff , Buddha Buck , Anthony Towns Subject: Re: Decisiveness in Voting Methods (was: Re: Cloneproof SSD) Message-ID: <981293863.c88ccac4@debian.org> References: <016301c08332$2034ab60$d2164818@mandos.accesscomm.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <016301c08332$2034ab60$d2164818@mandos.accesscomm.ca>; from npetry@accesscomm.ca on Sat, Jan 20, 2001 at 04:41:21PM -0600 X-Evolution: 000000b0-0010 On Sat, Jan 20, 2001 at 04:41:21PM -0600, Norman Petry wrote: > Sure. I've actually rewritten some comprehensive tests looking at the > decisiveness of a variety of voting methods. For now, I'll just assume that > the importance of decisiveness is obvious. I'll present an argument for > decisiveness later when we return to some of the supermajority proposals > (Miller-2, etc.) and Raul's latest proposal (Condorcet with no tiebreaker). I suspect we're getting to the point where it's time to continue this discussion. > It seems to me that there are at least three ways of judging how decisive a > voting method is: > > 1) Total Tiebreaks: ... > 2) Elections Requiring Tiebreaker: ... > 3) Outcome Affected by Tiebreaker: ... I should note that "further discussion and revote" as a tie breaker minimizes the number of tiebreaks needed in an election [at most you need 1]. However, that's not why I was advocating that method. Instead, it was the idea that if the results represent a conflict too deep to be resolved by a single casting vote, then it's probably time to talk about why this is the case. The question is: us it wise to declare that a consensus has been achieved when one must modify a majority of the ballots to achieve that consensus? -- Raul From moth@debian.org Tue Feb 6 02:23:36 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 18140 invoked from network); 6 Feb 2001 02:23:36 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Feb 2001 02:23:36 -0000 Received: (qmail 23876 invoked by uid 1000); 6 Feb 2001 02:23:14 -0000 Date: Mon, 5 Feb 2001 21:23:14 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: moth@debian.org, npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: cloneproof ssd defeat strength Message-ID: <981425925.9aa90c50@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Feb 05, 2001 at 02:39:48AM -0000 X-Evolution: 000000b1-0010 On Mon, Feb 05, 2001 at 02:39:48AM -0000, MIKE OSSIPOFF wrote: > For SSD & Cloneproof SSD, the weakest defeat is the defeat that has > fewest people voting for it. The people voting against the defeat > aren't counted (except that of course they must be less than those > voting for the defeat, or else it wouldn't be a defeat). Er.. since you didn't address the point I tried to raise in my last message in this thread, I'll try to raise it again: Let's imagine several defeats: [A] 101 > 100 [B] 100 > 0 [C] 100 > 99 [D] 99 > 98 I have no problem with the idea that [A] is the strongest defeat and that [D] is the weakest. But I'm asking whether [B] should be considered a defeat of equivalent strength to [C]. My understanding is that [C] should be considered a weaker defeat than [B]. That defeats should be considered equal only if both the "winner" and the "loser" get the same number of votes. -- Raul From moth@debian.org Tue Feb 6 02:36:46 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11389 invoked from network); 6 Feb 2001 02:36:46 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Feb 2001 02:36:46 -0000 Received: (qmail 24072 invoked by uid 1000); 6 Feb 2001 02:36:24 -0000 Date: Mon, 5 Feb 2001 21:36:24 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Decisiveness in Voting Methods (was: Re: Cloneproof SSD) Message-ID: <981426384.3a314c5b@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Feb 05, 2001 at 03:05:05AM -0000 X-Evolution: 000000b2-0010 Raul wrote: > >The question is: us it wise to declare that a consensus has been achieved > >when one must modify a majority of the ballots to achieve that consensus? On Mon, Feb 05, 2001 at 03:05:05AM -0000, MIKE OSSIPOFF wrote: > If there's a circular tie there's no consensus. In fact there's > virtually never a consensus anyway. Sorry, sloppy terminology on my part. Rephrased: The question is: us it wise to declare that a majority decision has been reached when one must modify a majority of the ballots to achieve that majority decision? > If you have no decision and call for further discussion when > there's a circular tie, then I can easily vote to make a > strategic circular tie if I know that my favorite option isn't > going to be the CW. Then I can make you listen to my arguments > until the next vote. And when that vote comes, I'll use offensive > order-reversal to make another strategic circular tie, and you'll > have to listen to my arguments again, etc... Finally, people will > start getting so tired of this that they'll vote my way, knowing > that their favorite, the CW, hasn't been able to win, and isn't > going to. This seems to require near godlike ability to predict the outcome of the election, the ability to organize a significant chunk of the voters, and no such abilities on the part of the rest of the voters. > Maybe they'll do that because they're giving up to me, , and, in > that way, Condorcet Only has a lot in common with the Consensus > decisionmaking process. Or maybe they're just giving up because > they've found that their favorite just can't win (without noticing > that my offensive strategy is the reason why their favorite can't > win). So they're trying another way of voting, just to get the whole > thing overwith, so that the committee can move on to the next issue. Ok, but I'd like to understand a bit more of the nature of this problem. For example, I'm wondering if forcing a revote to only include condorcet winners from the previous vote (under certain conditions, perhaps: has already gone to a revote, and not all options from last election were condorcet winners) would defeat this strategy. > Offensive order-reversal is one way to make a strategic circular tie, > but it isn't the only way. Truncation will do it too. I've observed > offensive strategically-motivated truncation in a pairwise-count > election. Norm says that, on the average, people only vote for half > of the options. That's a lot of truncation. Even if it isn't done > with offensive strategic intentions, it's enough to totally mess up > Condorcet winners. So do we let truncation reward the truncator by > stopping the election of the CW, as can & will happen in Condorcet > Only (CO), or do we use a voting system that doesn't reward truncation > in that way, a voting system that will elect the CW anyway, in spite > of the truncation? A voting system in which truncation against a CW or > the sincere Smith set, whether or not it's strategically motivated, > can't benefit the truncators. Hmm.. this could imply either forbidding truncation, or allowing omitted preferences to be determined systematically by the vote resolution process. > You don't get that with CO. You instead get an ongoing battle in which > a stubborn offensive strategizer will prevail. Or in which, at the > very least, stubbornness and pushiness will tend to prevail over the > co-operativeness of people who just want to get the issue resolved. I understand this assertion, but I don't understand how to create representative examples. Thanks, -- Raul From moth@debian.org Tue Feb 6 21:05:18 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24958 invoked from network); 6 Feb 2001 21:05:18 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 6 Feb 2001 21:05:18 -0000 Received: (qmail 7269 invoked by uid 1000); 6 Feb 2001 21:04:57 -0000 Date: Tue, 6 Feb 2001 16:04:56 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: cloneproof ssd defeat strength Message-ID: <981492651.9fe81a25@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Tue, Feb 06, 2001 at 08:11:38PM -0000 X-Evolution: 000000b3-0010 On Mon, Feb 05, 2001 at 02:39:48AM -0000, MIKE OSSIPOFF wrote: > > > For SSD & Cloneproof SSD, the weakest defeat is the defeat that has > > > fewest people voting for it. The people voting against the defeat > > > aren't counted (except that of course they must be less than those > > > voting for the defeat, or else it wouldn't be a defeat). > > > >Er.. since you didn't address the point I tried to raise in my > >last message in this thread, I'll try to raise it again: > I addressed the question posed below. I said this: On Tue, Feb 06, 2001 at 08:11:38PM -0000, MIKE OSSIPOFF wrote: > > >the weakest defeat is the defeat that has > > > fewest people voting for it. > > So if we wanted to compare defeat [B] and defeat [C], to say which > of those is weaker than the other, then we'd say that they're equal. I understand that that's *what* you said, but I didn't see any reason for saying that [A] > [B] > [C] > [D] is not true. > >Let's imagine several defeats: > > > >[A] 101 > 100 > >[B] 100 > 0 > >[C] 100 > 99 > >[D] 99 > 98 > > > >I have no problem with the idea that [A] is the strongest defeat and that > >[D] is the weakest. But I'm asking whether [B] should be considered a > >defeat of equivalent strength to [C]. > > Since we judge the defeat strengths by the number of people voting > for the defeat, and don't consider the number of people voting against > the defeat (except to require that they be fewer than the number > voting for the defeat), the answer to your questions is that defeats > [B] & [C] are equal, as judged by Condorcet and by Schulze's method. But why? > By "Condorcet", I mean SSD, Cloneproof SSD, PC, Smith//PC, SD, and > Tideman. Tideman is Prof. Tideman's reasonable interpretation of one > of Condorcet's proposals. When I say "Tideman", I refer to that method > using Condorcet's own way of measureing defeat-strength. > > On the EM list, our discussion established that Condorcet intended for > defeat-strength to be measured by the number of people voting for > that defeat. Was there any discussion on the EM list of the use of number of people voting against as a tie-breaker? > >My understanding is that [C] should be considered a weaker defeat > >than [B]. That defeats should be considered equal only if both the > >"winner" and the "loser" get the same number of votes. > > No, I meant it literally when I said that the strength of a pairwise > defeat is measured by the number of people who voted for that defeat. > The number voting against the defeat is irrelevant, except of course > that it must be less than the number of people voting for the defeat, > in order for that defeat to exist. > > Defeat [B] and defeat [C] are equal, according to the "defeat-support" > measure of defeat-strength. That's the measure that Condorcet himself > proposed, and it's the one that is used by the voting systems that > Norm & I are proposing for Debian. But is that because the issue was not considered by Condorcet, or because it's important that they be treated as equal. If it's important: why? > I know that one would at first expect margins to be the right measure > for defeat strength. But in my previous posting about this I told > several important reasons why defeat-support is a better measure > of defeat-strength. I fail to see how this justifies treating [B] and [C] as equal. Thanks, -- Raul From moth@debian.org Sun Feb 11 17:43:59 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 20590 invoked from network); 11 Feb 2001 17:43:59 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 11 Feb 2001 17:43:59 -0000 Received: (qmail 11785 invoked by uid 1000); 11 Feb 2001 17:43:36 -0000 Date: Sun, 11 Feb 2001 12:43:36 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <981912406.7cd9b2af@debian.org> Reply-To: moth@debian.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Sun, Feb 11, 2001 at 12:20:48AM -0000 X-Evolution: 000000b4-0010 > >The question is: us it wise to declare that a majority decision has been > >reached when one must modify a majority of the ballots to achieve that > >majority decision? On Sun, Feb 11, 2001 at 12:20:48AM -0000, MIKE OSSIPOFF wrote: > But when Cloneproof SSD drops a defeat, it would rarely be a defeat > with majority support. We drop the weakest defeat, overruling the > fewest voters possible. It's still a defeat of a member of the schwartz set. > CO requires the modification of ballots, by the voters, in order to > repeat the same circular tie that led to the discussion & revote. This is only true if there are no other options. I can see the value of cloneproof ssd if the problems are really irresolvable, but I've yet to encounter any examples of such problems. > Unless the discussion changes people's opinion about the options, > , which can't be counted on, or else someone has to vote insincerely > next time, in order to avoid getting the same circular tie as before. > The need to vote insincerely is something that we want to avoid. > CO often will require insincere voting. Cloneproof SSD & BeatpathWinner > do the best job of not making anyone have need to vote insincerely. You left the possibility of introducing other options. Basically, what I'm thinking is this: if a nontrivial schwartz set exists, I'd like to make sure that there are no better options before overriding voters. > That's because that method's automated compromise does the > compromising for us. We don't have to try to judge what is the best we > can get. We don't have to haggle. We just vote our sincere rankings. > > If someone really preferred consensus discussion & revote to a > rank-count, then they could propose Pluality, with discussion & revote > if no one gets a majority. You accept pairwise-count's automatic > compromise, when there's a CW. It avoids much strategy & haggling. A > top-quality circular tie breaker like Cloneproof SSD or BeatpathWinner > avoids those problems even better. Plurality has other flaws. > > > If you have no decision and call for further discussion when > > > there's a circular tie, then I can easily vote to make a > > > strategic circular tie if I know that my favorite option isn't > > > going to be the CW. Then I can make you listen to my arguments > > > until the next vote. And when that vote comes, I'll use offensive > > > order-reversal to make another strategic circular tie, and you'll > > > have to listen to my arguments again, etc... Finally, people will > > > start getting so tired of this that they'll vote my way, knowing > > > that their favorite, the CW, hasn't been able to win, and isn't > > > going to. > > > >This seems to require near godlike ability to predict the > >outcome of the election, the ability to organize a significant > >chunk of the voters, and no such abilities on the part of > >the rest of the voters. > > No, one need only say "X is my favorite, and so I won't rank anyone > but X." With CO, that will often work to defeat a CW, so that the > strategy will be rewarded by improving X's chance. Or, one might even > make a guess about what option is the biggest rival to his favorite, > and vote some other option over it. That's called "burying", > "turkey-raising", or "offensive order reversal". > > I've observed offensively-intended truncation in a pairwise-count > vote. > > I've observed order-reversal in a rank-balloting. I have no problem with arbitrarily ranking preferences which a voter has left unstated. I do have a problem ignoring expressed preferences, however. So, I guess I'm saying I'd not at all mind a limited form of cloneproof ssd -- one which can be achieved by introducing arbitrary preferences where voters haven't ranked options. Basically: if only a first preference was specified by a voter, it would be ok to indicate second, third, etc. preferences for that voter. If the cloneproof winner would be the condorcet winner after introducing such unexpressed preferences, that's fine. > > > Maybe they'll do that because they're giving up to me, , and, in > > > that way, Condorcet Only has a lot in common with the Consensus > > > decisionmaking process. Or maybe they're just giving up because > > > they've found that their favorite just can't win (without noticing > > > that my offensive strategy is the reason why their favorite can't > > > win). So they're trying another way of voting, just to get the whole > > > thing overwith, so that the committee can move on to the next issue. > > > >Ok, but I'd like to understand a bit more of the nature of this > >problem. For example, I'm wondering if forcing a revote to > >only include condorcet winners from the previous vote (under > >certain conditions, perhaps: has already gone to a revote, and > >not all options from last election were condorcet winners) would > >defeat this strategy. > > You mean only include the Smith set in the discussion & revote? > That doesn't get rid of the strategy incentives in CO. I can still > increase the win-probability of my favorite merely by voting for > it only. Without having any predictive information. With a guess about > my favorite's biggest rival, I can often benefit from offensive > order-reversal with CO. Any other strategy besides not expressing preferences? > Then there's the need for haggling in the discussion, and the fact > that the more assertive, stubborn, and unco-operative people will > be the ones who benefit, because the more co-operative people will > "consense" to give up what they wanted and change their rankings in > the subsequent revote. I do understand this, but there's also the possibility of meaningful discussion. > >this could imply either forbidding truncation > > But that's a drastic solution. Voters shouldn't have to rank more > options than they want to. They needn't, if we use Cloneproof SSD > or BeatpathWinner. > > , or allowing omitted > >preferences to be determined systematically by the vote resolution > >process. > > People will get mad if the count process adds to their rankig > preferences that they didn't vote. Even if the effect is only to validate the cloneproof ssd outcome? > >I understand this assertion, but I don't understand how to > >create representative examples. > > Examples will be along shortly. Thanks, -- Raul From moth@debian.org Mon Feb 12 06:19:48 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2219 invoked from network); 12 Feb 2001 06:19:48 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 06:19:48 -0000 Received: (qmail 21045 invoked by uid 1000); 12 Feb 2001 06:19:24 -0000 Date: Mon, 12 Feb 2001 01:19:24 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <981958624.78bffdab@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Feb 12, 2001 at 06:01:23AM -0000 X-Evolution: 000000b5-0010 On Mon, Feb 12, 2001 at 06:01:23AM -0000, MIKE OSSIPOFF wrote: > The fact that Debian now uses a voting system that gets a definite > winner via a count rule shows that that's how they like it. Actually, one of the biggest reasons we're having this discussion is that the current constitution may be interpreted in a way that all options are eliminated in the case of a circular tie. -- Raul From moth@debian.org Mon Feb 12 06:37:00 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 30004 invoked from network); 12 Feb 2001 06:37:00 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 06:37:00 -0000 Received: (qmail 21147 invoked by uid 1000); 12 Feb 2001 06:36:36 -0000 Date: Mon, 12 Feb 2001 01:36:36 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <981958773.7cc6f418@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Feb 12, 2001 at 06:01:23AM -0000 X-Evolution: 000000b6-0010 On Mon, Feb 12, 2001 at 06:01:23AM -0000, MIKE OSSIPOFF wrote: > >So, I guess I'm saying I'd not at all mind a limited form of > >cloneproof ssd -- one which can be achieved by introducing > >arbitrary preferences where voters haven't ranked options. > > But with Cloneproof SSD, or BeatpathWinner, truncation doesn't cause > a problem. Viewpoint #1. Counter argument -- they might miss a valuable opportunity. > It's one thing to have discussion & revote because there's a genuine > circular tie. It's another thing when it happens merely because someone > truncates, with strategic intentions, or maybe just out of laziness. Viewpoint #2. I agree. > >Basically: if only a first preference was specified by a voter, it > >would be ok to indicate second, third, etc. preferences for that voter. > > There are people who'd strongly object to having preferences counted > for them that they didn't vote. Viewpoint #3. Counter argument -- for the mechanism I'm proposing (see below), this would never result in a worse result than that which would be obtained in cloneproof ssd. > >If the cloneproof winner would be the condorcet winner after introducing > >such unexpressed preferences, that's fine. > > That wouldn't make Cloneproof SSD or BeatpathWinner any more likely > to choose a sincere CW. Viewpoint #1. See above. > >Any other strategy besides not expressing preferences? [response elided] I meant in the context of condorcet. [Or: more precisely, condorcet but resorting to cloneproof ssd for circular ties caused by truncated ballots.] See below for formal proposal. > > > People will get mad if the count process adds to their rankig > > > preferences that they didn't vote. > > > >Even if the effect is only to validate the cloneproof ssd outcome? > > But Cloneproof SSD & BeatpathWinner don't need that kind of protection. But I'm trying to ask about a combination of simple condorcet and cloneproof ssd. Allow me to propose this formally: cloneproof ssd, but the matter goes to revote if it can't be expressed as a simple condorcet winner by arbitrarily introducing specific preferences on truncated ballots. The observations behind this are: [1] circular ties are very rare, and [2] some people change their opinions during discussion [3] new ideas and solutions come up in discussion #3 is the real reason I'm pursuing this line of argument, but #1 and #2 are reasons why I suspect that it just might work. > > > Examples will be along shortly. > > Sincere preferences: > > 40: ABC > 25: BAC > 35: CBA > > The 40 ABC people truncate, because they want to give A as much help > as possible against the other options, an understandable and inevitable > temptation. The resulting votes: > > 40: A > 25: BAC > 35: CBA > > If everyone had voted sincerely, B would win as CW. But due to the > truncation, we have a circular tie, and it goes to discussion & > revote. Would not go up for revote with the mechanism I've just proposed. Thanks, -- Raul From moth@debian.org Mon Feb 12 07:27:54 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 17242 invoked from network); 12 Feb 2001 07:27:54 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 07:27:54 -0000 Received: (qmail 21799 invoked by uid 1000); 12 Feb 2001 07:27:29 -0000 Date: Mon, 12 Feb 2001 02:27:29 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <981962446.8f6c1c61@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Mon, Feb 12, 2001 at 07:11:57AM -0000 X-Evolution: 000000b7-0010 > > > But with Cloneproof SSD, or BeatpathWinner, truncation doesn't cause > > > a problem. > > > >Viewpoint #1. Counter argument -- they might miss a > >valuable opportunity. On Mon, Feb 12, 2001 at 07:11:57AM -0000, MIKE OSSIPOFF wrote: > Sure, with any voting system, someone can hurt himself by not > supporting a compromise that he needs. No voting system can help > someone who fails to support a needed compromise. When I said that > truncation causes no problem, I meant that it doesn't steal the > election for the truncators. That's not the opportunity. The opportunity lies in discussing the reasons underlying a true circular tie -- a rather rare and almost contradictory event. [As an aside, this probably needs a timeout mechanism -- something like: if a revote results in the same non-trivial set of condorcet winners as the previous vote, use cloneproof ssd unchecked.] My hunch is that in the [rare] circumstance where A>B>C>A there could be an as yet unrealized option D (D>A, D>B and D>C) which shares features of all three. [This this wouldn't make sense in leader elections.] I guess I should have fleshed this out a bit more before formally proposing it -- but what I really want to do right now is understand its weaknesses (if there are significant ones). Thanks, -- Raul From moth@debian.org Mon Feb 12 15:07:55 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 1665 invoked from network); 12 Feb 2001 15:07:55 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 15:07:55 -0000 Received: (qmail 27529 invoked by uid 1000); 12 Feb 2001 15:07:33 -0000 Date: Mon, 12 Feb 2001 10:07:33 -0500 From: Raul Miller To: Steve Greenland Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <981989701.0eb91514@debian.org> References: <981958773.7cc6f418@debian.org> <20010212083419.A747@molehole.moregruel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010212083419.A747@molehole.moregruel.net>; from stevegr@debian.org on Mon, Feb 12, 2001 at 08:34:19AM -0600 X-Evolution: 000000b8-0010 > On 12-Feb-01, 00:36 (CST), Raul Miller wrote: > > > > But I'm trying to ask about a combination of simple condorcet and > > cloneproof ssd. Allow me to propose this formally: > > > > > > cloneproof ssd, but the matter goes to revote if it can't be expressed as > > a simple condorcet winner by arbitrarily introducing specific preferences > > on truncated ballots. > > On Mon, Feb 12, 2001 at 08:34:19AM -0600, Steve Greenland wrote: > Ick. A couple of problems with this. > > A: it sounds hard to implement, if I understand correctly: take all the > truncated ballots, and try arbitray combinations of votes for those > truncations until there is a winner. Yuck. What if different combinations > produce different winners? Who gets to choose? I don't think it's that complicated. All we need to do is show that the winner is ok -- so adding the winner as the last preference on any ballots which didn't specify a preference for the winner should be sufficient. Anything more complicated should be irrelevant for a pure condorcet winner. > B: If I truncate a ballot, it's because I think all the remaining > choices are equally bad, and my understanding of pairwise methods is > the best way to vote against a choice is to leave it unranked. (Or is > that true only of some of the methods?) If this is an issue, then it's a reason to avoid cloneproof ssd. I don't see this as a reason to favor unchecked cloneproof ssd. > C: The premise doesn't even sound right. If there is no CW, then your > method is a whole new way of producing a winner, not cloneproof SSD. I'm using cloneproof ssd to pick the winner, I'm using straight condorcet to check the winner. > I understand your objection to dropping a choice that people have voted > for, but you're doing that anyway when you have any kind of election, > unless the winning choice is unanimous. My objection is to dropping a choice which more people prefer than the winner. In the interests of defeating strategy, I'm willing to do something arbitrary about ballots which express no preference about either of those options (the winner, and whatever more people prefer than the winner). > > The observations behind this are: > > > > ... > > [2] some people change their opinions during discussion > > [3] new ideas and solutions come up in discussion > > But our current technique allows revoting, which takes care of [2], and > [3] should have been dealt with before the call for voting. If a truly > new desirable choice comes up after the ballot has been issued, then > there should be sufficient people (re-)voting "Further Discussion" to > cause a new vote with the new option. [1] and [2] weren't justifications, they were probabalistic observations. My point about [3] is that in the rare event that a circular tie *does* occur, that says something unusual about the character of the decision. Saying that [3] should have been dealt with before the call for voting is about as satisfying as saying that there should be no circular ties. My point is that a truly new desirable choice might be made evident because of the vote results. I'll agree that I don't know this for sure, but given the rarity of circular ties (which I think Norm has indicated are rarer in practice than in simulation), I'd like to at least see if this approach is vulnerable to any strategies. Thanks, -- Raul From moth@debian.org Mon Feb 12 20:08:47 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24435 invoked from network); 12 Feb 2001 20:08:47 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 12 Feb 2001 20:08:47 -0000 Received: (qmail 1378 invoked by uid 1000); 12 Feb 2001 20:08:23 -0000 Date: Mon, 12 Feb 2001 15:08:23 -0500 From: Raul Miller To: Steve Greenland Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <982007985.4ebf8a8b@debian.org> References: <981958773.7cc6f418@debian.org> <20010212083419.A747@molehole.moregruel.net> <981989701.0eb91514@debian.org> <20010212110350.A911@molehole.moregruel.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010212110350.A911@molehole.moregruel.net>; from stevegr@debian.org on Mon, Feb 12, 2001 at 11:03:50AM -0600 X-Evolution: 000000b9-0010 > On 12-Feb-01, 09:07 (CST), Raul Miller wrote: > > I'm using cloneproof ssd to pick the winner, I'm using straight condorcet > > to check the winner. On Mon, Feb 12, 2001 at 11:03:50AM -0600, Steve Greenland wrote: > Just to make sure I understand your proposed sequence: > > 1. Find the winner X according to Cloneproof SSD. > > 2. If (1) required dropping weakest defeats to break cycles, then check > by adding X as the lowest ranked option to any ballots that did not > previously rank X and confirming that X is now the "pure" CW. > > 3. If (2) is not true, re-run the election (probably with choices from > the original Schwartz set plus (possibly) one or more new options). Yes, that's what I had proposed. > > My objection is to dropping a choice which more people prefer than the > > winner. In the interests of defeating strategy, I'm willing to do > > something arbitrary about ballots which express no preference about > > either of those options (the winner, and whatever more people prefer > > than the winner). > > But Norm and Mike assert that Cloneproof SSD is relatively immune to > strategy, and I guess I don't see why arbitrarily adding votes to > previously truncated ballots is better than arbitrarily dropping the > weakest defeat and accepting that result. Except perhaps that your > scheme will *strongly* discourage truncation. If that's the real intent, > then we should just forbid truncated ballots and be done with it. The issue here isn't strategy, but quality of result. I guess it's safe to say that I'm outside of voting theory here, and into more general concepts related to group problem solving. > Even if your scheme does turn out to be a good (by the various > criteria we've been using to judge EMs), there's something emotionally > distasteful about modifying submitted ballots (even in a "we're just > checking" mode). I think there's enough paranoid people in Debian to > suspect ulterior motives in your approach (which, I want to emphasize, > I *don't* suspect), which will tend to raise acrimony when the time > comes to actually get this approved. The EM criteria assume that the playing field is fixed. This most recent proposal of mine focusses on changing the playing field [in a certain, rather restricted setting, where the outcome of the vote shows a significant problem associated with the playing field]. Thanks, -- Raul P.S. I am concerned about the complexity of my proposal, and its potential need for a bailout clause ("if same schwartz set two times in a row, with no simple cw winner, just use cloneproof ssd") which would increase that complexity even further. From moth@debian.org Thu Feb 15 03:51:04 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2607 invoked from network); 15 Feb 2001 03:51:04 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 15 Feb 2001 03:51:04 -0000 Received: (qmail 23464 invoked by uid 1000); 15 Feb 2001 03:50:32 -0000 Date: Wed, 14 Feb 2001 22:50:32 -0500 From: Raul Miller To: Anthony Towns Cc: MIKE OSSIPOFF , npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com Subject: Re: CO vs Cloneproof SSD Message-ID: <982208909.224cb8e4@debian.org> References: <981958773.7cc6f418@debian.org> <20010213124200.H13314@azure.humbug.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010213124200.H13314@azure.humbug.org.au>; from aj@azure.humbug.org.au on Tue, Feb 13, 2001 at 12:42:00PM +1000 X-Evolution: 000000ba-0010 On Tue, Feb 13, 2001 at 12:42:00PM +1000, Anthony Towns wrote: > In other words, if there's a circular tie in the absence of truncation > (that is, a sincerely held, circular tie), the matter goes to revote. > > Isn't that more or less what we have at the moment, and what we're > specifically trying to avoid? Sure -- it's expressed ambiguously. It makes a lot of sense to interpret the constitution this way, but if you do you wind up basically ignoring some rather ornate clauses. Anyways, cloneproof ssd with condorcet checking would choose a winner where the current constitution wouldn't. -- Raul From moth@debian.org Thu Feb 15 03:57:11 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9970 invoked from network); 15 Feb 2001 03:57:11 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 15 Feb 2001 03:57:11 -0000 Received: (qmail 23542 invoked by uid 1000); 15 Feb 2001 03:56:46 -0000 Date: Wed, 14 Feb 2001 22:56:46 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <982209048.bcea1db2@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Wed, Feb 14, 2001 at 03:11:36AM -0000 X-Evolution: 000000bb-0010 On Wed, Feb 14, 2001 at 03:11:36AM -0000, MIKE OSSIPOFF wrote: > Norm said that on the average, people in Debian elections only rank > half of the candidates or options. If we randomly fill in the unmarked > rank positions, every election becomes "anything-can-happen-day". Randomly? Where did you get that idea? > >[1] circular ties are very rare, and > > If we base our recommendations on the fact that circular ties are very > rare, then we'll recommend no change from Concorde (Maybe clean up > its wording). That only makes sense if you consider this item in isolation. > >[2] some people change their opinions during discussion > > Hopefully they'll fully study the issues during the pre-election > discussion, so that they won't have to change their opinions later. Yep. > Hopefully everyone who has an idea for a good option will nominate it > initially. People aren't going to like drawn-out vote-discuss-revote > procedures. It will greatly multiply decisionmaking time. This is the argument I'm most worried about. In proposing this, I'm hoping it's not that significant of a concern. > >[3] new ideas and solutions come up in discussion > > But if people propose the best they can find, in the pre-election > nominating period, there won't be a need for belated discussion > and proposal-making. If we were perfect we wouldn't even need to vote, we could do everything all ourselves. Thanks, -- Raul From moth@debian.org Thu Feb 15 04:03:49 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 18703 invoked from network); 15 Feb 2001 04:03:49 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 15 Feb 2001 04:03:49 -0000 Received: (qmail 23677 invoked by uid 1000); 15 Feb 2001 04:03:25 -0000 Date: Wed, 14 Feb 2001 23:03:25 -0500 From: Raul Miller To: MIKE OSSIPOFF Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <20010214230325.A23403@usatoday.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Wed, Feb 14, 2001 at 03:23:25AM -0000 eval: msgid debian X-Evolution: 000000bc-0010 > >The opportunity lies in discussing the reasons underlying a true circular > >tie -- a rather rare and almost contradictory event. On Wed, Feb 14, 2001 at 03:23:25AM -0000, MIKE OSSIPOFF wrote: > If voters & options/candidates were positioned in a 1-dimensional > policy space, circular ties would never happen, and no circular tiebreaker > would be needed. > > But when we add more dimensions to the issue-space, circular ties > will start to happen sometimes. Maybe one reason why Debian doesn't > have many circular ties is because its options are in a 1-dimensional > issue-space. On the other hand: On Tue, Jan 16, 2001 at 12:03:56AM -0600, Norman Petry wrote: > My simulator can work with any number of dimensions of policy space, and if > you like, I can provide additional examples showing the performance curves > for 2,3, or more dimensions. I have found, however that the toughest test > for *any* voting method is the one-dimensional case. Perhaps surprisingly, > *all* voting methods improve significantly in accuracy if there are 2 or > more dimensions. Thanks, -- Raul From moth@debian.org Thu Feb 15 04:22:24 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 10256 invoked from network); 15 Feb 2001 04:22:24 -0000 Received: from pacific.usatoday.com (HELO mail9.usatoday.com) (167.8.29.64) by qmail.accesscomm.ca with SMTP; 15 Feb 2001 04:22:24 -0000 Received: (qmail 23953 invoked by uid 1000); 15 Feb 2001 04:21:59 -0000 Date: Wed, 14 Feb 2001 23:21:59 -0500 From: Raul Miller To: MIKE OSSIPOFF , npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: CO vs Cloneproof SSD Message-ID: <982209947.fde9c9d5@debian.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nkklrp@hotmail.com on Wed, Feb 14, 2001 at 03:11:36AM -0000 X-Evolution: 000000bd-0010 > >cloneproof ssd, but the matter goes to revote if it can't be expressed as > >a simple condorcet winner by arbitrarily introducing specific preferences > >on truncated ballots. I just now tried beefing this up with a variety of improvements that I considered important for stability and fairness. The result was way too complicated for me. I withdraw the proposal. Thanks, -- Raul From nkklrp@hotmail.com Mon Jan 15 03:12:16 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11530 invoked from network); 15 Jan 2001 03:12:16 -0000 Received: from f297.law10.hotmail.com (HELO hotmail.com) (64.4.14.172) by qmail.accesscomm.ca with SMTP; 15 Jan 2001 03:12:16 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Jan 2001 19:12:13 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 15 Jan 2001 03:12:13 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Cloneproof SSD Date: Mon, 15 Jan 2001 03:12:13 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jan 2001 03:12:13.0749 (UTC) FILETIME=[F50CAE50:01C07EA0] X-Evolution: 000000c8-0010 SSD can be made cloneproof by changing its stopping rule: Drop the weakest defeat that's among the current Schwartz set. Repeat till there are no cycles in the Schwartz set. [end of definition] Is this equivalent to Schulze, even in small committees? Or do equal defeats cause Schulze & Cloneproof SSD to pick different winners or to give the alternatives different win probabilities? Norm, you once said that Tideman, unlike Schulze, requires special tiebreaking rules in order to maintain cloneproofness. Is that true of Cloneproof SSD too? Could you comment on how that happens, with a few examples? You once mentioned differences in decisiveness among Schulze, SSD, & Tideman. Could you comment more on that, with a few examples? Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Wed Jan 17 01:52:38 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 21793 invoked from network); 17 Jan 2001 01:52:38 -0000 Received: from f311.law10.hotmail.com (HELO hotmail.com) (64.4.14.186) by qmail.accesscomm.ca with SMTP; 17 Jan 2001 01:52:38 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Jan 2001 17:52:36 -0800 Received: from 63.193.17.133 by lw10fd.law10.hotmail.msn.com with HTTP; Wed, 17 Jan 2001 01:52:35 GMT X-Originating-IP: [63.193.17.133] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Tideman Schwartz set failure example Date: Wed, 17 Jan 2001 01:52:35 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jan 2001 01:52:36.0068 (UTC) FILETIME=[2A27EA40:01C08028] X-Evolution: 000000c9-0010 >My thought was that since you were indicated that you were >ignoring various criteria you were doing so on the basis >of Norm's simulation results. At first I was saying that we shouldn't use the Clone Criterion against SSD, because of the unlikliness of SSD having a problem with it. Norm's simulation confirmed that SSD doesn't really have a clone problem when there are 150 voters. I argued that, even with few voters, the problem isn't likely enough to dominate anyone's decision on running similar alternatives. But I also agree that it's better if we can give an absolute assurance that doing so _can't_ cause unfair advantage or disadvantage. So I agree that it's desirable to meet ICC, and that's why Cloneproof SSD is now my main recommendation for our recommendation to Debian. Likewise for the Schwartz Criterion. I still feel that failing that criterion is no more than an aesthetic embarrassment. But why not avoid that embarrassment if possible, if the cost isn't too high. That's a genuine advantage of Schulze & Cloneproof SSD over Tideman. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Sun Jan 21 06:25:18 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 645 invoked from network); 21 Jan 2001 06:25:18 -0000 Received: from f180.law10.hotmail.com (HELO hotmail.com) (64.4.15.180) by qmail.accesscomm.ca with SMTP; 21 Jan 2001 06:25:18 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 20 Jan 2001 22:25:15 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Sun, 21 Jan 2001 06:25:15 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, moth@debian.org Subject: Re: Decisiveness in Voting Methods (was: Re: Cloneproof SSD) Date: Sun, 21 Jan 2001 06:25:15 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 21 Jan 2001 06:25:15.0406 (UTC) FILETIME=[EABBCAE0:01C08372] X-Evolution: 000000cc-0010 I've pasted something from the end of Norm's letter, and my reply to it, to the beginning of the letter, because it relates to things that clarifies some issues that are discussed later. I'd replied to the entire letter, but then realized that most or all of the reply was unnecessary due to the part that I quote here. So I've deleted the rest of my reply, and only include here these few paragraphs by Norm, with my replies: >Mike has suggested an alternate proposal, 'Cloneproof SSD', which would >probably be equivalent to calculating beatpath-undefeated candidates (both >in terms of decisiveness and results) if all the weakest defeats in any >cycles are dropped and the Schwartz set recalculated until only >pairwise-tied options remain. That's what Cloneproof SSD's rules say to do: Drop the weakest defeat that's among the current Schwart set. Repeat till there are no cycles in the current Schwartz set. [end of definition] The above wording carries out what you said in your paragraph that I quoted. But it isn't necessary to say to drop the weakest defeats in any cycle. They're only dropped within the current Schwartz set, and all that's necessary is to say to drop the weakest defeat among the current Schwartz set. As Norm said, Cloneproof SSD appears to be the same as Beatpath Undefeated, which is the same as the Schulze method as I defined it. The complete Schulze method includes also an add-on tiebreaker. Since I suggest using the same add-on tiebreaker with Cloneproof SSD, that means that Cloneproof SSD is the same as Schulze in its results. At least no on has said otherwise. But, whether it's the same or not, I claim that Cloneproof SSD has all the desirable results properties of Schulze. Cloneproofness. Equal decisiveness. Same results. That's what Norm suggested is likely, and I agree. >However that procedure would actually make >SSD *less* decisive Less decisive than what? Plain SSD gains decisiveness at the cost of clone-criterion noncompliance. You _didn't_ say that Cloneproof SSD is less decisive than Schulze. You suggested that they're the same in that regard, and produce the same results, which is what I'd expect too. >so it would be necessary to wrap the procedure in an >iterative elimination step for it to be the same as Schulze. Yes, it would be necessary to wrap Cloneproof SSD in the same interative elimination step that we wrap Schulze in :-) It's not as if Cloneproof SSD needs wrapping that Schulze doesn't need. It's just that that iterative elimination step is being counted as part of the definition of Schulze, and as something added to Cloneproof SSD. But what it amounts to is that it's something that can be used with either method. That add-on that Schulze uses is part of my Cloneproof SSD proposal. Let me indicate now that, when Cloneproof SSD encounters 2 or more defeats that are equally weakest among the Schwartz set, the obvious thing is to drop them all simultaneously. That's so obvious & natural that it hardly needs to be said. It certainly doesn't qualify as a tiebreak that makes Cloneproof SSD less decisive. Sure it might have to be done at one or more points in the middle of the count. But Cloneproof SSD, just like Schulze, can only have a tie to solve at the final conclusion of the procedure (method plus the iterative tiebreaker that they both use). Both methods, even with the add-on iterative tiebreaker that would be used with both, could return a final tie. An instance of 2 or more winners. Both then need a tiebreaking ballot. Cloneproof SSD, as I'm proposing it, uses the same add-on iterative tiebreaking procedure that Schulze uses. When Schulze or Cloneproof SSD returns a final tie, I suggest that Random Ballot, the use of a ballot randomly chosen from among the election's ballots, would be much more democratic than the use of a tiebreaking ballot written by one particular person, such as a chairman or the DPL. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Mon Jan 22 05:17:29 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 11033 invoked from network); 22 Jan 2001 05:17:29 -0000 Received: from f113.law10.hotmail.com (HELO hotmail.com) (64.4.15.113) by qmail.accesscomm.ca with SMTP; 22 Jan 2001 05:17:29 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 21 Jan 2001 21:17:27 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Mon, 22 Jan 2001 05:17:26 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, npetry@accesscomm.ca Cc: stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Cloneproof SSD: Not more tiebreaks. Date: Mon, 22 Jan 2001 05:17:26 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jan 2001 05:17:27.0044 (UTC) FILETIME=[9C36C440:01C08432] X-Evolution: 000000cd-0010 There's one more thing I want to clarify. I mentioned this in the letter that I deleted, but I don't remember if it was in the letter that I sent: The simulation program reported that SSD used many times more tiebreaks than Schulze did. But that's because the program considered it a tie every time SSD encountered 2 or more equally weakest defeats in the current Schwartz set. But that isn't a tie, in the sense of something that needs a tiebreaker. Cloneproof SSD, in that situation, merely simultaneously drops all of those equally weakest defeats. What could be more natural? They're the weakest, so drop them. That's nothing more than part of Cloneproof SSD's deterministic procedure. No randomizing needed. No drawing lots. No calling the DPL in the middle of the night. No referring to a tiebreaking ranking. No indecisive situation. No tie in any practical sense. I felt that I should mention that, lest the program output give anyone the wrong impression about SSD & Cloneproof SSD. As I said, I now include in Cloneproof SSD's definition the same add-on iterative tiebreaking procedure that's likewise added into Schulze's definition: If, at the end of the count, more than 1 alternative is undefeated, then eliminate all the defeated alternatives and start the count all over. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Thu Feb 1 06:51:34 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 29348 invoked from network); 1 Feb 2001 06:51:34 -0000 Received: from f123.law10.hotmail.com (HELO hotmail.com) (64.4.15.123) by qmail.accesscomm.ca with SMTP; 1 Feb 2001 06:51:34 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 31 Jan 2001 22:51:31 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 01 Feb 2001 06:51:29 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au, moth@debian.org Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Date: Thu, 01 Feb 2001 06:51:29 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2001 06:51:31.0063 (UTC) FILETIME=[68713870:01C08C1B] X-Evolution: 000000d0-0010 Norm wrote: >Yesterday, Mike Ossipoff wrote: > > > > >But Norm invented a wildly different method which he calls Cloneproof > >SSD. Norm, I encourage you to invent whatever you want to, but please > >use an original name for your inventions. And would you be so kind as > >to let me be the one who decides what is my definition of a method > >that I propose? > > > >etc. > >Mike seems to be implying that I was attempting to redefine his proposed >method in order to level false criticisms against it. I honestly don't >know >why he should think I would want to do that. No, I only said that you'd written a wildly different definition, without saying it was intentional. > >When I began looking at Cloneproof SSD, I referred to the definition that >Mike had supplied, which was: > >"Drop the weakest defeat that's among the Schwartz set. Repeat till there >are no cycles in the Schwartz set. Whoever is unbeaten at that time wins." > >The way I interpreted this was: > >1. Calculate the Schwartz set, S. >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them >all) >3. Repeat (2), until there are no cycles among candidates in S. > >Mike's intended method was: > >1. Calculate the Schwartz set, S. >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them >all) >3. Repeat (1), until there are no cycles among candidates in S. Excuse me, but what you say was my intention is identical with what you say was your interpretation. > >I believe that the definition that Mike supplied was unclear It's true that I often unintentionally omitted the "current" from "current Schwartz set". But I indicated a number of times that the Schwartz set that I use is the Schwartz set based only on undropped defeats. , and that the >my (admittedly incorrect) interpretation of Cloneproof SSD is also >described >by the definition he supplied. The problem is that it is not obvious what >exactly is being repeated -- is it the dropping of weakest defeats, or the >calculation of Schwartz sets? Do you have a problem with: "Eliminate the candidate who, among the uneliminated candidates, has fewest votes. Repeat till a candidate has a majority of the votes"? To execute the 1st sentence, we must determine what candidates are uneliminated. To execute the 1st sentence of Cloneproof SSD, we must determine the Schwartz set, based only on undropped defeats. If you know what "uneliminated" means, then why don't you know what "undropped" means? In the IRV definition, you apparently would say: "What is being repeated? Is it the elimination of candidates, or is it the determination of which candidates are uneliminated? I suggest that your confusion isn't reasonable. Ok, Norm, let's get out a copy of my most recent letter. Let's find the sentence that immediately precedes the one that starts with "Repeat...". That preceding sentence says to drop the weakest defeat in the current Schwartz set. In fact, other than the sentence saying "Repeat...", that first sentence is the only other one in the definition. So, what that sentence says to do is what the next sentence says to repeat: Drop the weakest defeat that's among the current Schwartz set. So, to answer your question, the dropping of weakest defeats is what's being repeated. The calculation of the Schwartz set based only on undropped defeats is unmistakeably implied by the fact that the instruction refers to the Schwartz set based only on undropped defeats. That's part of the execution of the action: Drop the weakest defeat that's among the Schwartz set based only on uneropped defeats". Maybe you think that "undropped" doesn't mean "undropped at the time when repeating the instruction in which "undropped" appears. But that's the literal interpretation, and that's what I meant. Executing that action "Drop the weakest defeat that's among the Schwartz set based only on undropped defeats" obviously requires you to first find out what defeats are undropped, if the instruction is taken literally. If you say it's ambigous "when" they must be undropped, I claim that any condition stipulated in an instruction that is to be repeated must be checked on any time when that instruction is executed. That's the literal meaning, and that's what I meant. It didn't say "undropped as of the beginning of the count", or "undropped as of last Tuesday". It just said "undropped". So if, when the instuction is being carried out, a certain defeat has been dropped, then we obviously don't consider it when determining the Schwartz set. And, even though I don't include an explict instruction to determine the Schwartz set, of course we must determine it when executing that instruction. In writing the computer program, these things would all have to be spelled out, of course. But they needn't be spelled out for the person writing the program. Executing "Drop the weakest defeat that's among the Schwartz set based only on undropped defeats" has only one literal meaning to a person, though the FORTRAN compiler needs explicit instructions to check the list of undropped defeats and then calculate the Schwartz set according to a specific formula. Just as we needn't repeat that formula to the programmer in my definition, we also needn't tell him that it's necessary to calculate the Schwartz set in order to execute the instruction that refers to the Schwartz set. If you want to say that "Schwartz set based only on undropped defeats" refers to defeats that are undropped at some time other than when when the instruction is being executed, then I'd be curious at what time you interpreted "undropped" to apply to. Similarly, if IRV's definition says "Eliminate the candidate who , among the as-yet uneliminated candidates, has fewest votes. Repeat the execution of that instruction till a candidate has a majority of the votes", are you going to say that you don't understand that the execution of that instruction requires that we determine which candidates are uneliminated? If you understand that, then you understand that "Drop the weakest defeat that's among the Schwartz set based only on undropped defeats. Repeat till there are no cycles in the Schwartz set based only on undropped defeats" requires that the execution of that instruction requires that we determine the Schwartz set based only on as-yet undropped defeats. If you're saying that you don't understand those two wordings, then I suggest that you're confusion isn't reasonable. If you really insist that you don't understand that, then we can add a special explicit step to the definition, like the one that would be have to be written in your computer program, then we can add that to the definition of Cloneproof SSD. But I claim that the meaning is unambiguous as-is. And, as I said, it's odd that you didn't have trouble with it in ordinary SSD's definition. >Even with Mike's clarified definition, I >don't think it is obvious. Others may disagree, of course. I hope I've answered that. But, if you still don't understand it, we can spell it out much more wordily for you. And, you understood what that meant in the definition of SSD. You have understood SSD correctly, because you correctly said that it's equivalent to Schulze when there are no pairwise ties. And yet, quite inexplicably, you misunderstand that same wording in Cloneproof SSD, as if changing the stopping rule affects your understanding of the preceding rules. Your correct understanding of SSD, contradicts your claim that that same wording is too confusing for you in Cloneproof SSD. >A *proof* that the methods are equivalent would be better, of course, but I >have no doubt that Cloneproof SSD is the same as the Schulze beatpath >method >(at least, as I had always understood it -- more on this later). A demonstration of that will be along tonight. > > >Yes or No: Can you find an example where Cloneproof > >SSD fails a criterion that Schulze passes, or is less decisive than > >Schulze? Yes or No: Can you find an example where the 2 methods produce > >different winner-sets, or different win-probabilities? > >No. The methods are equivalent, provided that the 'beatpaths' used in >Schulze's method are constructed using pairwins only. I had always >interpreted Schulze's method in that way -- that is, a 'beatpath' is >composed only of 'beats' (pairwise victory vote totals). However, in a >recent message to EM, Markus clarified that his concept of beatpaths can >actually contain tied values as well. With that interpretation, the two >methods *are* slightly different. Here's what Markus wrote on that >subject: I didn't think you were going to bring that up here. We've been using "Schulze's method" to mean a method based on beatpaths. Now Schulze tells us that it's based on beat-&-tie paths. What would have been wrong with just using our previous meaning, unless you want to propose Markus's new method. But now that you've brought it up, we can't call our old "Schulze's method" by that name anymore. To distinguish its use of beatpaths, rather than beat-&-tie-paths, I suggest we change the name of our previous "Schulze's method" to "BeatpathWinner". And let "Schulze's method" refer only to Markus's new beat-&-tie-path method. If you consider Schulze's method, the beat-&-tie-path method, to be better than BeatpathWinner, then of course propose it, and state its advantages over BeatpathWinner & Cloneproof SSD. Of course, if you do, then I'll propose, additionally, an iterative SSD-style version of it. > >A more accurate description for Markus' concept would be 'beatOrTiePath', >but that's a bit clumsy, I suppose. I suggest that we call it "Schulze's method", and that our old "Schulze's method" now be called BeatpathWinner. > >My previous testing of Schulze used pairwins only, so the result of >changing >the method to allow for ties in the beatpaths will yield slightly different >results than Cloneproof SSD. Markus argues that by allowing ties in >beatpaths, the method does a bit better job at minimising the number of >voters who may be dissatisfied with the choice of winner. That's the Borda standard. In the case of Borda's method, a high price is paid for that, and most likely that's also so in Schulze's method, the beat-&-tie-path method. I never noticed that aspect of Markus's old proposal, and so I have no idea what its properties are. I suggest that we don't want to recommend to Debian a new method whose properties haven't been sufficiently studied. >Markus claims that allowing ties (or wins) in beatpaths is all that is >necessary to guarantee that the method satisfies the Smith criterion (or >LIIAC). Since Smith allows pairties, this sounds correct to me, but I >haven't tested the revised implementation for Smith compliance. I would >guess that all of Mike's strategy-free criteria would still be met as well >(how could one hope to manipulate an election outcome by relying on >pairwise >ties?), but perhaps Mike is in a better position than I am to comment on >that. I don't know either. It seems to me that it's too late in this process to introduce a new method whose properties we don't know yet. If we hurriedly study its properties, by simulation, etc, and recommend it, and Debian adopts it, they may find problems that our hurried study didn't turn up. Let's stick with methods we know the properties of. >[...] > > >Cloneproof SSD is SSD with a new stopping rule: We don't stop until > >there are no cycles in the current Schwartz set. Otherwise it's the > >same as SSD. I'll restate it here: > > > >Drop the weakest defeat that's among the current Schwartz set. Repeat > >till there are no cycles in the current Schwartz set. > > > >(The current Schwartz set is the Schwartz set based only on undropped > >defeats). > > > >[end of definition] > . > > > >Now Norm, is that clear? That definition is not complicated. > > > >I agree it's not complicated (presupposing one understands the Schwartz-set >concept), but no, it still isn't very clear, for reasons explained above. >I >do now understand what you mean, though. Why didn't you have trouble with that same wording in the SSD definition, if you find it unclear in the Cloneproof SSD definition? The part that you have trouble with in the Cloneproof SSD definition is identical in the SSD definition. Do you have a problem with: "Eliminate the candidate who, among the uneliminated candidates, has fewest votes. Repeat till a candidate has a majority of the votes"? To execute the 1st sentence, we must determine what candidates are uneliminated. To execute the 1st sentence of Cloneproof SSD, we must determine the Schwartz set, based only on undropped defeats. If you know what "uneliminated" means, then why don't you know what "undropped" means? That paragraph says what I want to say briefly, and so I'm going to paste it to the beginning of this letter. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Thu Feb 1 07:35:03 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 24082 invoked from network); 1 Feb 2001 07:35:03 -0000 Received: from f106.law10.hotmail.com (HELO hotmail.com) (64.4.15.106) by qmail.accesscomm.ca with SMTP; 1 Feb 2001 07:35:03 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 31 Jan 2001 23:35:00 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Thu, 01 Feb 2001 07:35:00 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Omission in IRV definition Date: Thu, 01 Feb 2001 07:35:00 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2001 07:35:00.0367 (UTC) FILETIME=[7BB569F0:01C08C21] X-Evolution: 000000d1-0010 I've just noticed that my definition of IRV left out the instruction for transfering votes. In that form the definition wouldn't work as intended, of course, but it still serves to make the point that I wanted to make, about clarity and unambiguity. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 01:03:35 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 2805 invoked from network); 2 Feb 2001 01:03:35 -0000 Received: from f130.law10.hotmail.com (HELO hotmail.com) (64.4.15.130) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 01:03:35 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 17:03:33 -0800 Received: from 63.193.17.133 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 01:03:32 GMT X-Originating-IP: [63.193.17.133] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, nkklrp@hotmail.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Demonstration that Schulze = Cloneproof SSD Date: Fri, 02 Feb 2001 01:03:32 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 01:03:33.0058 (UTC) FILETIME=[F6983A20:01C08CB3] X-Evolution: 000000d2-0010 I'm going to show that Cloneproof SSD & Schulze are just 2 wordings of the same method, 2 implementations that always give the same outcome. I'll be using the beatpath definition of the Schwartz set. The definition that I've been using, and with which I've defined SSD & Cloneproof SSD is the unbeaten set definition. It's a well-established & accepted fact in voting system discussion that those 2 definitions always define the same set. Though I'll be using that fact without proof in this letter, I'll demonstrate why it's so in an immediately subsequent letter. For now, I'll just state the beatpath definition: If there's a beatpath from A to B, but not from B to A, then B has an unreturned beatpath. An option is in the Schwartz set if & only if it doesn't have an unreturned beatpath. [end of definition] In this letter, "AB" means "The beatpath from A to B whose weakest defeat is the strongest". "AB>BA" means that AB's weakest defeat is stronger than that of BA. By "Schwartz set", I mean "current Schwartz set", the Schwartz set based only on undropped defeats. Why Schulze & Cloneproof SSD are the same: Suppose that option A is a Schulze winner. That means that, for all B, distinct from A, AB>BA, or AB = BA. By the beatpath definition of the Schwartz set, that means that A is in the Schwartz set. For any particular B: If AB or BA is going to be broken, by dropping one of its defeats, it will be BA that is broken before or simultaneous with AB, because Cloneproof SSD drops weaker defeats in the Schwartz set before stronger ones. Of course, when BA has been broken, all of the weaker beatpaths from B to A will have been broken also--before AB could be broken. That means that A can never be removed from the Schwartz set. Because A is always in the Schwartz set, that means that every member of any cycle containing A is also in the Schwartz set. That's because, in general, if one element of a cycle is in the Schwartz set, then every element of that cycle must also be in the Schwartz set. To show why that is: Say X is a cycle member that beats A. The Schwartz set is unbeaten from without, and so if A is in that set, so must X be. Say Y beats X. The same argument says that Y must also be in the Schwartz set. This argument can be repeated all the way around the cycle. Since any cycle containing A is in the Schwartz set, and since Cloneproof SSD always results in there being no cycles in the Schwartz set, then any cycle containing A is going to be broken. Every beatpath from A to B forms a cycle with every beatpath from B to A. None of those will remain when Cloneproof SSD's process is concluded. For every B distinct from A: Because AB's weakest defeat is stronger than or equal to BA, and because BA, by definition, has a stronger weakest defeat than any other beatpath from B to A, then, by Cloneproof SSD's rules, every Beatpath from B to A will be broken before AB is broken, or simultaneously with it. That means that, when the cycles containing A & B are broken, as they must be eventually, there will be no beatpaths from B to A, because Cloneproof SSD drops weakest defeats first. That's true for every B distinct from A, and so eventually A will have no beatpaths to it, since, as stated previously, Cloneproof SSD continues till there are no cycles in the Schwartz set. A pairwise defeat is a 1-step beatpath. The references to beatpaths in this demonstration say nothing that excludes 1-step beatpaths from those references' application. And so, eventually A will have no defeats. Now, suppose that A is not a Schulze winner. That means that, for at least one B, distinct from A, BA>AB. That means that AB will never be broken before BA is broken, or simultaneous with it. That means that one of the following must be true: Either neither AB nor BA ever gets broken, or AB is broken before BA. If neither ever gets broken, then A retains a beatpath to it. Obviously there can't be a beatpath to A unless A has a pairwise defeat, and so, because A always has a beatpath to it, the A always has a defeat. If AB gets broken before BA does, then, by the beatpath definition of the Schwartz set, A is removed from the Schwartz set. Since A has a beatpath to it, then A has a pairwise defeat. Since no defeat that isn't among the Schwartz set can be dropped, then A will always have that defeat. I've shown that if A is a Schulze winner, then A will have no defeats at the conclusion of Cloneproof SSD's count, and that if A is not a Schulze winner, then A will have a defeat at the conclusion of Cloneproof SSD's count. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 01:54:02 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9532 invoked from network); 2 Feb 2001 01:54:02 -0000 Received: from f89.law10.hotmail.com (HELO hotmail.com) (64.4.15.89) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 01:54:02 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 17:53:59 -0800 Received: from 63.193.17.130 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 01:53:59 GMT X-Originating-IP: [63.193.17.130] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, nkklrp@hotmail.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Demonstration of Schwartz definition equivalence Date: Fri, 02 Feb 2001 01:53:59 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 01:53:59.0646 (UTC) FILETIME=[0294E7E0:01C08CBB] X-Evolution: 000000d3-0010 I'm going to show that the beatpath definition of the Schwartz set defines the same set as that defined by the unbeaten set definition of the Schwartz set, the definition by which I've defined Cloneproof SSD. Suppose A has an unreturned beatpath. That means that, for some B distinct from A, there's a beatpath from B to A, but not from A to B. {A} isn't an unbeaten set, because having a beatpath to A means that A is beaten. The set of B & the options having beatpaths to B is an unbeaten set, because if anything outside that set beat a member of that set, then it would have a beatpath to B. But if it did, it wouldn't be outside of that set. Because A doesn't have a beatpath to B, then A isn't a member of that unbeaten set. I'll call that unbeaten set S. In the beatpath from B to A, say X beats A. Any unbeaten set containing A must contain B. Likewise Y which beats X, etc., all the way back to B. Any unbeaten set containing A must also contain B, and everything that has a beatpath to B, by the same argument. So, A isn't in S, but any beatpath containing A must contain S within it. That means that A can't be in an unbeaten set that doesn't contain a smaller unbeaten set. By the unbeaten set definition of the Schwartz set, A isn't in the Schwartz set. Suppose A doesn't have an unreturned beatpath. The set of A and everything that has a beatpath to A is an unbeaten set, by the same argument used above for set S. The name "S" will now apply to the set of A & everything that has a beatpath to A. Since A doesn't have an unreturned beatpath, then A has a beatpath to everything else in S. For any B in S, since A has a beatpath to B, then A must be in any unbeaten set that B is in, by an argument previously used above. A is in an unbeaten set, S. And S doesn't contain any element that's in an unbeaten set that A isn't in. The only way for A to not be in the Schwartz set would be for S to contain a smaller unbeaten set that A isn't in. If every smaller unbeaten set that it contains also contains A, then A is in the innermost unbeaten set. If it contains no smaller unbeaten set, then likewise A is in the innermost unbeaten set. I've shown that an option with an unreturned beatpath isn't in an innermost unbeaten set, and that an option with no unreturned beatpath is in an innermost unbeaten set. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 02:18:23 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 12800 invoked from network); 2 Feb 2001 02:18:23 -0000 Received: from f60.law10.hotmail.com (HELO hotmail.com) (64.4.15.60) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 02:18:23 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 18:18:20 -0800 Received: from 63.193.17.130 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 02:18:20 GMT X-Originating-IP: [63.193.17.130] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Date: Fri, 02 Feb 2001 02:18:20 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 02:18:20.0875 (UTC) FILETIME=[698AC1B0:01C08CBE] X-Evolution: 000000d4-0010 > She didn't like SD because of the cycles, which sounded very > counterintuitive when I mentioned them. I think that this means that you didn't have a very good definition of what a cycle was. Which implies that you didn't talk about how you could have more than one candidate in the innermost unbeaten set. Which implies that she didn't understand what you meant by "disregard the fact that the people have said they like someone else better". I reply: I told her that there can be a situation where A beats B, B beats C, and C beats A. She said "No...", as if to say "Oh come on!" So she didn't like cycles because the idea of a cycle is counterintuitive. For that reason she didn't like SD. You're right: I didn't talk about how there could be more than 1 candidate in the innermost unbeaten set. But there's no need to go into that when defining SSD or advocating it. That's a mechanical detail that isn't needed for those purposes. You're also right that I didn't explain how it could be that no one is unbeaten. Again, that seemed a mechanical detail that isn't needed in that introduction. After all, it was a definition & introduction, not a course on all that can happen and how it can happen. So I feel that it's perfectly honest to define & explain it like that. She understood & liked it because it wasn't necessary to tell her the things that would cause confusion and require lengthy explanation. That's what I like so much about SSD. I got the impression that a person would sign the enactment initiative petition for SSD based on that definition & explanation. Surely I didn't deceive her about anything by not going into mechanical details about how all can be beaten or how the innermost unbeaten set could contain more than 1 candidate. This is a partial reply. There are probably answers that I can & will send to the rest of your letter. Mike _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 05:03:46 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 31596 invoked from network); 2 Feb 2001 05:03:46 -0000 Received: from f96.law10.hotmail.com (HELO hotmail.com) (64.4.15.96) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 05:03:46 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 21:03:43 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 05:03:42 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org, nkklrp@hotmail.com Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: A brief few typos & omissions Date: Fri, 02 Feb 2001 05:03:42 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 05:03:43.0160 (UTC) FILETIME=[83AF4B80:01C08CD5] X-Evolution: 000000d5-0010 In my letter "Demonstration that Schulze = Cloneproof SSD", in the 4th paragraph from last, I should have added that if AB is in the Schwartz set, then BA is, by a previous argument that any element of a cycle being in the Schwartz set means that ever element of the cycle is in the Schwartz set. Adding that shows why if the defeats in BA are in the Schwartz set, qualifying for dropping, then that's true of the defeats in AB. I could have started that paragraph with a special case in which A is not initially in the Schwartz set. In that case, of course, it has a defeat that can't be dropped, since only defeats in the Schwartz set can be dropped. Then I could have said, as a 2nd case, that A is not in the initial Schwartz set. But it isn't necessary to do it that way. The demonstration makes sense without dividing it into those 2 cases. In the 2nd to last paragraph, I should have added, to the end of the 1st sentence, "...because every A to B beatpath other than AB is weaker than AB, by AB's definition, and therefore has been broken by the time that AB is broken. So at that time there's no beatpath from A to B, while BA still remains. So A is removed from the Schwartz set, by the beatpath definition of the Schwartz set." In my letter "Demonstration of Schwartz definition equivalence", in the 4th paragraph, beginning with the words "In the beatpath from B to A...", the "B" in the 2nd sentence should be replaced with "X". So it's: "Any unbeaten set containing A must contain X." In the 5th paragraph, first sentence, "...but any beatpath..." should be replaced with "...but any unbeaten set...". Additionally in that paragraph, when I said that any unbeaten set containing A must contain S within it, I should have added "...or be S." Of course, if it doesn't contain S within it as a proper subset, then it must be S. And that means that any unbeaten set that could contain A must be S, but we know that A is not in S. So in that case A can't be in any unbeaten set. If it wouldn't seem like I'm posting too much, I feel that tomorrow I should post the corrected versions of these 2 demonstrations, without the typos & omissions that I'm aware of. Mike Ossipoff _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 05:35:31 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 9739 invoked from network); 2 Feb 2001 05:35:31 -0000 Received: from f101.law10.hotmail.com (HELO hotmail.com) (64.4.15.101) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 05:35:31 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Feb 2001 21:35:28 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 05:35:28 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Re: Cloneproof SSD & Norm's misdefinition of it. Date: Fri, 02 Feb 2001 05:35:28 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 05:35:28.0905 (UTC) FILETIME=[F398E790:01C08CD9] X-Evolution: 000000d6-0010 > >The way I interpreted this was: > > > >1. Calculate the Schwartz set, S. > >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them > >all) > >3. Repeat (2), until there are no cycles among candidates in S. ^^^ > >Mike's intended method was: > > > >1. Calculate the Schwartz set, S. > >2. Drop the weakest defeat in S (if there is more than 1 equal, drop them > >all) > >3. Repeat (1), until there are no cycles among candidates in S. ^^^ On Thu, Feb 01, 2001 at 06:51:29AM -0000, MIKE OSSIPOFF wrote: > Excuse me, but what you say was my intention is identical with what > you say was your interpretation. Not exactly, though I think he should have said Alright, thanks for pointing that difference out; I hadn't noticed it. But Norm changed the meaning when he gave the Schwartz set a letter name S, because then "S" is going to mean some fixed set throughout the count. I didn't say it that way. I said "Drop the weakest defeat in the current Schwartz set." Now, in order to execute that instruction, we have to know what the Schwartz set is. To know that, we have to calculate it. With the word "current" in there, it would be difficult to explain Norm's belief that I meant the initial Schwartz set. 3. Repeat (1,2), until there are no cycles among candidates in S. > Do you have a problem with: "Eliminate the candidate who, among > the uneliminated candidates, has fewest votes. Repeat till a candidate > has a majority of the votes"? I think he had a problem with the question of "which schwartz set". Meaning that he had a problem with the question "The Schwartz set of what time?" Say you're carrying out those instructions. When you get to a repetition of "Drop the weakest defeat in the current Schwartz set", what does that mean? Current doesn't mean the Schwartz set of some other time. When you get to a repetition of the execution of that sentence, you drop the weakest defeat in the current Schwartz set. Current means as of right now. Of course I'd also defined it as the Schwartz set based only on undropped defeats. But, either way, when it isn't specified that Schwartz set means the Schwartz set of some particular other time, and you're about to execute that instruction that refers to the current Schwartz set, then you have to know what the Schwartz set consists of, and so you must calculate it to carry out that instruction. There are many other iterative definitions that are like that: I mentioned IRV last time, though I left out the transfer clause. SD: Drop the weakest undropped defeat that's in a cycle. Repeat till there's an undefeated candidate. Question: Exactly what is being repeated? Is it the dropping of defeats, or is it the looking-up of what defeats have been dropped, or is it the calculation of which undropped defeats are in cycles? Answer: The wording specifically says that it's the dropping of defeats that's being repeated. However, to carry out that instruction in the 1st sentence, we must know what defeats are undropped, and which of those are in cycles. That requires that we look up which defeats have not been dropped, and that we calculcate which of those are in cycles. There's no other interpretation. When we get to the time to execute that instuction in the 1st sentence, we have to act on information about what defeats are undropped, and which of those are in cycles. Question: Which set of undropped defeats (as of what time)? Answer: Since no time is specified, undropped defeats means defeats that are undropped now, whenever "now" is. Defeats that are in cycles means defeats that are in cycles now, whenever "now" is. When you come to the time to execute the 1st sentence, "now" is the time when you come to execute the 1st sentence. I've mentioned IRV & SD. I could do the same question & answer session with Nanson's iterative Borda elimination, or PC, etc. There are 2 ways to write an iterative method: One can actually write down every operation, in a pseudocode-like list of operations. Or one can write a briefer set of instructions that implies looking up or calculating certain things, by saying to act based on what those things are. In other words, some operations are unmistakeably implied in other instructions. If I encounter the super-spelled-out pseudo-code way, I say "Oh shit, this is going to be long, and it's necessary to go through this thing, and find out what is being done. And then, to explain it to others, it's necessary to write it more concisely." I've tried to write my definitions more concisely. To me that's much clearer than the pseudocode-like approach that spells out each operation, even when it's implied by other instructions. Now, maybe it could be argued that the actual official count rules should be in the pseudocode or pseudocode-like form, to avoid even the possibility of having to answer the kind of objections that Norm made. Fine. But I claim that the introduction, the definition for the purpose of actually telling people what the method is, in a way that will be quickest & easiest for them, should be written in the concise form that doesn't spell out every operation that is unmistakeably implied by other instructions. If I tell you to go to the store and bring back a quart of milk, I don't have to specify the instruction to take it off the shelf and pay the man for it. That's implied by my instruction to come back with it. My concise wordings are in keeping with the only practical way of giving instructions most of the time, and, since the un-spelled-out operations are undeniably implied by other instructions, there's not need to not be concise. I'm not the only person to use concise iteration instructions, and I've never before heard of a problem with it. Cloneproof SSD eliminates a "pairwise beat", which may result in the elimination of a candidate when the schwartz set is refigured. I seem to recall that you had a definition of cloneproof ssd where you said "current schwartz set", but the definition Norm included (quoted at the top of this message) doesn't even have that. I reply: That's right. How could "current Schwartz set" be misconstrued to mean "initial Schwartz set"? Mike Ossipoff In any event, if we go with cloneproof ssd, we would either need to make sure to provide a gloss which defines "current schwartz set" [as well as other terms] or the definition would have to be changed to explicitly spell out that the schwartz set is refigured based on a beats matrix where the votes in favor tally for the weakest beat have been zeroed out. We would also need make sure it's explicit what to do where the weakest beat has multiple instances. [I hesitate to call this a tie.] I reply: I agree with both of those statements. Mike Ossipoff -- Raul _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com From nkklrp@hotmail.com Fri Feb 2 11:06:54 2001 Return-Path: Delivered-To: npetry@accesscomm.ca Received: (qmail 14433 invoked from network); 2 Feb 2001 11:06:54 -0000 Received: from f40.law10.hotmail.com (HELO hotmail.com) (64.4.15.40) by qmail.accesscomm.ca with SMTP; 2 Feb 2001 11:06:54 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 2 Feb 2001 03:06:53 -0800 Received: from 204.120.48.3 by lw10fd.law10.hotmail.msn.com with HTTP; Fri, 02 Feb 2001 11:06:53 GMT X-Originating-IP: [204.120.48.3] Reply-To: nkklrp@hotmail.com From: "MIKE OSSIPOFF" To: moth@debian.org Cc: npetry@accesscomm.ca, stevegr@debian.org, robla@eskimo.com, bmbuck@14850.com, aj@azure.humbug.org.au Subject: Not claiming that my wording is best Date: Fri, 02 Feb 2001 11:06:53 -0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2001 11:06:53.0828 (UTC) FILETIME=[3FEF5C40:01C08D08] X-Evolution: 000000d7-0010 I'm not claiming that the Cloneproof SSD wording that I used should be the wording used by Debian. I just wanted to express disagreement with the claim that it's unclear. I'd just use the weaker term "less explicit".