Nombre de chiffres requis pour le DU

Ce que je peux faire :

  • Oublier la formulation DU6mois, plus gênante qu’autre chose
  • DU tous les jours à 12h00 (= période dt = 24 * 3600 secondes)
  • Prendre la date du 21 Mars 2017, et déclencher une augmentation du DU de c² (M/N) tous les 365,25 / 2 jours (= période dtReeval = 15.778.800 secondes)

Dans tous les cas je ne fonctionne qu’en périodes, donc j’ai besoin d’une quantité de secondes. Les 2 seules exceptions sont les dates de 1er DU et de 1er recalcul du DU. On a donc au final 4 paramètres :

  • Période du DU dt
  • Période du recalcul du DU dtReeval
  • la date et l’heure précise du 1er DU de la monnaie
  • la date et l’heure précise du 1er recalcul du DU

Et tant pis pour le 21 septembre.

1 « J'aime »

Oui peu importe.

21 Mars 2017 12h00 + 15.778.800 secondes ne tombera certainement pas à 12h00, donc comment tu fais !? :slight_smile: Il faut que tu choisisses le 12h00 le plus proche sans doute !?

Je décorrèle la création du DU de sa mise à jour, cette dernière se fera donc :

2 « J'aime »

D’accord, et sa mise à jour sera alors inscrite en blockchain ?

1 « J'aime »

Oui voilà, pas de façon explicite dans un bloc, mais de façon implicite en base de données.

Et donc au DU effectif suivant, la valeur aura changé.

1 « J'aime »

Voilà, c’est implémenté, prêt pour la duniter@1.0.

J’ai également écrit un test automatisé simulant les débuts en dividende de Ğ1. Alors c’est très très minimaliste, je peux le retranscrire ici en termes humains :

  • Blockchain démarrant le 9 Mars 2017 à 12h00
  • c = 4,88%
  • N = 2
  • DU(0) = 10,00
  • DU(0) le 10 Mars 2017 à 12h00, puis DU suivants chaque jour à 12h00
  • 1er recalcul du DU le 21 Mars 2017 à 12h00, puis tous les 6 mois

