Pourquoi les ordinateurs comptent-ils à partir de zéro?

Comme l'ont déjà dit d'autres, les ordinateurs ne commencent pas à compter à partir de zéro.

Certains langages commencent à l'index 0. L'indexation à partir de 0 présente deux principaux avantages :

1. Cela se convertit en langage d'assemblage de manière naturelle car cela peut être interprété comme un décalage par rapport à un pointeur vers la première position.

2. Vous n'obtenez pas de situations étranges lorsque vous voulez des nombres négatifs. Combien d'années entre 1 avant J.-C. et 1 après J.-C. ? Aucune. Car bien que l'avant J.-C. soit effectivement des dates négatives, il n'y a pas d'année zéro. S'il y avait eu une année 0 après J.-C., il n'y aurait eu aucun problème ici. On retrouve le même problème un peu partout en science où les gens ont naïvement défini le premier élément d'un ensemble comme étant +1.

Le comptage commence naturellement à zéro

Voici l'algorithme pour compter les pommes dans un panier :

comptage := 0

pour chaque pomme dans le panier
   comptage := comptage + 1

Après l'exécution du code ci-dessus, comptage contient le nombre de pommes. Il peut être zéro, car les paniers peuvent être vides.

Si vous n'utilisez pas votre carte de crédit pendant un mois entier, recevez-vous une facture d'un dollar ? Ou d'un centime ?

Lorsque vous remettez à zéro le compteur kilométrique de votre voiture, passe-t-il à 0001 ou à 0000 ?

Les tableaux peuvent fournir plusieurs vues des mêmes données

Considérez un tableau de structures de 32 bits d, composées chacune de mots de 16 bits w. Chaque mot est constitué de deux octets de 8 bits b. Sous l'indexation à zéro, la superposition est très pratique :

d: |   0   |   1   |
w: | 0 | 1 | 2 | 3 |
b: |0|1|2|3|4|5|6|7|

L'objet de 32 bits d[1] se trouve à l'adresse du mot w[2], ce qui est facilement calculé en multipliant l'index par 2, qui est le rapport entre les tailles des objets de 32 et 16 bits. En outre, en adressage par octet, c'est b[4].

Cela fonctionne car zéro est zéro, dans chaque unité de mesure : l'octet, le mot, le double mot, etc.

Regardez le diagramme ci-dessus : il ressemble beaucoup à une règle, où les conversions d'unités sont intuitives.

Avec l'indexation à un, cela casse :

d: |   1   |   2   |
w: | 1 | 2 | 3 | 4 |
b: |1|2|3|4|5|6|7|8|

Maintenant, nous ne pouvons pas simplement multiplier l'index de d par 2 pour obtenir l'index de w, ou par 4 pour obtenir l'index de b. La conversion entre les unités devient maladroite. Par exemple, pour passer de d[2] à b[4], nous devons calculer ((2 - 1) * 4) + 1 = 5.

Nous devons soustraire ce satané 1 de biais dans les unités de d, puis effectuer l'échelle dans le système de coordonnées naturel à zéro, et ensuite ajouter de nouveau le satané 1 dans les unités de b. Notez que ce n'est pas le même 1 ! Nous soustrayons la largeur d'un double mot, mais ajoutons ensuite celle d'un octet.

La conversion entre différentes vues des données devient quelque chose comme la conversion Celsius-Fahrenheit.

Ceux qui disent que les tableaux à base un sont faciles à manipuler au niveau de l'implémentation, car il suffit d'une simple soustraction de 1, se trompent, et vous trompent. Cela est vrai seulement si nous ne faisons pas de calculs d'échelle entre différents types de données. De tels calculs se produisent dans tout programme qui a une vue flexible sur les données (par exemple, un tableau multidimensionnel également consulté comme un tableau unidimensionnel) ou qui manipule le stockage : par exemple, un allocateur de mémoire, un système de fichiers, ou une bibliothèque de tampon d'image vidéo.

Minimiser les chiffres

Dans n'importe quelle base, si nous voulons utiliser le moins de chiffres pour implémenter une plage de valeurs qui est une puissance de cette base, nous devons commencer à zéro. Par exemple, en base dix, trois chiffres suffisent pour nous donner mille valeurs distinctes de 0 à 999. Si nous commençons à 1, nous dépassons juste d'une valeur, et nous avons besoin de quatre chiffres.

