[top-politics] Re: Content added to Wiki

Magnus — 2006-11-27 16:14:23+0100

-No, I explanied wrongly first time. The aim is to speed up in case of a majority switch since otherwise, the accumulated support would have to decrease a time from the initial side until it could start build up on the new side. With the zeroing, this is shortened a bit since only built up on the new side has to be made before the acc. support reaces +1 or -1. The total time will be enough long anyway since we have had a switch in majority and the first side build up is “waisted” time. No other aims.

—~—~————-~—~——~——————~———-~—~——~ You received this message because you are subscribed to the Google Groups “top-politics” group. To post to this group, send email to top-politics@googlegroups.com To unsubscribe from this group, send email to top-politics-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/top-politics?hl=en -~—————~——~——~——~———~——~———~—~—-

[top-politics] Re: Content added to Wiki

echarp — 2006-11-27 15:52:53+0100

> But what would be the name for d? > Participation constant?

The point is, not to have a constant :)

Besides, it is no such thing, because it can be changed.

It could be called a “ratification threshold” (buffer does seem strange). The one above which proposals are passed. When you explain it you would then just describe the calculation, and: “this goes on until a democratically chosen ratification threshold is reached” :)

Read more… / Lire plus…

> > One consequence is that all proposals will be evolving at each iteration > > unless their (yes-no)=0. > > Does it have consequences? > > A very small risk indeed. But in those cases, I’m sure that the > originatior of the proposal starts to build more opinion around his > proposal in order to make it advance, jsut as he would do if there are > too few voting making the progress very slow. > > > > In regards to close calls without a clear majority, wouldn’t it > > > actually make sense for these to drag on until a proposal is > > > satisfactory enough for a larger support to gather and tip the balance? > > > > Agreed. > > And it would remove one “special case” and thus make it simpler to > > implement :) > > See my answer above, we should have the resetting as an option, > possible to use since there are many cases, today at least, which are > very near even. > It is possible to tell without more practical experiense if the option > is needed or not, I would say. > And is it really a big deal to implement?

Any “special case” or “option” is a big deal. Because it not only has to be implemented, but also to be tested and supported. The inevitable problems, bugs and evolutions will have to go around one more bump to be properly corrected or implemented.

Every “special case” in a project, is one more rule to remember. The less the better, for everybody, even the users.

echarp – http://leparlement.org

[top-politics] Re: Content added to Wiki

Serge — 2006-11-27 13:27:05+0100

For d, I guess one could call it ratification buffer. Not very inspired now, but surely we can come up with a self-explanatory name.

In regards to the zeroing, Let me get this straight. The point of zeroing the accumulated support each time the majority changes, especially when the majority changes often, is to ensure the deliberation takes longer and avoids the risk of a proposal passing without real support. What are the other aims, if any, of the zeroing step?

[top-politics] Re: Content added to Wiki

Magnus — 2006-11-27 10:25:39+0100

>One consequence is that all proposals will be evolving at each iteration unless their (yes-no)=0.
Does it have consequences?

-A very small risk indeed. But in those cases, I’m sure that the originatior of the proposal starts to build more opinion around his proposal in order to make it advance, jsut as he would do if there are too few voting making the progress very slow.

>> In regards to close calls without a clear majority, wouldn’t it > actually make sense for these to drag on until a proposal is > satisfactory enough for a larger support to gather and tip the balance?

Read more… / Lire plus…

>Agreed. And it would remove one “special case” and thus make it simpler to implement :)

-See my answer above, we should have the resetting as an option, possible to use since there are many cases, today at least, which are very near even.
It is possible to tell without more practical experiense if the option is needed or not, I would say.
And is it really a big deal to implement?

>I’d like to offer you a drink, and speak about all that!

-Programmers ready for the next step of democacy will be offered many drinks by AD and the rest of mankind!! ;-)

[top-politics] Re: Content added to Wiki

Magnus — 2006-11-27 09:34:42+0100

