timrcv, a reimplementation of rcv in rust

[tjhunter]

Hello, I want to bring to your attention the timrcv project (I am the developer). timrcv is a clean room reimplementation of rcv in the Rust programming language. It supports a subset of the features (for example, no UI, only one winner, no vote certificates), and also implements additional inputs (csv, microsoft forms in ranking and likert formats, google forms). It started from an interest in understanding the current voting algorithms and the desire to learn rust.

It currently passes half of the test suite of rcv. The rest may be implemented over the rest of the year depending on interest and the availability of real-life scenarios. The main priority for now will be to publish the rust library that powers the utility, and general bug fixing.

Thank you for starting rcv and for creating a standard collection of voting data. The specification is clear and I did not have to read the code to understand how the implementation works. Here are a couple of small points I found when trying to replicate the output of rcv:

• some of output json is not sorted (for example the tallyResult section). The test harness of timrcv sorts the json keys to ensure stability, it would be great to have that directly in rcv
• the output has sometimes "Undeclared Write-ins" : "0". This is ignored
• relying on the java random number for shuffling seems like a source of potential biases to me (see discussion in tickets as well). I am considering an alternate implementation based on cryptogragraphic hashes (using SHA-256 to hash the name of the candidate, padded with a seed and the round number, for example). Have you considered such solutions?

I am opening this ticket to discuss these points. Feel free to send me directly an email as well.

[rrojas350]

Greetings Tim! Sorry for the late reply on this but do you want to send me an email and we can go over some of these points? I can be reached at [email protected].

[tarheel]

Btw, lots of discussion about the random number topic in #170. We haven't prioritized it because there are currently no jurisdictions that rely on the software for any sort of random tie-breaking.