Apps: not equal numbers on polkadot-js and polkassembly

[illlefr4u]

The numbers showing how much the voter needs to lose to change the decision, and how much the voters need to gain against to change the decision, differ in comparison with the calculations on the polkassembly (https://kusama.polkassembly.io/referendum/44).

[jacogr]

Ok, not actually "wrong" - different.

So the issue here is the application of the actual conviction and the effect thereof on the result. Both take a different default, The actual only correct answer here is a full calculator, i.e.

• if I vote with 0.1x conviction, what do I need
• if I vote with 1x conviction, what do I need
  ...
• if I vote with 6x conviction, what do I need

The aim here is certainly _not_ to match up with whatever other parties do in their calcs, but rather do make it visible on which steps to do next. UX-wise, not there yet with the info here :(

[illlefr4u]

calculation/conversation at polkassembly repository: https://github.com/paritytech/polkassembly/pull/595

[jacogr]

Ok, so checked all these against Bruno's spreadsheets, and it all matches. (At 1x) It won't make anybody happy, since it is now even higher at 1x than the screenshot numbers you posted above. (

(Which seems to work on a different assumption - the assumption here is how much can we subtract, while still passing - not with only negative, how much positive do we need. Same with going from failing to passing, how much to add from base)

[jacogr]

TL;DR _Can_ get to 140k (as posted by you), but sadly that number doe not show a movement from the current base downwards, so for the purposes here, is incorrect.

Rather what the UI shows (or rather will, shortly) is around 166k - while is the value to which the current voters can reduce to, while still passing. (It takes the reality of the current convictions as applied into account, instead of working everybody at 1x, which is how the 140k number is deduced)

[illlefr4u]

TL;DR Can get to 140k (as posted by you), but sadly that number doe not show a movement from the current base downwards, so for the purposes here, is incorrect.

This is why I removed the “correct” numbers from the initial message, as I began to understand how the system works exactly, and it’s not obvious to me how to calculate the real threshold without any assumptions about new votes

[jacogr]

Your points have been very valid though - in the linked PR, I have now included a hover that shows the calculation assumptions, which are now always 1x. Nobody can read my mind...

However, as indicated, the numbers are def. higher than elsewhere (By design, since it takes existing of the same type into account)

[jacogr]

Closing this, from the apps UI perspective it is as close to correct (without a full-blown scenario calculator) it will get based on what we want to show, i.e. what is actionable to get to a different outcome.

We do need https://github.com/polkadot-js/apps/issues/2536 soon-ish though, it was on the list somewhere.

[jacogr]

Re-opening. ;) just want to think through the downward adjustments. So upwards it’s makes sense to assume 1x conviction.

Downwards, maybe, just maybe the better (default) approach is to assume voters just change their conviction downwards.

So for the 44 -

• nays get new voters, all 1x (as-is, new vote, higher turnout)
• ayes keep the voters, but they adjust from eg. 6x to 5x (Leser vote, same turnout)

Worth a think though. (As defaults, probably need a “extend to a calc” issue)

[illlefr4u]

I had an idea that it might be useful taking previous referenda into account when making assumptions, dividing those that passed and those that didn't. E.g. if we are on a pass side now, then we need to look at all those referenda that didn't pass and count their avg. multiplier.

But then I rejected this idea, since a) voting can be of different importance; b) the average multiplier for different stakes should vary significantly (I hypothesize that medium and large stakes often use large multipliers, since they are more conscious of their decisions, but it is necessary to perform the calculations to understand it better); c) more importantly, as i understand, this information is not stored onchain, so all of the above has little meaning :)

Therefore, it seems that the model should be simple, without looking at previous votes. But it is necessary to investigate, depending on the voting status, the “losing” party more often receives new participants, or changes its multiplier (it’s not obvious to me. Those who voted probably follow the voting more, because they are interested, but they can less monitor the voting , since they have already taken the necessary action).

[jacogr]

Yes, it cannot read minds. So there are a couple of approaches -

1. only adjust multipliers, aka no effect on turnout (this is the initial approach followed, so what is showed was the adjustments that can be made via convictions)
2. always assume new votes or old votes removed (this is what it does atm, so it assumes 1x additions and removals)
3. a combination, one side with new votes, the other side only adjusting conviction
4. all user-specified

So as it stands -

1. don' think the initial "conviction-only" adjustment was bad, just not properly communicated - it certainly has value for me on 44 atm, i.e. I can see exactly where I can adjust my aye conviction to without making if fail, likewise the nay voter has the sam info at hand
2. the current approach is nod bad (with the 1x), however it gives good info on nay, but not really on aye - so on nay can see the info for more votes, on aye, tweaks will probably not be vote removals
3. Based on my description in 2, this is what I'm thinking atm - or just a move back to 1 (this time with the proper info available)
4. ... will get there (but it certainly is a bit "nice-to-have", want a nice no-config actionable display right off the bat)

[jacogr]

Ok, closing it now, tweaks welcome.

• calcs moved to apps UI for easy customization
• changed to reflect convictions changes only for all, i.e. no effect on turnout (As per original, now with proper info box that says exactly that)

All this is tweak-able, https://github.com/polkadot-js/apps/blob/master/packages/page-democracy/src/util.ts#L38

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.