>About recalculations, couldn’t a duplication step be included ahead of the counting? This would ensure a snapshot of the voting position remains available for reference should a malfunction / delay occur.

-Good idea!

>About formulas and making d and the process of accumulation over time more intellegible, if I get this right, the basic logic is that for proposals with a high proportion of the population voting and agreeing,

a proposal can be passed fairly quickly. Equally, if not many people are voting or agreeing, then a proposal will drag on.

Read more… / Lire plus…

-Correct.

>Explaining this in layman’s terms therefore seems pretty straightforward. You could define d=7 as corresponding to a period of one week for ratification of a vote if 100% of the population votes in favour. Accordingly, as the proportion of participation / support drops, the time for ratification increases in proportion, which ensures

no loonie proposal can be passed discreetly and quickly without proper participation and scrutiny. That would probably make it more understandable than calling it a democratic constant.

-But what would be the name for d? Participation constant?

>In regards to close calls without a clear majority, wouldn’t it actually make sense for these to drag on until a proposal is satisfactory enough for a larger support to gather and tip the balance?

-This could be discussed. There is this aspect of it, but nver the less, in real life many things seems to be quite even.
Maybe the zeroing of the accumulated support could be an option used if the proposals seems to never end in an organization.

[top-politics] Re: Content added to Wiki

echarp — 2006-11-25 12:08:49+0100

On Fri, Nov 24, 2006 at 03:35:50PM -0000, Serge wrote:

> > Hey, > > About recalculations, couldn’t a duplication step be included ahead of > the counting? This would ensure a snapshot of the voting position > remains available for reference should a malfunction / delay occur.

There should probably be something like that, to make sure calculations are non destructive and can be traced back in time.

> About formulas and making d and the process of accumulation over time > more intellegible, if I get this right, the basic logic is that for > proposals with a high proportion of the population voting and agreeing, > a proposal can be passed fairly quickly. Equally, if not many people > are voting or agreeing, then a proposal will drag on. > > Explaining this in layman’s terms therefore seems pretty > straightforward. You could define d=7 as corresponding to a period of > one week for ratification of a vote if 100% of the population votes in > favour. Accordingly, as the proportion of participation / support > drops, the time for ratification increases in proportion, which ensures > no loonie proposal can be passed discreetly and quickly without proper > participation and scrutiny. That would probably make it more > understandable than calling it a democratic constant.

Read more… / Lire plus…

This is exactly my point, to transform a constant in something more comprehensible.

It also highlights the one remaining important item: “t”, the number of iterations. Those iterations being over time, it in effects introduces an interesting time factor.

One consequence is that all proposals will be evolving at each iteration unless their (yes-no)=0.

Does it have consequences?

> > The argument for it is that the issue is well known by the voters and > > majority switches might happen many times in even issues, 49/51 to > > 51/49 etc. This might lead to very long voting times thus impractical. > > In regards to close calls without a clear majority, wouldn’t it > actually make sense for these to drag on until a proposal is > satisfactory enough for a larger support to gather and tip the balance?

Agreed.

And it would remove one “special case” and thus make it simpler to implement :)

> Regards,

Are you in paris or going through it in the near future? I’d like to offer you a drink, and speak about all that!

echarp – http://leparlement.org

[top-politics] Re: Content added to Wiki

Serge — 2006-11-24 16:35:50+0100

Hey,

About recalculations, couldn’t a duplication step be included ahead of the counting? This would ensure a snapshot of the voting position remains available for reference should a malfunction / delay occur.

About formulas and making d and the process of accumulation over time more intellegible, if I get this right, the basic logic is that for proposals with a high proportion of the population voting and agreeing, a proposal can be passed fairly quickly. Equally, if not many people are voting or agreeing, then a proposal will drag on.

Explaining this in layman’s terms therefore seems pretty straightforward. You could define d=7 as corresponding to a period of one week for ratification of a vote if 100% of the population votes in favour. Accordingly, as the proportion of participation / support drops, the time for ratification increases in proportion, which ensures no loonie proposal can be passed discreetly and quickly without proper participation and scrutiny. That would probably make it more understandable than calling it a democratic constant.

Read more… / Lire plus…

> The argument for it is that the issue is well known by the voters and > majority switches might happen many times in even issues, 49/51 to > 51/49 etc. This might lead to very long voting times thus impractical.

In regards to close calls without a clear majority, wouldn’t it actually make sense for these to drag on until a proposal is satisfactory enough for a larger support to gather and tip the balance?

Regards,

Serge

[top-politics] Re: Content added to Wiki

Magnus — 2006-11-24 13:20:23+0100

>> Why? It is only to use the number of yes/no votes casted on the > original time for summation and redo the division.

>Participants can vote and revote at any time, the last one being the valid one. If you relaunch the calculation 10 hours later, you will have
to find out the last votes of all participants at the time of the original calculation.

This is not simple SQL, it is not a simple recalculation. And it has to be done for all proposals.

-Well, if the system goes down so no calculation can be made, the possibility to vote should also go down?
But if not, it is only reuse the day before value and send out a message to re-vote.
But you could also wait to next day and use the latest ballots from all if they are existent. (If so, there could be a rule that the vote is proplonged with the time the sytem has been down.)
The same could happen to any internet based voting system, that it breaks down.

Read more… / Lire plus…

>> Well, if 60% have voted yes, the formulas A* = M* + A and A = A* > /(dxZ) could be expressed: > A=(M* + A(index:t-1=former A)) / dxZ

-Sorry for my writing about 60%, it should only be: The formulas A* = M* + A and A = A* /(dxZ) could be expressed: A=(M* + A(index:t-1=former A)) / dxZ

>A proposal would be accepted if: A=(M* + A(index:t-1=former A)) / Z and A > d ?
d a fraction of the total population

Or, without division or multiplication:
A=M* + A(index:t-1=former A) and A > d’ ?
d’ a margin or threshold

-Maybe…I’m not a matemathician…what is your angle?

>The accumulation of a difference over time did leave me puzzled. And I’m not sure it is that easy to explain to the layman.

-The only complex part as I see it, is how thing are affected in the case thats normal; not all are voting yes, but only say 54%. In this case the accumulation to A* will go slower. The day when there is exactly 54% yes-votes and 46% no, the addition to A will be exactly 54% of the addition if we had 100% yes votes, meaning a slower progress.

>The sum of all (yes-no) votes over days.

Is this equation an equivalent representation of yours?

_t \ / (yes-no) > d ’-0

-I think so yes..

