1. Detect the power of 10 we need (should we set a max, in case we get 0.333333…?)
2. Multiply all values by that power of ten, to get integers
3. Proceed as usual
4. Perhaps pipe the multiplier to the charts so they can divide before rendering

When there are too many proposals to expect judges to express a judgment on all (or even most) of them, normalizing the amount of judgments per proposal makes sense.

It would mean for example using percentages instead of the actual amounts.

Since we don't want to risk floating-point errors, the core of the algorithm only accepts integers. We can normalize to the least common multiple (LCM), but that requires shenanigans with math/big, since those numbers can become huge very fast (when unlucky, but about 50% of my job is to care for unlucky people).

I'm still exploring an API that would allow us to keep the core algo math/big free (hence keeping performance and simplicity).

Meanwhile, we're working on accepting floating-point values in the CSV, by detecting with how many powers of 10 we need to multiply them to use them as integers without losing precision.

Override the guessed amount of judges with a provided value.

mj example.csv --default majority --judges 23

That value MUST be higher than, or equal to the maximum amount of judgments a proposal received.

This gnuplot script example could be used in a new exporter in order to display merit profile with gnuplot. It includes the dataset provided in readme.

Usage:

gnuplot ./test.plot

Or:

cat ./test.plot | gnuplot

Result:

Reinforce resilience with more extensive testing.

• https://github.com/minimaxir/big-list-of-naughty-strings
• https://github.com/robotframework/SeleniumLibrary/blob/master/atest/resources/testlibs/blns.json

Support a CSV with the (anonymized) individual ballots as input:

    Pizza,  Pasta, Chips
excellent,   good,  poor
very good, reject,  poor
…

Grade detection may be complex (or impossible in some cases). We can try our best with preset gradings (:lion: :warning: ), but we'll need a --grades flag to let users set their grades.

There's also the possibility of using the first line of the CSV as grading, like so:

reject, poor, good, very good, excellent
    Pizza,  Pasta, Chips
excellent,   good,  poor
very good, reject,  poor
…

This would start a big development arc, since there will be many possible plots from such detailed data.

We also need to detect which form of the CSV is used as input, and that's not going to be pretty.

… somehow.

Of note

• Any grade should be able to have default judgments.
• A single merit profile may have multiple grades with default judgments (eventually, when we let judges choose their default judgment strategy)
• Heck, we'll probably need to handle delegated judgments as well

mj --format svg --chart merit > merit.svg

I'm not going to take this on, since we already have gnuplot and my plate is full with detailed judgments as input and normalization.

Make sure to ping @roipoussiere about this, since he gave the subject a lot of thought already.