Réévaluations du montant du DU

Est ce que duniter-ts et durs sont d’accord…?

Le projet s’appelle Duniter.

1 « J'aime »

Non Duniter utilise bien la fonction CEIL comme l’atteste son code source, c’est moi qui est du faire une erreur dans mon calcul manuel :wink:

Durs n’a pas encore implémenté la formule de cacul du DU mais je vais reprendre la meme directement dans le code de Duniter donc il ne devrait pas y avoir de delta.

Teaser:

╒═══════════════════════════╤══════════════════════════════════════╕
│         Currency          │                  Ğ1                  │
├───────────────────────────┼──────────────────────────────────────┤
│       Next UD date        │         2019-09-19 13:00:00          │
├───────────────────────────┼──────────────────────────────────────┤
│     Current UD value      │ 10.07 Ğ1 (since 2019-03-22 00:00:00) │
├───────────────────────────┼──────────────────────────────────────┤
│   Next UD reevaluation    │ 10.12 Ğ1 (from  2019-09-20 16:00:00) │
├───────────────────────────┼──────────────────────────────────────┤
│    Next next UD reeval    │ 10.18 Ğ1 (from  2020-03-21 06:00:00) │
├───────────────────────────┼──────────────────────────────────────┤
│   Next UD value formula   │ UD(t) = UD(t-1) + c² * M(t-1)/N(t-1) │
╘═══════════════════════════╧══════════════════════════════════════╛
5 « J'aime »

La réévaluation vient d’avoir lieu à 16h. Silkaj dit vrai. À deux mains 14h pour 10,12 Ğ1 !

7 « J'aime »

Bon, bah, c’est 10,11 Ğ1 :confused:

Duniter applique un ceil() en global sur les valeurs au format centimes et non un arrondi au centième sur un format unité.

Du coup, après mes correctifs sur Silkaj qui auraient permis d’obtenir 10,11 à cette réévaluation, le prochain devrait être 10,16 Ğ1 :sweat_smile:

╒═══════════════════════════╤══════════════════════════════════════════╕
│     Previous UD value     │ 10.07 Ğ1 (from 2019-03-22 to 2019-09-20) │
├───────────────────────────┼──────────────────────────────────────────┤
│     Current UD value      │     10.11 Ğ1 (since 2019-09-20 16h)      │
├───────────────────────────┼──────────────────────────────────────────┤
│   Next UD reevaluation    │     10.16 Ğ1 (from  2020-03-21 06h)      │
├───────────────────────────┼──────────────────────────────────────────┤
│      Next UD formula      │     UD(t+1) = UD(t) + c² × M(t)/N(t)     │
╘═══════════════════════════╧══════════════════════════════════════════╛

9 « J'aime »

Je viens de faire un petit tableur pour prévoir les futurs DU. Il y a quelques approximations mais globalement ça doit être assez juste. Je vous laisse faire mumuse avec mais c’est du dispo et éditable sur internet donc ne vous y fiez pas à 100 %.

https://lite.framacalc.org/gvalue-du-g1

1 « J'aime »

Je ne sais pas si tu es au courant, mais j’ai réalisé une page qui va chercher automatiquement ces infos dans la blockchain : Ğxtrais - Revalorisation du DU

Pour être plus précis, je donne les infos du block de midi qui livre le nouveau DU, pas le block qui calcule le nouveau DU (et qui n’est pas forcement le block de midi, pour ça que je n’indique pas d’heure comme tu le fait).

Tu peux facilement faire un Ctrl+A/Ctrl+C/Ctrl+V dans un tableur :slight_smile:

(Par contre je dois corriger le calcul de la date et du montant du prochain DU :stuck_out_tongue: )

Egalement, je crois que tu as une erreur dans ton tableur : pour calculer le DU(t+1), il faut utiliser M(t)/N(t), et non M(t+1) :slight_smile: (il n’y a pas besoin de faire une estimation de la valeur futur de M :wink: et donc le futur DU est déjà connu avec précision)

2 « J'aime »

Merci pour la page, effectivement ça permet de mettre des vrais chiffres (je suis allé cherché directement les blocs dans la blockchain, en tout cas pour les premiers, avec l’heure correcte). Mais ce sont des variations trop petites pour être réellement significatives.

Quant à la formule de calcul, je me suis basé sur la ligne de code (ligne 1159 du fichier indexer.ts) :

 HEAD.dividend = Math.ceil(HEAD_1.dividend + Math.pow(conf.c, 2) * Math.ceil(HEAD_1.massReeval / Math.pow(10, previousUB)) / HEAD.membersCount / (conf.dtReeval / conf.dt));

En gros, on prend la masse monétaire au DU précédent (c’est bien la masse monétaire de la ligne du dessus que je prends dans le tableur) mais le nombre de membres courant au moment du calcul (donc le N sur la même ligne), à moins que j’aie raté quelque chose, @cgeek ?

1 « J'aime »

Ah oui, tu as bien raison, j’ai pas vu ce détail. Ça devrait être M et N à la date du DU précédent. Tu as spotté un bogue ?

De loin ça m’a l’air bon, avec l’arrondi au centième supérieur ça colle aux DU constatés.

1 « J'aime »

Mais du coup, la formule utilisée pour le calcul du DU n’est pas

DU(t) = DU(t-1) + c² × M(t - 1)/N( t - 1 ) / 1/2 an

comme on le croyait, mais bien

DU(t) = DU(t-1) + c² × M(t - 1)/N( t ) / 1/2 an

Ce qui n’est pas tout-à-fait la même chose. Et cela veut aussi dire qu’on ne peut pas connaître à l’avance le prochain DU, ou seulement en interpolant quelques temps à l’avance la progression du nombre de membres (au final, à quelques membres près ça ne change rien à moins d’être juste en bordure d’un changement d’arrondi).

3 « J'aime »

Non, c’est M(t) qui est pris et il est passé par un ceil(). Ça fait :

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

J’arrive pas à comprendre comment ça fait pour ne pas générer une valeur correcte. Faut que je pose ça tranquillement.

Bien vu @jytou il y a la un effet de bord qui pourrait un jours générer des écarts entre duniter et d’autres logiciels sur le calcul de la réévaluation du DU.
Fort heureusement je n’ai pas encore intégré cette formule dans Dunitrust, il faudra que je je soit parfaitement conforme en prenant donc M(t-1) mais s’il m’aurait paru plus logique de prendre M(t) :sweat_smile:

@moul HEAD_1 représente le bloc précédent (équivaut a la notation HEAD~1 dans le protocole) donc sur ce coup la c’est jytou qui a raison :wink:

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'aime »

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 »