Le topic de la programmation: Et envoyez des sioux!

**deathdigger** · 26/09/2018, 16h40

J'avais une discussion sur le Windev ce midi, et est venu sur la table le fait que les tableaux commencent à 1 et pas à 0. Là, on m'a sorti que c'est normal, et que sur l'AS400 (COBOL ou RPG, je ne sais plus), c'était déjà comme ça.
Mais du coup, pourquoi les tableaux dans la majorité des langages commencent à 0 ? Ça vient du C ? Y'a une raison logique à ça ?

**acdctabs** · 26/09/2018, 16h44

Ben l'adresse qui commence à 0 c'est logique en fait, enfin je trouve.
Commencé à 1 c'est plus logique en terme humain.

**William Vaurien** · 26/09/2018, 16h54

On parle quand même du premier élément d'une collection.

Donc non, ce n'est pas vraiment logique et ça vient sûrement du C, et des langages à pointeurs, où un tableau n'est en fait qu'une suite de pointeur.

La convention est restée, mais écrire des trucs du genre "maListe.get(0)" est quand même assez absurde.

**Møgluglu** · 26/09/2018, 16h59

Les tableaux qui commencent à 0, ça vient des langages machines et assembleur, et les langages bas-niveau proche du hardware en général. Ceux où a[i] représente simplement la donnée à l'adresse a+i, que les pervers aiment aussi noter i[a].

Par exemple, en 1842, Ada Lovelace commençait ses tableaux à 0, parce que c'est comme ça que l'adressage fonctionnait dans l'Analytical Engine de Charles Babbage :

Les tableaux qui commencent à 1, c'est plutôt Grace Hopper.

(Il faut que je me renseigne sur le Plankalkül de Zuse, mais comme ça je parierais sur 1 aussi.)

Edit: au temps pour moi, en regardant bien Lovelace ne commence à 0 que quand elle reprend les exemples de Menabrea qui les tient directement de Babbage. Quand c'est ses propres exemples (comme ici: https://www.fourmilab.ch/babbage/sketch.html#NoteB ), elle commence à 1.

On peut donc conclure par la réalité historique que les programmeurs qui font du software commencent à 1, les architectes qui font du hardware commencent à 0.

**Helix** · 26/09/2018, 17h21

Comme l'indique Møgluglu, à partir du moment ou les valeurs du tableau ne sont indicées que par des décalages en mémoire, c'est logique de commencer à 0 (première case, pas de décalage).
D'ailleurs il y a eu une grosse polémique récemment sur le langage Julia (une nouveauté qui cherche à remplacer matlab et python en calcul intensif et analyse de données). Par défaut, les tableaux commencent à 1 (logique d'un point de vue math et analyse de données). Cela a fait crier au scandale par mal de gens habitués au C/C++.

**vectra** · 26/09/2018, 17h45

Envoyé par William Vaurien

On parle quand même du premier élément d'une collection.

Donc non, ce n'est pas vraiment logique et ça vient sûrement du C, et des langages à pointeurs, où un tableau n'est en fait qu'une suite de pointeur.

Heu non, c'est plutôt une plage de mémoire continue.
Je veux bien qu'on discute de la convénience des bidules, mais à un moment, il ne faut pas oublier de séparer la modélisation de l'implémentation. Et quitte à polémiquer pour un sucre syntaxique, autant que celui-ci ait un intérêt pour la lisibilité ou la compréhension du code.

De nos jours, comme sucres syntaxiques, on a des trucs comme ça:

Code:

int tab[5] = { 2, 3, 8, 4, 9};
for (auto i : tab)
    cout << endl <<  i;

Avec la même syntaxe, tu déclares un vecteur qui est implémenté quasiment pareil et qui propose les méthodes front() et back(), etc...
C'est du C++11, on en est au 17, y'a le 19 qui sort bientôt.

**FB74** · 26/09/2018, 17h45

Ouais à mort !!!

**deathdigger** · 26/09/2018, 17h55

Du coup, j'ai quand même cherché en plus de ce que dit Mogluglu, et c'est assez génial en fait :
https://stackoverflow.com/questions/...with-zero-in-c

http://developeronline.blogspot.com/...rt-from-0.html : en gros tu ne comptes pas l'élement mais son éloignement par rapport au début si j'ai capté
Et sinon :

https://i.stack.imgur.com/RTs1Q.png

**Helix** · 26/09/2018, 18h01

