jean-michel bain-cornu a écrit :
>> Cela sous-entend que commencer à compter à zéro est une notion
>> "actuelle", plus moderne.
>> Mais cela est loin d'être évident. On a pris l'habitude de faire avec,
>> ce qui n'implique pas que ce soit mieux.
>
> Il y aurait là-dessous le fait qu'un registre de processeur s'initialise
> à zéro que ce ne serait pas étonnant...
Oui et non.

> et pourquoi 0 ? parce que électriquement ça se fait tout seul.
C'est presque vrai.

> Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser un
> registre à 1 ?
C'est presque faux.


> On demande un électronicien dans la salle...
Présent

Initialiser un registre demande des ressources. Que ce soit pour l'initialiser à 0 ou à n'importe qu'elle autre valeur. En C, le système commence par initialiser TOUTES les variables qui doivent avoir une valeur connue lors du lancement du programme (que ce soit 0 ou d'autres valeurs). En python, la variable est initialisée à la première affectation. On peut y mettre 0 ou 1 ou n'importe quoi, ça ne change rien. Sauf sur certaines machines où "effacer" une case mémoire est un peu plus rapide. Mais c'est plus trop d'actualité avec les processeurs modernes.

La vraie raison du 0 c'est, comme l'a dit Amaury, que pour compter de 0 à 3, il faut 2 bits alors que pour compter de 1 à 4, il faut 3 bits.
On pourrait imaginer que l'interpréteur fasse le décalage tout seul mais alors celui-ci consommerait du temps CPU pour faire ces décalages "inutiles".
Et comme l'a dit Michel, c'est qu'une question d'habitude.

Nicolas

jean-michel bain-cornu a écrit :
>> Cela sous-entend que commencer à compter à zéro est une notion
>> "actuelle", plus moderne.
>> Mais cela est loin d'être évident. On a pris l'habitude de faire avec,
>> ce qui n'implique pas que ce soit mieux.
>
> Il y aurait là-dessous le fait qu'un registre de processeur s'initialise
> à zéro que ce ne serait pas étonnant...
Oui et non.

> et pourquoi 0 ? parce que électriquement ça se fait tout seul.
C'est presque vrai.

> Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser un
> registre à 1 ?
C'est presque faux.


> On demande un électronicien dans la salle...
Présent

Initialiser un registre demande des ressources. Que ce soit pour l'initialiser à 0 ou à n'importe qu'elle autre valeur. En C, le système commence par initialiser TOUTES les variables qui doivent avoir une valeur connue lors du lancement du programme (que ce soit 0 ou d'autres valeurs). En python, la variable est initialisée à la première affectation. On peut y mettre 0 ou 1 ou n'importe quoi, ça ne change rien. Sauf sur certaines machines où "effacer" une case mémoire est un peu plus rapide. Mais c'est plus trop d'actualité avec les processeurs modernes.

La vraie raison du 0 c'est, comme l'a dit Amaury, que pour compter de 0 à 3, il faut 2 bits alors que pour compter de 1 à 4, il faut 3 bits.
On pourrait imaginer que l'interpréteur fasse le décalage tout seul mais alors celui-ci consommerait du temps CPU pour faire ces décalages "inutiles".
Et comme l'a dit Michel, c'est qu'une question d'habitude.

Nicolas

NicolasP a écrit :
>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>> langage de programmation.
> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
> un interpréteur Python aurait du mal a rentrer.
> Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est
> du temps réel dur qu'il me faut. Hormis le C, point de salut.
>
> Nicolas

....[aucune réaction des développeurs ADA]....[ils ne doivent pas lire
fclp]....

;-)

NicolasP a écrit :
>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>> langage de programmation.
> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
> un interpréteur Python aurait du mal a rentrer.
> Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est
> du temps réel dur qu'il me faut. Hormis le C, point de salut.
>
> Nicolas

....[aucune réaction des développeurs ADA]....[ils ne doivent pas lire
fclp]....

;-)

MC a écrit :
> Bonsoir !
>
> Je profite de cet appel à troller...
>
>> des innombrables langages propriétaires qui existaient il y a une
>> vingtaine d'années...
>
> AMHA, il n'y a jamais eu autant de langages propriétaires qu'actuellement.
>
>
>> des langages actuels
>
> Cela sous-entend que commencer à compter à zéro est une notion
> "actuelle", plus moderne.
> Mais cela est loin d'être évident. On a pris l'habitude de faire avec,
> ce qui n'implique pas que ce soit mieux.

Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
commencer à zéro... si qq'un a/retrouve ce texte...

MC a écrit :
> Bonsoir !
>
> Je profite de cet appel à troller...
>
>> des innombrables langages propriétaires qui existaient il y a une
>> vingtaine d'années...
>
> AMHA, il n'y a jamais eu autant de langages propriétaires qu'actuellement.
>
>
>> des langages actuels
>
> Cela sous-entend que commencer à compter à zéro est une notion
> "actuelle", plus moderne.
> Mais cela est loin d'être évident. On a pris l'habitude de faire avec,
> ce qui n'implique pas que ce soit mieux.

Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
commencer à zéro... si qq'un a/retrouve ce texte...

NicolasP a écrit :
>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>> langage de programmation.
> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
> un interpréteur Python aurait du mal a rentrer.
> Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est
> du temps réel dur qu'il me faut. Hormis le C, point de salut.

Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à
l'exercice ?

NicolasP a écrit :
>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>> langage de programmation.
> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
> un interpréteur Python aurait du mal a rentrer.
> Et sur d'autres machines sur lesquelles il y a plus de ressources, c'est
> du temps réel dur qu'il me faut. Hormis le C, point de salut.

Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à
l'exercice ?

* Laurent Pointal <laurent.pointal@limsi.fr> in fr.comp.lang.python:
> Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
> anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
> commencer à zéro... si qq'un a/retrouve ce texte...

http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html

Et aussi :

Should array indices start at 0 or 1? My compromise of 0.5 was rejected
without, I thought, proper consideration.

Stan Kelly-Bootle

--
DW

* Laurent Pointal <laurent.pointal@limsi.fr> in fr.comp.lang.python:
> Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
> anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
> commencer à zéro... si qq'un a/retrouve ce texte...

http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html

Et aussi :

Should array indices start at 0 or 1? My compromise of 0.5 was rejected
without, I thought, proper consideration.

Stan Kelly-Bootle

--
DW

Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :

> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
> à l'exercice ?

OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
le compilo est si chatouilleux par rapport aux erreurs de programmation
courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
programme qui fonctionne.

Je fais du C depuis des années alors que je n'ai plus fait d'Ada depuis
les études et pourtant j'aurais bien voulu me frotter à Ada sur un
'vrai' projet.

--
Sébastien Kirche

Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :

> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
> à l'exercice ?

OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
le compilo est si chatouilleux par rapport aux erreurs de programmation
courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
programme qui fonctionne.

Je fais du C depuis des années alors que je n'ai plus fait d'Ada depuis
les études et pourtant j'aurais bien voulu me frotter à Ada sur un
'vrai' projet.

--
Sébastien Kirche

Damien Wyart a écrit :
> * Laurent Pointal <laurent.pointal@limsi.fr> in fr.comp.lang.python:
>> Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
>> anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
>> commencer à zéro... si qq'un a/retrouve ce texte...
>
> http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
>
> Et aussi :
>
> Should array indices start at 0 or 1? My compromise of 0.5 was rejected
> without, I thought, proper consideration.
>
> Stan Kelly-Bootle
>

Raté, c'était un autre anonyme "prof.dr. Edsger W. Dijkstra".

Damien Wyart a écrit :
> * Laurent Pointal <laurent.pointal@limsi.fr> in fr.comp.lang.python:
>> Il y a un article, mais que je n'arrive pas à retrouver, d'un auteur
>> anonyme genre Knuth ou consor, qui explique pourquoi c'est mieux de
>> commencer à zéro... si qq'un a/retrouve ce texte...
>
> http://www.cs.utexas.edu/users/EWD/t...xx/EWD831.html
>
> Et aussi :
>
> Should array indices start at 0 or 1? My compromise of 0.5 was rejected
> without, I thought, proper consideration.
>
> Stan Kelly-Bootle
>

Raté, c'était un autre anonyme "prof.dr. Edsger W. Dijkstra".

