dans le livre de swinnen l exercice suivant est propos=E9 :
5=2E9. =C9crivez un script qui recopie une cha=EEne (dans une nouvelle
variable) en l'inversant.
Ainsi par exemple, =AB zorglub =BB deviendra =AB bulgroz =BB.
La solution donn=E9e par l'auteur :
#! /usr/bin/env python
# -*- coding: Latin-1 -*-
# Inversion d'une cha=EEne de caract=E8res
# Cha=EEne fournie au d=E9part :
ch =3D raw_input ('entrer un mot: ' )
lc =3D len(ch) # nombre de caract=E8res total
i =3D lc - 1 # le traitement commencera =E0 partir du dernier
caract=E8re
nch =3D "" # nouvelle cha=EEne =E0 construire (vide au d =E9part)
while i >=3D 0:
nch =3D nch + ch[i]
i =3D i - 1
# Affichage :
print nch
ca marche mais je ne comprend pas pourquoi la variable "i" est
encapsul=E9 la valeur "lc - 1" et non pourquoi simplement la valeur "lc
" , j'avais fait un script similaire avant de regarder la solution
mais je n'avais pas diminuer la valeur lc de 1 . Il est =E9crit que
c'est pour commencer par le dernier caract=E8re , mais si l'on enl=E8ve
1 , ne commence t-on pas avec l'avant dernier caract=E8re ?
output erreur sans la valeur lc - 1 :
me@robby:~/python.swinnen/solutions$ python exercice_5_09.py
entrer un mot: hello
Traceback (most recent call last):
File "exercice_5_09.py", line 12, in ?
nch =3D nch + ch[i]
IndexError: string index out of range
quelqu'un peut m'expliquer ? j'ai d=E9j=E0 chercher le nom de l erreur
mais elle pas trop compr=E9hensible a ce niveau ..
Ah, mais non! Il y a bien Stackless qui est un "fork" de Python, tu pourrais faire French, qui serait un fork-a-mots-cles-Fr de Python...
Bon je sors...
NicolasP
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
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.
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
NicolasP
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
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.
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
Laurent Pointal
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]....
;-)
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]....
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]....
;-)
Laurent Pointal
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...
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...
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...
Bruno Desthuilliers
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 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 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 ?
Damien Wyart
* Laurent Pointal 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...
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...
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...
Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.
Stan Kelly-Bootle
-- DW
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
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.
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
NicolasP
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
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 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
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" ?
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" ?
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" ?
