# RE: What is Data Model FOR?

From: Mark Winegar <mwinegar_at_mtmc_dot_edu>
Date: Thu Apr 29 2004 - 15:01:23 CDT

Any number of votes may be cast up to the number of offices (0 - n).

-----Original Message-----
From: Daniel Lifschitz [mailto:danlif_at_ucsc_dot_edu]
Sent: Thursday, April 29, 2004 1:12 PM
To: voting-project@lists.sonic.net
Subject: RE: What is Data Model FOR?

Sorry I'm not sure I understand =). What do you mean by partial
permutations?

Sincerely,
Daniel Lifschitz

-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[mailto:owner-voting-project@afterburner.sonic.net] On Behalf Of Arthur
Keller
Sent: Thursday, April 29, 2004 10:48 AM
To: voting-project@lists.sonic.net
Subject: RE: [voting-project] What is Data Model FOR?

Dear Daniel, thanks for your message. n! is good enough closed form
for me. But n! only gives you the full permutations of n!
candidates, not the partial permutations of up to n candidates. Do
you have a formula for that? Do you want to derive it?

Best regards,
Arthur

At 9:58 AM -0700 4/29/04, Daniel Lifschitz wrote:
>Sterling's Formula approximates n! I believe:
>
>n! = ( Root(2*pi*n) * (n/e)^n * (1 + theta(1/n))) Where theta 1/n is
any
>function in the set of functions theta(1/n).
>
>I just had a CS101 test on this =)
>
>Sincerely,
>Daniel Lifschitz
>
>
>
>
>-----Original Message-----
>From: owner-voting-project@afterburner.sonic.net
>[mailto:owner-voting-project@afterburner.sonic.net] On Behalf Of Arthur

>Keller
>Sent: Thursday, April 29, 2004 9:26 AM
>To: voting-project@lists.sonic.net
>Subject: RE: [voting-project] What is Data Model FOR?
>
>
>Since ranked preference voting says: A, B, C is different than B, A, C,

>there are more than 6 possible vote combinations for 3 candidates.
>(ABC, ACB, BAC, BCA, CAB, CBA are the full ones; also A, B, C, AB, BA,
>AC, CA, BC, CB, and no choices selected. Wow, that's 16 choices. Does
>someone have a formula in closed form for the number of possible
>rankings for n candidates? For the full ones, its the number of
>permutations of n candidates, or n! (n factorial).)
>
>You could list all the combinations and keep a count of how many times
>each combination was a voter's selection. Or you could incrementally
>build the list of combinations as they were encountered in the
>canvassing, while maintaining the count of repetitions.
>
>Once the canvassing is completed, you can perform the appropriate
>calculations. As long as you keep the raw counts of combinations, you
>can do the calculation as often as you like. It's probably a good idea

>to publish the raw counts of combinations so others can check your
>final vote assignment algorithm or even do research to develop new
>ones.
>
>Best regards,
>Arthur
>
>At 10:36 AM -0500 4/29/04, Mark Winegar wrote:
>>Doug,
>>
>>You may be able to implement the canvassing of ranked preference votes

>>as a simple array of contests. This should simplify the required logic

>>of the canvassing process.
>>
>>Mark Winegar
>>
>>-----Original Message-----
>>From: Douglas W. Jones [mailto:jones@cs.uiowa.edu]
>>Sent: Thursday, April 29, 2004 10:27 AM
>>To: voting-project@lists.sonic.net
>>Subject: Re: [voting-project] What is Data Model FOR?
>>
>>
>>
>>On Apr 29, 2004, at 12:48 AM, David Mertz wrote:
>>
>>> dr-jekyll@att.net wrote:
>>> |Does "vote aggregation" mean vote totals? The Data Model I
>submitted
>>
>>> |does have a place for accumulating vote totals.
>>>
>>> Aggregation is likely to involve move than a simple counter.
Maybe
>>> the counter suffices for a first pass, on some kinds of races.
But
>>> consider, for example either N of M or ranked-preference contests.
>>> The tallying of rank orders involves more than just counting the
>>> votes; for example, in IRV, it would go through stages with
>>> reassignments of votes and recounts.
>>
>>I should note that the canvassing rules I proposed in my previous post

>>don't apply directly to ranked preference votes, but there are
>>generalizations that do apply. Designing canvassing procedures that
>>allow for self-audit throughout the process is most difficult for IRV
>or
>>STV systems. It is easier for weighted preference systems.
>>
>> Doug Jones
>> jones@cs.uiowa.edu
>
>
>--
>-----------------------------------------------------------------------
-
>-------
>Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA 94303-4507 tel

>+1(650)424-0202, fax +1(650)424-0424

```--
------------------------------------------------------------------------
-------
Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507 tel
+1(650)424-0202, fax +1(650)424-0424
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
```
Received on Fri Apr 30 23:17:24 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT