A l'aide S.V.P

Annie D.

22/07/2003 à 01:34

"Gé" wrote:

A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.

Une petite question : comment le savez-vous ?

| Total : 20 538 408 960 octets
|
| Ouf, j'ai bien retrouvé mes 20,5Go et même un peu plus :)

"Vous rendez-vous compte de l'aberration de ce que vous écrivez ?"

Euh, non. Mais vous allez m'éclairer.

Depuis quand la conversion entre octets / Ko / Mo / Go se fait en décalant la
virgule sur la droite ?

Depuis l'adoption de l'échelle décimale par la Commission des Poids et
Mesures en 1790. J'ai bon ?

Veuillez vérifier ceci avant de critiquer haut et fort :
- 1 Go = 1024 Mo
- 1 Mo = 1024 Ko
- 1 Ko = 1024 octets
- 1 octet = 8 Bits

Vérifier où ? Avez-vous une source *officielle* ?

Veuillez vérifier ceci de votre côté :
1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

En cas de doute persistant je vous engage à vérifier le paragraphe 3.1
du document brochure-si.pdf disponible sur cette page du site du Bureau
International des Poids et Mesures :

http://www.bipm.fr/fra/6_Publications/si/si-brochure.html

Soit, dans votre cas (je vous laisse vérifier les calculs par vous même) :
- 20 538 408 960 octets = 19.12 Go.

Nous n'avons pas les mêmes "M" et "G". Au moins les miens font l'objet
d'une normalisation internationale valable dans les domaines
scientifique, technique, et commercial. Peut-on en dire autant des
vôtres ?

Bizarre, vous avez dit bizarre ? Votre disque est pourtant donné pour 20.5 Go...

Rien à dire, il fait bien 20,5 de mes giga-octets (comme le veut la
coutume de mon pays, j'utilise la virgule comme séparateur décimal). Le
compte y est.

Dernière minute : les fabricants de disques durs, pas les derniers
concernés, appliquent les définitions des préfixes du SI. Exemples :

* Western Digital
"Western Digital defines a megabyte (MB) as 1,000,000 bytes and a
gigabyte (GB) as 1,000,000,000 bytes"
Source:
http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqidq6&p_created37285862

* Maxtor
"Go = 1 milliard doctets"
Source:
http://www.maxtor.com/fr/documentation/quick_specs/diamondmax_plus_d740x_quick_specs.pdf

* Seagate
"gigabyte (Gbyte) 1,000 megabytes or 1,000,000,000 bytes."
"megabyte (Mbyte) 1) 1,048,576 bytes for semiconductor memory
2) 1,000,000 bytes for drive capacity."
[Dans ce fil on parle bien de disque, cas 2), pas de mémoire
semi-conductrice]
Source: http://www.seagate.com/docs/pdf/training/SG_GLOS.pdf

A présent, si vous persistez à affirmer que la capacité réelle de vos
disques est inférieure à celle annoncée, c'est que vous qualifiez leurs
fabricants de menteurs.
Personnellement, c'est plutôt l'affichage des systèmes d'exploitation et
de certains logiciels utilitaires que je qualifie d'erroné.

"Gé" wrote:

A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.

Une petite question : comment le savez-vous ?

| Total : 20 538 408 960 octets
|
| Ouf, j'ai bien retrouvé mes 20,5Go et même un peu plus :)

"Vous rendez-vous compte de l'aberration de ce que vous écrivez ?"

Euh, non. Mais vous allez m'éclairer.

Depuis quand la conversion entre octets / Ko / Mo / Go se fait en décalant la
virgule sur la droite ?

Depuis l'adoption de l'échelle décimale par la Commission des Poids et
Mesures en 1790. J'ai bon ?

Veuillez vérifier ceci avant de critiquer haut et fort :
- 1 Go = 1024 Mo
- 1 Mo = 1024 Ko
- 1 Ko = 1024 octets
- 1 octet = 8 Bits

Vérifier où ? Avez-vous une source *officielle* ?

Veuillez vérifier ceci de votre côté :
1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

En cas de doute persistant je vous engage à vérifier le paragraphe 3.1
du document brochure-si.pdf disponible sur cette page du site du Bureau
International des Poids et Mesures :

http://www.bipm.fr/fra/6_Publications/si/si-brochure.html

Soit, dans votre cas (je vous laisse vérifier les calculs par vous même) :
- 20 538 408 960 octets = 19.12 Go.

Nous n'avons pas les mêmes "M" et "G". Au moins les miens font l'objet
d'une normalisation internationale valable dans les domaines
scientifique, technique, et commercial. Peut-on en dire autant des
vôtres ?

Bizarre, vous avez dit bizarre ? Votre disque est pourtant donné pour 20.5 Go...

Rien à dire, il fait bien 20,5 de mes giga-octets (comme le veut la
coutume de mon pays, j'utilise la virgule comme séparateur décimal). Le
compte y est.

Dernière minute : les fabricants de disques durs, pas les derniers
concernés, appliquent les définitions des préfixes du SI. Exemples :

* Western Digital
"Western Digital defines a megabyte (MB) as 1,000,000 bytes and a
gigabyte (GB) as 1,000,000,000 bytes"
Source:
http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqidq6&p_created37285862

* Maxtor
"Go = 1 milliard doctets"
Source:
http://www.maxtor.com/fr/documentation/quick_specs/diamondmax_plus_d740x_quick_specs.pdf

* Seagate
"gigabyte (Gbyte) 1,000 megabytes or 1,000,000,000 bytes."
"megabyte (Mbyte) 1) 1,048,576 bytes for semiconductor memory
2) 1,000,000 bytes for drive capacity."
[Dans ce fil on parle bien de disque, cas 2), pas de mémoire
semi-conductrice]
Source: http://www.seagate.com/docs/pdf/training/SG_GLOS.pdf

A présent, si vous persistez à affirmer que la capacité réelle de vos
disques est inférieure à celle annoncée, c'est que vous qualifiez leurs
fabricants de menteurs.
Personnellement, c'est plutôt l'affichage des systèmes d'exploitation et
de certains logiciels utilitaires que je qualifie d'erroné.

Vous avez filtré cet utilisateur ! Consultez son message

"Gé" wrote:

A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.

Une petite question : comment le savez-vous ?

| Total : 20 538 408 960 octets
|
| Ouf, j'ai bien retrouvé mes 20,5Go et même un peu plus :)

"Vous rendez-vous compte de l'aberration de ce que vous écrivez ?"

Euh, non. Mais vous allez m'éclairer.

Depuis quand la conversion entre octets / Ko / Mo / Go se fait en décalant la
virgule sur la droite ?

Depuis l'adoption de l'échelle décimale par la Commission des Poids et
Mesures en 1790. J'ai bon ?

Veuillez vérifier ceci avant de critiquer haut et fort :
- 1 Go = 1024 Mo
- 1 Mo = 1024 Ko
- 1 Ko = 1024 octets
- 1 octet = 8 Bits

Vérifier où ? Avez-vous une source *officielle* ?

Veuillez vérifier ceci de votre côté :
1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

En cas de doute persistant je vous engage à vérifier le paragraphe 3.1
du document brochure-si.pdf disponible sur cette page du site du Bureau
International des Poids et Mesures :

http://www.bipm.fr/fra/6_Publications/si/si-brochure.html

Soit, dans votre cas (je vous laisse vérifier les calculs par vous même) :
- 20 538 408 960 octets = 19.12 Go.

Nous n'avons pas les mêmes "M" et "G". Au moins les miens font l'objet
d'une normalisation internationale valable dans les domaines
scientifique, technique, et commercial. Peut-on en dire autant des
vôtres ?

Bizarre, vous avez dit bizarre ? Votre disque est pourtant donné pour 20.5 Go...

Rien à dire, il fait bien 20,5 de mes giga-octets (comme le veut la
coutume de mon pays, j'utilise la virgule comme séparateur décimal). Le
compte y est.

Dernière minute : les fabricants de disques durs, pas les derniers
concernés, appliquent les définitions des préfixes du SI. Exemples :

* Western Digital
"Western Digital defines a megabyte (MB) as 1,000,000 bytes and a
gigabyte (GB) as 1,000,000,000 bytes"
Source:
http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqidq6&p_created37285862

* Maxtor
"Go = 1 milliard doctets"
Source:
http://www.maxtor.com/fr/documentation/quick_specs/diamondmax_plus_d740x_quick_specs.pdf

* Seagate
"gigabyte (Gbyte) 1,000 megabytes or 1,000,000,000 bytes."
"megabyte (Mbyte) 1) 1,048,576 bytes for semiconductor memory
2) 1,000,000 bytes for drive capacity."
[Dans ce fil on parle bien de disque, cas 2), pas de mémoire
semi-conductrice]
Source: http://www.seagate.com/docs/pdf/training/SG_GLOS.pdf

A présent, si vous persistez à affirmer que la capacité réelle de vos
disques est inférieure à celle annoncée, c'est que vous qualifiez leurs
fabricants de menteurs.
Personnellement, c'est plutôt l'affichage des systèmes d'exploitation et
de certains logiciels utilitaires que je qualifie d'erroné.

Gé

22/07/2003 à 12:44

Bonjour,

| >C'était pourtant l'un de tes problèmes, non, la taille "anormale" ?
| >
| Ben en fait, pas vraiment ... trop ignare pour y voir quoi que ce
| soit, j'avais seulement recopié les indications données par la
| fonction "Propriété"de la boite de dialogue sans penser que ça
| pouvait faire l'objet d'une discussion spéciale ...

Je te cites :
"Capacité totale ..18,6 Go (20 010 500 096)
Or le DD est un disque de 20 Go"

J'ai donc justifié ce point de différence entre 18.6 et 20 Go.

| Autres infos : si je boote sur le DD mis en maître bien sûr, j'ai
| comme message : pas de systeme disque
| si après avoir booté sur la disquette de démarrage je fais "c:" j'ai
| bien le prmpt qui se met derrière "C" mais si je fais un "Dir" à ce
| moment il marque " Type de média non valide lecture sur lecteur C"
| Qd je fais FDISK à partir de "A" juste pour info, il m'indique que le
| DD est partitionné et que la partition, unique ("C") est bien activée

Pour récupérer l'utilisation de ton DD : fdisk. Tu détruis toutes tes
partitions, tu en crées une unique que tu formates, comme ça tu auras de nouveau
accès à ton disque. Vu les problèmes rencontrés, il me semble fort improbable de
pouvoir récupérer le système sans réinstallation. Par contre, si des données
sont indispensables sur le DD, ne réinstalle rien sur ce disque avant d'avoir
récupérer tes données avec le procédé que je t'ai indiqué dans mon premier
message.

Bonne chance,

Amicalement,

Gé.

Gé

22/07/2003 à 13:16

| > A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.
|
| Une petite question : comment le savez-vous ?

Peut-être parce que je lis les infos que mon ordi me donne, mais je les lis en
Go, pas en octets. Chez moi, partition unique, 100 % de la capacité de mon DD,
j'ai :
- capacité totale : 19 994 050 560 octets / 18.6 Go
(et non 19.99 Go).
- inscription sur les 2 DD : 20.0 GB (Western Digital WD200)

| > | Total : 20 538 408 960 octets
| > |
| > | Ouf, j'ai bien retrouvé mes 20,5Go et même un peu plus :)
| >
| > "Vous rendez-vous compte de l'aberration de ce que vous écrivez ?"
|
| Euh, non. Mais vous allez m'éclairer.
|
| > Depuis quand la conversion entre octets / Ko / Mo / Go se fait en décalant
la
| > virgule sur la droite ?
|
| Depuis l'adoption de l'échelle décimale par la Commission des Poids et
| Mesures en 1790. J'ai bon ?

Ben non. La comversion qui nous concerne n'est pas décimale ! Mais bien comme je
l'ai écrite :

| > - 1 Go = 1024 Mo
| > - 1 Mo = 1024 Ko
| > - 1 Ko = 1024 octets
| > - 1 octet = 8 Bits
|
| Vérifier où ? Avez-vous une source *officielle* ?

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
pour une explication technique

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
tableau différenciant la taille approximative (comme vous) de la taille exacte
(comme moi)

http://www.linux-france.org/prj/jargonf/K/ko.html
pour une petite explication rapide du pourquoi

http://www.pckado.com/index_e-marketing.html
"Ko : Kilo-Octet. Soit 1024 octets, et non pas 1000.
Mo : Méga Octet. C'est-à-dire non pas un million d'octets, mais 1048000
et des poussières (1024*1024). Attention, certaines entreprises (les
fabricants de disques durs, par exemple) définissent le Mo comme 10
puissance 6 octets (1.000.000).
Go : Abrév. de giga-octet, ce qui représente UN PEU PLUS de un milliard
d'octets."

| Veuillez vérifier ceci de votre côté :
| 1 Gtruc = 1 000 Mtrucs
| 1 Mtruc = 1 000 ktrucs
| 1 ktruc = 1 000 trucs
| Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

C'est ce qu'on appelle un abus de langage pour les termes utilisés en
informatiques, vu que ce n'est pas une base décimale.

[...]
| A présent, si vous persistez à affirmer que la capacité réelle de vos
| disques est inférieure à celle annoncée, c'est que vous qualifiez leurs
| fabricants de menteurs.

Ce n'est pas impossible... Etant donné que pour simplifier les choses, ils
n'utilisent pas la conversion réelle, mais la conversion décimale qui n'a pas
lieu dans notre cas, je les traite effectivement de menteur.

| Personnellement, c'est plutôt l'affichage des systèmes d'exploitation et
| de certains logiciels utilitaires que je qualifie d'erroné.

Il faut bien trouver un responsable ! Mais il n'est pas là où vous l'indiquez
!!! Certain(e)s se fient à des vendeurs, d'autres à des données sûres.

Amicalement,

Gé.

"Ne pas avoir entendu parler d'une chose ne signifie pas que cette chose
n'existe pas".
--
Pour me répondre directement, sortez le mammouth.

Vous avez filtré cet utilisateur ! Consultez son message

| > A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.
|
| Une petite question : comment le savez-vous ?

Peut-être parce que je lis les infos que mon ordi me donne, mais je les lis en
Go, pas en octets. Chez moi, partition unique, 100 % de la capacité de mon DD,
j'ai :
- capacité totale : 19 994 050 560 octets / 18.6 Go
(et non 19.99 Go).
- inscription sur les 2 DD : 20.0 GB (Western Digital WD200)

| > | Total : 20 538 408 960 octets
| > |
| > | Ouf, j'ai bien retrouvé mes 20,5Go et même un peu plus :)
| >
| > "Vous rendez-vous compte de l'aberration de ce que vous écrivez ?"
|
| Euh, non. Mais vous allez m'éclairer.
|
| > Depuis quand la conversion entre octets / Ko / Mo / Go se fait en décalant
la
| > virgule sur la droite ?
|
| Depuis l'adoption de l'échelle décimale par la Commission des Poids et
| Mesures en 1790. J'ai bon ?

Ben non. La comversion qui nous concerne n'est pas décimale ! Mais bien comme je
l'ai écrite :

| > - 1 Go = 1024 Mo
| > - 1 Mo = 1024 Ko
| > - 1 Ko = 1024 octets
| > - 1 octet = 8 Bits
|
| Vérifier où ? Avez-vous une source *officielle* ?

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
pour une explication technique

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
tableau différenciant la taille approximative (comme vous) de la taille exacte
(comme moi)

http://www.linux-france.org/prj/jargonf/K/ko.html
pour une petite explication rapide du pourquoi

http://www.pckado.com/index_e-marketing.html
"Ko : Kilo-Octet. Soit 1024 octets, et non pas 1000.
Mo : Méga Octet. C'est-à-dire non pas un million d'octets, mais 1048000
et des poussières (1024*1024). Attention, certaines entreprises (les
fabricants de disques durs, par exemple) définissent le Mo comme 10
puissance 6 octets (1.000.000).
Go : Abrév. de giga-octet, ce qui représente UN PEU PLUS de un milliard
d'octets."

| Veuillez vérifier ceci de votre côté :
| 1 Gtruc = 1 000 Mtrucs
| 1 Mtruc = 1 000 ktrucs
| 1 ktruc = 1 000 trucs
| Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

C'est ce qu'on appelle un abus de langage pour les termes utilisés en
informatiques, vu que ce n'est pas une base décimale.

[...]
| A présent, si vous persistez à affirmer que la capacité réelle de vos
| disques est inférieure à celle annoncée, c'est que vous qualifiez leurs
| fabricants de menteurs.

Ce n'est pas impossible... Etant donné que pour simplifier les choses, ils
n'utilisent pas la conversion réelle, mais la conversion décimale qui n'a pas
lieu dans notre cas, je les traite effectivement de menteur.

| Personnellement, c'est plutôt l'affichage des systèmes d'exploitation et
| de certains logiciels utilitaires que je qualifie d'erroné.

Il faut bien trouver un responsable ! Mais il n'est pas là où vous l'indiquez
!!! Certain(e)s se fient à des vendeurs, d'autres à des données sûres.

Amicalement,

Gé.

"Ne pas avoir entendu parler d'une chose ne signifie pas que cette chose
n'existe pas".
--
Pour me répondre directement, sortez le mammouth.

Annie D.

22/07/2003 à 16:01

"Gé" wrote:

| > A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.
|
| Une petite question : comment le savez-vous ?

Peut-être parce que je lis les infos que mon ordi me donne, mais je les lis en
Go, pas en octets.

Voilà, c'est votre erreur. Le programme qui vous affiche ces tailles ne
fait pas la conversion correctement. Ce n'est pas sa faute, il a été
écrit comme ça par des informaticiens qui ne devaient pas connaître le
SI.

Chez moi, partition unique, 100 % de la capacité de mon DD,
j'ai :
- capacité totale : 19 994 050 560 octets / 18.6 Go
(et non 19.99 Go).

Vous ne trouvez pas ça bizarre, de lire côte à côte 20 milliards
d'octets et 18,6 giga-octets ? Moi ça m'aurait mis la puce à l'oreille.

| Vérifier où ? Avez-vous une source *officielle* ?

http://site.ifrance.com/pcupgrade/ko_mo_go.htm

Ah ouais, PC Upgrade, c'est vachement officiel comme source. Sans
blague, vous n'avez pas mieux ?

En passant, on dirait que l'auteur de la page est partisan de la théorie
du complot des fabricants voleurs d'octets. Encore un qui devait dormir
en cours de science.

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
tableau différenciant la taille approximative (comme vous) de la taille exacte
(comme moi)

C'est chez moi ou c'est le même lien ? Pas de tableau en vue.

http://www.linux-france.org/prj/jargonf/K/ko.html
pour une petite explication rapide du pourquoi

Ce n'est toujours pas officiel, mais au moins c'est honnête : la
description reconnaît que 1 ko = 1024 octets est une approximation
pratique, une entorse au SI.

http://www.pckado.com/index_e-marketing.html

Oh, encore une référence hautement officielle. Voyons...

"Ko : Kilo-Octet. Soit 1024 octets, et non pas 1000.

Mais je m'en moque du Ko. Le préfixe K n'est pas normalisé SI. Par
contre, si vous accordez crédit à ce site, vous n'avez pas pu manquer de
lire aussi

http://www.pckado.com/e-marketing/k/k.html
"En fait, ce préfixe est ambigü : il peut vouloir dire 1000 (unité SI)
ou 1024 (unité binaire : 2 puissance 10). On peut séparer les deux sens
en mettant « k » pour 1000 et « K » (la majuscule) pour « 1024 »"

http://www.pckado.com/e-marketing/k/kb.html
"Kilobits, c'est-à-dire 1 000 ou 1 024 bits." Vu la situation
embrouillée, ils ne se mouillent pas trop !

http://www.pckado.com/e-marketing/k/kilo-octet.html
"L'usage du préfixe « kilo » est abusif, un remplacement proposé est
kibi-octet."

Poussé par la curiosité, vous avez donc dans la foulée consulté sur ce
même site les définitions de kibi-octet, mebi-octets, gibi-octet.
"kibi-octet : 1024 octets. Néologisme proposé par l'IEC en remplacement
de kilo-octet, le préfixe « kilo » représentant 1000 et non pas 2
puissance 10."

| 1 Gtruc = 1 000 Mtrucs
| 1 Mtruc = 1 000 ktrucs
| 1 ktruc = 1 000 trucs

C'est ce qu'on appelle un abus de langage pour les termes utilisés en
informatiques,

Vous renversez la situation. C'est l'usage de ces préfixe en
informatique qui est un abus par approximation de leur définition.
Espérons que la tentative de nettoyage de tout ce foutoir par l'IEC
(organisme officiel) portera ses fruits.

vu que ce n'est pas une base décimale.

Ça ne veut rien dire, "ce n'est pas une base décimale". Dans la nature,
la seule base décimale existante c'est le nombre de doigts des deux
mains d'un humain moyen. On l'a choisie arbitrairement, c'est un choix
et on s'y tient. Les préfixes multiplicateurs sont définis sur cette
base décimale. Quand vous écrivez "20 giga-octets", le "20" est bien en
base décimale, n'est-ce pas ? Alors pourquoi le "giga" ne le serait-il
pas aussi ? Il faut être cohérent.

