Nombre de chiffres requis pour le DU

Formule du DUjour équinoxial :

c = 4,88% / 6 mois
DU(0) = 10,00
DU(t+1) = DU(t) + Si(t=21 Septembre ou t=21mars) {c² (M/N) / 182,625}

Ce qui nous fait donc en termes de périodes, exprimées en secondes (unité de référence temporelle dans Duniter) :

  • Periode DU6 mois = 6 mois = 365,25 jours / 2 = 182,625 jours = 15.778.800 secondes

Mais pour avoir un nombre entier de créations, DU6 mois doit être multiple de DUquotidien :

  • Periode DUquotidien = 15.778.800 / (30 jours * 6 mois) = 24,35 heures = 87.660 secondes

Et pour avoir les équinoxes :

  • udEffectiveTime(0) = 21 Mars 2017 12h00 secondes = 1490094000
  • Au 21 Mars 12h00, un nouveau DU6 mois est calculé

On aura donc au final dans le code de Duniter :

  • DUquotidien = DU6 mois / 180
  • Periode DU6 mois = 15.778.800 secondes
  • Periode DUquotidien = 87.660 secondes
  • DU6 mois(0) = 10,00 * 180

Pour avoir un nombre entier de créations il faut diviser 15.778.800 par un nombre entier, au choix, 182 ou 183 créations feront l’affaire :

  • 15.778.800 / 182 = 86.696 secondes = 24,08 heures
  • 15.778.800 / 183 = 86.223 secondes = 23,95 heures
3 Likes

Ça marche aussi en effet :smiley:

Division par 183 me paraît mieux finalement (on a vraiment un DU par 24 heures échues), les nouvelles valeurs :

  • DUquotidien = DU6 mois / 183
  • Periode DU6 mois = 15.778.800 secondes
  • Periode DUquotidien = 86.223 secondes
  • DU6 mois(0) = 10,00 * 183

Ca me paraît très bien. Avec c = 4,88% / 6 mois…

Par contre je me demandais comment tu cales tes équinoxes exactement ? Par exemple tu démarres ta monnaie en Avril, comment tu vas te caler pour le 21 Septembre (ou le 20 Septembre 20h00 peu importe) !? Tu n’auras pas 15.778.800 secondes, mais il te faudra regarder la date voulue !?

En fait je ne peux que me caler sur une date, puis avoir une période fixe.

Donc là je me cale sur l’équinoxe de printemps, tous les ans ce sera au 21 mars. Et pour celui de septembre, c’est précisément une période d’1/2 année, soit 365,25 jours / 2 (15.778.800 secondes). Mais je ne tombe pas sur le 21 septembre, par contre je retombe sur le 21 mars.

Exemple :

1 Like

Oui ok, une date déterminée, l’autre étant calculée, ça ira très bien.

Il reste un problème : si mon DU est sur 4 chiffres, rien ne dit que sa division par 183 sera entière.

Ce qui veut dire que pour gérer le reste, il faut que je rafistole sur les X derniers coups pour y ajouter 1 unité, où X = DU6mois % 183.

Non, il n’y a pas de problème. 10,00 x 183 * (4,88%)^2 / 183 = 0,238 tu arrondis à 0,23 ou 0,24 ça ne changera pas grand chose.

La période choisie, donc le c = 4,88% sont justement choisis pour qu’une masse monétaire minimale avec un DU 4 chiffres soit impactée à minima au centime (120 jours auraient suffi), ici on voit qu’on a au moins 23 centimes, arrondis à 24 ou pas ne changera rien cette fois, le taux sera bien appliqué correctement.

10,00 x 183 * (4,88%)^2 / 183 = 0,0238 plutôt, l’arrondi serait à 0,02 ou 0,03.

Je ne suis pas hyper à l’aise avec les manipulations faites ici, toujours est-il que si mon DU6mois n’est pas multiple de 183, alors quel est le mieux : arrondi inférieur ou supérieur ?

Yes !

Peu importe, l’arrondi au plus proche sera très bien, ça ne changera pas grand chose. Du moment que les 4 chiffres sont touchés au moins au centime, l’arrondi sera toujours au final quantité négligeable.

Vu que le DU augmente 2 fois par an, on peut pas faire une fois sur deux, arrondi inférieur la première fois, supérieur la seconde fois ?

