Implement PJR checker #8160
Implement PJR checker #8160
Conversation
coriolinus
added
A3-in_progress
Also, note that this will probably be a configuration in any case. So we don't need to decide on this now and here. |
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Note that this currently fails. I hope that this can be rectified by calculating the threshold instead of choosing some arbitrary number.
primitives/npos-elections/src/pjr.rs
Outdated
| /// `Max {score(c)} < t` where c is every unelected candidate, then this solution is t-PJR. However, | ||
| /// this test is incomplete: while every solution which passes this test satisfies t-PJR, not every | ||
| /// solution which is t-PJR passes this test. We therefore look to a more accurate test. |
There was a problem hiding this comment.
| /// `Max {score(c)} < t` where c is every unelected candidate, then this solution is t-PJR. However, | |
| /// this test is incomplete: while every solution which passes this test satisfies t-PJR, not every | |
| /// solution which is t-PJR passes this test. We therefore look to a more accurate test. | |
| /// `Max {score(c)} < t` where c is every unelected candidate, then this solution is t-PJR. |
I think this whole sentence is misleading and either need to be reworked or removed. I know that you are trying to address the accuracy issues. But you are phrasing it in a way as if somehow, sometimes, a PJR solution is suddenly no longer PJR. A better assumption is: If a solution S is PJR and is no longer PJR due to accuracy issues, it is simply because it is no longer S but rather S', a variant thereof.
There was a problem hiding this comment.
So, that was in response to #8160 (comment). I think the actual intent is more like, "There exist solutions which do not pass this test but are nevertheless t-PJR."
I'll give this some thought and try to clarify.
There was a problem hiding this comment.
What do you think of the phrasing introduced in eb94375?
There was a problem hiding this comment.
Better, but I think it is important to clarify why: accuracy errors.
There was a problem hiding this comment.
No, I think it's possible for solutions to fail (in edge cases) for reasons that don't derive from accuracy errors. I'm basing that on this text:
The test implies the condition, but not every solution that satifies the condition passes the test.
This isn't ideal; more realistic numbers would be about twice these. However, either case generation or voting has nonlinear execution time, and doubling these values brings iteration time from ~20s to ~180s. Fuzzing 6x as fast should make up for fuzzing cases half the size.
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Kian Paimani <5588131+kianenigma@users.noreply.github.com>
Co-authored-by: Shawn Tabrizi <shawntabrizi@gmail.com>
|
bot merge |
|
Waiting for commit status. |
ghost
merged commit 
Continuation of #7191. Adds a function which, given the complete set of voting data and a proposed solution, can determine whether or not that solution satisfies t-PJR for some selected t.
determine an appropriate "standard" value for t which we can use at least in the testsdevelop an intuition for what t means, to aid in test scenario construction