Jita Park Speakers Corner

They might not. I do

This actually happened last year. Part of the reason why the CFC doesn't have more people on. If people rank their actual preference instead of sticking with a bloc vote (or if bloc candidates can appeal to voters outside their bloc), then they'll succeed more. Of course, then they'll actually *represent* more...

Still independent, if not more so ;-) Actually, I spent a good bit of time in highsec after making the corp hop...something about a bunch of people needing mercs to do things to pocos.

Well, I am all for balance.
And if you go far back enough in my posting history (have to go WAY back), I was not nearly so extremist.
That shrillness is a direct result of the constant erosion that has occurred to the high sec casual gameplay over the past few years. CCP does not listen to reasoned, modulated responses (not that CCP listens to anything from any high sec casual player, especially me.)

From the 90% nerf in datacore research, to the introduction of the Catalyst and Talos as ganking ships, to the new ESS build, to the diversion of huge PoCo income to the goons, there has been an inexorable move to lowering high sec income potential while increasing null sec cartel income.

I know what endgame of the cartels' campaign against high sec look like. The ultimate question is how much CCP agrees with the cartels' vision of the game.

If we go far enough back in your posting history (winding up on the old forums) we can see you complaining about how CCP is nerfing wormholes and nullsec to drive people to highsec. And RMT, of course. You've never not tinfoiled about that.

dinsdale has never actually explained the reasoning behind his belief that CCP is in cahoots with imaginary RMT cartels that sell isk for bitcoins or something, especially the crucial aspect of why CCP would be in cahoots with those imaginary RMT cartels

he also hasn't shown a shred of evidence for his RMT tinfoil because he doesn't have any beyond "well nullsec alliances work hard to secure income streams so it must be for RMT and not because things can happen in 0.0 that can turn out quite expensive"

I finally got round to analyzing the voting code and actually found a bug, My first though was to contact CCP privately about it, but while writing the message I realized it was not exactly feasibly exploitable and it was very easy for concerned voters to foil any exploitation attempt.

The problem is that you can't get eliminated if you have no votes. This is due to the vote counter accumulator not being initialized with 0. This can result in at least people being eliminated in the wrong order and potentially wrong people getting elected, but only if nobody votes for one of the candidates with their top votes so that when it comes to potential elimination situation someone else will get eliminated and the exploiting candidate will stay in the race. While it sounds bad it's really hard to pull off and getting together a group of people that will make sure everyone gets at least one #1 vote the exploitation attempt will instead lead to early elimination.

I also confirmed the only undesirable feature I suspected the voting code to have, so feel free to quote me on it Dinsdale. The decision to eliminate someone is done based on the number of votes which at first seems like a no brainer. The general problem with this is that candidate needs certain numbers of top votes to hang on in the race if elimination happens in addition of broad support that would get her elected later in the process. I acknowledge that only general fix would takes us to the voting system proposed last year that has unfeasible computation time. So there is no way of totally fixing this weakness, so it is something the candidates should make themselves aware of.

There is a tweak that I'm playing with to mitigate this problem a little bit. If the total number of ballots someone appears on is low enough they have very slim or no chance of being elected and could be eliminated first regardless of the number of votes they have. It is possible that someone with broad support in the lower spots would be saved from elimination if the people who have no hope of being elected are removed. The hard part is where to draw the line. It can't be the value of the quota at a specific point of the process because when partly filled ballots are exhausted the quota will be reduced accordingly. Maybe it's possible to calculate how low the quota can drop and use that. But then again maybe that number is so low that it would axe nobody anyway.

I only stumbled upon it while building pathological inputs to demonstrate the 'undesirable feature' mentioned in the post. I'll post the ballot exact ballot data I used tomorrow, but here are the main points. I had a candidate with no #1 votes, but plenty #2's to get elected, one that had exactly the quota to get elected straight away, and 2 others whose votes were crossed so that one of them it was a tie on the #1 votes and neither of them had total votes enough to fill the quota. 2 seats to be filled.

I had a big WTF moment at first because the guy I though was going to be screwed by the system got elected. When I started fiddling with the vote counts I noticed he was never up for elimination.

I've created my share of trivially detectable by manual inspection bugs so it's hard for me to blame Veritas for this. Mainly because people tend to vote themselves, any real life test data is unlikely to have this situation in it.

the fix btw is adding something like

for x in remainingCandidates:
--ident-- accumulator[x] = 0.

after the accumulator is created.

Actually a candidate could have no first choice votes and still be viable and even elected.

In the most recent CSM election Kesper North had the majority of second votes from mynnna supporters (and vica versa). If swapped the positions of the two on all ballots with Kesper in first place then Kesper would still get elected.

I'm pretty sure that even if you eliminated all ballots with Kesper as the first choice he would still get elected. Of course this is kind of the point of STV as it can make use of a ballot's second (and sometimes later) choice in the case that the first choice has more than enough support.

Personally I'd like to see an STV implementation like Meeks or Warren which have better ways of dealing with the surplus votes than the more simple approach that the Wright system uses.

I agree that fix is trivial, but that is not the right one. Let's assume we have a block that has the votes to get 2 people elected and they all vote with identical ballots. With your fix only the one on the #1 spot would survive your fix and the block would get just one seat with the extra votes going to somebody that had at least 1 #1. In the real world it wouldn't make any difference because just one #1 vote would make the candidate survive the fix and as stated people tend to vote for themselves.

Conceptually the right thing to do is count the zero votes correctly in the vote counting step and if elimination comes it will eliminate the zeros first. In the example case above the blocks #1 guy would get elected and extra votes transferred to he #2 guy before we even have to consider any elimination so he would have the votes to survive the elimination.




I haven't checked but it's pretty safe to assume this didn't have any effect on the last years results because it's likely that everybody had at least 1 #1 vote.

It is also very likely that CCP will make every effort to close this loop hole by making a trivial change to the voting code. It's unfortunately difficult to fix things you didn't know were broken. As I said the flaw would not manifest with anything resembling a real life dataset for CSM election.

And finally, I this will be difficult to swallow, but just take my word for it: The over / under didn't move an inch.

Fixing the flaw is more likely to effect someone who takes the CSM vote code and runs an election with considerably smaller number of votes and seats than CSM elections, but that is big enough reason to fix it.