C'est important en informatique, car le nombre de chiffres en binaire se traduit par des lignes d'adresse matérielles. Par exemple, une puce ROM avec 256 mots peut être adressée de 0 à 255, ce qui nécessite 8 bits : 00000000 à 11111111. Si elle est adressée de 1 à 256, alors neuf bits sont nécessaires. Nous devons ajouter de manière gaspilleuse une trace d'adresse supplémentaire au circuit imprimé ou au circuit intégré. Ainsi, ce qui se passerait en pratique serait probablement que 0 serait simplement appelé 1 au niveau de l'API logiciel pour accéder à cette puce. Une demande de mot 1 mettrait en fait 00000000 sur le bus d'adresse à 8 bits. Ou alors, une demande pour 1 serait traduite en adresse 00000001, comme attendu, mais une demande pour 256 serait mappée sur l'adresse à 8 bits inutilisée 00000000 au lieu de l'adresse à 9 bits 100000000. Ces astuces bidouillées et mordues par le sac sont vraiment des solutions à la recherche d'un problème, et elles sont entièrement évitées en utilisant systématiquement de 0 à 255 au niveau du matériel, dans le logiciel et dans toutes les interfaces utilisateur et documentations.

Les déplacements à base un sont fondamentalement stupides

Considérons la théorie musicale occidentale par exemple. Nous avons des échelles diatoniques avec sept notes, mais nous appelons l'espace qu'elles couvrent une octave ! L'inversion des intervalles suit ensuite la règle du neuf : par exemple l'inversion d'une tierce est une sixte (on soustrait trois de neuf). Ainsi, trois nombres différents sont en jeu pour quelque chose de si simple : sept (notes dans une échelle), huit (octave) et neuf (soustraction pour inverser).

Si sept notes formaient une septième ou une huitième, et que les intervalles étaient à base zéro, alors nous soustrairions de sept pour inverser. Tout serait basé sur sept.

De plus, les intervalles pourraient être facilement empilés. Dans le système actuel, si nous sautons d'une cinquième puis d'une quarte à nouveau, puis d'une tierce, nous ne pouvons pas simplement les ajouter. L'intervalle résultant est de deux de moins. Ce n'est pas une douzième, mais en réalité une dixième ! À chaque étape, nous devons soustraire un. Monter d'une cinquième puis d'une quarte n'est pas une neuvième, mais seulement une octave.

Dans un système musical conçu de manière saine, nous pourrions simplement ajouter des intervalles pour déterminer les sauts résultants. Une séquence de notes qui commence et se termine sur la même note aurait alors une propriété similaire à la loi de tension autour d'un circuit : tous les intervalles s'ajouteraient à zéro.

La théorie musicale et l'écriture sont désespérément dépassées. La plupart d'entre elles n'ont pas changé depuis l'époque où la composition se faisait à la plume à la lueur d'une chandelle.

Les systèmes à base un confondent les mêmes personnes qui ne peuvent pas gérer les tableaux à zéro

Lorsque l'année 2000 est arrivée, beaucoup de gens étaient confus sur pourquoi le nouveau millénaire n'avait pas encore commencé. Ceux qui faisaient remarquer qu'il ne commencerait pas avant 2001 étaient considérés comme des rabat-joies et des ringards. Après tout, vous avez vingt ans lorsque vous avez vingt ans, n'est-ce pas ? Pas quand vous en avez vingt-et-un. Si vous pensiez que le millénaire avait commencé le 1er janvier 2000, alors vous n'avez aucun droit de vous plaindre des tableaux à zéro dans n'importe quel langage de programmation. Ils fonctionnent exactement comme vous le souhaitez. (Mais oui, les partisans des déplacements et tableaux à base un sont des ringards et des rabat-joies. Les siècles devraient commencer les années en XX00, et les millénaires les années en X000.)

Les calendriers sont stupides, mais au moins l'heure de la journée est à base zéro