Tout ça parce qu'il y a longtemps les informaticiens se sont rendus
compte que 2^10 était proche de 1000, alors on s'est dit que remplacer
1024 par 1K ou 1k simplifierait l'écriture avec une bonne approximation
(2,4% d'erreur). Mais la différence a sérieusement commencé à se voir
quand on est passé au méga (5%), puis au giga (7%). Avec le téra qui
s'approche à grands pas, l'écart atteindra 10%...

"Gé" wrote:

| > A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.
|
| Une petite question : comment le savez-vous ?

Peut-être parce que je lis les infos que mon ordi me donne, mais je les lis en
Go, pas en octets.

Voilà, c'est votre erreur. Le programme qui vous affiche ces tailles ne
fait pas la conversion correctement. Ce n'est pas sa faute, il a été
écrit comme ça par des informaticiens qui ne devaient pas connaître le
SI.

Chez moi, partition unique, 100 % de la capacité de mon DD,
j'ai :
- capacité totale : 19 994 050 560 octets / 18.6 Go
(et non 19.99 Go).

Vous ne trouvez pas ça bizarre, de lire côte à côte 20 milliards
d'octets et 18,6 giga-octets ? Moi ça m'aurait mis la puce à l'oreille.

| Vérifier où ? Avez-vous une source *officielle* ?

http://site.ifrance.com/pcupgrade/ko_mo_go.htm

Ah ouais, PC Upgrade, c'est vachement officiel comme source. Sans
blague, vous n'avez pas mieux ?

En passant, on dirait que l'auteur de la page est partisan de la théorie
du complot des fabricants voleurs d'octets. Encore un qui devait dormir
en cours de science.

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
tableau différenciant la taille approximative (comme vous) de la taille exacte
(comme moi)

C'est chez moi ou c'est le même lien ? Pas de tableau en vue.

http://www.linux-france.org/prj/jargonf/K/ko.html
pour une petite explication rapide du pourquoi

Ce n'est toujours pas officiel, mais au moins c'est honnête : la
description reconnaît que 1 ko = 1024 octets est une approximation
pratique, une entorse au SI.

http://www.pckado.com/index_e-marketing.html

Oh, encore une référence hautement officielle. Voyons...

"Ko : Kilo-Octet. Soit 1024 octets, et non pas 1000.

Mais je m'en moque du Ko. Le préfixe K n'est pas normalisé SI. Par
contre, si vous accordez crédit à ce site, vous n'avez pas pu manquer de
lire aussi

http://www.pckado.com/e-marketing/k/k.html
"En fait, ce préfixe est ambigü : il peut vouloir dire 1000 (unité SI)
ou 1024 (unité binaire : 2 puissance 10). On peut séparer les deux sens
en mettant « k » pour 1000 et « K » (la majuscule) pour « 1024 »"

http://www.pckado.com/e-marketing/k/kb.html
"Kilobits, c'est-à-dire 1 000 ou 1 024 bits." Vu la situation
embrouillée, ils ne se mouillent pas trop !

http://www.pckado.com/e-marketing/k/kilo-octet.html
"L'usage du préfixe « kilo » est abusif, un remplacement proposé est
kibi-octet."

Poussé par la curiosité, vous avez donc dans la foulée consulté sur ce
même site les définitions de kibi-octet, mebi-octets, gibi-octet.
"kibi-octet : 1024 octets. Néologisme proposé par l'IEC en remplacement
de kilo-octet, le préfixe « kilo » représentant 1000 et non pas 2
puissance 10."

| 1 Gtruc = 1 000 Mtrucs
| 1 Mtruc = 1 000 ktrucs
| 1 ktruc = 1 000 trucs

C'est ce qu'on appelle un abus de langage pour les termes utilisés en
informatiques,

Vous renversez la situation. C'est l'usage de ces préfixe en
informatique qui est un abus par approximation de leur définition.
Espérons que la tentative de nettoyage de tout ce foutoir par l'IEC
(organisme officiel) portera ses fruits.

vu que ce n'est pas une base décimale.

Ça ne veut rien dire, "ce n'est pas une base décimale". Dans la nature,
la seule base décimale existante c'est le nombre de doigts des deux
mains d'un humain moyen. On l'a choisie arbitrairement, c'est un choix
et on s'y tient. Les préfixes multiplicateurs sont définis sur cette
base décimale. Quand vous écrivez "20 giga-octets", le "20" est bien en
base décimale, n'est-ce pas ? Alors pourquoi le "giga" ne le serait-il
pas aussi ? Il faut être cohérent.

Tout ça parce qu'il y a longtemps les informaticiens se sont rendus
compte que 2^10 était proche de 1000, alors on s'est dit que remplacer
1024 par 1K ou 1k simplifierait l'écriture avec une bonne approximation
(2,4% d'erreur). Mais la différence a sérieusement commencé à se voir
quand on est passé au méga (5%), puis au giga (7%). Avec le téra qui
s'approche à grands pas, l'écart atteindra 10%...

Vous avez filtré cet utilisateur ! Consultez son message

"Gé" wrote:

| > A titre d'info, mes 2 DD "20 Go" font effectivement 18.6 Go.
|
| Une petite question : comment le savez-vous ?

Peut-être parce que je lis les infos que mon ordi me donne, mais je les lis en
Go, pas en octets.

Voilà, c'est votre erreur. Le programme qui vous affiche ces tailles ne
fait pas la conversion correctement. Ce n'est pas sa faute, il a été
écrit comme ça par des informaticiens qui ne devaient pas connaître le
SI.

Chez moi, partition unique, 100 % de la capacité de mon DD,
j'ai :
- capacité totale : 19 994 050 560 octets / 18.6 Go
(et non 19.99 Go).

Vous ne trouvez pas ça bizarre, de lire côte à côte 20 milliards
d'octets et 18,6 giga-octets ? Moi ça m'aurait mis la puce à l'oreille.

| Vérifier où ? Avez-vous une source *officielle* ?

http://site.ifrance.com/pcupgrade/ko_mo_go.htm

Ah ouais, PC Upgrade, c'est vachement officiel comme source. Sans
blague, vous n'avez pas mieux ?

En passant, on dirait que l'auteur de la page est partisan de la théorie
du complot des fabricants voleurs d'octets. Encore un qui devait dormir
en cours de science.

http://site.ifrance.com/pcupgrade/ko_mo_go.htm
tableau différenciant la taille approximative (comme vous) de la taille exacte
(comme moi)

C'est chez moi ou c'est le même lien ? Pas de tableau en vue.

http://www.linux-france.org/prj/jargonf/K/ko.html
pour une petite explication rapide du pourquoi

Ce n'est toujours pas officiel, mais au moins c'est honnête : la
description reconnaît que 1 ko = 1024 octets est une approximation
pratique, une entorse au SI.

http://www.pckado.com/index_e-marketing.html

Oh, encore une référence hautement officielle. Voyons...

"Ko : Kilo-Octet. Soit 1024 octets, et non pas 1000.

Mais je m'en moque du Ko. Le préfixe K n'est pas normalisé SI. Par
contre, si vous accordez crédit à ce site, vous n'avez pas pu manquer de
lire aussi

http://www.pckado.com/e-marketing/k/k.html
"En fait, ce préfixe est ambigü : il peut vouloir dire 1000 (unité SI)
ou 1024 (unité binaire : 2 puissance 10). On peut séparer les deux sens
en mettant « k » pour 1000 et « K » (la majuscule) pour « 1024 »"

http://www.pckado.com/e-marketing/k/kb.html
"Kilobits, c'est-à-dire 1 000 ou 1 024 bits." Vu la situation
embrouillée, ils ne se mouillent pas trop !

http://www.pckado.com/e-marketing/k/kilo-octet.html
"L'usage du préfixe « kilo » est abusif, un remplacement proposé est
kibi-octet."

Poussé par la curiosité, vous avez donc dans la foulée consulté sur ce
même site les définitions de kibi-octet, mebi-octets, gibi-octet.
"kibi-octet : 1024 octets. Néologisme proposé par l'IEC en remplacement
de kilo-octet, le préfixe « kilo » représentant 1000 et non pas 2
puissance 10."

| 1 Gtruc = 1 000 Mtrucs
| 1 Mtruc = 1 000 ktrucs
| 1 ktruc = 1 000 trucs

C'est ce qu'on appelle un abus de langage pour les termes utilisés en
informatiques,

Vous renversez la situation. C'est l'usage de ces préfixe en
informatique qui est un abus par approximation de leur définition.
Espérons que la tentative de nettoyage de tout ce foutoir par l'IEC
(organisme officiel) portera ses fruits.

vu que ce n'est pas une base décimale.

Ça ne veut rien dire, "ce n'est pas une base décimale". Dans la nature,
la seule base décimale existante c'est le nombre de doigts des deux
mains d'un humain moyen. On l'a choisie arbitrairement, c'est un choix
et on s'y tient. Les préfixes multiplicateurs sont définis sur cette
base décimale. Quand vous écrivez "20 giga-octets", le "20" est bien en
base décimale, n'est-ce pas ? Alors pourquoi le "giga" ne le serait-il
pas aussi ? Il faut être cohérent.

Tout ça parce qu'il y a longtemps les informaticiens se sont rendus
compte que 2^10 était proche de 1000, alors on s'est dit que remplacer
1024 par 1K ou 1k simplifierait l'écriture avec une bonne approximation
(2,4% d'erreur). Mais la différence a sérieusement commencé à se voir
quand on est passé au méga (5%), puis au giga (7%). Avec le téra qui
s'approche à grands pas, l'écart atteindra 10%...

Annie D.

22/07/2003 à 16:36

Arnaud Debaene wrote:

1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

Pas en informatique, désolé :-)

Pourtant, l'informatique utilise à profusion les méga-hertz (10^6 Hz),
les kilo-bits par seconde (10^3 bits/s). Je ne fais pas d'informatique,
moi, et je préfère que les préfixe normalisés employés en informatique
aient la même valeur que partout ailleurs. L'informatique, village
gaulois qui résiste encore et toujours ?

Si tu veux la raison du pourquoi du comment,

Je connais, merci. Mais j'aime bien jouer aussi.

Dans l'absolu, tu as raison sauf que en pratique personne n'utilise
les termes exacts : Voir http://physics.nist.gov/cuu/Units/binary.html

Merci pour le lien vers cette page qui confirme tout ce que j'écris.

(le NIST, c'est assez officiel pour toi?

Ça ira.

Conclusion des courses, on ne devrait pas dire kilooctet mais
kibioctet, et tout à l'avenant, seulement PERSONNE ne connait ces
termes, et la pratique courante veut que 1 KO24 octets.

Et bien, il suffit de s'y mettre. Je commence dès aujourd'hui.

- pour les développeurs, 1KO = 2^10 octets parce que c'est la seule
façon logique de faire quand on travaille en binaire,

Le binaire est un prétexte. Qui travaille encore réellement en binaire ?
En tout cas pas l'utilisateur qui achète un disque dur et regarde la
taille de ses fichiers. Ceux qui ont besoin de travailler en binaire
utilisent du vrai binaire, ou de l'hexadécimal, pas un mélange de
chiffres décimaux et de préfixes binaires.

Une taille de disque dur, de fichier, n'a rien d'un nombre binaire et il
n'y a aucune justification à l'exprimer en puissance de 2. A l'heure où
les disques comptent des centaines de millions de secteurs, qui se
soucie que la taille élémentaire d'un secteur soit une petite puissance
de 2 à part ceux qui conçoivent les logiciels système ? La seule
exception est la capacité des composants de mémoire électronique (RAM,
Flash), qui par construction est une puissance de 2.

les fabricants de disques durs on pris la convention qui leur
permettent d'annoncer la plus grande capacité (et donc le plus grand
prix) pour un disque donné. Allez comprendre... :-)

Je peux comprendre aisément que le nombre résultant plus grand a dû
faciliter leur décision de rentrer dans le droit chemin et de se
conformer aux définitions des préfixes SI.

Mais tu peux penser ce que tu veux, ca m'étonnerait juste que ca
change quoi que ce soit à la pratique existante :-)

