# Duniter wotb : problème d'arrondi
**URL:** https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199
**Category:** Duniter-v1
**Tags:** duniter, wot, duniteroxyde
**Created:** [27 April 2020 10:29 UTC](https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199 "2020-04-27T10:29:48Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [27 April 2020 10:29 UTC](https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199/1 "2020-04-27T10:29:48Z")
On voit tout de suite qui a installé DuniterOxyde sur la Ğ1 🙂
```auto
│2020-04-27T12:23:51+02:00 - info: Blocks were not applied. ┤
│2020-04-27T12:23:51+02:00 - info: Block resolution: 1 potential blocks after current#317504... ┤
│2020-04-27T12:23:51+02:00 - error: Error: ruleMembershipDistance ┤
│ at Function.checkBlock (/home/moul/duniter/app/lib/blockchain/DuniterBlockchain.js:149:19) ┤
│ at process._tickCallback (internal/process/next_tick.js:68:7) ┤
│2020-04-27T12:23:51+02:00 - info: Fork resolution: 2 potential block(s) found... ┤
│2020-04-27T12:23:51+02:00 - info: Fork resolution: block #317505-0000048F is known as incorrect. Skipping. ┤
│2020-04-27T12:23:52+02:00 - info: Blocks were not applied. ┤
│2020-04-27T12:23:52+02:00 - info: Blocks were not applied. ┤
│2020-04-27T12:23:52+02:00 - info: Block resolution: 1 potential blocks after current#317504... ┤
│2020-04-27T12:23:52+02:00 - error: Error: ruleMembershipDistance ┤
│ at Function.checkBlock (/home/moul/duniter/app/lib/blockchain/DuniterBlockchain.js:149:19) ┤
│ at process._tickCallback (internal/process/next_tick.js:68:7) ┼
│2020-04-27T12:23:52+02:00 - info: Fork resolution: 2 potential block(s) found... ┤
│2020-04-27T12:23:52+02:00 - info: Fork resolution: block #317505-0000048F is known as incorrect. Skipping.
```
[`Mart53`](https://g1.duniter.fr/#/app/block/317505/0000048F038FE12D12D47C02F4E5B11ADA442712AB28A73C418EAD52F427805D) ne devait pas respecter la règle de distance lors de ce renouvellement)
Sur la branche `bugfix/invalid-rules-distance-sigqty` avec une nouvelle synchro ça ne passe pas.
Je retourne sur `dev`. Vos nœuds vont également rester bloqués.
Bon, j’arrive pas à me synchroniser avec la branche `dev`.
```auto
2020-04-27T14:35:15+02:00 - info: Block #317501 added to the blockchain in 38 ms
2020-04-27T14:35:16+02:00 - info: Block #317502 added to the blockchain in 184 ms
2020-04-27T14:35:16+02:00 - info: Block #317503 added to the blockchain in 138 ms
2020-04-27T14:35:16+02:00 - info: Block #317504 added to the blockchain in 99 ms
2020-04-27T14:35:16+02:00 - error: Unhandled rejection: Error: ruleMembershipDistance
2020-04-27T14:35:16+02:00 - error: Error: ruleMembershipDistance
at Function.checkBlock (/home/moul/duniter/app/lib/blockchain/DuniterBlockchain.js:149:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
```
> **Du coup, de retour sur \`bugfix/invalid-rules-distance-sigqty\` avec ce patch, et ça ne bloque plus**
>
> ```auto
> diff --git a/app/lib/indexer.ts b/app/lib/indexer.ts
> index 1082d3d5..37affc05 100644
> --- a/app/lib/indexer.ts
> +++ b/app/lib/indexer.ts
> @@ -867,7 +867,7 @@ export class Indexer {
> mindex.map((ENTRY: MindexEntry) => {
> ENTRY.isBeingRevoked = !!ENTRY.revoked_on;
> });
> -yarn
> +
> // BR_G107
> if (HEAD.number > 0) {
> await Promise.all(
> @@ -934,7 +934,7 @@ yarn
> // BR_G24
> // Global testing, because of wotb
> let stepMax = conf.stepMax;
> - if (HEAD.version < 12) {
> + if (HEAD.version <= 12) {
> conf.stepMax = 7;
> }
> const oneIsOutdistanced = await checkPeopleAreNotOudistanced(
> @@ -958,7 +958,7 @@ yarn
> ENTRY.distanceOK = true;
> }
> });
> - if (HEAD.version < 12) {
> + if (HEAD.version <= 12) {
> conf.stepMax = stepMax;
> }
>
> ```
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [27 April 2020 13:46 UTC](https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199/2 "2020-04-27T13:46:13Z")
@Moul oui depuis quelques jours j’avais pris l’initiative de tester mon noeud oxydé sur la G1 pour voir s’il n’y avait pas des problèmes, et j’ai effectivement remarqué des problèmes, dont 1 que j’ai réglé sur la branche `fix/wotb-save-at-sync`, mais ce matin un autre problème s’est produit auquel je ne m’attendais pas, j’étais justement en train d’investiguer, tu m’a devancé 😛
Sauf que ton patch est incorrect, il ne corrige pas le problème mais le contourne et masque le vrai bug que nous devons encore trouver.
En effet, en protocole v12 la règle de distance est censée être correctement appliquée, il faut que je vérifie manuellement si Mart53 respecte effectivement la règle de distance ou pas. Deux hypothèses possibles :
1. Il y a encore un bug dans Duniter non découvert qui fait que la règle de distance n’est parfois pas respectée, et l’oxydation corrigerai ce bug.
2. L’oxydation a introduit une régression.
Pour trancher entre ces 2 hypothèses, je vais devoir lancer manuellement l’évaluation de la distance pour Mart53 😕
EDIT: A par moul et cgeek qui sont très proche du code, pour les autres je vous recommande de ne pas tester sur la G1 tant que nous ne vous l’auront pas explicitement demandé, ça peut être très délicat donc c’est aux dev d’aller au casse-pipe en premier 😆
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [27 April 2020 16:03 UTC](https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199/3 "2020-04-27T16:03:29Z")
@Moul @cgeek il semblerais que ce soit un problème d’arrondi, et la mauvaise nouvelle c’est que je ne peut pas simuler la façon dont C++ convertis de double vers uint32\_t, donc je n’ai pas de solution :
Au moment des faits il y avait 1670 membres référents et Mart53 était suffisamment proche de 1335 d’entre eux soit environ 79,940119%
Or, 0.8 x 1670 = 1336, donc d’après ma calculatrice casio, Mart53 **ne respecte pas** la règle de distance.
Le problème ? Et bien pour une raison obscure, la plupart des compilateurs C++ vont déduire que 0.8 x 1670 = 1335 😕
J’ai trouvé ici quelqu’un qui a eu le même problème : [http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14326.html](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14326.html)
Formule en Rust :
```
outdistanced = f64::from(success) < x_percent * f64::from(sentries)
```
f64 est l’équivalent du double en C++, ici on compare des doubles donc.
Formule en C++
```
result.isOutdistanced = result.nbSuccess < x_percent * result.nbSentries;
```
Sachant que nbSuccess et nbSentries sont des uint32\_t, on compare donc des entiers.
Problème, si je transforme la formule en Rust pour comparer également des entiers, Mart53 ne passe toujours pas la règle de distance :
```
outdistanced: success < (x_percent * f64::from(sentries)).round() as u32,
```
Que je tente avec round(), ceil(), trunc() ou encore floor(), impossible d’obtenir le même résultat qu’en C++…
Le seul moyen de résoudre le problème c’est de faire un -1 :
```
outdistanced: success < ((x_percent * f64::from(sentries)).round() as u32 - 1)
```
Et cela résout le problème.
Je tiens toutefois a relativiser ce problème, d’après ma sync cautious en version oxydée ce problème avec Mart53 est le seul cas de toute l’histoire de la G1, il est très probable qu’on est jamais un tel cas de nouveau avant très longtemps, d’ici là tout le monde aura la version oxydée donc il n’y aura plus de delta dans la façon de faire les arrondis.
---
### Author:  [@cgeek](https://forum.duniter.org/u/cgeek)
#### Post date: [27 April 2020 16:28 UTC](https://forum.duniter.org/t/duniter-wotb-probleme-darrondi/7199/4 "2020-04-27T16:28:04Z")
A partir du bloc #317605 le problème ne sera plus visible pour la version oxydée non plus, sauf en synchronisation cautious.