On peut y constater que :

  • DU(0) = 1.000 le 10 Mars 2017 12h00 (block#2)
  • DU(1) = 1.000 le 11 Mars 2017 12h00 (block#3)
  • DU(2) = 1.000 le 12 Mars 2017 12h00 (block#4)
  • DU(10) = 1.000 le 20 Mars 2017 12h00 (block#12)
  • DU(11) = 1.027 le 21 Mars 2017 12h00 (block#13)
  • DU(12) = 1.027 le 22 Mars 2017 12h00 (block#14)

Voilà.

2 « J'aime »

En démarrant au 9 Mars et en supposant que N ne variera pas ou peu d’ici le 21 Mars, alors on aura M/N = 12 DU, alors vérifions le calcul au 21 Mars :

DU(t+1) = DU(t) + c² M/N / 182,625 = 10,0015 = 10,00 sur 4 chiffres.

Le DU ne devrait pas bouger, M/N est encore bien trop petit !

Hopla oui, il me manque la division par 182,625 !

Mais j’aurais quand même une augmentation : je passerai à 10,01, faisant l’arrondi supérieur.

Pas de problème.

Vendu alors. Le test verrouille désormais ce comportent.

4 « J'aime »

je tente de me faire un ‹ module Galilée › avec les paramètre de Ḡ1, mais avec cette subtilité de DU jour et DU semestriel, j’ai eu un peu de mal…
j’ai conçut un tableau qui fait une ligne par jour, mais pour avoir une augmentation nulle sauf aux « équinoxes », j’ai implémentée une colonne qui est toujours à 0 sauf aux équinoxes ou elle est à 1. enfin, pas aux dates astrales, aux dates à fréquence (15.778.800 secondes)
j’ai tiré mes cases pour remplir 38 000 lignes soit 103 ans, à nombre de membre constant.

la masse moyenne tends vers 3836 DU mais on est à 80% de cette limite dès la 11ème année.

Mon tableau, tronqué pour qu’il ne soit pas trop lourd
et le graphique qui en découle:

EDIT : mon fichier ne passe pas, je voit ça demain.
EDIT : voila! simul G1.ods (100,1 Ko)

Suite à une remarque de @Galuel, j’ai dû à nouveau revoir la formulation car le M(t) à prendre en compte n’était pas le bon dans le code, mais correspondait plutôt à M(t+1).

Du coup, voici les nouvelles valeurs à N stable pour Ğ1 :

  • DU = 10,00 / jour du 08/03/2017 au 20/03/2017 (initialisation)
  • DU = 10,00 / jour du 21/03/2017 au 20/09/2017
  • DU = 10,01 / jour de 21/09/2017 au 20/03/2018
  • DU = 10,04 / jour du 21/03/2018 au 20/09/2018
  • DU = 10,09 / jour de 21/09/2018 au 20/03/2019
  • DU = 10,17 / jour du 21/03/2019 au 20/09/2019
  • DU = 10,27 / jour de 21/09/2019 au 20/03/2020
  • DU = 10,40 / jour du 21/03/2020 au 20/09/2020
  • DU = 10,55 / jour de 21/09/2020 au 20/03/2021
  • DU = 10,73 / jour du 21/03/2021 au 20/09/2021
  • DU = 10,93 / jour de 21/09/2021 au 20/03/2022
  • DU = 11,16 / jour du 21/03/2022 au 20/09/2022
  • DU = 11,41 / jour de 21/09/2022 au 20/03/2023
  • DU = 11,69 / jour du 21/03/2023 au 20/09/2023
  • DU = 12,00 / jour de 21/09/2023 au 20/03/2024
  • DU = 12,33 / jour du 21/03/2024 au 20/09/2024
  • DU = 12,69 / jour de 21/09/2024 au 20/03/2025
  • DU = 13,08 / jour du 21/03/2025 au 20/09/2025
  • DU = 13,50 / jour de 21/09/2025 au 20/03/2026
  • DU = 13,95 / jour du 21/03/2026 au 20/09/2026
  • DU = 14,44 / jour de 21/09/2026 au 20/03/2027
2 « J'aime »

J’ai tenté de reproduire en corrigeant mon tableau.

  • formule qui implémente les DU aux équinoxes (test conditionnel sur date)
  • décalage pour que la première réévaluation du DU soit en septembre
    simul G1 entam.ods (165,3 Ko)
    Mais je ne retrouve pas les mêmes valeurs que toi, Cgeek.

J’ai peur qu’il y ait, de mon coté, un problème au démarrage, cette histoire de T0 me chagrine.

Vos retours m’aideront à progresser.

Etudie bien la formule très bien notée dans Cesium. Ne confonds pas “t” et “t+1” ou “t” et “t-1” selon ce que tu appelles “t”…

Généralisons le calcul en recherche relative avec (M/N)max = 1/c DU = p/cp DUjour, et en considérant que nous cherchons x,p,cp tels que :

  • cp² (1/x) (M/N)max / p ≥ 1/1000 DUjour
  • Soit cp ≥ x/1000
  • Avec cp = (1+c)^(p/365,25) - 1
  • Soit p ≥ ln(1+x/1000) / ln(1+c) * 365,25

calculs relatifs.ods (28,2 Ko)

Comment lire ce graphique !? Par exemple voir que pour une période de calcul de 50 jours environ il faut que M/N soit proche de (M/N)max / 10 soit 10% de la monnaie pleine pour que le calcul donne un résultat plus grand que 1/1000 de DUjour.

Ou encore en lisant l’axe des « x », selon la proportion de la monnaie pleine où l’on se trouve, on pourrait adapter à chaque fois la période de mise à jour du prochain DU afin de calculer à chaque fois le prochain centime d’augmentation, plutôt que de fixer la période et d’avoir une augmentation quantitative variable.

Ainsi à une date « t », en fonction de la proportion de la monnaie pleine où l’on se trouve, on déterminerait la prochaine date de mise à jour du DU à laquelle on recalculera de nouveau la date de calcul suivante etc.

2 « J'aime »

La même étude en donnant 1/x (proportion de M/N nécessaire pour toucher 1/1000ème de DU) en fonction de p :

  • 1000*[(1+c)^(p/365,25)-1] ≥ x

calculs relatifs-2.ods (33,6 Ko)

Comment lire ce graphique ?

Pour M/N = 10% de (M/N)max (environ 365 DUjour), la période de calcul est de 40 jours environ pour toucher 1/1000ème du DUjour.

On voit aussi qu’une période de calcul de 182 jours touchera 1/1000 du DUjour dès que M/N vaudra environ 2% de (M/N)max (environ 70 DUjour).

Quelques projections :

  • DU(sept2017) = 10,01
  • DU(mars2018) = 10,02 (en supposant N stable d’aujourd’hui à l’équinoxe de septembre 2017
  • DU(sept2018) = ? (dépend de la variation de N entre sept2017 et mars2018)

Le nombre de membre croit fortement, le DU augmente timidement ! Mais il augmente :slight_smile:

1 « J'aime »

Il augmente ? Combien vaut-il en % de M/N ?

1 « J'aime »
  • DU(sept2017) = 10,01 = 8,20% de M/N
  • DU(mars2018) = 10,02 = 0.898% de M/N

Donc le DU baisse fortement en % de M/N, même s’il augmente en valeur quantitative !

Au niveau interprétation, constater que le DU représente de moins en moins par rapport à la part moyenne de monnaie par membre est logique : plus on crée de monnaie à DU quasi-constant, moins celui-ci représente une part importante de monnaie nouvelle.

Je pense que c’est un effet qu’on constate tant que l’on est pas en phase de croisière (c’est-à-dire tant que ceffectif > 4,88%), mais je ne sais pas le démontrer.

3 « J'aime »

Le sujet a déjà été traité théoriquement :

La valeur recherchée ici (rapport du DU à M/N) est l’inverse de la grandeur mr dans le document ci-dessus.

1 « J'aime »