Je le sais. Il suffit de remplacer les K, M, G litigieux par Ki, Mi et
Gi et je ne dirai plus rien. Ce n'est pourtant pas compliqué.
J'essaie juste de réveiller quelques consciences endoctrinées par la
religion binaire. C'est avec des confusions de ce genre qu'on plante
l'ordinateur d'une sonde spatiale en route vers une planète lointaine.

Arnaud Debaene wrote:

1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

Pas en informatique, désolé :-)

Pourtant, l'informatique utilise à profusion les méga-hertz (10^6 Hz),
les kilo-bits par seconde (10^3 bits/s). Je ne fais pas d'informatique,
moi, et je préfère que les préfixe normalisés employés en informatique
aient la même valeur que partout ailleurs. L'informatique, village
gaulois qui résiste encore et toujours ?

Si tu veux la raison du pourquoi du comment,

Je connais, merci. Mais j'aime bien jouer aussi.

Dans l'absolu, tu as raison sauf que en pratique personne n'utilise
les termes exacts : Voir http://physics.nist.gov/cuu/Units/binary.html

Merci pour le lien vers cette page qui confirme tout ce que j'écris.

(le NIST, c'est assez officiel pour toi?

Ça ira.

Conclusion des courses, on ne devrait pas dire kilooctet mais
kibioctet, et tout à l'avenant, seulement PERSONNE ne connait ces
termes, et la pratique courante veut que 1 KO24 octets.

Et bien, il suffit de s'y mettre. Je commence dès aujourd'hui.

- pour les développeurs, 1KO = 2^10 octets parce que c'est la seule
façon logique de faire quand on travaille en binaire,

Le binaire est un prétexte. Qui travaille encore réellement en binaire ?
En tout cas pas l'utilisateur qui achète un disque dur et regarde la
taille de ses fichiers. Ceux qui ont besoin de travailler en binaire
utilisent du vrai binaire, ou de l'hexadécimal, pas un mélange de
chiffres décimaux et de préfixes binaires.

Une taille de disque dur, de fichier, n'a rien d'un nombre binaire et il
n'y a aucune justification à l'exprimer en puissance de 2. A l'heure où
les disques comptent des centaines de millions de secteurs, qui se
soucie que la taille élémentaire d'un secteur soit une petite puissance
de 2 à part ceux qui conçoivent les logiciels système ? La seule
exception est la capacité des composants de mémoire électronique (RAM,
Flash), qui par construction est une puissance de 2.

les fabricants de disques durs on pris la convention qui leur
permettent d'annoncer la plus grande capacité (et donc le plus grand
prix) pour un disque donné. Allez comprendre... :-)

Je peux comprendre aisément que le nombre résultant plus grand a dû
faciliter leur décision de rentrer dans le droit chemin et de se
conformer aux définitions des préfixes SI.

Mais tu peux penser ce que tu veux, ca m'étonnerait juste que ca
change quoi que ce soit à la pratique existante :-)

Je le sais. Il suffit de remplacer les K, M, G litigieux par Ki, Mi et
Gi et je ne dirai plus rien. Ce n'est pourtant pas compliqué.
J'essaie juste de réveiller quelques consciences endoctrinées par la
religion binaire. C'est avec des confusions de ce genre qu'on plante
l'ordinateur d'une sonde spatiale en route vers une planète lointaine.

Vous avez filtré cet utilisateur ! Consultez son message

Arnaud Debaene wrote:

1 Gtruc = 1 000 Mtrucs
1 Mtruc = 1 000 ktrucs
1 ktruc = 1 000 trucs
Vous pouvez remplacer "truc" par le symbole d'unité de votre choix.

Pas en informatique, désolé :-)

Pourtant, l'informatique utilise à profusion les méga-hertz (10^6 Hz),
les kilo-bits par seconde (10^3 bits/s). Je ne fais pas d'informatique,
moi, et je préfère que les préfixe normalisés employés en informatique
aient la même valeur que partout ailleurs. L'informatique, village
gaulois qui résiste encore et toujours ?

Si tu veux la raison du pourquoi du comment,

Je connais, merci. Mais j'aime bien jouer aussi.

Dans l'absolu, tu as raison sauf que en pratique personne n'utilise
les termes exacts : Voir http://physics.nist.gov/cuu/Units/binary.html

Merci pour le lien vers cette page qui confirme tout ce que j'écris.

(le NIST, c'est assez officiel pour toi?

Ça ira.

Conclusion des courses, on ne devrait pas dire kilooctet mais
kibioctet, et tout à l'avenant, seulement PERSONNE ne connait ces
termes, et la pratique courante veut que 1 KO24 octets.

Et bien, il suffit de s'y mettre. Je commence dès aujourd'hui.

- pour les développeurs, 1KO = 2^10 octets parce que c'est la seule
façon logique de faire quand on travaille en binaire,

Le binaire est un prétexte. Qui travaille encore réellement en binaire ?
En tout cas pas l'utilisateur qui achète un disque dur et regarde la
taille de ses fichiers. Ceux qui ont besoin de travailler en binaire
utilisent du vrai binaire, ou de l'hexadécimal, pas un mélange de
chiffres décimaux et de préfixes binaires.

Une taille de disque dur, de fichier, n'a rien d'un nombre binaire et il
n'y a aucune justification à l'exprimer en puissance de 2. A l'heure où
les disques comptent des centaines de millions de secteurs, qui se
soucie que la taille élémentaire d'un secteur soit une petite puissance
de 2 à part ceux qui conçoivent les logiciels système ? La seule
exception est la capacité des composants de mémoire électronique (RAM,
Flash), qui par construction est une puissance de 2.

les fabricants de disques durs on pris la convention qui leur
permettent d'annoncer la plus grande capacité (et donc le plus grand
prix) pour un disque donné. Allez comprendre... :-)

Je peux comprendre aisément que le nombre résultant plus grand a dû
faciliter leur décision de rentrer dans le droit chemin et de se
conformer aux définitions des préfixes SI.

Mais tu peux penser ce que tu veux, ca m'étonnerait juste que ca
change quoi que ce soit à la pratique existante :-)

Je le sais. Il suffit de remplacer les K, M, G litigieux par Ki, Mi et
Gi et je ne dirai plus rien. Ce n'est pourtant pas compliqué.
J'essaie juste de réveiller quelques consciences endoctrinées par la
religion binaire. C'est avec des confusions de ce genre qu'on plante
l'ordinateur d'une sonde spatiale en route vers une planète lointaine.

Norbert

22/07/2003 à 17:26

Annie D. wrote:

Pourtant, l'informatique utilise à profusion les méga-hertz (10^6 Hz),
les kilo-bits par seconde (10^3 bits/s). Je ne fais pas
d'informatique, moi,

Ca n'était pas la peine de le préciser, ça se voit de suite.

[...]
Le binaire est un prétexte. Qui travaille encore réellement en binaire ?
En tout cas pas l'utilisateur qui achète un disque dur et regarde la
taille de ses fichiers. Ceux qui ont besoin de travailler en binaire
utilisent du vrai binaire, ou de l'hexadécimal, pas un mélange de
chiffres décimaux et de préfixes binaires.

Ben justement, si tu travaillais dans l'informatique, tu saurais qu'on
mélange joyeusement le binaire, l'hexa et le décimal.
Je ne dis pas que c'est bien, je dis simplement que la situation est comme
ça, et je doute qu'elle change de sitot.

--
à bientot
================================= les secrets de l'univers http://nrumiano.free.fr
un atlas de l'univers http://atunivers.free.fr
images du ciel http://images.ciel.free.fr
==================================

Remy Moulin

24/07/2003 à 23:26

Remy Moulin wrote:
...

"4 Go informatiques" = "1 Mmachin" (Limite d'adressage des
processeurs '32 bits'; limite de gestion de la FAT 32
...

Gros gourrage détecté : il faut lire ici Limite de FAT 16 !

La FAT 32 permet de gérer des disques bien plus gros que 4Go !!!

Mes plus plates excuses pour la confusion...

--
Herm

Remy Moulin

25/07/2003 à 20:33

Annie D. wrote:

Naturel pour qui ? Pour une poignée de développeurs "bas niveau"
...

Bonsoir,

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !); vous ne vous offusquerez plus de voir que votre fichier occupant
un cluser de 4,096 Ko quand vous avez des blocs de stockage de "4Ko"; etc,
etc...

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule... Mais sûrement me
gourre-je...

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 ?

Les programmeurs de Goret, non, effectivement, ils s'en foutent.

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), qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...

La différence entre un programme bien fait, court, rapide, efficace, et un
gros machin qui de plus, souvent, plante (parce que ce type programmeur de
gorêt ne tique généralement pas à l'idée de faire des lectures/écritures
avec des pointeurs nuls ou hors-zone...).

Mais je m'égarre...

Sans compter que la représentation avec préfixe binaire complique
inutilement :

dès qu'il s'agit de convertir des "KB" en "MB" (on préfèrera KiB et MiB)
ou de les ajouter, c'est le
casse-tête et il faut sortir la calculatrice. Trouvez-vous cela
naturel ? Moi non.

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.

Une bonne unité de mesure doit être choisie en rapport à ce que l'on mesure.
Il est des unités de stockage informatique nettement plus adaptés !

Par exemple : cette unité là, appelons-là "truc", où le K vaudrait 1000 ...
en hexadécimal !

On obtient, certes, 4096 en conversion décimale, mais restons en
hexadécimal.

Là, on a 1 M = 1000 K = 1000² unités. Chouette, non ?

Mettons une barette mémoire de "256Mo informatiques", soit 268435456(d)
octets ou 10 000 000 (h) octets, soit "10 Mtrucs". Une barette de "512Mo
informatiques" ? Ça fait bien "20 Mtrucs". Naturel, cette façon de compter.

Mais par contre, cette unité produit des nombres qui peuvent contienir les
lettres A à F. Déroutant pour le badeau moyen.

De plus, cette puissance de 2 est bâtarde ! 4096 = 2^12, et 12 n'est pas un
nombre bien commode à gérer pour un ordinateur...

Ce qu'il faudrait, c'est un nombre étant puissance de 2 'noble' pour
l'ordinateur. Pourquoi pas 65536 (soit 2^16) ? En hexadécimal, ça se
traduit par 10 000. Super unités, mais là, c'est l'humain qui est dérouté :
des K valant 10 000 unités.

Appelons-la "machin".

Les unités informatiques se traduisent bien par contre (et l'on comprends
pourquoi certains nombres sont "magiques" au point de vue informatique) :

65536 octets = "64 Ko informatiques" = "1 Kmachin" (RAM des machines
anciennes; limite d'adressage en pointeurs 16 bits).

"256Mo informatiques" = "1000 Kmachin" ou "0,1 Mmachin" (Barette mémoire
courante)

-----(correction)

"4 Go informatiques" = "1 Mmachin" (Limite d'adressage des processeurs '32
bits'; limite de gestion de la FAT 16 (sous windows NT, parce que avec
Win95-Me, seuls 15 bits sont exploitables, limite à "2Go" ou "0,5 Mmachin"))

-----(correction)

Le malheur, c'est qu'il n'existe pas de terrain d'entente homme-machine
là-dessus. A force de voir l'informatique, on en vient à découvrir que
certains nombres sont plus fréquents en informatique, mais sans pouvoir en
comprendre la cause. Ce n'est que lorsque l'on prends une unité qui se
rapproche du fonctionnement binaire de "la chose" que l'on commence à
comprendre le pourquoi du comment.

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" : derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

Cf taille des clusters de "4Ko", courant en FAT32, que j'ai développé plus
haut.

L'affichage est destiné à l'utilisateur humain,
et pour celui-ci, ce sont les puissance de 10 qui sont naturelles et
qu'il peut mentalement manipuler en ajoutant des zéros ou en
déplaçant la virgule.

Ces nombres ne sont pas là pour être manipulés par des humains. Ils sont là
pour exprimer, dans une unité de mesure pas trop éloignée de ce les humains
on l'habitude de voir, la taille des objets manipulés.

Ce qui n'est pas évident au premier abord, c'est que cela ne concerne que
(et exclusivement) les capacités de stockages !

Toutes les autres unités, du MHz au kbit/s sont des unités purement
décimales à base 1000.

Pour le MHz, c'est que très simplement, l'oscillation d'un quartz dans une
horloge est un phénomène physique qui n'a strictement rien en commun avec
l'informatique. Et ce n'est pas parce que l'informatique est utilisatrice de
ceci que cela va changer quoi que ce soit. (Les Volts n'ont pas changé
d'ordre physique depuis l'informatique non plus, et pourtant, c'est le même
cas de figure).

Pour le kbit/s, c'est un peu plus fin à comprendre. Ce qui est mesuré là, ce
n'est pas un espace de stockage dans une matrice avec des adresses x & y
exprimés en nombres binaires (c'est à dire, une mémoire RAM). Non, non.

Ce qui est mesuré, c'est la vitesse de déplacement d'un objet. Ici ce sont
des bits qui sont échangés, mais ça seraient des patates, ou des
ratons-laveurs, le résultat serait strictement la même chose.

Et la vitesse de déplacement d'une entité n'a rien à voir avec
l'informatique. C'est une mesure physique, donc exprimée en base 1000. Et
que ce soit des unités binaires -des bits- ou autres, ça ne change rien.

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), et que
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).

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,
manipulants déjà avec difficultées les différents préfixes courant !

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éelement
exploitable bien moindre de ce à quoi l'on pouvait s'attendre.

Bien que le nombre en base 1000 et le nombre en base 1024 désignent le même
objet, c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seul fin marketeuse en plus !

Ç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" selon ses critères que l'on
peut imaginer comme étant tout sauf honnêtes, objectives et loyales.

Ce sont ces gens-là qui trompent leurs clients.

En conclusion ? On n'a pas fini de voir des Ko valant 1024 !

--
Herm
Mes 0,02 bits apportés au sujet...

Annie D. wrote:

Naturel pour qui ? Pour une poignée de développeurs "bas niveau"
...

Bonsoir,

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !); vous ne vous offusquerez plus de voir que votre fichier occupant
un cluser de 4,096 Ko quand vous avez des blocs de stockage de "4Ko"; etc,
etc...

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule... Mais sûrement me
gourre-je...

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 ?

Les programmeurs de Goret, non, effectivement, ils s'en foutent.

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), qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...

La différence entre un programme bien fait, court, rapide, efficace, et un
gros machin qui de plus, souvent, plante (parce que ce type programmeur de
gorêt ne tique généralement pas à l'idée de faire des lectures/écritures
avec des pointeurs nuls ou hors-zone...).

Mais je m'égarre...

Sans compter que la représentation avec préfixe binaire complique
inutilement :

dès qu'il s'agit de convertir des "KB" en "MB" (on préfèrera KiB et MiB)
ou de les ajouter, c'est le
casse-tête et il faut sortir la calculatrice. Trouvez-vous cela
naturel ? Moi non.

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.

Une bonne unité de mesure doit être choisie en rapport à ce que l'on mesure.
Il est des unités de stockage informatique nettement plus adaptés !

Par exemple : cette unité là, appelons-là "truc", où le K vaudrait 1000 ...
en hexadécimal !

