Code : Tout sélectionner
a.f = 4294967295
Debug a
[V3.x - v4] Truc bizarre avec un float ... [Résolu]
[V3.x - v4] Truc bizarre avec un float ... [Résolu]
Ce code :
... retourne "-1" en PB3.94 et "4294967295" en PB4 : normal ?
Dans la 3.94 un float est codé sur 4 octets alors que dans la V4, alors que maintenant je pense qu'elle est codée sur 8 octets.
Un nombre flottant ne peut pas dépasser la valeur d'un type long pour la 3.94 ou d'un quad pour la V4.
D'ailleurs si tu fais 4294967295.0 le compilateur t'indique que ton chiffre est trop grand!
Un nombre flottant ne peut pas dépasser la valeur d'un type long pour la 3.94 ou d'un quad pour la V4.
D'ailleurs si tu fais 4294967295.0 le compilateur t'indique que ton chiffre est trop grand!
La preuve par l'exemple (nombres signés):
Code : Tout sélectionner
q.q = 9223372036854775807 ; 64 bits
l.l = 2147483647 ; 32 bits
w.w = 32767 ; 16 bits
b.b = 127 ; 8 bits
f.f = 10000000 + 1 / 3 ; flottant sur 32 bits
d.d = 10000000 + 1 / 3 ; flottant sur 64 bits
Debug q
Debug l
Debug w
Debug b
Debug f
Debug d
Vive le thread-safe !
Les nombres à virgule flottante c'est un sujet assez délicat car le nombre est stocké grâce à un système d'exposants et donc comme l'indique la doc au plus le nombre est grand (avant la virgule) au moins la précision (après la virgule) est grande.
Pour visualiser le nombre flottant il faut donc le calculer et avec PB 3.94 le plus grand type était d'une taille de 32 bits (un long) le nombre ne dépassait pas +2147483647 (nombres signés):
Comme ce sont des nombres signés après le plus grand nombre positif on passe au plus petit nombre négatif. Si l'on continue on va passer des nombres négatifs aux positifs:
La version 4 de PB nous a accouché de nombres plus grands càd sur 64 bits (les quad).
Quand tu veux visualiser un float il calcule donc sur 64 bits au lieu de 32 bits ce qui fait que la limite des Long signés (+2147483647) est passé à celle des quad (+9223372036854775807 en signés).
On remarque clairement que la limite du long est passée mais pas celle du float et du quad.
Le passage à des nombres négatifs se fait toujours puisque ce sont des nombres signés mais la limite est devenue celle des quad:
Donc c'est normal qu'avec PB3.94 il te donne -1 et pas avec PB4.
Dans les différents exemples on peut aussi clairement voir que la précision diminue au plus le nombre est grand.
Un dernier point à éclaircir, c'est que le "stockage" du nombre flottant reste sur 32bits même si son "affichage" se calcule sur 64bits:
SizeOf() donne la taille en octets donc on multiplie par 8 pour avoir le nombre de bits.
Pour visualiser le nombre flottant il faut donc le calculer et avec PB 3.94 le plus grand type était d'une taille de 32 bits (un long) le nombre ne dépassait pas +2147483647 (nombres signés):
Code : Tout sélectionner
;PB 3.94
f.f = 2147483647
l.l = 2147483647
Debug f
Debug l
f.f = 2147483649
l.l = 2147483649
Debug f
Debug l
Code : Tout sélectionner
; PB 3.94
f.f = 3000000000
l.l = 3000000000
Debug f
Debug l
f.f = 4294967295
l.l = 4294967295
Debug f
Debug l
f.f = 4294967298
l.l = 4294967298
Debug f
Debug l
Quand tu veux visualiser un float il calcule donc sur 64 bits au lieu de 32 bits ce qui fait que la limite des Long signés (+2147483647) est passé à celle des quad (+9223372036854775807 en signés).
Code : Tout sélectionner
; PB 4
f.f = 2147483649
q.q = 2147483649
l.l = 2147483649
Debug f
Debug q
Debug l
Le passage à des nombres négatifs se fait toujours puisque ce sont des nombres signés mais la limite est devenue celle des quad:
Code : Tout sélectionner
; PB 4
f.f = 9223372036854775807
q.q = 9223372036854775807
Debug f
Debug q
f.f = 9223372036854775808
q.q = 9223372036854775808
Debug f
Debug q
Dans les différents exemples on peut aussi clairement voir que la précision diminue au plus le nombre est grand.
Un dernier point à éclaircir, c'est que le "stockage" du nombre flottant reste sur 32bits même si son "affichage" se calcule sur 64bits:
Code : Tout sélectionner
; PB 4
b.b
w.w
l.l
q.q
f.f
d.d
Debug SizeOf(b) * 8
Debug SizeOf(w) * 8
Debug SizeOf(l) * 8
Debug SizeOf(f) * 8
Debug SizeOf(q) * 8
Debug SizeOf(d) * 8
Vive le thread-safe !
y'a ca aussi pour compenser le nombre de décimales en PB
en plus le compilo traduit l'expression tout seul comme un grand donc c'est comme si on faisait a = valeur.
là encore on a du mal à retomber sur la valeur souhaitée, c'est du au format des nombres réels (IEEE)
Dri
en plus le compilo traduit l'expression tout seul comme un grand donc c'est comme si on faisait a = valeur.
Code : Tout sélectionner
a.f = (4294967 * 1000) + 295
Debug aDri
Je ne pense pas confondre.
Un nombre à virgule flottante est un nombre stocké différemment des nombres classiques.
Il est formé pour les floats (donc sur 32bits) d'une mantisse (23 bits), d'un exposant (8 bits) et d'un bit de signe.
Je ne vais pas détailler le truc mais prennons un exemple qui s'en rapproche: 10 ^ (exposant) 20.
Quand je dis "10 exposant 20" ce n'est pas un nombre comme on peut le voir en debug, il faut le "calculer" pour afficher 100 000 000 000 000 000 000 (y'a 20 zéros).
Les float c'est plus ou moins le même principe et donc pour l'afficher il faut "calculer". Avec PB3.94 le calcul se faisait avec des Long qui sont limités à 2^31 (31 car y'a un bit de signe) mais avec PB4 le calcul est fait avec des Quad qui peuvent monter jusque 2^63 (toujours un bit de signe).
En ce qui concerne les doubles, c'est exactement comme des floats sauf que la mantisse est de 52 bits et l'exposant est de 11 bits.
La différence c'est qu'ils ont une bien meilleure précision que les floats mais il faut savoir que ça prend plus de temps de calcul (et donc c'est plus lent).
Pour moi le meilleur exemple c'est 1/3 car il y a une infinité de chiffres après la virgule et en l'occurence c'est toujours le même.
Ici avec PB 3.94 on a 6 chiffres derrière la virgule.
On peut voir ici que l'arrondi se fait beaucoup plus loin qu'en PB 3.94 car il est calculé grâce à des nombres plus grands (64 bits quoi).
On remarque aussi que les doubles ont une plus grande précision car ils ont une mantisse et exposant plus grands.
Un nombre à virgule flottante est un nombre stocké différemment des nombres classiques.
Il est formé pour les floats (donc sur 32bits) d'une mantisse (23 bits), d'un exposant (8 bits) et d'un bit de signe.
Je ne vais pas détailler le truc mais prennons un exemple qui s'en rapproche: 10 ^ (exposant) 20.
Quand je dis "10 exposant 20" ce n'est pas un nombre comme on peut le voir en debug, il faut le "calculer" pour afficher 100 000 000 000 000 000 000 (y'a 20 zéros).
Les float c'est plus ou moins le même principe et donc pour l'afficher il faut "calculer". Avec PB3.94 le calcul se faisait avec des Long qui sont limités à 2^31 (31 car y'a un bit de signe) mais avec PB4 le calcul est fait avec des Quad qui peuvent monter jusque 2^63 (toujours un bit de signe).
En ce qui concerne les doubles, c'est exactement comme des floats sauf que la mantisse est de 52 bits et l'exposant est de 11 bits.
La différence c'est qu'ils ont une bien meilleure précision que les floats mais il faut savoir que ça prend plus de temps de calcul (et donc c'est plus lent).
Pour moi le meilleur exemple c'est 1/3 car il y a une infinité de chiffres après la virgule et en l'occurence c'est toujours le même.
Code : Tout sélectionner
; PB 3.94
f.f = 1 / 3
Debug fCode : Tout sélectionner
; PB4
f.f = 1 / 3
d.d = 1 / 3
Debug f
Debug dOn remarque aussi que les doubles ont une plus grande précision car ils ont une mantisse et exposant plus grands.
Vive le thread-safe !