Elo Calculation for (Team) FFA currently wrong?

With a team elo system (current one or my new ones) you can calculate winning probabilities for 2 teams. But in a game with N teams (also if every team has only 1 player), what is the winning probability for any team if you only know the winning probabilities for all pairs of teams? I didn't have a solution to this problem for a long time, but now I do.

If I understand SpringBattle.cs correctly, the current system treats (team) FFA as a 2 teams game where the winning team is against a team consisting of all other teams, which wouldn't be correct.[Spoiler]
For calculating team FFA win probabilities I have a simple normed average calculation and a complicated expectation value calculation. Surprisingly they result in the same:
We want to calculate the probability that team number 0 wins. A team elo system gives us a (N-1)-dimensional probability vector p, where p_k is the probability that team 0 wins vs team k. I will use § instead of * for multiplication, because star is bugged. Then the probability that team 0 wins the whole game is simply 2§||p||_1 /(N§(N-1)), where ||.||_1 is the 1-norm of a vector (sum of all components).
[Spoiler]
I have proven that giving every team an elo change proportional to the probability that the above formula suggests for the opposite of the real game outcome fullfills all conditions (sum over probabilities is 1; expectation value of elo change is 0 for each team; sum of all elo changes is 0 in any case so that the avg elo remains 1500).

Yes, !predict calculates this indeed. Maybe SpringBattle.cs calculates something else.

Is it irony that you missed the point? !predict is also important (to fix). I don't know how !predict is correlated to SpringBattle.cs, though.

Thx Sprung.

[Spoiler]we can describe the above result for the probability that team k wins the game as simply ||P_k||_1 / ||P||_1, where P_k is the k-th column of P and ||.||_1 the sum of all components, because ||P||_1=N*(N-1)/2. (The column P_k is the vector p in my first post.)

[Spoiler]
I hope this solution will be implemented. The current implementation seems to be incorrect. It may fulfill some of the conditions, but current FFA teams' expectation value of elo change is probably far from zero and it would be nice to see reasonable !predicitons. Every team would have to be treated individually in the code. Maybe I can help with that.

Even though it may sound impossible, I will probably soon release a further generalization of the elo system that allows for giving every team in any team FFA (including normal teams and 1v1) a real winning probability of 1/N no matter how unbalanced the teams seem to be.

quote: allows for giving every team in any team FFA (including normal teams and 1v1) a real winning probability of 1/N no matter how unbalanced the teams seem to be

I think I misunderstood. How will you give someone a real 1/2 win chance in a 1v1 against an arbitrary opponent? You can't just take Godde and some lobster and arrive at 1/2 win chance.

Indeed I had a promising idea to proove P=NP. But as it didn't work, I'm in doubt about P=NP.

I already have a plan how to change SpringBattle.cs in order to account for FFA. Instead of using "losers" and "winners" for the loser and winner team, using team[teamnumber], where team[0] is the winner team, would be easiest for the matrix calculation. The only thing I don't know is how to replace the following lines to get teamnumber and team[teamnumber]:

var losers = SpringBattlePlayers.Where(x => !x.IsSpectator && !x.IsInVictoryTeam).Select(x => new { Player = x, x.Account }).ToList();
var winners = SpringBattlePlayers.Where(x => !x.IsSpectator && x.IsInVictoryTeam).Select(x => new { Player = x, x.Account }).ToList();

Probably I could do the rest of the code. The variables winnerW, loserW, winnnerInvW, loserInvW, winnerElo and loserElo would have to be generalized analogously. In order to represent the matrix P in the code I would use the NxN matrix P' but with P_(k,k)=0 instead of P'_(k,k)=1/2. Additionally I would use the relation P_(k,l)=1-P_(l,k) to make the code more efficient. (Some months ago I already noticed that the current code doesn't use this equivalence.)