On obtient, certes, 4096 en conversion décimale, mais restons en
hexadécimal.

Là, on a 1 M = 1000 K = 1000² unités. Chouette, non ?

Mettons une barette mémoire de "256Mo informatiques", soit 268435456(d)
octets ou 10 000 000 (h) octets, soit "10 Mtrucs". Une barette de "512Mo
informatiques" ? Ça fait bien "20 Mtrucs". Naturel, cette façon de compter.

Mais par contre, cette unité produit des nombres qui peuvent contienir les
lettres A à F. Déroutant pour le badeau moyen.

De plus, cette puissance de 2 est bâtarde ! 4096 = 2^12, et 12 n'est pas un
nombre bien commode à gérer pour un ordinateur...

Ce qu'il faudrait, c'est un nombre étant puissance de 2 'noble' pour
l'ordinateur. Pourquoi pas 65536 (soit 2^16) ? En hexadécimal, ça se
traduit par 10 000. Super unités, mais là, c'est l'humain qui est dérouté :
des K valant 10 000 unités.

Appelons-la "machin".

Les unités informatiques se traduisent bien par contre (et l'on comprends
pourquoi certains nombres sont "magiques" au point de vue informatique) :

65536 octets = "64 Ko informatiques" = "1 Kmachin" (RAM des machines
anciennes; limite d'adressage en pointeurs 16 bits).

"256Mo informatiques" = "1000 Kmachin" ou "0,1 Mmachin" (Barette mémoire
courante)

-----(correction)

"4 Go informatiques" = "1 Mmachin" (Limite d'adressage des processeurs '32
bits'; limite de gestion de la FAT 16 (sous windows NT, parce que avec
Win95-Me, seuls 15 bits sont exploitables, limite à "2Go" ou "0,5 Mmachin"))

-----(correction)

Le malheur, c'est qu'il n'existe pas de terrain d'entente homme-machine
là-dessus. A force de voir l'informatique, on en vient à découvrir que
certains nombres sont plus fréquents en informatique, mais sans pouvoir en
comprendre la cause. Ce n'est que lorsque l'on prends une unité qui se
rapproche du fonctionnement binaire de "la chose" que l'on commence à
comprendre le pourquoi du comment.

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" : derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

Cf taille des clusters de "4Ko", courant en FAT32, que j'ai développé plus
haut.

L'affichage est destiné à l'utilisateur humain,
et pour celui-ci, ce sont les puissance de 10 qui sont naturelles et
qu'il peut mentalement manipuler en ajoutant des zéros ou en
déplaçant la virgule.

Ces nombres ne sont pas là pour être manipulés par des humains. Ils sont là
pour exprimer, dans une unité de mesure pas trop éloignée de ce les humains
on l'habitude de voir, la taille des objets manipulés.

Ce qui n'est pas évident au premier abord, c'est que cela ne concerne que
(et exclusivement) les capacités de stockages !

Toutes les autres unités, du MHz au kbit/s sont des unités purement
décimales à base 1000.

Pour le MHz, c'est que très simplement, l'oscillation d'un quartz dans une
horloge est un phénomène physique qui n'a strictement rien en commun avec
l'informatique. Et ce n'est pas parce que l'informatique est utilisatrice de
ceci que cela va changer quoi que ce soit. (Les Volts n'ont pas changé
d'ordre physique depuis l'informatique non plus, et pourtant, c'est le même
cas de figure).

Pour le kbit/s, c'est un peu plus fin à comprendre. Ce qui est mesuré là, ce
n'est pas un espace de stockage dans une matrice avec des adresses x & y
exprimés en nombres binaires (c'est à dire, une mémoire RAM). Non, non.

Ce qui est mesuré, c'est la vitesse de déplacement d'un objet. Ici ce sont
des bits qui sont échangés, mais ça seraient des patates, ou des
ratons-laveurs, le résultat serait strictement la même chose.

Et la vitesse de déplacement d'une entité n'a rien à voir avec
l'informatique. C'est une mesure physique, donc exprimée en base 1000. Et
que ce soit des unités binaires -des bits- ou autres, ça ne change rien.

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), et que
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).

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,
manipulants déjà avec difficultées les différents préfixes courant !

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éelement
exploitable bien moindre de ce à quoi l'on pouvait s'attendre.

Bien que le nombre en base 1000 et le nombre en base 1024 désignent le même
objet, c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seul fin marketeuse en plus !

Ç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" selon ses critères que l'on
peut imaginer comme étant tout sauf honnêtes, objectives et loyales.

Ce sont ces gens-là qui trompent leurs clients.

En conclusion ? On n'a pas fini de voir des Ko valant 1024 !

--
Herm
Mes 0,02 bits apportés au sujet...

Vous avez filtré cet utilisateur ! Consultez son message

Annie D. wrote:

Naturel pour qui ? Pour une poignée de développeurs "bas niveau"
...

Bonsoir,

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !); vous ne vous offusquerez plus de voir que votre fichier occupant
un cluser de 4,096 Ko quand vous avez des blocs de stockage de "4Ko"; etc,
etc...

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule... Mais sûrement me
gourre-je...

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 ?

Les programmeurs de Goret, non, effectivement, ils s'en foutent.

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), qu'un tableau de 65536 entrées est gérable plus
rapidement (parce que l'on peut utiliser des pointeurs 16 bits), ...

La différence entre un programme bien fait, court, rapide, efficace, et un
gros machin qui de plus, souvent, plante (parce que ce type programmeur de
gorêt ne tique généralement pas à l'idée de faire des lectures/écritures
avec des pointeurs nuls ou hors-zone...).

Mais je m'égarre...

Sans compter que la représentation avec préfixe binaire complique
inutilement :

dès qu'il s'agit de convertir des "KB" en "MB" (on préfèrera KiB et MiB)
ou de les ajouter, c'est le
casse-tête et il faut sortir la calculatrice. Trouvez-vous cela
naturel ? Moi non.

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.

Une bonne unité de mesure doit être choisie en rapport à ce que l'on mesure.
Il est des unités de stockage informatique nettement plus adaptés !

Par exemple : cette unité là, appelons-là "truc", où le K vaudrait 1000 ...
en hexadécimal !

On obtient, certes, 4096 en conversion décimale, mais restons en
hexadécimal.

Là, on a 1 M = 1000 K = 1000² unités. Chouette, non ?

Mettons une barette mémoire de "256Mo informatiques", soit 268435456(d)
octets ou 10 000 000 (h) octets, soit "10 Mtrucs". Une barette de "512Mo
informatiques" ? Ça fait bien "20 Mtrucs". Naturel, cette façon de compter.

Mais par contre, cette unité produit des nombres qui peuvent contienir les
lettres A à F. Déroutant pour le badeau moyen.

De plus, cette puissance de 2 est bâtarde ! 4096 = 2^12, et 12 n'est pas un
nombre bien commode à gérer pour un ordinateur...

Ce qu'il faudrait, c'est un nombre étant puissance de 2 'noble' pour
l'ordinateur. Pourquoi pas 65536 (soit 2^16) ? En hexadécimal, ça se
traduit par 10 000. Super unités, mais là, c'est l'humain qui est dérouté :
des K valant 10 000 unités.

Appelons-la "machin".

Les unités informatiques se traduisent bien par contre (et l'on comprends
pourquoi certains nombres sont "magiques" au point de vue informatique) :

65536 octets = "64 Ko informatiques" = "1 Kmachin" (RAM des machines
anciennes; limite d'adressage en pointeurs 16 bits).

"256Mo informatiques" = "1000 Kmachin" ou "0,1 Mmachin" (Barette mémoire
courante)

-----(correction)

"4 Go informatiques" = "1 Mmachin" (Limite d'adressage des processeurs '32
bits'; limite de gestion de la FAT 16 (sous windows NT, parce que avec
Win95-Me, seuls 15 bits sont exploitables, limite à "2Go" ou "0,5 Mmachin"))

-----(correction)

Le malheur, c'est qu'il n'existe pas de terrain d'entente homme-machine
là-dessus. A force de voir l'informatique, on en vient à découvrir que
certains nombres sont plus fréquents en informatique, mais sans pouvoir en
comprendre la cause. Ce n'est que lorsque l'on prends une unité qui se
rapproche du fonctionnement binaire de "la chose" que l'on commence à
comprendre le pourquoi du comment.

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" : derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

Cf taille des clusters de "4Ko", courant en FAT32, que j'ai développé plus
haut.

L'affichage est destiné à l'utilisateur humain,
et pour celui-ci, ce sont les puissance de 10 qui sont naturelles et
qu'il peut mentalement manipuler en ajoutant des zéros ou en
déplaçant la virgule.

Ces nombres ne sont pas là pour être manipulés par des humains. Ils sont là
pour exprimer, dans une unité de mesure pas trop éloignée de ce les humains
on l'habitude de voir, la taille des objets manipulés.

Ce qui n'est pas évident au premier abord, c'est que cela ne concerne que
(et exclusivement) les capacités de stockages !

Toutes les autres unités, du MHz au kbit/s sont des unités purement
décimales à base 1000.

Pour le MHz, c'est que très simplement, l'oscillation d'un quartz dans une
horloge est un phénomène physique qui n'a strictement rien en commun avec
l'informatique. Et ce n'est pas parce que l'informatique est utilisatrice de
ceci que cela va changer quoi que ce soit. (Les Volts n'ont pas changé
d'ordre physique depuis l'informatique non plus, et pourtant, c'est le même
cas de figure).

Pour le kbit/s, c'est un peu plus fin à comprendre. Ce qui est mesuré là, ce
n'est pas un espace de stockage dans une matrice avec des adresses x & y
exprimés en nombres binaires (c'est à dire, une mémoire RAM). Non, non.

Ce qui est mesuré, c'est la vitesse de déplacement d'un objet. Ici ce sont
des bits qui sont échangés, mais ça seraient des patates, ou des
ratons-laveurs, le résultat serait strictement la même chose.

Et la vitesse de déplacement d'une entité n'a rien à voir avec
l'informatique. C'est une mesure physique, donc exprimée en base 1000. Et
que ce soit des unités binaires -des bits- ou autres, ça ne change rien.

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), et que
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).

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,
manipulants déjà avec difficultées les différents préfixes courant !

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éelement
exploitable bien moindre de ce à quoi l'on pouvait s'attendre.

