[EM] Election Methods Code Repository Proposal
Greg Nisbet
gregory.nisbet at gmail.com
Mon Sep 12 10:59:53 PDT 2011
First off, I meant to say "Python and Ruby, respectively". I had
written that, but later changed the wording of the paragraph beneath
it, mangled the text I originally had written, and forgot to
proofread, my bad.
The reference implementation is the important part. I'm comfortable
enough with Python and with Perl to contribute, so I'd vote for those
for ease and familiarity. I think the adoption of a common coding
style / agreement on which preexisting libraries to use is also
important, perhaps more so than the choice of which language to use. I
guess that's another point in Python's favor. The language is
opinionated and consistent enough maintaining uniformity of code
written by different authors is that much easier.
On Mon, Sep 12, 2011 at 1:39 PM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
> 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
>>
>
>
More information about the Election-Methods
mailing list