Réévaluation du DU

Ok, c’est pas t-1 = now() - 6 mois, c’est juste le bloc précédent HEAD~1.

Avec la documentation du protocole c’est plus simple.

Du coup, ce sont les valeurs courantes de M et de N qui sont prises pour calculer le nouveau DU aujourd’hui ? Je ne comprends pas, on utilisait M et N à la date du précédent équinoxe ? Selon mes calculs, pour la réévaluation qui vient de se produire, on aurait dû obtenir 10,12.

1007+0.04886^2×614000000÷1742÷182.6 ≃ 1011,6 −> 10,11 Ğ1 1007+0.04886^2×987900000÷2229÷182.6 ≃ 1012,8 −> 10,12 Ğ1

En fait, ce n’est pas HEAD_1 ou HEAD qui fait ça, mais massReeval et non monetaryMass : on prend bien la masse monétaire de la dernière réévaluation. Et le nombre de membres courant (sinon ça serait quelque chose comme membersReeval).

2 J'aimes

Je sais pas ce qu’est ce massReeval, pas ça semble pas être une différence :

1007+0.04886^2×(987900000- 614000000)÷2229÷182.6 ≃ 1009

Pow, la complexité de ce calcul. Je me demande combien ils étaient pour développer ça.

Donc on ne connait pas le prochain DU avec certitude ? :astonished:

Et le calcul précédent (avec M/N(equinoxe)) affiché sur Cesium ainsi qu’à plusieurs endroits de ce forum n’est pas le bon ? :astonished:

massReeval, c’est la masse monétaire lors de la dernière réévaluation du DU, soit M(t-1) lors de la prochaine rééval. Regarde comment il est mis à jour aux lignes 1197-1200 de indexer.ts : lors de la réévaluation il est mis à jour avec la masse courante (en fait la masse du bloc précédent, ce qui n’est peut-être pas vraiment exact, mais à moins d’avoir vraiment pas de chance en tombant pile poil sur un arrondi, ça ne change rien), et sinon il est trimballé de bloc en bloc sans changement pour le transmettre à la prochaine réévaluation.

1 J'aime

La formule exacte, telle que je la lis dans le code de Duniter, est :

DU(t) = ceil_centimes( DU(t-1) + c² × ceil( M(t-1) ) / N(t) / ½ an )

Exprimée en français, c’est le DU précédent auquel on ajoute : c², multiplié par l’arrondi supérieur de la masse monétaire lors de la dernière réévaluation, divisé par le nombre de membres courant, divisé par l’intervalle entre deux réévaluations (en jours) ; le tout arrondi au centime supérieur.