Bruno Desthuilliers a écrit :
> NicolasP a écrit :
>>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>>> langage de programmation.
>> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
>> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
>> un interpréteur Python aurait du mal a rentrer.
>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>
> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à
> l'exercice ?
>
Je ne connais pas ces langages. Comme il a été dit précédemment, le C est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.

Nicolas

Bruno Desthuilliers a écrit :
> NicolasP a écrit :
>>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>>> langage de programmation.
>> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
>> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le programme,
>> un interpréteur Python aurait du mal a rentrer.
>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>
> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas à
> l'exercice ?
>
Je ne connais pas ces langages. Comme il a été dit précédemment, le C est le langage le plus "universel". Même si ce n'est pas toujours le plus adapté, on peut tout faire avec.

Nicolas

Sébastien Kirche a écrit :
> Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :
>
>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>> à l'exercice ?
>
> OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
> réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
> le compilo est si chatouilleux par rapport aux erreurs de programmation
> courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
> programme qui fonctionne.

Ariane 5 ? Qui a dit Ariane 5 ?-)

Sébastien Kirche a écrit :
> Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :
>
>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>> à l'exercice ?
>
> OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
> réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
> le compilo est si chatouilleux par rapport aux erreurs de programmation
> courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
> programme qui fonctionne.

Ariane 5 ? Qui a dit Ariane 5 ?-)

NicolasP a écrit :
> Bruno Desthuilliers a écrit :
>> NicolasP a écrit :
>>>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>>>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>>>> langage de programmation.
>>> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
>>> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le
>>> programme, un interpréteur Python aurait du mal a rentrer.
>>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>>
>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>> à l'exercice ?
>>
> Je ne connais pas ces langages. Comme il a été dit précédemment, le C
> est le langage le plus "universel". Même si ce n'est pas toujours le
> plus adapté, on peut tout faire avec.

Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
point de salut" ?

NicolasP a écrit :
> Bruno Desthuilliers a écrit :
>> NicolasP a écrit :
>>>> Je ne saurais trop que dire ; C est universellement utilisé, mais
>>>> franchement pas pratique, en tout cas pour l'usage que j'ai d'un
>>>> langage de programmation.
>>> Perso, je programme tout en C. Et je ne peux pas faire autrement. Sur
>>> une machine où il y a 32Ko de RAM et 256Ko de FLASH pour le
>>> programme, un interpréteur Python aurait du mal a rentrer.
>>> Et sur d'autres machines sur lesquelles il y a plus de ressources,
>>> c'est du temps réel dur qu'il me faut. Hormis le C, point de salut.
>>
>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>> à l'exercice ?
>>
> Je ne connais pas ces langages. Comme il a été dit précédemment, le C
> est le langage le plus "universel". Même si ce n'est pas toujours le
> plus adapté, on peut tout faire avec.

Je n'en disconviens pas - mais cela justifie-t-il ton "Hormis le C,
point de salut" ?

Bruno Desthuilliers a écrit :
> Sébastien Kirche a écrit :
>> Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :
>>
>>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>>> à l'exercice ?
>>
>> OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
>> réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
>> le compilo est si chatouilleux par rapport aux erreurs de programmation
>> courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
>> programme qui fonctionne.
>
> Ariane 5 ? Qui a dit Ariane 5 ?-)
>

C'était pas un problème plus 'hard' (bus qui saturait et réinitialisait
le système, celui-ci considérant au démarrage qu'il était au niveau du sol)?

Donc pas trop lié au langage...

Bruno Desthuilliers a écrit :
> Sébastien Kirche a écrit :
>> Le 28 septembre 2007 à 09:29, Bruno Desthuilliers vraute :
>>
>>> Juste par curiosité: des langages comme ADA ou OCaml ne se prêtent pas
>>> à l'exercice ?
>>
>> OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du temps
>> réel, du parallélisme avec gestion de rendez-vous, ce genre de chose. Et
>> le compilo est si chatouilleux par rapport aux erreurs de programmation
>> courantes quand lorsqu'un programme Ada compile, on n'est pas loin d'un
>> programme qui fonctionne.
>
> Ariane 5 ? Qui a dit Ariane 5 ?-)
>

C'était pas un problème plus 'hard' (bus qui saturait et réinitialisait
le système, celui-ci considérant au démarrage qu'il était au niveau du sol)?

Donc pas trop lié au langage...

À (at) Thu, 27 Sep 2007 21:41:10 +0200,
jean-michel bain-cornu <pythonnews@nospam.jmbc.fr> écrivait (wrote):
>> Cela sous-entend que commencer à compter à zéro est une notion
>> "actuelle", plus moderne.
>> Mais cela est loin d'être évident. On a pris l'habitude de faire
>> avec, ce qui n'implique pas que ce soit mieux.
>
> Il y aurait là-dessous le fait qu'un registre de processeur
> s'initialise à zéro que ce ne serait pas étonnant...
> et pourquoi 0 ? parce que électriquement ça se fait tout seul.
> Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser
> un registre à 1 ? On demande un électronicien dans la salle...

Je pense que, historiquement, le décompte à partir de zéro qui est
utilisé en C (et dans de nombreux langages) provient en fait des modes
d'adressage relatif des processeurs qui utilisent deux registres : le
premier contient l'adresse en mémoire du tableau et le second indique
le décalage à appliquer à cette adresse de départ pour accéder à
l'élément cherché.

On peut donc voir cela non pas comme un index (un numéro d'ordre) mais
plutôt comme un offset (un décalage) par rapport au point de départ.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

À (at) Thu, 27 Sep 2007 21:41:10 +0200,
jean-michel bain-cornu <pythonnews@nospam.jmbc.fr> écrivait (wrote):
>> Cela sous-entend que commencer à compter à zéro est une notion
>> "actuelle", plus moderne.
>> Mais cela est loin d'être évident. On a pris l'habitude de faire
>> avec, ce qui n'implique pas que ce soit mieux.
>
> Il y aurait là-dessous le fait qu'un registre de processeur
> s'initialise à zéro que ce ne serait pas étonnant...
> et pourquoi 0 ? parce que électriquement ça se fait tout seul.
> Pourquoi pas +1 ? parce qu'il faut un cycle de plus pour initialiser
> un registre à 1 ? On demande un électronicien dans la salle...

Je pense que, historiquement, le décompte à partir de zéro qui est
utilisé en C (et dans de nombreux langages) provient en fait des modes
d'adressage relatif des processeurs qui utilisent deux registres : le
premier contient l'adresse en mémoire du tableau et le second indique
le décalage à appliquer à cette adresse de départ pour accéder à
l'élément cherché.

On peut donc voir cela non pas comme un index (un numéro d'ordre) mais
plutôt comme un offset (un décalage) par rapport au point de départ.

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Le 28 septembre 2007 à 12:53, Laurent Pointal a formulé :

> > > OCaml je ne connais pas mais tout un pan d'Ada est prévu pour du
> > > temps réel, du parallélisme avec gestion de rendez-vous, ce genre
> > > de chose. Et le compilo est si chatouilleux par rapport aux
> > > erreurs de programmation courantes quand lorsqu'un programme Ada
> > > compile, on n'est pas loin d'un programme qui fonctionne.
> >
> > Ariane 5 ? Qui a dit Ariane 5 ?-)
> >
>
> C'était pas un problème plus 'hard' (bus qui saturait et
> réinitialisait le système, celui-ci considérant au démarrage qu'il
> était au niveau du sol)?
>
> Donc pas trop lié au langage...

Le problème d'Ariane 5 c'est qu'il ont réutilisé des modules soft de la
génération précédente sans se poser trop de questions (pour des
problèmes de coût il me semble) quand aux différences. Après tout si ça
marchait pour la série 4 ça devait pouvoir marcher pour la série
suivante. Sauf que le nouveau modèle poussait plus fort, plus vite et
des charges plus importantes. Le calculateur s'est retrouvé en dehors
des plages de fonctionnement prévues et croyant voir l'engin partir dans
le décor, il a activé l'autodestruction. En décortiquant, ils se sont
rendu compte que des débordement de capacité auraient pu être gérés par
le programme, mais pour gagner en performance ça avait été compilé en
désactivant les vérifications fournies par le compilo.

Du coup ce qui a été économisé avant a été largement perdu dans
l'accident. Un peu comme avec Hubble : on a économisé la vérification du
miroir avant lancement mais ça a coûté une mission spatiale pour aller
poser des lunettes sur le nez du télescope myope... P
--
Sébastien Kirche