Au printemps ça pousse, à l’automne ça fane ? :smiley:

Sur le principe j’aime bien, après je préfère éviter cette complication :slight_smile:

1 Like

Faut faire simple… Le montant ne sera au centime que pour M/N très petit, dès que M/N sera de 100 DU supplémentaires (183 de plus après 6 mois supplémentaires ce sera le cas…) ça ne se verra pas… Vous prenez pas la tête avec ça, c’est vraiment négligeable, on n’a géré qu’un cas de limite très basse !

  • M/N = 365 DU | DU = 10,00 | c² M/N / 183 = 0,0475
  • c² = 4,88% ^ 2 = 183 * 0,0475 / (365 * 10,00) = 0,00238
  • c² = 183 * 0,05 / (365 * 10,00) = 0,00250
  • c² = 183 * 0,04 / (365 * 10,00) = 0,00200

Arrondi au plus proche c’est parfait. Arrondi supérieur c’est bien aussi, ça n’aura pas d’impact autre que parfaitement négligeable (250 - 238) / 238 = 12 / 238 = négligeable, même 38 / 238 reste négligeable.

Note : pour avoir un DUquotidien borné à 4 chiffres dans notre cas, il faut que DU6mois soit borné à 6 chiffres, car au pire 999.999 / 183 = 5.464, soit 54,64 en affichage.

Je serais plutôt parti de la condition connue : “borné à 4 chiffres” pour le DUjour :

  • 10,00 ≤ DUjour ≤ 99,99
  • 1830,00 ≤ DU6mois ≤ 18298,17

7 chiffres semblent donc nécessaires.

Je vais certainement revoir le protocole, pour que le roulement se fasse bien sur le DUjour, à 4 chiffres. Le roulement sur le DU6mois n’est pas la cible.

Certainement pas, mais justement pourquoi t’embêter à définir et calculer ce DU6mois ? Pourquoi ne pas plus simplement utiliser une formule jour conditionnelle ?

c = 4,88% / 6 mois
DU(0) = 10,00
DU(t+1) = DU(t) + Si(t=21 Septembre ou t=21mars) {c² (M/N) / 182,625}

Ca n’ira pas, parce qu’en 183 occurrences, les 0,05 heures qui manquent deviennent 9,15 heures de retard, ce qui fera une exception notable en décalage pour le 184ème calé sur 12h00.

Je pense qu’il faut simplifier, le DUjour est calculé à heures fixes comme c’est déjà le cas, et que le calcul intègre tout simplement la condition de respecter la période choisie pour “c”.

Or quand “c” = 1 jour, on définit bien période du calcul du DU = période de création du DU. On a a donc in-fine 2 périodes à définir qui étaient confondues jusqu’ici. Et la période du calcul est elle aussi calée sur un événement fixe, comme la création. Donc on se retrouve avec la formulation simple que j’ai donnée, où il faut considérer des moments fixes pour le calcul de mise à jour d’une part, et la création d’autre part (qui sont sans doute des fonctions renvoyant “true” ou “false” selon le timestamp) :

pcréation() = 1 jour (à 12h00)
pcalcul() = équinoxe (au 21 Mars 12h00 + 21 Septembre 12h00) = 4,88% / équinoxe (0 sinon)
DU(t+1) = DU(t) + Si(pcalcul()) {c² (M/N) / 182,625}

Arrondi au centime le plus proche.

Il n’y a ainsi aucun glissement de l’horaire du DUjour et le nombre de jours entre le 21 septembre et le 21 mars oscillant entre 182 et 183 jours tous les 4 ans, la précision est très largement suffisante et n’aura aucun impact sur le résultat.

Qui plus est la formulation est généralisable et relativement simple à comprendre, puisqu’on voit apparaître avec la condition les moments de mise à jour du DU. Pour un DU jour comme dans Gtest on aurait pcréation = pcalcul avec un truc du genre :

pcréation = 1 jour (à 12h00)
pcalcul = 1 jour (à 12h00) = 3,50% / jour
DU(t+1) = DU(t) + Si(pcalcul()) {c² (M/N) / 1 jour}

@cgeek : si tu te demandes comment concevoir ces paramètres… Une syntaxe à la crontab pour les paramètres de création du Du me paraît ici tout indiquée.