[EM] Election Methods Code Repository Proposal

[Jameson Quinn]

I'd also vote for python (which is not the same as ruby). Python also has
"fast" version cython, which for this kind of thing should not be too hard
to port to/from.

(There's also some similar "parallel" python environments, not so much
separate versions, but really to use them you need a ground-up rewrite, so
it's mostly irrelevant. Or you can sometimes write from the start to use
math packages like Sage, which generally have bigger primitives which can be
parralelized after the fact more easily... but probably that would only work
for a few voting methods.)

JQ

2011/9/12 Andy Jennings <elections at jenningsstory.com>

> On Sun, Sep 11, 2011 at 9:15 PM, Greg Nisbet <gregory.nisbet at gmail.com>wrote:
>
>> Anyway, IEVS is in C, RubyVote and PythonVote are obviously in Python,
>> and my old code is in Java. If the community could settle on a single
>> language for reference implementations (speed being less important
>> here than clarity and familiarity) of various voting methods and maybe
>> a quick language such as C, C++, D, or Java when additional speed is
>> required, and possibly an efficiently parallelizable language (e.g.
>> Erlang, Haskell) to allow for distributed computation and greater
>> scalability.
>>
>
> I definitely agree on the "reference implementation" part.  I vote for
> Python, but maybe someone should set up an approval-style poll.
>
> As for a "fast language implementation" and a "parallel language
> implementation", that's not a bad idea, but I don't know that we're ready to
> maintain three different code repositories, yet.
>
> ~ Andy
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20110912/a240517e/attachment-0004.htm>