De toute façon, le premier entier naturel est 0 et pas 1,

.

**William Vaurien** · 26/09/2018, 18h02

Alors c'est le zéroième

?

**acdctabs** · 26/09/2018, 18h03

J'explique simplement et vous êtes obligés de faire une thèse pour dire la même chose. Pff !

**vectra** · 26/09/2018, 18h07

Envoyé par William Vaurien

Alors c'est le zéroième

?

Prends une règle graduée et imagine-toi des données entre chaque tiret de millimètre. La première donnée est à l'adresse 0, entre 0 et 1, et c'est logique de désigner où elle commence plutôt que où elle finit.
Sinon, utilise .front() ou first() ou car ou ce que tu veux pour un accès direct.

**FB74** · 26/09/2018, 18h15

Envoyé par acdctabs

J'explique simplement et vous êtes obligés de faire une thèse pour dire la même chose. Pff !

Et t'es plutôt 0 ou 1 ?

Choisis ton camp !!!

**acdctabs** · 26/09/2018, 18h24

0 !

vectra explique ça très bien.

**Helix** · 26/09/2018, 18h29

1, parce que je ne suis pas dev et que j'ai été élevé à coups de Matlab.

**Møgluglu** · 26/09/2018, 18h54

Envoyé par deathdigger

Et sinon :
https://i.stack.imgur.com/RTs1Q.png

Objection !

Le théorème n'est vrai que dans un système de numération qui a uniquement des chiffres positifs.

Dans un ordinateur ternaire avec les chiffres -1, 0 et 1 comme SETUN, un tableau de taille 3^n commence à -1 -1 -1 ... -1 = -(3^n-1)/2 et finit à 1 1 1 ... 1 = (3^n-1)/2, ce qui fait bien 3^n entrées en comptant l'élément 0 au milieu du tableau. Par exemple avec 4 trits d'adresse on va de -40 à +40 pour adresser un tableau de taille 81. Et c'est parfaitement symétrique avec un seul zéro, pas comme dans ces systèmes à la con en base paire.

**Munshine** · 26/09/2018, 19h03

Le L4G propriétaire de Sage X3 c'est plein de GOTO et GOSUB ...en 2018 ...sérieusement...

Heureusement que je vais pas y toucher tout de suite.

La dernière fois que j'ai eu affaire à un L4G de cet acabit c'était du Gembase pour une solution pour les Telecom en 2000.
Et j'étais content de passer sur la version en c++ 3/4 ans plus tard.

**deathdigger** · 26/09/2018, 19h15

Envoyé par Møgluglu

Objection !

Le théorème n'est vrai que dans un système de numération qui a uniquement des chiffres positifs.

Dans un ordinateur ternaire avec les chiffres -1, 0 et 1 comme SETUN, un tableau de taille 3^n commence à -1 -1 -1 ... -1 = -(3^n-1)/2 et finit à 1 1 1 ... 1 = (3^n-1)/2, ce qui fait bien 3^n entrées en comptant l'élément 0 au milieu du tableau. Par exemple avec 4 trits d'adresse on va de -40 à +40 pour adresser un tableau de taille 81. Et c'est parfaitement symétrique avec un seul zéro, pas comme dans ces systèmes à la con en base paire.

Du coup, acdTabs est plus concis : c'est comme ça, parce que c'est plus logique

**ducon** · 26/09/2018, 19h54

Envoyé par Møgluglu

Les tableaux qui commencent à 0, ça vient des langages machines et assembleur, et les langages bas-niveau proche du hardware en général. Ceux où a[i] représente simplement la donnée à l'adresse a+i, que les pervers aiment aussi noter i[a].

Donc Python est plutôt bas niveau.

En mathématiques, les suites et les polynômes sont indexés à partir de 0, les matrices à partir de 1.

**Cwningen** · 26/09/2018, 20h56

Donc si je comprends bien le paragraphe sur le vocabulaire, 0 est le premier entier (0^er pour faire court), 1 est le second (1^d), 2 est le deuxième (2^ème), 3 est le troisième (3^ème), ... c'est ça ? Mais comment on appelle en anglais l'ordinal entre second et third ?

**BentheXIII** · 26/09/2018, 22h15