Donc en fait beaucoup de formules qui circulent sont effectivement fausses. Celle de Cesium est aussi fausse (en fait, il faudrait propager les t dans chacun des membres M et N car là on pourrait croire qu’il faut multiplier M/N par (treeval-dtreeval). @kimamila

La question qui se pose peut-être est : est-ce qu’on veut plutôt garder la formule contenue dans le code de Duniter et dans le protocole, ou celle qui circule ? Car au final, ce qui est la loi, c’est ce que ceux qui font tourner des nœuds décident. :stuck_out_tongue:

Dans les deux cas, le DU va s’ajuster en fonction du nombre de membres, avec plus ou moins de retard selon qu’on prend le nombre de membres actuel ou le nombre de membres à la dernière réévaluation. Cette deuxième solution a l’avantage qu’on pourra déterminer le DU dès la réévaluation précédente, tandis que celle utilisée actuellement ne permet pas de déterminer le prochain DU à l’avance, ou en tout cas seulement peu de temps avant la prochaine réévaluation par extrapolation et prévision du nombre de membres. C’est peut-être plus rigolo, on peut même lancer des paris. :stuck_out_tongue: Dans tous les cas, ça n’a que peu voire pas d’impact du tout, vu la très faible réévaluation, tous les utilisateurs se fichent éperdument d’un petit centime d’écart à la prochaine réévaluation et ce pour encore assez longtemps a priori. Ça a un impact long terme peut-être un peu plus prononcé, mais ça reste négligeable.

Pour ma part, je changerais les clients et je garderais la formule, histoire d’avoir le moins d’impact possible au niveau des développeurs. Quant à la formule, 99,9 % des utilisateurs ne la comprennent pas de toute façon. :smiley:

2 J'aimes

Attention le code n’est pas la loi, ce qui fait foi c’est la spécification du protocole ici, qui donne la formule suivante :

HEAD.dividend = CEIL(HEAD_1.dividend + c² * CEIL(HEAD~1.massReeval / POW(10, HEAD~1.unitbase)) / HEAD.membersCount)

C’est uniquement sur cette spécification que l’on peut se baser pour juger une formule de « juste » ou « fausse ». Il semble que la formule dans le code de Duniter soit bien conforme a la spécification, donc c’est bien les clients qui sont en tord :slight_smile:

Pour info, j’ai édité mon message au-dessus. Pour ma part, je suis d’accord pour garder la formule telle qu’elle est codée.

ceil(1007+0.04886^2×614000000÷2229÷182.6)/100 ≃ ceil(1010.6)/100 −> 10,11 Ğ1

Je comprends pas pourquoi M(t-1) et N(t) sont utilisés.

Avec N(t-1):

ceil(1007+0.04886^2×614000000÷1742÷182.6)/100 ≃ ceil(1011.6)/100 −> 10,12 Ğ1

C’est pas la formule décrite dans la TRM et ça fausse le taux de croissance c.

En soi c’est pas si grave.

me too. Mais est ce que ça vaut le coup de modifier le protocole pour ça ? J’ai tendance a penser comme Jytou que ce n’est pas urgent et qu’on peut laisser le protocole tel qu’il est pour le moment :slight_smile: Après si veut qu’on en change, tu peut ouvrir un thread sur le forum technique :wink:

Une personne/association/entreprise a besoin de faire des prévisions pour ses calculs économiques :confused: Pouvoir connaître avec certitude ce genre d’informations à l’avance c’est jamais de refus !

Mais effectivement, la part relative du DU varie déjà en fonction de N au jour le jour. Que N varie juste avant ou juste après la revalorisation change pas grand chose à cela.

Ça ne fait que renforcer mon intuition que les entreprises n’utiliserons pas le DU mais plutôt la moyenne comme référentiel/unité de compte :slight_smile:

3 J'aimes

C’est vrai, les prévisions ont leur importance, c’est pour ça que je l’ai souligné. Mais franchement, on peut d’ores et déjà prévoir avec une forte probabilité le prochain DU. Je viens de calculer l’intervalle du nombre de membres qui ferait un DU à 10,16 Ğ1 pour la prochaine réévaluation, ça se situe entre 2588 et 3235 membres dans 6 mois. Vu les progressions précédentes, on peut déjà dire aujourd’hui (6 mois à l’avance quand même) qu’il y a quand même de fortes chances que l’on soit dans cet intervalle. Plus l’échéance va se rapprocher, plus la probabilité va augmenter et il sera même probablement possible au moins un mois avant de le savoir avec certitude vu la vitesse max des certifications. :slight_smile:

2 J'aimes

Ahah, j’avais déjà dans l’idée de générer ce tableau dans Gxtrais :stuck_out_tongue:

1 J'aime

Bonsoir,

Bravo @jytou pour avoir levé ce lièvre !

Je pense que maintenant que l’objet de la problématique est établit, il serait plus adéquat de discuter ce point sur forum.duniter plutôt qu’ici.

À mon sens, ça demande un correctif car on sort du cadre de la TRM. Mais l’avis de notre ami perpignanais serait à prendre en compte.

Il me semble ^^

Cordialement,

Candide

1 J'aime

Du coup, qu’en pense tu @Galuel ? :slight_smile:

Je pense que la formule dans Cesium est la bonne, je l’ai vérifiée minutieusement à la date où Benoît avait prévu de l’y mettre (ou que j’ai fortement suggéré de l’y mettre, peu importe !). Après ce qui est dans le code je ne sais pas, mais les premières réévaluations étaient parfaitement prévisibles.

Après d’un point de vue expérimental - pratique, la différence sera minime et sans impact majeur.

2 J'aimes

J’ai vérifié moi-même dans le code de Duniter et @jytou a raison, la formule appliquée par Duniter n’est pas la même que dans Cesium.
Après, la différence étant minime, je préfère qu’on ne modifie pas le protocole juste pour ça, et qu’on attende une futur version majeure de protocole pour y intégrer la correction de la formule dans la foulée :slight_smile:

1 J'aime

Ca n’a pas de raison d’être une priorité majeure, ça ne pose pas de problème ni pratique ni théorique, on obtiendra une courbe extrêmement proche de l’autre, qui ne change qu’un delta.

1 J'aime

Oui, exactement, c’était exactement ce que je voulais dire par :

De manière approchée, oui, mais pas de manière exacte. Il me paraît quand même important que les formules affichées soient identiques à celle appliquée par Duniter, sinon quelqu’un qui appliquerait la formule affichée risque d’être un peu surpris… si on peut éviter les confusions, c’est mieux.

1 J'aime

@jytou peut tu ouvrir une issue sur le dépôt de Duniter pour tracer ce problème ? Merci :slight_smile: