J’avais bien compris cela, d’où les colonnes “Théorique”, “Floor”, “Ceil”. Je n’ai pas encore été au bout de la réflexion par contre, donc il peut y avoir des erreurs dans le tableur.
Oui j’ai vérifié et c’est bien ça, on voit bien que dans certains cas le DU ne bouge pas, dans d’autres il croît notablement plus vite que sa valeur théorique. Ce qui est dit dans ce fil corrige ce biais.
Pour s’en convaincre numériquement il faut comparer par exemple la croissance d’un DU jour à 4 chiffres avec la formulation donnée ici et la croissance d’un DU possédant 2 chiffres avant la virgule et 7 chiffres après la virgule avec le c jour = 0,026% / jour, les deux doivent parfaitement bien coller.
Pour comparer les deux évolutions e1 et e2, simplement faire le comparatif graphique e2/e1 qui doit rester bien calé autour de 1 (pour l’évolution de M/N mais pour le DU ça va différer très sensiblement, car il faudrait comparer non pas le DU à l’instant “t”, mais la somme des DU sur 120 jours).
Bref, en terme de continuité je penche toutefois pour la solution à 9 chiffres, qui évitera tout pallier, et en pratique il sera très certainement utile que les transaction ramassent tous les chiffres après les centimes de manière automatique, afin que ça ne traîne pas dans les coins… et ainsi on restera de manière transparente à 4 chiffres.
2 Likes
[quote=“Galuel, post:14, topic:1498”]
Pour comparer les deux évolutions e1 et e2, simplement faire le comparatif graphique e2/e1 qui doit rester bien calé autour de 1[/quote]
Rectificatif : seulement sur une petite période, car deux exponentielle même proches mais pas exactement égales vont diverger dans tous les cas… Suffit d’être patient 
J’ai fait des rectificatifs dans les posts précédents, en fait il faut diviser par 40 ou 120 après le calcul par c²M/N, car ce calcul donne le DU pour 40 jours ou 120 jours. Il faut en effet calculer exactement comme suit :
DU(t+1) = DU(t) + (c²*M/N) / p
Où p est la période de calcul du DU (p=1 pour 1 jour, p = 40 pour 40 jours, avec c = 1,045% / 40 jours). Ce qui est normal si on y réfléchit correctement puisqu’on veut produire un DU journalier, mais calculé tous les p jours.
Voici le tableau en monnaie pleine avec 9 chiffres :
DU_journalier_formule.ods (526,6 Ko)
Puis en monnaie montante toujours avec 9 chiffres :
DU_journalier_formule.ods (524,7 Ko)
Ils sont tombent juste comme on peut le vérifier en relatif (tout à droite).
En changeant le DU à 4 chiffres, en montée, la formulation tronquée à 4 chiffres avec fréquence allongée colle mieux au 100% décimal que les tronquées simples qui divergent nettement :
En monnaie pleine (M = 1/c DU * N) c’est encore plus flagrant, ça part carrément en vrille (normal, c’est attendu) :
DU_journalier_formule.ods (521,8 Ko)
Généralisons le problème, soit un DU à h chiffres, un c = 10% / an (c = 0,026% / jour) on cherche cp correspondant à une période « p » de calcul du DU en p jours, qui impacte à minima l’unité du DU, afin que le calcul ne soit pas faussé et colle à l’exponentielle théorique de manière suffisamment proche.
- cp = (1+10%)^(p/365,25)-1
Sachant que les p premiers DU sont les mêmes, le premier calcul de la monnaie se fera sur un M/N de l’ordre de M/N = pDU, au bout de p jours, résultat qui sera ensuite étalé sur p jours (le DU calculé tous les « p » jours est créé en plusieurs fois sur p jours), donc qu’on devra diviser par p pour créer un DU journalier.
On veut donc que le calcul impacte au moins l’unité du DU, soit :
- cp² M/N / p = cp² * pDU / p ≥ 1
- Soit cp² ≥ 1/DU
- Ou encore p ≥ 365,25 * ln[√(1/DU) + 1]/ln(1+10%)
Pour voir les solutions j’ai amélioré le tableur pour y inclure M0, DU0, p, cp en variables, on peut donc simuler un DU0 du nombre de chiffres souhaité, M0 minimal (=pDUN) ou plein ( M plein = 1/cjour*DU0 * N), et essayer plusieurs valeurs pour « p » pour voir à quel moment le DU est impacté au moins à l’unité.
On verra rapidement en graphe relatif que les solutions grossières qui consistent à tronquer le résultat à l’unité au lieu de trouver la bonne période de calcul du DU font nettement diverger la monnaie obtenue de sa valeur normale.
Il sera amusant de voir, quand on choisit p = 365,25 jours = 1 an, comment la monnaie obtenue se comporte par rapport à la monnaie quasi continue calculée en jours avec autant de décimales que voulu.
On s’apercevra que pour un DU jour à 4 chiffres p est efficace (en monnaie pleine uniquement) dès p = 4 jours, avec cp = 0,1044% / 4 jours, mais en monnaie montante, ça ne fonctionne pas (puisque M/N est trop petit pour que cp² M/N / p soit supérieur à l’unité), et il faut bien p = 120 jours pour que cela fonctionne correctement.
DU_journalier_formule.ods (412,9 Ko)
Étant donné l’efficacité économique des 4 chiffres pour le DU, je souhaite conserver cette valeur. Mais par ailleurs en termes techniques, je ne souhaite pas gérer plus de 4 chiffres non plus.
Soit cela oui.
Je crois que je préfère cette solution si le “caché” pouvait être un peu mieux qu’un simple masquage dans l’affichage, qui ferait quand même stocker techniquement 9 chiffres pour le DU. Je pense notamment qu’on peut mémoriser les valeurs théoriques de DU et M sur 9 chiffres, appelons les DUh et Mh (h pour hypothétique), et on aurait alors les formulations suivantes :
DUh(t+1) = DUh(t) + c² Mh(t)/N
Et :
DU(t+1) = PLANCHER(DUh(t+1))
Avec :
DUh(0) = DU(0) * 10⁵
Et donc on fonctionnerait bien sur 4 chiffres pour le DU, mais la formule prendrait en compte non pas le DU ni le M effectif précédent, mais reposerait plutôt sur sa valeur théorique sur 9 chiffres.
Je n’ai pas encore regardé les valeurs sur un tableur, mais j’évoque cette solution car elle me semble assez simple à réaliser techniquement.
1 Like
Non ça n’ira pas, parce que les nombres ne seront alors pas dans la monnaie, ce n’est pas qu’une question d’affichage, car il y a le cumul des DU à 9 chiffres, qui seraient une monnaie, alors que si on ne prend que les parties entières ces DU, on aura pas la bonne exponentielle, ça revient à tronquer.
Il n’y a pas de demi-mesure possible :
- Soit on gère un DU à 9 chiffres effectivement, et la monnaie sommera tous ces DU.
- Soit on gère un DU à 4 chiffres avec la formule qui s’applique tous les 120 jours, les DU jours étant stables entre.
- Soit on gère la période de DU carrément sur 120 jours (mais on perd la continuité).
- Soit on passe à 5 chiffres (40 jours), 6, 7… etc…
A noter que ça ne change absolument rien à la formulation DU(t+1) = DU(t) + c²M/N ni au calcul de la croissance journalière, il suffit juste de noter :
c = 3,18% / 120 jours = 10 % an = 0,026% / jour
La période choisie définit juste le moment du calcul du terme c²M/N qui contient cette période dans c². Le DU reste donc avec une formule journalière, qui est juste adaptée à cause du nombre de chiffres souhaité pour définir la longueur numérique fixe (nombre de chiffres) du DU.
Cela m’embête d’avoir un code à exception, ça complique vraiment la lecture. Je crois que je préférerais gérer 9 chiffres et me traîner 5 cachés.
Est-ce si gênant que ça, étant donné qu’un compte ne peut pas avoir moins de 1,00 unités ? A la limite la seule chose gênante est qu’il faut 4 octets pour stocker le montant, mais ce n’est rien en comparaison de la taille de la clé publique associée.
J’aurai besoin de relire les sujets où l’on voyait ce problème de stockage en fonction de la longueur du DU.
Il faut voir l’impact sur la taille de la blockchain aussi, qui va de toute façon gonfler avec le temps… Mais si c’est dérisoire par rapport aux clés, et que les clés apparaissent de toute façon à chaque transaction, alors ça ne devrait pas impacter trop.
Je sais, c’est égoïste, je pense à ma petite brique de rien du tout… mais, pour moi, le fait de faire tourner un nœud sur un tout petit ordinateur est important, pour assurer qu’il y aura plus de machines sur le réseau, et donc une meilleure résilience
Si ça n’avait pas été dans mes principes de base, Duniter serait déjà un truc qui tourne uniquement sur de gros serveurs gérés par des sysadmin. Le fait que tu puisses le faire tourner sur une brique n’est pas un hasard, rassures-toi 
4 Likes
Oh oui, je sais bien que tu y mets du temps et de l’énergie, dans ces releases ARM, et je t’en suis bien reconnaissant
Pourquoi pas, c’est une solution.
Est-ce vraiment un code à exception !? Le calcul du DU jour de Gtest ne se base-t-il pas sur une lecture du temps pour se lancer ? Donc le temps fait forcément partie des conditions du calcul.
Dire que le DU est calculé tous les 120 jours ne pose donc pas de problème d’exception. Dire qu’il est calculé, ou “mis à jour”, tous les 120 jours, mais produit à cadence journalière ne fait que distinguer le temps de release des DU avec le temps de leur production effective, je ne pense pas que ce soit très compliqué en terme de lecture. Déjà en économie quantité de choses, y compris le RSA d’ailleurs, sont mis à jour tous les 6 mois ou tous les ans, mais géré à des fréquences plus courtes (au mois généralement).
Après théoriquement je n’ai pas de préférence, c’est un choix technique à faire.
Pour la taille du truc, il suffit de compter avec 1 million de membres et on aura en monnaie pleine M/N = 1/cjour DU < 4000 DU
Soit M = 10⁶ * 4*10³ * 4 chiffres = 16 Giga chiffres, mais répartis sur moins de comptes, car là on est en centimes. Si donc on a 1,00 minimum par compte ça ne fait donc plus que 160 Méga comptes. Après faut voir la taille d’un compte…
1 Like
Question courte : la fréquence du DU la plus élevée qu’on puisse avoir avec 4 chiffres sans que ça ne pose de problème, c’est combien ?
Pourquoi pas, et sinon, une période de préférence ? Changement au moment des équinoxes ?
3 Likes
J’aime l’idée mais si on prend 120 jours ça n’ira pas, faut prendre alors 182,625 jours et c_6mois = (1+10%)^(1/2) = 4,88% / 6 mois.
Voir le fil pour les détails avec le dernier tableur où tout est précisé, et cgeek a bien répondu. Fréquence la plus haute ok ou période la plus petite puisque f = 1/p
Si j’ai bien compris l’idée, on a donc :
- 1 DU fixe pour 6 mois (= DU précédent) : <=> c = 0% par jour
- 1 DU normal pour 6 mois avec c = 4,88% / 6 mois = 1,0488^(1/182,625) <=> c = 0,026% par jour
Donc alternativement, c vaut 0% ou 0,026%. Est-ce bien cela ?
edit : mauvais chiffre, et après recalcul je retombe sur le 0,026% par jour. Le problème n’a pas changé.
Non DU6mois(t+6mois) = DU6mois(t) + (4,88%)² M/N
Et pour transformer en DUjour on divise par 6 mois : DUjour = DU6mois / 182,625 jours, soit donc :
DUjour(t+6mois) = DUjour(t) + (4,88%)² M/N / 182,625 jours
Qu’on ne calcule que tous les 6 mois, entre-temps ça ne bouge pas.
Je n’avais même pas compris cela. On a donc un DU quotidien, mais dont la valeur ne varie que tous les 6 mois.
OK, c’est effectivement assez simple.
1 Like
Et on voit bien la pertinence du truc, si on calcule avec un M/N petit = 182,625 DUjour = 182,625 * 10,00 (somme des DU jours sur 6 mois) :
DU(t+6mois) = 10,00 + (4,88%)² * 10,00 = 10,02 on voit bien que la dernière décimale est touchée à minima (2 au lieu de 1 car on a pris 182,625 jours au lieu de 120 jours minimal).