Déclaration Byte (Integer Long) et traitement de la décimale .5

[job75]

Bonjour à tous,

Testé seulement sur Excel 2010.

Je n'arrive pas à comprendre pourquoi les résultats de ces 2 macros sont différents :

Sub Test1()
Dim n As Byte 'Integer 'Long
n = 1.5 '2.5
n = n + 1
MsgBox n
End Sub

Sub Test2()
Dim n As Byte  'Integer 'Long
n = 1
n = n + 1.5 '2.5
MsgBox n
End Sub

Et refaites les tests avec 2.5 !!

Quelqu'un comprend ça ? Merci de votre réponse.

A+

 

[job75]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Re,

Bon maintenant je comprends que l'arrondi dépend de la parité du nombre qui précède .5 :

Sub Test3()
Dim a, i As Byte, n As Byte
a = Array(1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5, 10.5, 11.5)
For i = 0 To UBound(a)
  n = a(i)
  MsgBox a(i) & " => " & n
Next
End Sub

Nombre impair => arrondi supérieur

Nombre pair => arrondi inférieur.

D'où vient cette différence de traitement ? Roger2327 devrait pouvoir nous l'expliquer.

A+

 

[Staple1600]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour à tous

Job75 😉
Voici une piste fournie par l'aide VBA peut-être, non ?
Les fonctions CInt et CLng arrondissent les parties décimales égales à 0,5 au nombre pair le plus proche. Par exemple, 0,5 est arrondi à 0 et 1,5 est arrondi à 2. Les fonctions CInt et CLng diffèrent des fonctions Fix et Int, qui tronquent la partie décimale d'un nombre sans forcément l'arrondir. En outre, les fonctions Fix et Int renvoient toujours une valeur du type passé.


Il semblerait comme tu l'as remarqué que ce soit la même logique avec Byte.

 

[laetitia90]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

bonjour tous🙂
salut l'ami Job🙂🙂

cela vient de la declaration de la variable a mon avis??

 Dim n  As Double

autrement s'interesser a ByRef & ByVal

ps salut l'ami JM🙂🙂

 

[Staple1600]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour leti 😉


Un Dim n donne le bon résultat aussi
(donc en Variant)

 

[laetitia90]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

re,🙂🙂🙂

bien sur JM 😉😉 j'ai pris double seulement pour la memoire 8 octets..... variant 16 ou 22 si texte

 

[job75]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour Jean-Marie, Laetitia 🙂

Mon propos est de comprendre pourquoi l'arrondi diffère avec la parité quand n est déclaré Byte Integer ou Long.

Bien sûr il n'y a pas d'arrondi si n est déclaré Double ou Single...

JM tes explications avec CInt ou CLng sont correctes :

Sub a()
MsgBox CInt(1.5) '=> 2
MsgBox CInt(2.5) '=> 2
MsgBox CLng(1.5) '=> 2
MsgBox CLng(2.5) '=> 2
End Sub

Nota : avec les nombres négatifs le phénomène est identique :

Sub Test4()
Dim a, i As Byte, n As Integer
a = Array(-4.5, -3.5, -2.5, -1.5, -0.5, 0.5, 1.5, 2.5, 3.5, 4.5)
For i = 0 To UBound(a)
  n = a(i)
  MsgBox a(i) & " => " & n
Next
End Sub

A+

 

[job75]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Re,

La remarque de JM est très juste : VBA convertit toujours n comme font les fonctions CByte, CInt ou CLng.

Mais alors pourquoi ces conversions diffèrent-elles suivant la parité ?

Quelle est la raison ou la logique de tout ça ? Il y en a forcément une.

A+

 

[job75]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Re,

Noter que la fonction Round fait exactement la même chose :

Sub Test5()
Dim a, i As Byte, n As Double
a = Array(-4.5, -3.5, -2.5, -1.5, -0.5, 0.5, 1.5, 2.5, 3.5, 4.5)
For i = 0 To UBound(a)
  n = Round(a(i)) 'Round(a(i), 0)
  MsgBox a(i) & " => " & n
Next
End Sub

Alors que dans une feuille de calcul la parité n'intervient pas :

=ARRONDI(1,5;0) renvoie 2

=ARRONDI(2,5;0) renvoie 3

A+

 

[Dranreb]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour Job75

Tu m'en (ré ?)apprend une belle ! J'étais persuadé depuis un moment que Round(x) = Int(x + 0.5)
Et bien non !
J'utiliserai dorénavant la 2ième forme.
Remarque : ce n'est pas faux si on ne cherche que l'entier le plus proches, vu qu'il y en a deux, là, sans attacher d'importance à d'autre considérations de congruence à 1.

Mais j'ai trouvé la raison de ce choix discutable: Réduire l'accumulation toujours dans le même sens d'erreurs de +0.5 dans l'addition des nombres arrondis.
Ce lien n'existe plus

Si la partie fractionnaire est exactement égale à 0,5, les fonctions de conversion d'entier l'arrondissent toujours au nombre entier pair le plus proche. Par exemple, 0,5 est arrondi à 0 ; 1,5 et 2,5 sont tous les deux arrondis à 2. C'est ce que l'on appelle parfois l'arrondi bancaire et son but est de compenser un écart qui pourrait s'accumuler lors de l'ajout de tels nombres.

Bien cordialement.

 

[job75]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour Bernard,

Merci pour l'info.

La raison donnée par Microsoft est donc de "compenser" l'accumulation des écarts.

Cela me paraît un "gadget" car il n'y aura pas de compensation si tous les nombres sont pairs, ou impairs.

Et dans une feuille de calcul cette compensation n'existe pas...

A+

 

[Dranreb]

Re : Déclaration Byte (Integer Long) et traitement de la décimale .5

Bonjour job75.
Tout à fait d'accord.
Cordialement.

P.S. Je soupçonne vaguement d'autres raisons plus obscures et beaucoup plus difficiles à expliquer :
J'ignore si c'est le cas, mais il se pourrait très bien que la fonction se contente d'utiliser une instruction machine qui effectue l'arrondi de cette façon.
Cette instruction n'existerait que parce que ce serait dommage qu'elle n'existe pas, vu que l'organisation des interconnexions la permettant y seraient de toute façon dans l'unité arithmétique et logique.
Parce qu'elles seraient utilisées de façon interne dans l'ALU pour ajuster l'alignement des mantisses de nombres flottants avant addition. Parce qu'elle aurait tendance à offrir une plus grande précision des calculs par un alignement plus favorable à la conservation de bits du plus petit nombre en augmentant d'un cran son ordre de grandeur dans le système de numération binaire.
Mais bon. Ça fait beaucoup de suppositions tout ça !