Tiens, je suis tombé sur un truc un peu débile aujourd'hui. J'avais des assertions dans le style assert(1==0) qui passaient. Il se trouvait que la macro NDEBUG avait été définie et de fait désactivait assert. Ce qui est surprenant, c'est que c'est l'inclusion de "std=c++17" dans mes CMAKE_CXX_FLAGS dans cmake qui définissait NDEBUG. C'est voulu ce truc (clang 10) ?

**vectra** · 26/09/2018, 23h17

C'est pour ça que je me suis défini une macro dynamic_assert(condition, "tagl");
On a parfois de bonnes raisons de faire cesser un programme de la même manière qu'assert le fait, sauf qu'assert est conçu pour se désactiver à terme.

**Nilsou** · 27/09/2018, 00h08

Envoyé par Helix

Comme l'indique Møgluglu, à partir du moment ou les valeurs du tableau ne sont indicées que par des décalages en mémoire, c'est logique de commencer à 0 (première case, pas de décalage).
D'ailleurs il y a eu une grosse polémique récemment sur le langage Julia (une nouveauté qui cherche à remplacer matlab et python en calcul intensif et analyse de données). Par défaut, les tableaux commencent à 1 (logique d'un point de vue math et analyse de données). Cela a fait crier au scandale par mal de gens habitués au C/C++.

Voila, c'est absolument cohérent d'un point de vue adressage. Donc il n'y a pas vraiment besoin d'aller chercher plus loin : les langages natifs serait horrible si les tableaux commençait à 1 dés qu'on manipulerais des adresse ça ferais des nœuds dans le cerveau ...

- - - Mise à jour - - -

Envoyé par William Vaurien

Donc non, ce n'est pas vraiment logique et ça vient sûrement du C, et des langages à pointeurs, où un tableau n'est en fait qu'une suite de pointeur.

Tutut, en C un tableau standard n'est absolument pas une suite de pointeur. Mais un espace mémoire contigüe, de mémoire. C'est si tu commence à faire des tableaux de tableaux que tu a des suites de pointeurs. Et il y a donc une différence fondamentale, toujours de mémoire, entre un tableau 2D déclaré comme ceci [][] et une suite de malloc sur un tableau de pointeur [].

- - - Mise à jour - - -

Envoyé par Møgluglu

Objection !

Le théorème n'est vrai que dans un système de numération qui a uniquement des chiffres positifs.

Dans un ordinateur ternaire avec les chiffres -1, 0 et 1 comme SETUN, un tableau de taille 3^n commence à -1 -1 -1 ... -1 = -(3^n-1)/2 et finit à 1 1 1 ... 1 = (3^n-1)/2, ce qui fait bien 3^n entrées en comptant l'élément 0 au milieu du tableau. Par exemple avec 4 trits d'adresse on va de -40 à +40 pour adresser un tableau de taille 81. Et c'est parfaitement symétrique avec un seul zéro, pas comme dans ces systèmes à la con en base paire.

D'ailleurs c'est quoi la raison logique qui a fait abandonner le ternaire ? J'imagine qu'il y avais une histoire de fiabilité des processeur sur des pas plus petit vis à vis du bruit, mais aujourd'hui cet argument est-il encore valable ? J'imagine qu'on pourrait tout à fait pondre des systèmes mathématique qui fonctionne avec 4 paliers et de pondre les puces qui vont bien. En plus avec 4 pallier c'est toujours possible d'imaginer une compatibilité avec le binaire.

--------------------------------------------------

Petite question sinon pour les experts :

J'ai X threads POSIX (sur systeme linux) X étant grand, très grand. Les X threads étant déclenché séquentiellement (via un séquenceur qui tourne sur un thread) via des semaphores.

Bon, le constat c'est qu'actuellement on arrive a surcharger uniquement 50/60% des cœurs. Pour nos applications (réseaux de neurone, robot, laboratoire etc...), ça ne nous va pas trop tout ça, nous on veut que ça prenne 100% du temps processeur, on les a pas acheté pour des billes

(en plus c'est vos impôts, dites vous qu'en répondant vous les rentabilisez

)

