vous ne vous offusquerez plus de voir que votre fichier occupant
un cluster de 4,096 Ko quand vous avez des blocs de stockage de
"4Ko";
^^
Merci de faire attention : on écrit 4,096 ko. Enfin, à ce niveau, moi
j'écrirais simplement 4069 octets.
Vous offusquez-vous de lire des approximations dans les tailles des
fichiers exprimées en unités binaires ? Moi non, et là c'est pareil.
Quand ça tombe juste, c'est un coup de pot.
Je prends un fichier quelconque de mon disque dur. Le système
m'affiche
Taille: 1,46 Mo (1 538 466 octets)
Taille sur le disque: 1,46 Mo (1 540 096 octets)
Dans les deux cas, 1,46 MiB est une approximation. En quoi est-elle
meilleure que 1,54 Mo ? Au moins je n'ai pas eu besoin de calculatrice
pour obtenir cette valeur.
En informatique, pour tout ce qui est stockage, et uniquement ce qui
est stockage, les unités dérivées des puissances de 2 (1024=2^10)
donnent des nombres entiers plutôt que des nombres à virgules.
C'est faux pour la taille des disques durs, voir plus bas. C'est faux
pour la taille des objets stockés. Ça concerne essentiellement les
unités élémentaires de stockage (secteurs, clusters, pages). A partir
du moment où le nombre d'unités élémentaires, par essence non binaire
sauf pour la RAM, est grand devant la taille d'une unité, les tailles
résultantes n'ont plus grand chose de binaire. A partir du moment où,
par nécessité, on utilise pour exprimer ces tailles d'autres préfixes
que les préfixes qui conviennent aux unités élémentaires, les nombres
obtenus ne sont plus entiers. Pour preuve, reprenez l'exemple
précédent, sachant que la taille de cluster était de 4 KiB.
Mais l'utilisateur ou même le programmeur d'applications, qu'est-ce
que ça peut leur faire qu'en-dessous il y ait des puissances de 2
puisque eux ne les voient jamais directement ?
Ceux qui essayent de faire du code rapide savent qu'il est plus
efficace de gérer des tableaux ayant une taille multiple d'une
puissance de 2 (gérer les tests de bord du tableau),
Vous auriez un exemple de code (de préférence en C, merci) ?
Quand il m'arrive - rarement - de programmer, j'utilise des tableaux
dont la taille est juste suffisante pour contenir ce que j'ai besoin
d'y mettre. C'est mal ?
qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...
<humour>
Ah, vous parlez de ceux qui écrivent des programmes pour des
processeurs 8 ou 16 bits de faible puissance de calcul. Faites
excuses, je pensais
qu'on parlait d'architectures modernes.
</humour>
D'autre part, je pensais naïvement que c'était le fait que la taille
d'un élément, et pas le nombre, soit une puissance de deux qui
permettait de calculer plus rapidement l'offset à partir de l'indice,
par simple décalage binaire plutôt que par vraie multiplication.
Mais le programmeur, dans les langages comme le C du moins, il ne peut
pas coder directement en KiB ou MiB. C'est bête, le langage ne connaît
pas ces préfixes. Il est donc obligé d'écrire le nombre complet sans
préfixe multiplicateur. Là encore, où est l'utilité des préfixes
binaires ?
En effet. Cette unité de mesure 1024 n'est que le résultat d'un
compromis : être une puissance de deux (conversion pas trop pénible
pour l'ordinateur, unité de mesure qui produit des nombres entiers),
et n'être pas trop loin de cette unité de mesure 'homophile' qu'est
le nombre 1000.
Compromis qui n'a plus lieu d'être puisque les quantités binaires ont
maintenant leurs préfixes multiplicateurs normalisés distincts des
préfixes SI décimaux.
<snip délire hexadécimal qui fait mal à la tête et aux yeux>
C'est la même chose en unités binaires quand le nombre d'unités
composant un objet, qui n'a a priori rien d'une puissance de 2,
dépasse le millier. Voir mon exemple de taille de fichier plus haut.
Cf taille des clusters de "4Ko", courant en FAT32, que j'ai
développé plus haut.
Et vous en voyez souvent, vous, des clusters ? Moi je vois surtout des
fichiers, avec des tailles quelconques.
Bien sûr que si. A partir du moment où ces nombre sont visibles d'une
façon ou d'une autre, c'est qu'ils ont été ou sont destinés à être
manipulés par des humains. Sinon, ils restent cachés dans les
variables internes des programmes et le problème ne se pose même pas.
Ce qui n'est pas évident au premier abord, c'est que cela ne
concerne que (et exclusivement) les capacités de stockages !
Même pas toutes. Prenons le cas du nombre de secteurs d'un disque dur.
Vous n'arriverez pas plus à exprimer ce nombre comme un multiple
simple d'une puissance de 2 que comme celui d'une puissance de 10. J'ai
dit
simple, pas à 6 chiffres ou plus, hein.
Par exemple, le nombre de secteurs du WD AC28400 de ~8,4 Go (~8 GiB)
est 16 514 064 = 1 032 129 * 16. Pas terrible comme puissance de 2.
Taille totale : 8 455 200 768 octets
soit 8 257 032 KiB
soit 8 063,507 813 MiB
soit 7,874 519 349 GiB
On a du mal à voir des nombre entiers simples, ne trouvez-vous pas ?
Pour le kbit/s, c'est un peu plus fin à comprendre. [...]
Ce qui est mesuré, c'est la vitesse de déplacement d'un objet.
<HS>
C'est une vitesse de transmission, pas de déplacement. Le débit mesure
le nombre de bits, mètres cubes... qui entrent ou sortent du tuyau à
chaque seconde, pas la vitesse de propagation/déplacement des bits ou
de l'eau le long du tuyau, qui serait exprimée en m/s.
</HS>
Donc, je résume : il n'y a que (et uniquement que) les unités de
stockage qui sont exprimés en base 1024 en informatique, tout
simplement parce que ça donne des nombres entiers ( => plus facile
pour nous, humains),
Des fois. Pas toujours.
Et là ou ça devient corsé, c'est quand on combine les tailles de
fichiers, en kilo binaires selon l'usage, et les débits de
transmissions, en kilo décimaux. 512 kbits/s, c'est 512000 bits/s.
Oui, mais en kilo-octets, ça fait combien ?
Eh bien, c'est comme vous voulez,
ou plutôt comme les auteurs des logiciels qui vous affichent les
résultats l'a voulu.
Petite démonstration.
Client ftp de Windows 2000 :
ftp : 831951 octets reçus dans 13,36Secondes 62,27Ko/sec.
831951/13,36 = 62272 octets/s => kilo décimal écrit à tort "K".
Client ftp v0.10 de Linux :
831951 bytes received in 13.15 secs (61.8 kB/s)
831951/13,15 = 63266 octets/s = 61,8 KiB/s => kilo binaire écrit à
tort "k".
Bref, les deux affichent un débit faux, mais différemment. Il fallait
le faire. On est pas sorti de l'auberge. J'affirme que le kilo
binaire est source d'erreur dès qu'il a le malheur de devoir être
associé à des mesures décimales.
l'ordre de grandeur est approchante de l'ordre de grandeur de ce que
nous avons l'habitude de manipuler ( pas trop loin de 1000, mais pas
exactement, malheureusement).
Le problème, c'est que l'erreur relative augmente à chaque fois qu'on
passe au préfixe supérieur : 2% d'erreur entre le kilo "informatique"
et le kilo SI, 7% avec le giga. 7% sur un giga-octet, ça se voit, et bien
gros. Pour 14 Go, ça fait 1 Go de différence.
Remplacer les "Ko informatiques" par des "Ki" ou autre bizarrerie de
la sorte, c'est contre-nature pour les pauvres hêres que nous sommes,
C'est là que je ne vous comprends pas. Ces préfixes ont été créés pour
mettre tout le monde d'accord : ceux qui comme moi, dénoncent l'emploi
abusif des préfixes SI quand on leur prête une valeur binaire ainsi
que la confusion qui en découle, et ceux qui comme vous veulent continuer
pour des raisons pratiques à utiliser des préfixes ayant des valeurs
binaires. Qu'est-ce que vous trouvez contre-nature ? C'est juste un
petit changement d'écriture, un petit "i" de plus, la belle affaire,
et les nombres que vous avez l'habitude de manipuler ne changent pas.
Je rejoins le club ce ceux qui râlent de ce que les fabricants de
disques durs expriment la taille en unités base 1000. Vu par
l'informatique (et c'est quand même la finalité de la chose : on
n'écrit pas au stylo bille les bits sur les plateaux !), on se
retrouve avec une capacité réellement exploitable bien moindre de ce
à quoi l'on pouvait s'attendre.
Mais non. Les "informaticiens" sont des spécialistes, ils savent à
quoi s'attendre, eux, et ils font la conversion au besoin (quel
besoin ?).
Moi je pense à l'utilisateur lambda induit en erreur par l'affichage
de son système d'exploitation, à cent lieues d'imaginer que le giga
affiché représente 2^30 et pas 10^12.
c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seule fin marketeuse en plus !
Pas uniquement "à fin marketeuse". Les fabricants de disques durs sont
justement des industriels, des commerçants, pas des informaticiens. Ce
sont eux qui fabriquent et vendent les octets, et ils sont davantages
tenus d'utiliser les préfixes normalisés et unités du SI, valable
aussi bien pour les sciences et les techniques que pour le commerce, qu'un
éditeur de logiciel qui ne vend pas de la capacité et que cela
n'engage guère d'utiliser des unités fantaisistes au regard du reste du
monde.
D'un point de vue technique, la seule et unique puissance de 2 dans un
disque dur, c'est la taille de 512 octets d'un secteur élémentaire.
Est-ce à vos yeux suffisant pour exprimer cette taille en giga-octets
avec un facteur d'erreur de 7% ?
Ça m'horripile autant que cet autre constructeur de CPU qui ne
mesure pas la fréquence d'horloge de son produit, mais la "fréquence
d'horloge d'un produit concurrent qui aurait la même puissance"
Si vous parlez d'AMD avec ses Athlon XP, ce n'est pas comparable. Le
nombre fait partie d'un nom commercial, ce n'est pas une
caractéristique technique (il n'est jamais suivi de "GHz"). D'autre
part, j'ai lu que ce "P-rating" n'était pas basé sur une comparaison
avec le Pentium d'Intel
mais avec la génération d'Athlon précédente, le Thunderbird, dont le
nom commercial contenait la fréquence réelle. A confirmer. De toute
façon,
quand vous achetez un CPU, vous achetez de la puissance de calcul ou
de
la fréquence ? Vous auriez préféré l'inverse, un processeur aux
performances minables mais tournant à un fréquence délirante ?
En conclusion ? On n'a pas fini de voir des Ko valant 1024 !
Je n'ai donc pas fini d'afficher ma signature !
vous ne vous offusquerez plus de voir que votre fichier occupant
un cluster de 4,096 Ko quand vous avez des blocs de stockage de
"4Ko";
^^
Merci de faire attention : on écrit 4,096 ko. Enfin, à ce niveau, moi
j'écrirais simplement 4069 octets.
Vous offusquez-vous de lire des approximations dans les tailles des
fichiers exprimées en unités binaires ? Moi non, et là c'est pareil.
Quand ça tombe juste, c'est un coup de pot.
Je prends un fichier quelconque de mon disque dur. Le système
m'affiche
Taille: 1,46 Mo (1 538 466 octets)
Taille sur le disque: 1,46 Mo (1 540 096 octets)
Dans les deux cas, 1,46 MiB est une approximation. En quoi est-elle
meilleure que 1,54 Mo ? Au moins je n'ai pas eu besoin de calculatrice
pour obtenir cette valeur.
En informatique, pour tout ce qui est stockage, et uniquement ce qui
est stockage, les unités dérivées des puissances de 2 (1024=2^10)
donnent des nombres entiers plutôt que des nombres à virgules.
C'est faux pour la taille des disques durs, voir plus bas. C'est faux
pour la taille des objets stockés. Ça concerne essentiellement les
unités élémentaires de stockage (secteurs, clusters, pages). A partir
du moment où le nombre d'unités élémentaires, par essence non binaire
sauf pour la RAM, est grand devant la taille d'une unité, les tailles
résultantes n'ont plus grand chose de binaire. A partir du moment où,
par nécessité, on utilise pour exprimer ces tailles d'autres préfixes
que les préfixes qui conviennent aux unités élémentaires, les nombres
obtenus ne sont plus entiers. Pour preuve, reprenez l'exemple
précédent, sachant que la taille de cluster était de 4 KiB.
Mais l'utilisateur ou même le programmeur d'applications, qu'est-ce
que ça peut leur faire qu'en-dessous il y ait des puissances de 2
puisque eux ne les voient jamais directement ?
Ceux qui essayent de faire du code rapide savent qu'il est plus
efficace de gérer des tableaux ayant une taille multiple d'une
puissance de 2 (gérer les tests de bord du tableau),
Vous auriez un exemple de code (de préférence en C, merci) ?
Quand il m'arrive - rarement - de programmer, j'utilise des tableaux
dont la taille est juste suffisante pour contenir ce que j'ai besoin
d'y mettre. C'est mal ?
qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...
<humour>
Ah, vous parlez de ceux qui écrivent des programmes pour des
processeurs 8 ou 16 bits de faible puissance de calcul. Faites
excuses, je pensais
qu'on parlait d'architectures modernes.
</humour>
D'autre part, je pensais naïvement que c'était le fait que la taille
d'un élément, et pas le nombre, soit une puissance de deux qui
permettait de calculer plus rapidement l'offset à partir de l'indice,
par simple décalage binaire plutôt que par vraie multiplication.
Mais le programmeur, dans les langages comme le C du moins, il ne peut
pas coder directement en KiB ou MiB. C'est bête, le langage ne connaît
pas ces préfixes. Il est donc obligé d'écrire le nombre complet sans
préfixe multiplicateur. Là encore, où est l'utilité des préfixes
binaires ?
En effet. Cette unité de mesure 1024 n'est que le résultat d'un
compromis : être une puissance de deux (conversion pas trop pénible
pour l'ordinateur, unité de mesure qui produit des nombres entiers),
et n'être pas trop loin de cette unité de mesure 'homophile' qu'est
le nombre 1000.
Compromis qui n'a plus lieu d'être puisque les quantités binaires ont
maintenant leurs préfixes multiplicateurs normalisés distincts des
préfixes SI décimaux.
<snip délire hexadécimal qui fait mal à la tête et aux yeux>
C'est la même chose en unités binaires quand le nombre d'unités
composant un objet, qui n'a a priori rien d'une puissance de 2,
dépasse le millier. Voir mon exemple de taille de fichier plus haut.
Cf taille des clusters de "4Ko", courant en FAT32, que j'ai
développé plus haut.
Et vous en voyez souvent, vous, des clusters ? Moi je vois surtout des
fichiers, avec des tailles quelconques.
Bien sûr que si. A partir du moment où ces nombre sont visibles d'une
façon ou d'une autre, c'est qu'ils ont été ou sont destinés à être
manipulés par des humains. Sinon, ils restent cachés dans les
variables internes des programmes et le problème ne se pose même pas.
Ce qui n'est pas évident au premier abord, c'est que cela ne
concerne que (et exclusivement) les capacités de stockages !
Même pas toutes. Prenons le cas du nombre de secteurs d'un disque dur.
Vous n'arriverez pas plus à exprimer ce nombre comme un multiple
simple d'une puissance de 2 que comme celui d'une puissance de 10. J'ai
dit
simple, pas à 6 chiffres ou plus, hein.
Par exemple, le nombre de secteurs du WD AC28400 de ~8,4 Go (~8 GiB)
est 16 514 064 = 1 032 129 * 16. Pas terrible comme puissance de 2.
Taille totale : 8 455 200 768 octets
soit 8 257 032 KiB
soit 8 063,507 813 MiB
soit 7,874 519 349 GiB
On a du mal à voir des nombre entiers simples, ne trouvez-vous pas ?
Pour le kbit/s, c'est un peu plus fin à comprendre. [...]
Ce qui est mesuré, c'est la vitesse de déplacement d'un objet.
<HS>
C'est une vitesse de transmission, pas de déplacement. Le débit mesure
le nombre de bits, mètres cubes... qui entrent ou sortent du tuyau à
chaque seconde, pas la vitesse de propagation/déplacement des bits ou
de l'eau le long du tuyau, qui serait exprimée en m/s.
</HS>
Donc, je résume : il n'y a que (et uniquement que) les unités de
stockage qui sont exprimés en base 1024 en informatique, tout
simplement parce que ça donne des nombres entiers ( => plus facile
pour nous, humains),
Des fois. Pas toujours.
Et là ou ça devient corsé, c'est quand on combine les tailles de
fichiers, en kilo binaires selon l'usage, et les débits de
transmissions, en kilo décimaux. 512 kbits/s, c'est 512000 bits/s.
Oui, mais en kilo-octets, ça fait combien ?
Eh bien, c'est comme vous voulez,
ou plutôt comme les auteurs des logiciels qui vous affichent les
résultats l'a voulu.
Petite démonstration.
Client ftp de Windows 2000 :
ftp : 831951 octets reçus dans 13,36Secondes 62,27Ko/sec.
831951/13,36 = 62272 octets/s => kilo décimal écrit à tort "K".
Client ftp v0.10 de Linux :
831951 bytes received in 13.15 secs (61.8 kB/s)
831951/13,15 = 63266 octets/s = 61,8 KiB/s => kilo binaire écrit à
tort "k".
Bref, les deux affichent un débit faux, mais différemment. Il fallait
le faire. On est pas sorti de l'auberge. J'affirme que le kilo
binaire est source d'erreur dès qu'il a le malheur de devoir être
associé à des mesures décimales.
l'ordre de grandeur est approchante de l'ordre de grandeur de ce que
nous avons l'habitude de manipuler ( pas trop loin de 1000, mais pas
exactement, malheureusement).
Le problème, c'est que l'erreur relative augmente à chaque fois qu'on
passe au préfixe supérieur : 2% d'erreur entre le kilo "informatique"
et le kilo SI, 7% avec le giga. 7% sur un giga-octet, ça se voit, et bien
gros. Pour 14 Go, ça fait 1 Go de différence.
Remplacer les "Ko informatiques" par des "Ki" ou autre bizarrerie de
la sorte, c'est contre-nature pour les pauvres hêres que nous sommes,
C'est là que je ne vous comprends pas. Ces préfixes ont été créés pour
mettre tout le monde d'accord : ceux qui comme moi, dénoncent l'emploi
abusif des préfixes SI quand on leur prête une valeur binaire ainsi
que la confusion qui en découle, et ceux qui comme vous veulent continuer
pour des raisons pratiques à utiliser des préfixes ayant des valeurs
binaires. Qu'est-ce que vous trouvez contre-nature ? C'est juste un
petit changement d'écriture, un petit "i" de plus, la belle affaire,
et les nombres que vous avez l'habitude de manipuler ne changent pas.
Je rejoins le club ce ceux qui râlent de ce que les fabricants de
disques durs expriment la taille en unités base 1000. Vu par
l'informatique (et c'est quand même la finalité de la chose : on
n'écrit pas au stylo bille les bits sur les plateaux !), on se
retrouve avec une capacité réellement exploitable bien moindre de ce
à quoi l'on pouvait s'attendre.
Mais non. Les "informaticiens" sont des spécialistes, ils savent à
quoi s'attendre, eux, et ils font la conversion au besoin (quel
besoin ?).
Moi je pense à l'utilisateur lambda induit en erreur par l'affichage
de son système d'exploitation, à cent lieues d'imaginer que le giga
affiché représente 2^30 et pas 10^12.
c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seule fin marketeuse en plus !
Pas uniquement "à fin marketeuse". Les fabricants de disques durs sont
justement des industriels, des commerçants, pas des informaticiens. Ce
sont eux qui fabriquent et vendent les octets, et ils sont davantages
tenus d'utiliser les préfixes normalisés et unités du SI, valable
aussi bien pour les sciences et les techniques que pour le commerce, qu'un
éditeur de logiciel qui ne vend pas de la capacité et que cela
n'engage guère d'utiliser des unités fantaisistes au regard du reste du
monde.
D'un point de vue technique, la seule et unique puissance de 2 dans un
disque dur, c'est la taille de 512 octets d'un secteur élémentaire.
Est-ce à vos yeux suffisant pour exprimer cette taille en giga-octets
avec un facteur d'erreur de 7% ?
Ça m'horripile autant que cet autre constructeur de CPU qui ne
mesure pas la fréquence d'horloge de son produit, mais la "fréquence
d'horloge d'un produit concurrent qui aurait la même puissance"
Si vous parlez d'AMD avec ses Athlon XP, ce n'est pas comparable. Le
nombre fait partie d'un nom commercial, ce n'est pas une
caractéristique technique (il n'est jamais suivi de "GHz"). D'autre
part, j'ai lu que ce "P-rating" n'était pas basé sur une comparaison
avec le Pentium d'Intel
mais avec la génération d'Athlon précédente, le Thunderbird, dont le
nom commercial contenait la fréquence réelle. A confirmer. De toute
façon,
quand vous achetez un CPU, vous achetez de la puissance de calcul ou
de
la fréquence ? Vous auriez préféré l'inverse, un processeur aux
performances minables mais tournant à un fréquence délirante ?
En conclusion ? On n'a pas fini de voir des Ko valant 1024 !
Je n'ai donc pas fini d'afficher ma signature !
vous ne vous offusquerez plus de voir que votre fichier occupant
un cluster de 4,096 Ko quand vous avez des blocs de stockage de
"4Ko";
^^
Merci de faire attention : on écrit 4,096 ko. Enfin, à ce niveau, moi
j'écrirais simplement 4069 octets.
Vous offusquez-vous de lire des approximations dans les tailles des
fichiers exprimées en unités binaires ? Moi non, et là c'est pareil.
Quand ça tombe juste, c'est un coup de pot.
Je prends un fichier quelconque de mon disque dur. Le système
m'affiche
Taille: 1,46 Mo (1 538 466 octets)
Taille sur le disque: 1,46 Mo (1 540 096 octets)
Dans les deux cas, 1,46 MiB est une approximation. En quoi est-elle
meilleure que 1,54 Mo ? Au moins je n'ai pas eu besoin de calculatrice
pour obtenir cette valeur.
En informatique, pour tout ce qui est stockage, et uniquement ce qui
est stockage, les unités dérivées des puissances de 2 (1024=2^10)
donnent des nombres entiers plutôt que des nombres à virgules.
C'est faux pour la taille des disques durs, voir plus bas. C'est faux
pour la taille des objets stockés. Ça concerne essentiellement les
unités élémentaires de stockage (secteurs, clusters, pages). A partir
du moment où le nombre d'unités élémentaires, par essence non binaire
sauf pour la RAM, est grand devant la taille d'une unité, les tailles
résultantes n'ont plus grand chose de binaire. A partir du moment où,
par nécessité, on utilise pour exprimer ces tailles d'autres préfixes
que les préfixes qui conviennent aux unités élémentaires, les nombres
obtenus ne sont plus entiers. Pour preuve, reprenez l'exemple
précédent, sachant que la taille de cluster était de 4 KiB.
Mais l'utilisateur ou même le programmeur d'applications, qu'est-ce
que ça peut leur faire qu'en-dessous il y ait des puissances de 2
puisque eux ne les voient jamais directement ?
Ceux qui essayent de faire du code rapide savent qu'il est plus
efficace de gérer des tableaux ayant une taille multiple d'une
puissance de 2 (gérer les tests de bord du tableau),
Vous auriez un exemple de code (de préférence en C, merci) ?
Quand il m'arrive - rarement - de programmer, j'utilise des tableaux
dont la taille est juste suffisante pour contenir ce que j'ai besoin
d'y mettre. C'est mal ?
qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...
<humour>
Ah, vous parlez de ceux qui écrivent des programmes pour des
processeurs 8 ou 16 bits de faible puissance de calcul. Faites
excuses, je pensais
qu'on parlait d'architectures modernes.
</humour>
D'autre part, je pensais naïvement que c'était le fait que la taille
d'un élément, et pas le nombre, soit une puissance de deux qui
permettait de calculer plus rapidement l'offset à partir de l'indice,
par simple décalage binaire plutôt que par vraie multiplication.
Mais le programmeur, dans les langages comme le C du moins, il ne peut
pas coder directement en KiB ou MiB. C'est bête, le langage ne connaît
pas ces préfixes. Il est donc obligé d'écrire le nombre complet sans
préfixe multiplicateur. Là encore, où est l'utilité des préfixes
binaires ?
En effet. Cette unité de mesure 1024 n'est que le résultat d'un
compromis : être une puissance de deux (conversion pas trop pénible
pour l'ordinateur, unité de mesure qui produit des nombres entiers),
et n'être pas trop loin de cette unité de mesure 'homophile' qu'est
le nombre 1000.
Compromis qui n'a plus lieu d'être puisque les quantités binaires ont
maintenant leurs préfixes multiplicateurs normalisés distincts des
préfixes SI décimaux.
<snip délire hexadécimal qui fait mal à la tête et aux yeux>
C'est la même chose en unités binaires quand le nombre d'unités
composant un objet, qui n'a a priori rien d'une puissance de 2,
dépasse le millier. Voir mon exemple de taille de fichier plus haut.
Cf taille des clusters de "4Ko", courant en FAT32, que j'ai
développé plus haut.
Et vous en voyez souvent, vous, des clusters ? Moi je vois surtout des
fichiers, avec des tailles quelconques.
Bien sûr que si. A partir du moment où ces nombre sont visibles d'une
façon ou d'une autre, c'est qu'ils ont été ou sont destinés à être
manipulés par des humains. Sinon, ils restent cachés dans les
variables internes des programmes et le problème ne se pose même pas.
Ce qui n'est pas évident au premier abord, c'est que cela ne
concerne que (et exclusivement) les capacités de stockages !
Même pas toutes. Prenons le cas du nombre de secteurs d'un disque dur.
Vous n'arriverez pas plus à exprimer ce nombre comme un multiple
simple d'une puissance de 2 que comme celui d'une puissance de 10. J'ai
dit
simple, pas à 6 chiffres ou plus, hein.
Par exemple, le nombre de secteurs du WD AC28400 de ~8,4 Go (~8 GiB)
est 16 514 064 = 1 032 129 * 16. Pas terrible comme puissance de 2.
Taille totale : 8 455 200 768 octets
soit 8 257 032 KiB
soit 8 063,507 813 MiB
soit 7,874 519 349 GiB
On a du mal à voir des nombre entiers simples, ne trouvez-vous pas ?
Pour le kbit/s, c'est un peu plus fin à comprendre. [...]
Ce qui est mesuré, c'est la vitesse de déplacement d'un objet.
<HS>
C'est une vitesse de transmission, pas de déplacement. Le débit mesure
le nombre de bits, mètres cubes... qui entrent ou sortent du tuyau à
chaque seconde, pas la vitesse de propagation/déplacement des bits ou
de l'eau le long du tuyau, qui serait exprimée en m/s.
</HS>
Donc, je résume : il n'y a que (et uniquement que) les unités de
stockage qui sont exprimés en base 1024 en informatique, tout
simplement parce que ça donne des nombres entiers ( => plus facile
pour nous, humains),
Des fois. Pas toujours.
Et là ou ça devient corsé, c'est quand on combine les tailles de
fichiers, en kilo binaires selon l'usage, et les débits de
transmissions, en kilo décimaux. 512 kbits/s, c'est 512000 bits/s.
Oui, mais en kilo-octets, ça fait combien ?
Eh bien, c'est comme vous voulez,
ou plutôt comme les auteurs des logiciels qui vous affichent les
résultats l'a voulu.
Petite démonstration.
Client ftp de Windows 2000 :
ftp : 831951 octets reçus dans 13,36Secondes 62,27Ko/sec.
831951/13,36 = 62272 octets/s => kilo décimal écrit à tort "K".
Client ftp v0.10 de Linux :
831951 bytes received in 13.15 secs (61.8 kB/s)
831951/13,15 = 63266 octets/s = 61,8 KiB/s => kilo binaire écrit à
tort "k".
Bref, les deux affichent un débit faux, mais différemment. Il fallait
le faire. On est pas sorti de l'auberge. J'affirme que le kilo
binaire est source d'erreur dès qu'il a le malheur de devoir être
associé à des mesures décimales.
l'ordre de grandeur est approchante de l'ordre de grandeur de ce que
nous avons l'habitude de manipuler ( pas trop loin de 1000, mais pas
exactement, malheureusement).
Le problème, c'est que l'erreur relative augmente à chaque fois qu'on
passe au préfixe supérieur : 2% d'erreur entre le kilo "informatique"
et le kilo SI, 7% avec le giga. 7% sur un giga-octet, ça se voit, et bien
gros. Pour 14 Go, ça fait 1 Go de différence.
Remplacer les "Ko informatiques" par des "Ki" ou autre bizarrerie de
la sorte, c'est contre-nature pour les pauvres hêres que nous sommes,
C'est là que je ne vous comprends pas. Ces préfixes ont été créés pour
mettre tout le monde d'accord : ceux qui comme moi, dénoncent l'emploi
abusif des préfixes SI quand on leur prête une valeur binaire ainsi
que la confusion qui en découle, et ceux qui comme vous veulent continuer
pour des raisons pratiques à utiliser des préfixes ayant des valeurs
binaires. Qu'est-ce que vous trouvez contre-nature ? C'est juste un
petit changement d'écriture, un petit "i" de plus, la belle affaire,
et les nombres que vous avez l'habitude de manipuler ne changent pas.
Je rejoins le club ce ceux qui râlent de ce que les fabricants de
disques durs expriment la taille en unités base 1000. Vu par
l'informatique (et c'est quand même la finalité de la chose : on
n'écrit pas au stylo bille les bits sur les plateaux !), on se
retrouve avec une capacité réellement exploitable bien moindre de ce
à quoi l'on pouvait s'attendre.
Mais non. Les "informaticiens" sont des spécialistes, ils savent à
quoi s'attendre, eux, et ils font la conversion au besoin (quel
besoin ?).
Moi je pense à l'utilisateur lambda induit en erreur par l'affichage
de son système d'exploitation, à cent lieues d'imaginer que le giga
affiché représente 2^30 et pas 10^12.
c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seule fin marketeuse en plus !
Pas uniquement "à fin marketeuse". Les fabricants de disques durs sont
justement des industriels, des commerçants, pas des informaticiens. Ce
sont eux qui fabriquent et vendent les octets, et ils sont davantages
tenus d'utiliser les préfixes normalisés et unités du SI, valable
aussi bien pour les sciences et les techniques que pour le commerce, qu'un
éditeur de logiciel qui ne vend pas de la capacité et que cela
n'engage guère d'utiliser des unités fantaisistes au regard du reste du
monde.
D'un point de vue technique, la seule et unique puissance de 2 dans un
disque dur, c'est la taille de 512 octets d'un secteur élémentaire.
Est-ce à vos yeux suffisant pour exprimer cette taille en giga-octets
avec un facteur d'erreur de 7% ?
Ça m'horripile autant que cet autre constructeur de CPU qui ne
mesure pas la fréquence d'horloge de son produit, mais la "fréquence
d'horloge d'un produit concurrent qui aurait la même puissance"
Si vous parlez d'AMD avec ses Athlon XP, ce n'est pas comparable. Le
nombre fait partie d'un nom commercial, ce n'est pas une
caractéristique technique (il n'est jamais suivi de "GHz"). D'autre
part, j'ai lu que ce "P-rating" n'était pas basé sur une comparaison
avec le Pentium d'Intel
mais avec la génération d'Athlon précédente, le Thunderbird, dont le
nom commercial contenait la fréquence réelle. A confirmer. De toute
façon,
quand vous achetez un CPU, vous achetez de la puissance de calcul ou
de
la fréquence ? Vous auriez préféré l'inverse, un processeur aux
performances minables mais tournant à un fréquence délirante ?
En conclusion ? On n'a pas fini de voir des Ko valant 1024 !
Je n'ai donc pas fini d'afficher ma signature !
