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.
Ce que je peux faire :
dt = 24 * 3600 secondes)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 :
dt
dtReeval
Et tant pis pour le 21 septembre.
Oui peu importe.
21 Mars 2017 12h00 + 15.778.800 secondes ne tombera certainement pas à 12h00, donc comment tu fais !? 
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 :
D’accord, et sa mise à jour sera alors inscrite en blockchain ?
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é.
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 :
On peut y constater que :
Voilà.
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.
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 :
J’ai tenté de reproduire en corrigeant mon tableau.
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 :
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.
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 :
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 :
Le nombre de membre croit fortement, le DU augmente timidement ! Mais il augmente 