Alors bon, il y a bien quelques goulot d'étranglement évident au niveau du séquenceur qu'on fait de notre mieux pour réduire mais en dehors de ça, si vous avez des sources et idées pour traiter ce genre de problème d'un point de vue général.
Je pensais notamment à l'évaluation du coups des lancé et réceptions de sémaphore tout le temps, à la distribution des threads sur les cœurs, aux éventuelles options qu'on pourrait indiquer au systeme pour les threads (après tout, ne peut-on pas lui éviter le travail de faire les estimation de la consommation des thread et de l'assignation aux processeur si on sait pile quand ils vont se lancer et consommer ? )
etc etc...

Il y a toujours la solution de mettre tout dans un gestionnaire de tache qui lance telle ou telle fonction et resterait activé plus longtemps qu'un thread en moyenne donc, mais c'est un gros travail pour tracer les branches et attribuer telle ou telle machin à ce gestionnaire, donc j'ai un peu la flemme de tout changer ainsi...

**vectra** · 27/09/2018, 00h21

Envoyé par Nilsou

Tutut, en C un tableau standard n'est absolument pas une suite de pointeur. Mais un espace mémoire contigüe, de mémoire. C'est si tu commence à faire des tableaux de tableaux que tu a des suites de pointeurs. Et il y a donc une différence fondamentale, toujours de mémoire, entre un tableau 2D déclaré comme ceci [][] et une suite de malloc sur un tableau de pointeur [].

Dans la vraie vie, les images 2D et les volumes 3D sont implémentés par des tableaux 1D. L'arithmétique est simple et ne coûte rien au CPU.
Le tableau de pointeurs, c'est un bon exercice d'algo, mais ça va généralement pas plus loin IRL.

**Nilsou** · 27/09/2018, 01h02

Bah on en fait quand même non ? Pour des gros espaces mémoires ? Sinon il n'y a pas un risque de ne pas avoir l'espace contigüe demandé ?

Je sais plus...

Après oui, nous on traite presque tout en tableau 1D (surtout pour les images) donc bon... mais je ne pensais pas que les tableaux de pointeur n'avais aucune application ...

D'ailleurs, tant qu'on est la dedans, je me souviens avoir déja posé la question (je crois) mais je n'ai toujours pas trouvé de solutions élégantes au probleme.
Dison que j'ai une structure ou un objet defini comme ceci

struct mon_bidule
{
int a
int b
etc...
}

Structure ou objet pouvant être potentiellement assez gros.

disons que j'ai un tableau énorme de cette structure : mon_bidule[100000], exemple au pif.

Dans les calculs j'ai tendance à faire beaucoup d’accès à l’élément "a" de cette façon mon_bidule[i].a = plouf .
C'est pratique, car "a" appartient bien à "mon_bidule" d'un point de vue objet, donc c'est intuitif et compréhensible pour nos collaborateurs (et nous mêmes).

Néanmoins là ou c'est beaucoup moins pratique c'est que les accès successif à deux objets a sont loin d’être contigüe. Donc j'imagine, loin, très loin d’être optimale en comparaison d'un tableau externe "int a[10000]". Et si jamais ce type d'objet contient une image, on est partie pour copier ça dans un tableau contigüe pour pouvoir passer ça à un éventuel CUDA ou autre systeme de calcul (même pour le cpu il vaut mieux le faire donc...). Le truc affreux quoi ...

Bien sur, une solution simple est de créer un tableau déporté pour les éléments d’accès courant (par exemple a et b) genre mon_bidule_a[10000] et mon_bidule_b[10000]. Mais c'est pas vraiment élégant, et après tout, moi je me contenterais bien de l'illusion que a et b sont dans l'objet "mon_bidule", c'est pour la simplicité de coder surtout, la structure mémoire, si elle est fidèle à l'objet ou non, je ne m'en préoccupe guère.

Question : existe t-il une solution simple capable de résoudre ce soucis tout en conservant l’élégance d'appel ? (sur du C/C++ disons, mais plutôt du C), quitte à faire des bidouilles à base de macro etc...

Ou existe t-il une façon de dire au compilo : je veut que les éléments de cette structure soit disposé ainsi, à l’extérieur. Fait le taf ensuite.

**vectra** · 27/09/2018, 01h12

Je ne dirais pas forcément ça, mais c'est juste que je ne les connais pas.
Par contre, j'ai un peu trop souvent vu des images allouées ligne par ligne juste parce que l'exercice avait été fait en TP ou DS de 1ère année.

**Nilsou** · 27/09/2018, 01h18

Arf, je vois ...
tient j'ai édité mon pavé pour rajouter une question que je me pose en ce moment, si quelqu'un a une idée ...

**Thamior** · 27/09/2018, 01h19

Avec la mémoire virtuelle tu peux allouer xGB de mémoire avec des addresses virtuelles contigües sans avoir d'addresses physiques contigües donc j'aurais tendance à être du côté de vectra. Evidemment, il faut quand même avoir assez d'addresses physiques contigües pour la taille de page qui est utilisée (typiquement, 4KB). Après, oui, si tu alloues 4GB en utilisant une taille de page de 4GB et qu'il n'y a pas 4GB d'addresses contigües libres dans la mémoire physique tu vas avoir un problème mais ça ne me paraît pas être un problème que le commun des mortels rencontre souvent. Il faudra juste gérer le std::bad_alloc

Sinon pour les perfs ben je dirais un coup de gprof pour vérifier qu'il n'y a pas 40% du temps passé à synchroniser, peut-être.

Pour ton autre question, c'est un peu Array Of Structs vs. Struct of Arrays. Une question peut-être c'est quelle est la distance entre les éléments quand tu fais des accès? Typiquement, si ça sort du cache, ça ne vaut peut-être pas le coup de faire un tableau par membre si ça reste un cache miss.

Envoyé par Ducon

Donc Python est plutôt bas niveau.

Python c'est le truc ou quand tu as un tableau de 4 éléments et que tu accèdes l'index -1 ça te donne le dernier, c'est ça? Bas niveau qu'il disait

**Nilsou** · 27/09/2018, 01h30

Envoyé par Thamior

Avec la mémoire virtuelle tu peux allouer xGB de mémoire avec des addresses virtuelles contigües sans avoir d'addresses physiques contigües donc j'aurais tendance à être du côté de vectra. Evidemment, il faut quand même avoir assez d'addresses physiques contigües pour la taille de page qui est utilisée (typiquement, 4KB). Après, oui, si tu alloues 4GB en utilisant une taille de page de 4GB et qu'il n'y a pas 4GB d'addresses contigües libres dans la mémoire physique tu vas avoir un problème mais ça ne me paraît pas être un problème que le commun des mortels rencontre souvent. Il faudra juste gérer le std::bad_alloc

Ok, j'avoue que ma mémoire sur ces questions n'est plus ce qu'elle était, il me semblait pourtant avoir fait crasher des trucs en tentant l'allocation de truc contigüe trop gros. Mais ... je doit fumer... ou alors c'était en déclarant un tableau statique trop gros (ce qui n'est pas le même soucis), je sais plus trop ...