Chaque nouvelle minute sur votre montre commence avec :00 secondes. Chaque nouvelle heure commence avec 00:00 minutes et secondes. Et, au moins sur une horloge de 24 heures, le jour se termine lorsque minuit sonne et que 11:59:59 passe à 00:00:00.

Ainsi, si vous voulez calculer les secondes depuis minuit pour un moment comme 13:53:04, vous avez juste à évaluer 13 * 3600 + 53 * 60 + 4. Pas d'insipides 1 d'additions ou de soustractions.

Rant de clôture sur les MIDI

Ok, qu'est-ce qui se passe avec les musiciens, même ceux censés être techniques ?

MIDI ! Il utilise la numérotation à base zéro pour les programmes et les canaux dans la représentation filaire réelle des messages, mais les appareils l'affichent à base un ! Par exemple, les programmes 0 à 127 sont appelés 1 à 128 sur la plupart des appareils, mais certains les appellent 0 à 127 ou donnent même le choix à l'utilisateur.

Les programmes 71 à 80 sont considérés comme une "banque" de dix. C'est écrit sur ma pédale MIDI, par exemple. Les footswitches sont étiquetés de 1 à 10 et si je suis dans la septième banque, ils sélectionnent les programmes 71 à 80. Cependant, certains appareils ou logiciels affichent les numéros de programmes de 1 à 128 comme 0 à 127, ou donnent même le choix à l'utilisateur ! Qu'est-ce qui est pire : les systèmes à base un, ou le chaos créé en utilisant à la fois un et zéro à la fois ?

Les numéros de canaux MIDI sont appelés 1 à 16, mais sont représentés en binaire de 0 à 15. Comme par dérision envers la présentation à base un, certains appareils utilisent un commutateur pour configurer un numéro de canal et, souvent, ces commutateurs utilisent simplement le code binaire à base zéro. Donc si vous voulez le canal 3, vous devez le mettre sur 0010 (binaire 2).

Si je me souviens correctement de mon cours de Concepts de Langage de Programmation... les langages étant indexés à partir de 0 et d'autres à partir de 1 étaient dus à des raisons historiques. Algol-68, le grand ancêtre des langages de programmation était en fait indexé à partir de 1, tout comme Fortran et quelques autres langages "business" comme COBOL. Dans certains de ces langages cependant, vous pouviez spécifier explicitement quel serait votre indice de départ. Il y a un tableau intéressant de ceci ici.

Essentiellement, à l'époque des "Vieux Temps" les mathématiciens, scientifiques et autres "académiciens" utilisaient généralement des langages indexés à partir de 0, tandis que les utilisateurs de langages comme COBOL trouvaient inutile de commencer à compter à partir de 0, il semblait donc plus logique de commencer à 1 dans ces langages (cela semblait moins confus).

Maintenant, si votre question se rapporte à pourquoi un ordinateur (pas un langage) commence naturellement à compter à partir de zéro... eh bien je suppose que c'est inhérent au binaire en réalité : ex : 0000 = zéro 0001 = un ... et ainsi de suite...

Le numéro 0 pourrait avoir diverses significations : valeur numérique, ordinal, adresse mémoire, etc.

'L'index zéro' ne signifie pas que les programmeurs comptent à partir de zéro. Il représente le premier emplacement d'un bloc de mémoire alloué et '0' en est l'adresse.

En C, parcourir un tableau peut être écrit comme suit :

int arr[N];
for (i=0; arr[N]; ++i) {
...
}

Le même travail peut être effectué en C# :

Object[] arr;

for (Object o in arr) {
...
}

Je pense qu'il n'y a pas de comptage dans ces deux exemples.

Commencer à zéro est pratique lorsqu'on décrit une distance par rapport à quelque chose. Donc dans cet array :

[4,9,25,49]

la distance du début de l'array au 25 est de 2 - vous devez sauter deux étapes pour y arriver. La distance jusqu'au 4 est zéro - vous n'avez pas besoin de bouger du tout depuis le début.

Il est pratique de penser de cette manière lorsqu'on additionne des distances (ou des index) - j'avance d'une étape, puis zéro étape, puis deux étapes, où suis-je ? Je suis à l'index 1 + 0 + 2 = 3. En sautant trois étapes, j'arrive à 49 dans l'array ci-dessus.