Bien que le nombre en base 1000 et le nombre en base 1024 désignent le même
objet, c'est frustrant de constater que seuls, ces industriels n'utilisent
pas l'unité informatique, et à seul fin marketeuse en plus !

Ç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" selon ses critères que l'on
peut imaginer comme étant tout sauf honnêtes, objectives et loyales.

Ce sont ces gens-là qui trompent leurs clients.

En conclusion ? On n'a pas fini de voir des Ko valant 1024 !

--
Herm
Mes 0,02 bits apportés au sujet...

Annie D.

26/07/2003 à 00:41

Remy Moulin wrote:

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Pour le peu qu'il y a, ça ne me chagrine pas.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !);

J'ai admis l'exception pour les RAM dont la taille est par construction
une puissance de 2. Il suffit alors d'employer le bon préfixe pour
éviter toute ambiguïté : 256 MiB.

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule.

Je vous concède ce point. A condition que les nombres entiers ne
comportent pas plus de 4 ou 5 chiffres. C'est d'ailleurs l'utilité des
préfixes de limiter le nombre de chiffres significatifs des nombres.

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 ?

[...]

Mais je m'égare...

J'opine. Vous vous égarez.

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>

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" :
derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

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.

L'affichage est destiné à l'utilisateur humain,

Ces nombres ne sont pas là pour être manipulés par des humains.

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 ?

<snip la physique>

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 !

--
Evitez la confusion entre les préfixes SI et les préfixe binaires
http://physics.nist.gov/cuu/Units/binary.html
1 G = 1 000 M = 1 000 000 k = 1 000 000 000
1 Gi = 1 024 Mi = 1 048 576 Ki = 1 073 741 824

Remy Moulin wrote:

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Pour le peu qu'il y a, ça ne me chagrine pas.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !);

J'ai admis l'exception pour les RAM dont la taille est par construction
une puissance de 2. Il suffit alors d'employer le bon préfixe pour
éviter toute ambiguïté : 256 MiB.

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule.

Je vous concède ce point. A condition que les nombres entiers ne
comportent pas plus de 4 ou 5 chiffres. C'est d'ailleurs l'utilité des
préfixes de limiter le nombre de chiffres significatifs des nombres.

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 ?

[...]

Mais je m'égare...

J'opine. Vous vous égarez.

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>

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" :
derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

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.

L'affichage est destiné à l'utilisateur humain,

Ces nombres ne sont pas là pour être manipulés par des humains.

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 ?

<snip la physique>

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 !

--
Evitez la confusion entre les préfixes SI et les préfixe binaires
http://physics.nist.gov/cuu/Units/binary.html
1 G = 1 000 M = 1 000 000 k = 1 000 000 000
1 Gi = 1 024 Mi = 1 048 576 Ki = 1 073 741 824

Vous avez filtré cet utilisateur ! Consultez son message

Remy Moulin wrote:

Bon, et bien alors, plein de choses "qui tombaient juste" ne le seront plus.

Pour le peu qu'il y a, ça ne me chagrine pas.

Vous ferez attention à bien commander des barettes de mémoire de 268,435456
Mo à la place des "256Mo" (merci de ne pas arrondir, ou vous ne tombez plus
juste !);

J'ai admis l'exception pour les RAM dont la taille est par construction
une puissance de 2. Il suffit alors d'employer le bon préfixe pour
éviter toute ambiguïté : 256 MiB.

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.

Et il me semblait justement que l'esprit humain manipulait bien plus
aisément les nombres entiers que ceux à virgule.

Je vous concède ce point. A condition que les nombres entiers ne
comportent pas plus de 4 ou 5 chiffres. C'est d'ailleurs l'utilité des
préfixes de limiter le nombre de chiffres significatifs des nombres.

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 ?

[...]

Mais je m'égare...

J'opine. Vous vous égarez.

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>

En conséquence, je ne vois pas l'intérêt pratique, thérorique,
supposé, d'afficher des tailles de disques, de fichiers, d'occupation
mémoire, etc. avec des préfixes binaires alors qu'elles n'ont pas de
lien avec des puissances de 2.

Mais, pardi, parce que tout ce qui est stockage pour un ordinateur est lié à
des unités qui s'expriment en puissance de 2 !!! Depuis la "FAT 16" à "NTFS"
en passant par la "FAT 32" :
derrière ces noms barbares se cachent des
méthodes de découpage d'une zone de stockage (disque dur, lecteur ZIP, ...)
en morceaux exploitables par un système d'exploitation.

Traduits en unités purement décimales, on se retrouve avec des nombres à
virgule !

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.

L'affichage est destiné à l'utilisateur humain,

Ces nombres ne sont pas là pour être manipulés par des humains.

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 ?

<snip la physique>

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 !

--
Evitez la confusion entre les préfixes SI et les préfixe binaires
http://physics.nist.gov/cuu/Units/binary.html
1 G = 1 000 M = 1 000 000 k = 1 000 000 000
1 Gi = 1 024 Mi = 1 048 576 Ki = 1 073 741 824

Norbert

26/07/2003 à 09:30

Annie D. wrote:

<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>

Parce que vous croyez que tous les programmeurs du monde écrivent du C++ qui
tourne sur des Pentium à 4 GHz ?

En conclusion ? On n'a pas fini de voir des Ko valant 1024 !

Je n'ai donc pas fini d'afficher ma signature !

--
Evitez la confusion entre les préfixes SI et les préfixe binaires
http://physics.nist.gov/cuu/Units/binary.html
1 G = 1 000 M = 1 000 000 k = 1 000 000 000
1 Gi = 1 024 Mi = 1 048 576 Ki = 1 073 741 824

C'est bien d'inventer un nouveau système d'unités. Il va juste falloir
convaincre quelques milliards d'utilisateurs de l'utiliser :)

--
à bientot
================================= les secrets de l'univers http://nrumiano.free.fr
un atlas de l'univers http://atunivers.free.fr
images du ciel http://images.ciel.free.fr
==================================

A l'aide S.V.P

10 réponses

Veuillez sélectionner un problème