Envoyé par Thamior

Pour ton autre question, c'est un peu Array Of Structs vs. Struct of Arrays. Une question peut-être c'est quelle est la distance entre les éléments quand tu fais des accès? Typiquement, si ça sort du cache, ça ne vaut peut-être pas le coup de faire un tableau par membre puisque ça sera un cache miss aussi.

La taille de "a" dans mon exemple c'est un simple float, ou un double au pire. La taille de la structure mon_bidule, c'est un truc assez gros (pour un objet).
Je sais que le problème est du type Array Of Structs vs. Struct of Arrays, le seul truc c'est que je sais pertinemment que mon problème serait bien plus optimale dans le cas Struct of Array, mais le array of struct est bien plus élégant d'un point de vue code (dans mon cas). Il n'y a pas moyens de faire "croire" au compilo qu'un machin est un objet, mais qu'a la compilation il me foute certains membre de cette objet à l’extérieur en me remplaçant les appels éventuels à ces membres par l'appel qui va bien sur le tableau extérieure de ce membre...
je ne sais pas si je suis clair. Mais à priori, qu'est ce qui empêche le compilo de faire ce genre de boulot ? Je veut dire, ça n'a pas l'air si difficile que ça ...

Je veut dire, quand je transforme à la mano tout les mon_bidule[i].a par mon_bidule_a[i] c'est un peu ce que je fais...

**Thamior** · 27/09/2018, 01h43

Je ne suis pas convaincu que le compilo ait le droit de remplacer un malloc par N mallocs (N étant le nombre de membres dans l'objet)...

C'est du C ou du C++? En C++ on pourrait faire un truc avec des méthodes getMember(int n) ou chaque instance à les pointeurs vers les tableaux et un index, et getMember(0) renvoie vraiment a[index]. Ca prend plus de place et il y a une indirection en plus mais si les accès aux instances sont séquentiels ça peut aller plus vite.

En C j'ai pas d'idée, mais je suis sûr qu'un sorcier des macros saura faire.

Edit : J'ai encore dit une bêtise à base de templates

Discussion: Le topic de la programmation: Et envoyez des sioux!

Outils de la discussion

Règles de messages