>> Yes it is important, because if there is a majority switch, those > voted on the first side might want to consider their first vote (which > can be cahnged ofcourse, or start to drive opinion again, which takes > time. > In this way there is little risk that those voting in the beginning > with well built arguments will miss if there comes in arbitary > arguments of other unfair opinions.

Is that “reset” a required part of your system?

-Sorry for another error of mine… It’s the other way around, the accumulated support should be set to zero in order to avoid that the voting time streches out too much just because there is a switch of majority..
It can be díscussed if this resetting is needed but for practical reasons we think it’s a good feature.
The argument for it is that the issue is well known by the voters and majority switches might happen many times in even issues, 49/51 to 51/49 etc. This might lead to very long voting times thus impractical.

[top-politics] Re: Content added to Wiki

echarp — 2006-11-23 17:21:06+0100

> > For example, if a recalculation fails, it will be difficult to simply > > relaunch it a few hours later. > > Why? It is only to use the number of yes/no votes casted on the > original time for summation and redo the division.

Participants can vote and revote at any time, the last one being the valid one. If you relaunch the calculation 10 hours later, you will have to find out the last votes of all participants at the time of the original calculation.

This is not simple SQL, it is not a simple recalculation.

And it has to be done for all proposals.

Read more… / Lire plus…

> > Anyway, MG, can d be expressed not as a dividing constant, but as a > > threshold? Maybe a % of participants, or a number of accumulated > > (yes-no)? > > Well, if 60% have voted yes, the formulas A* = M* + A and A = A* > /(dxZ) could be expressed: > A=(M* + A(index:t-1=former A)) / dxZ

A proposal would be accepted if:
A=(M* + A(index:t-1=former A)) / Z and A > d ?
d a fraction of the total population

Or, without division or multiplication:
A=M* + A(index:t-1=former A) and A > d’ ?
d’ a margin or threshold

> Which is the same as :the percentage of all yes votes (or no votes if > negative) out of all, divided by a small number f.i. 7 or a large f.i. > 356. > > , making it 1/7 of the total or 1/356 of the total percentage. > > It is quite simple to explain to everyone on the street that if we then > repeat this and no more votes are comming in, after 7 (or 356) times of > adding another 1/7 (or 1/356) part, the vote is over because then we > have 7/7 (or 356/356) =1

The accumulation of a difference over time did leave me puzzled. And I’m not sure it is that easy to explain to the layman.

> > => (yes-no)0 + (yes-no)1 + (yes-no)… + (yes-no)t > d ?

The sum of all (yes-no) votes over days.

Is this equation an equivalent representation of yours?

_t \ / (yes-no) > d ’-0

> > This does not address the reversal of opinion which automatically > > “resets” the left part of the equation. > > > > Is that reversal really important? Considering your orientation, is it > > not logical that a proposal on which the general opinion changes so > > radically takes more time to be approved or refused? > > Yes it is important, because if there is a majority switch, those > voted on the first side might want to consider their first vote (which > can be cahnged ofcourse, or start to drive opinion again, which takes > time. > In this way there is little risk that those voting in the beginning > with well built arguments will miss if there comes in arbitary > arguments of other unfair opinions.

Is that “reset” a required part of your system?

echarp – http://leparlement.org

[top-politics] Re: Content added to Wiki

Magnus — 2006-11-23 14:48:44+0100

>For example, if a recalculation fails, it will be difficult to simply relaunch it a few hours later.

-Why? It is only to use the number of yes/no votes casted on the original time for summation and redo the division. >(To me Condorcet is also complex, too much for a realistic usage)

-To me too.

>Anyway, MG, can d be expressed not as a dividing constant, but as a threshold? Maybe a % of participants, or a number of accumulated (yes-no)?

Read more… / Lire plus…

-Well, if 60% have voted yes, the formulas A* = M* + A and A = A* /(dxZ) could be expressed: A=(M* + A(index:t-1=former A)) / dxZ

Which is the same as :the percentage of all yes votes (or no votes if negative) out of all, divided by a small number f.i. 7 or a large f.i.

, making it 1/7 of the total or 1/356 of the total percentage.

It is quite simple to explain to everyone on the street that if we then repeat this and no more votes are comming in, after 7 (or 356) times of adding another 1/7 (or 1/356) part, the vote is over because then we have 7/7 (or 356/356) =1

>=> (yes-no)0 + (yes-no)1 + (yes-no)… + (yes-no)t > d ?

In English, we could say that a proposal is accepted if its supporters constantly outnumbers its detractors by a certain margin.

-But then there need to be a certain margin, and this migth never occur.

>This does not address the reversal of opinion which automatically “resets” the left part of the equation.

Is that reversal really important? Considering your orientation, is it not logical that a proposal on which the general opinion changes so radically takes more time to be approved or refused?

-Yes it is important, because if there is a majority switch, those voted on the first side might want to consider their first vote (which can be cahnged ofcourse, or start to drive opinion again, which takes time.
In this way there is little risk that those voting in the beginning with well built arguments will miss if there comes in arbitary arguments of other unfair opinions.
One could also thing of a function where you would be able to filter on majority switches due to this.

>*Who* decides if and when a proposal is to be frozen? :)

-Exactly, this is a problem so AD want to keep open the possibility to put up your own proposals without limits.