"Michel Michaud" writes:Dans news:, Gabriel Dosfor (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec
Koenig, surtout pour les débutants : pour les boucles de
0 à N-1, et autres qui parcourent toutes les données, la
condition devrait être i != N pour éviter que des erreurs
passent inaperçues jusqu'au « moment opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
for (int i = 0; i < N; ++i)
// ...
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
"Michel Michaud" <mm@gdzid.com> writes:
Dans news:m3n088rizo.fsf@merlin.cs.tamu.edu, Gabriel Dos
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec
Koenig, surtout pour les débutants : pour les boucles de
0 à N-1, et autres qui parcourent toutes les données, la
condition devrait être i != N pour éviter que des erreurs
passent inaperçues jusqu'au « moment opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
for (int i = 0; i < N; ++i)
// ...
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.
Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
"Michel Michaud" writes:Dans news:, Gabriel Dosfor (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec
Koenig, surtout pour les débutants : pour les boucles de
0 à N-1, et autres qui parcourent toutes les données, la
condition devrait être i != N pour éviter que des erreurs
passent inaperçues jusqu'au « moment opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
for (int i = 0; i < N; ++i)
// ...
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
Dans news:, Gabriel Dos"Michel Michaud" writes:Dans news:, Gabriel Dosfor (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec Koenig,
surtout pour les débutants : pour les boucles de 0 à N-1, et autres
qui parcourent toutes les données, la condition devrait être i != N
pour éviter que des erreurs passent inaperçues jusqu'au « moment
opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Je sais qu'on a déjà eu cette discussion. Je sais aussi que c'est un
avis qui ne fait pas l'unanimité. Alors je veux bien en reparler, mais
je t'accorde dès maintenant que tu peux tout à fait avoir raison de
faire comme tu l'entends...
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit, je te
conseille un assert(0<=i && i<N); avant chaque v[i].
C'est une vérification plus formelle que l'expression d'une boucle,
qui ne dit rien de ce qui se passe dans le code contrôlé par le for.
(i pourrait y devenir négatif ou plus grand que N et revenir à une
valeur valide avec de retourner au test du for...)
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de la
boucle quand i<N est faux donc si i >= N.
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je suis
sorti et quelle était la valeur de i.
Pas avec i<N. C'est ce que Koenig indique et que je trouvais
intéressant. Moi au départ j'utilisais i!=N simplement parce que je
voulais avoir la même forme de boucle qu'avec les itérateurs.
Pour ce qui est des erreurs, je pensais à celles qui auraient
justement fait passer la variable de contrôle à une valeur plus grande
que N au lieu de N. J'ai aussi remarqué qu'il semble plus facile (pour
mes élèves) d'utiliser des bornes « un de plus » que de jouer avec le
choix entre < et <=. Tu peux tenter l'expérience et m'en reparler en
essayant cette question auprès de tes élèves :
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Comment tu prononces le for ci-haut pour ça sonne comme ça ? Bien sûr,
on peut lire « de i=0, tant que i est plus petit que N » et se dire
que c'est exactement ce que ça va nous donner. Mais le cas du != est
alors tout aussi clair, sinon plus, « de i=0, tant que i n'est pas
égal à N »...
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
simplement reconnaître qu'on peut trouver une justification
aux deux possibilités et on sera suffisamment d'accord pour
clore la discussion. Tiens autres justifications : toi tu
fais comme BS, c'est une bien bonne idée. Moi je fais comme
ARK... :-)
Dans news:m3isiv546b.fsf@merlin.cs.tamu.edu, Gabriel Dos
"Michel Michaud" <mm@gdzid.com> writes:
Dans news:m3n088rizo.fsf@merlin.cs.tamu.edu, Gabriel Dos
for (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec Koenig,
surtout pour les débutants : pour les boucles de 0 à N-1, et autres
qui parcourent toutes les données, la condition devrait être i != N
pour éviter que des erreurs passent inaperçues jusqu'au « moment
opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Je sais qu'on a déjà eu cette discussion. Je sais aussi que c'est un
avis qui ne fait pas l'unanimité. Alors je veux bien en reparler, mais
je t'accorde dès maintenant que tu peux tout à fait avoir raison de
faire comme tu l'entends...
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit, je te
conseille un assert(0<=i && i<N); avant chaque v[i].
C'est une vérification plus formelle que l'expression d'une boucle,
qui ne dit rien de ce qui se passe dans le code contrôlé par le for.
(i pourrait y devenir négatif ou plus grand que N et revenir à une
valeur valide avec de retourner au test du for...)
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de la
boucle quand i<N est faux donc si i >= N.
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je suis
sorti et quelle était la valeur de i.
Pas avec i<N. C'est ce que Koenig indique et que je trouvais
intéressant. Moi au départ j'utilisais i!=N simplement parce que je
voulais avoir la même forme de boucle qu'avec les itérateurs.
Pour ce qui est des erreurs, je pensais à celles qui auraient
justement fait passer la variable de contrôle à une valeur plus grande
que N au lieu de N. J'ai aussi remarqué qu'il semble plus facile (pour
mes élèves) d'utiliser des bornes « un de plus » que de jouer avec le
choix entre < et <=. Tu peux tenter l'expérience et m'en reparler en
essayant cette question auprès de tes élèves :
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.
Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Comment tu prononces le for ci-haut pour ça sonne comme ça ? Bien sûr,
on peut lire « de i=0, tant que i est plus petit que N » et se dire
que c'est exactement ce que ça va nous donner. Mais le cas du != est
alors tout aussi clair, sinon plus, « de i=0, tant que i n'est pas
égal à N »...
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
simplement reconnaître qu'on peut trouver une justification
aux deux possibilités et on sera suffisamment d'accord pour
clore la discussion. Tiens autres justifications : toi tu
fais comme BS, c'est une bien bonne idée. Moi je fais comme
ARK... :-)
Dans news:, Gabriel Dos"Michel Michaud" writes:Dans news:, Gabriel Dosfor (int i = 0; i < N; ++i)
v[i] = xxxx;
Commentaire : je suis maintenant fortement d'accord avec Koenig,
surtout pour les débutants : pour les boucles de 0 à N-1, et autres
qui parcourent toutes les données, la condition devrait être i != N
pour éviter que des erreurs passent inaperçues jusqu'au « moment
opportun » :-).
Peux-tu expliquer pourquoi « la condition *devrait* être », et
quelles erreurs ?
Je sais qu'on a déjà eu cette discussion. Je sais aussi que c'est un
avis qui ne fait pas l'unanimité. Alors je veux bien en reparler, mais
je t'accorde dès maintenant que tu peux tout à fait avoir raison de
faire comme tu l'entends...
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille du
tableau, alors il me semble que la manière immédiate de dire cela
avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit, je te
conseille un assert(0<=i && i<N); avant chaque v[i].
C'est une vérification plus formelle que l'expression d'une boucle,
qui ne dit rien de ce qui se passe dans le code contrôlé par le for.
(i pourrait y devenir négatif ou plus grand que N et revenir à une
valeur valide avec de retourner au test du for...)
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de la
boucle quand i<N est faux donc si i >= N.
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je suis
sorti et quelle était la valeur de i.
Pas avec i<N. C'est ce que Koenig indique et que je trouvais
intéressant. Moi au départ j'utilisais i!=N simplement parce que je
voulais avoir la même forme de boucle qu'avec les itérateurs.
Pour ce qui est des erreurs, je pensais à celles qui auraient
justement fait passer la variable de contrôle à une valeur plus grande
que N au lieu de N. J'ai aussi remarqué qu'il semble plus facile (pour
mes élèves) d'utiliser des bornes « un de plus » que de jouer avec le
choix entre < et <=. Tu peux tenter l'expérience et m'en reparler en
essayant cette question auprès de tes élèves :
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Une fois qu'il est confortable avec ça, on peut lui expliquer les
subtilités plus tard. Mais le but premier du cours, c'est
d'apprendre la programmation à quelqu'un qui n'a pas de pratique
préalable.Ce n'est qu'un bonne petite habitude à prendre...
Exactement pour quelle raison ? Pédagogiquement,
for (int i = 0; i < N; ++i)
se lit comme il se prononce et est une transcription de ce qu'on
vient d'expliquer au pauvre débutant.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Comment tu prononces le for ci-haut pour ça sonne comme ça ? Bien sûr,
on peut lire « de i=0, tant que i est plus petit que N » et se dire
que c'est exactement ce que ça va nous donner. Mais le cas du != est
alors tout aussi clair, sinon plus, « de i=0, tant que i n'est pas
égal à N »...
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
simplement reconnaître qu'on peut trouver une justification
aux deux possibilités et on sera suffisamment d'accord pour
clore la discussion. Tiens autres justifications : toi tu
fais comme BS, c'est une bien bonne idée. Moi je fais comme
ARK... :-)
"Michel Michaud" writes:Dans news:, Gabriel DosQuand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille
du tableau, alors il me semble que la manière immédiate de dire
cela avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
Non, non, pas du tout. Je parle de la simplicité d'expression
d'idées.
Tu parles de comment Koenig fait. Mais comme je t'ai indiqué dans le
précédent message, le public auquel on s'adresse n'est pas celui
visé par Koenig.
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit,
je te conseille un assert(0<=i && i<N); avant chaque v[i]. C'est
(1) Ce n'est pas de ça que je parle.
(2) Mettre assert() dans la boucle ne rend pas la chose plus
claire. (3) assert() est une macro qui peut être desactivée,
alors pour la vérification formelle, bof.
(i pourrait y devenir négatif ou plus grand que N et revenir à
une valeur valide avec de retourner au test du for...)
Bah non. C'est impossible. Si tu as un compilateur qui fait autre
chose, change de compilateur.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
que pour les valeurs positives
et strictement plus petites que la taille du tableau. Alors
En réalité, en termes d'expressions d'idées, i != N n'est pas aussi
immédiate que i < N.
Sur le plan de la sémantique formelle, les deux
sont équivalent. Mais les undergraduates en première année sans
expérience de programmation préalable font rarement de la sémantique
formelle le deuxième jour.
Avec i!=N, je sais exactement pourquoi je suis sorti et quelle
était la valeur de i. Pas avec i<N.
Là, ce raisonnement est faux.
C'est ce que Koenig indique
et que je trouvais intéressant. Moi au départ j'utilisais i!=N
simplement parce que je voulais avoir la même forme de boucle
qu'avec les itérateurs.
Je peux comprendre ton but. Mais ici, encore une fois, c'est un
cours de programmation pour des débutants et au deuxième cours, on
va pas leur parler d'itérateurs.
Par contre on veut qu'ils sachent utiliser des tableaux pour faire
des choses simples. Si je faisais un cours
Comme j'ai expliqué il n'y a pas longtemps, je n'enseigne pas ici.
(En fait, mes seuls « élèves » sont les élèves en thèse avec BS; et
bientôt les graduates avec qui je fais un groupe d'étude sur la
programmation template. Mais ceux là ont déjà dépassé le stade :-).
Il arrive simplement que presque toujours, je suis d'accord avec
ses choix pédagogiques -- il y a cependant des points vraiment
mineurs sur lesquels on a des avis légèrement différents. On en
discute, chacun justifiant sa vision. Il arrive même que des fois,
le lendemain on change d'avis et qu'on argue pour exactement la
position défendue par l'autre la veille :-)
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
Je ne cherche pas « la vérité ». Je suis plus intéressé par une
démarche pédagogique.
"Michel Michaud" <mm@gdzid.com> writes:
Dans news:m3isiv546b.fsf@merlin.cs.tamu.edu, Gabriel Dos
Quand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille
du tableau, alors il me semble que la manière immédiate de dire
cela avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
Non, non, pas du tout. Je parle de la simplicité d'expression
d'idées.
Tu parles de comment Koenig fait. Mais comme je t'ai indiqué dans le
précédent message, le public auquel on s'adresse n'est pas celui
visé par Koenig.
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit,
je te conseille un assert(0<=i && i<N); avant chaque v[i]. C'est
(1) Ce n'est pas de ça que je parle.
(2) Mettre assert() dans la boucle ne rend pas la chose plus
claire. (3) assert() est une macro qui peut être desactivée,
alors pour la vérification formelle, bof.
(i pourrait y devenir négatif ou plus grand que N et revenir à
une valeur valide avec de retourner au test du for...)
Bah non. C'est impossible. Si tu as un compilateur qui fait autre
chose, change de compilateur.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
que pour les valeurs positives
et strictement plus petites que la taille du tableau. Alors
En réalité, en termes d'expressions d'idées, i != N n'est pas aussi
immédiate que i < N.
Sur le plan de la sémantique formelle, les deux
sont équivalent. Mais les undergraduates en première année sans
expérience de programmation préalable font rarement de la sémantique
formelle le deuxième jour.
Avec i!=N, je sais exactement pourquoi je suis sorti et quelle
était la valeur de i. Pas avec i<N.
Là, ce raisonnement est faux.
C'est ce que Koenig indique
et que je trouvais intéressant. Moi au départ j'utilisais i!=N
simplement parce que je voulais avoir la même forme de boucle
qu'avec les itérateurs.
Je peux comprendre ton but. Mais ici, encore une fois, c'est un
cours de programmation pour des débutants et au deuxième cours, on
va pas leur parler d'itérateurs.
Par contre on veut qu'ils sachent utiliser des tableaux pour faire
des choses simples. Si je faisais un cours
Comme j'ai expliqué il n'y a pas longtemps, je n'enseigne pas ici.
(En fait, mes seuls « élèves » sont les élèves en thèse avec BS; et
bientôt les graduates avec qui je fais un groupe d'étude sur la
programmation template. Mais ceux là ont déjà dépassé le stade :-).
Il arrive simplement que presque toujours, je suis d'accord avec
ses choix pédagogiques -- il y a cependant des points vraiment
mineurs sur lesquels on a des avis légèrement différents. On en
discute, chacun justifiant sa vision. Il arrive même que des fois,
le lendemain on change d'avis et qu'on argue pour exactement la
position défendue par l'autre la veille :-)
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
Je ne cherche pas « la vérité ». Je suis plus intéressé par une
démarche pédagogique.
"Michel Michaud" writes:Dans news:, Gabriel DosQuand on vient d'expliquer à quelqu'un qu'un indice n'est valable
que s'il est positif et strictement plus que petit que la taille
du tableau, alors il me semble que la manière immédiate de dire
cela avec des symboles est
Tu parles d'invariant, moi je parle de logique (boucle)...
Non, non, pas du tout. Je parle de la simplicité d'expression
d'idées.
Tu parles de comment Koenig fait. Mais comme je t'ai indiqué dans le
précédent message, le public auquel on s'adresse n'est pas celui
visé par Koenig.
for (int i = 0; i < N; ++i)
// ...
Si tu veux vérifier qu'il est positif et strictement plus petit,
je te conseille un assert(0<=i && i<N); avant chaque v[i]. C'est
(1) Ce n'est pas de ça que je parle.
(2) Mettre assert() dans la boucle ne rend pas la chose plus
claire. (3) assert() est une macro qui peut être desactivée,
alors pour la vérification formelle, bof.
(i pourrait y devenir négatif ou plus grand que N et revenir à
une valeur valide avec de retourner au test du for...)
Bah non. C'est impossible. Si tu as un compilateur qui fait autre
chose, change de compilateur.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
que pour les valeurs positives
et strictement plus petites que la taille du tableau. Alors
En réalité, en termes d'expressions d'idées, i != N n'est pas aussi
immédiate que i < N.
Sur le plan de la sémantique formelle, les deux
sont équivalent. Mais les undergraduates en première année sans
expérience de programmation préalable font rarement de la sémantique
formelle le deuxième jour.
Avec i!=N, je sais exactement pourquoi je suis sorti et quelle
était la valeur de i. Pas avec i<N.
Là, ce raisonnement est faux.
C'est ce que Koenig indique
et que je trouvais intéressant. Moi au départ j'utilisais i!=N
simplement parce que je voulais avoir la même forme de boucle
qu'avec les itérateurs.
Je peux comprendre ton but. Mais ici, encore une fois, c'est un
cours de programmation pour des débutants et au deuxième cours, on
va pas leur parler d'itérateurs.
Par contre on veut qu'ils sachent utiliser des tableaux pour faire
des choses simples. Si je faisais un cours
Comme j'ai expliqué il n'y a pas longtemps, je n'enseigne pas ici.
(En fait, mes seuls « élèves » sont les élèves en thèse avec BS; et
bientôt les graduates avec qui je fais un groupe d'étude sur la
programmation template. Mais ceux là ont déjà dépassé le stade :-).
Il arrive simplement que presque toujours, je suis d'accord avec
ses choix pédagogiques -- il y a cependant des points vraiment
mineurs sur lesquels on a des avis légèrement différents. On en
discute, chacun justifiant sa vision. Il arrive même que des fois,
le lendemain on change d'avis et qu'on argue pour exactement la
position défendue par l'autre la veille :-)
N.B. Je ne crois pas réussir à te convaincre, je crois que c'est
un cas où il n'y a pas de « vérité ». Par contre, il faut
Je ne cherche pas « la vérité ». Je suis plus intéressé par une
démarche pédagogique.
On ne modifie pas la variable de contrôle d'un for dans la boucle.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe
plus ne me semble pas particulièrement utile:-).
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0
<= i < N. Quand on fait une comparaison, donc, on compare avec < N
ou >= 0.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
On ne modifie pas la variable de contrôle d'un for dans la boucle.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe
plus ne me semble pas particulièrement utile:-).
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou
=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0
<= i < N. Quand on fait une comparaison, donc, on compare avec < N
ou >= 0.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
On ne modifie pas la variable de contrôle d'un for dans la boucle.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe
plus ne me semble pas particulièrement utile:-).
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0
<= i < N. Quand on fait une comparaison, donc, on compare avec < N
ou >= 0.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le tableau
dans l'ordre croissant des indices. NB: L'indexation n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
Dans news:,On ne modifie pas la variable de contrôle d'un for dans la boucle.
Bien sûr. Tout comme on ne fait pas la guerre pour rien... :-)
On parle d'élèves et d'apprentissage ici.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de
la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Si i > N, anything goes, il y a une erreur dans le programme. Je
préfère continuer si ça permet de mieux m'en rendre compte...
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe plus
ne me semble pas particulièrement utile:-).
Le i n'existe pas, mais la condition de sortie reste vrai. Par
ailleurs, il arrive qu'on ne déclare pas la variable localement.
int indice;
for (indice=0 ; i!=N && !EstCeQueJeCherche(v[i]); ++i)
{}
if (i==N)
cout << "Pas trouvé ce que je cherchais";
else
cout << "Trouvé à " << indice;
[...]Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Je serais d'accord, mais curieusement c semble plus simple à
plusieurs...
[...]Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Oui... dont les indices varient de 0 à N-1...
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on ne
veut pas i==N comme indice...
[...]Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0 < > > i < N. Quand on fait une comparaison, donc, on compare avec < N ou
= 0.
Sans vouloir t'offusquer, il m'apparaît clairement tu décris comment
tu penses; c'est normal, je m'attends bien à ce que tu sois de ton
avis ! Mais peux-tu un instant voir qu'il y a d'autres façons de
penser ?
Si oui, tu verras que ce que je dis se tient tout autant. Ce n'est pas
la même chose, mais ça se tient tout autant.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
Il t'arrive souvent de décrire ce que tu as vu comme si c'était ce que
tout le monde fait...
Je ne saurais pour ma part prétendre savoir ce que tout le monde fait.
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais quand
même que j'ai certainement vu plus de programmeurs faire la même chose
que moi, que toi tu n'en as vu dans toute ta vie faire du C++ (bon,
c'est parce qu'il n'avait pas le choix, mais tout de même ! :-)
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
Tiens tu vois que tu penses comme ma solution c ci-haut :-)
Dans news:d6652001.0401300357.3e932cad@posting.google.com,
On ne modifie pas la variable de contrôle d'un for dans la boucle.
Bien sûr. Tout comme on ne fait pas la guerre pour rien... :-)
On parle d'élèves et d'apprentissage ici.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de
la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Si i > N, anything goes, il y a une erreur dans le programme. Je
préfère continuer si ça permet de mieux m'en rendre compte...
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe plus
ne me semble pas particulièrement utile:-).
Le i n'existe pas, mais la condition de sortie reste vrai. Par
ailleurs, il arrive qu'on ne déclare pas la variable localement.
int indice;
for (indice=0 ; i!=N && !EstCeQueJeCherche(v[i]); ++i)
{}
if (i==N)
cout << "Pas trouvé ce que je cherchais";
else
cout << "Trouvé à " << indice;
[...]
Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Je serais d'accord, mais curieusement c semble plus simple à
plusieurs...
[...]
Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Oui... dont les indices varient de 0 à N-1...
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on ne
veut pas i==N comme indice...
[...]
Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou
=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0 < > > i < N. Quand on fait une comparaison, donc, on compare avec < N ou
= 0.
Sans vouloir t'offusquer, il m'apparaît clairement tu décris comment
tu penses; c'est normal, je m'attends bien à ce que tu sois de ton
avis ! Mais peux-tu un instant voir qu'il y a d'autres façons de
penser ?
Si oui, tu verras que ce que je dis se tient tout autant. Ce n'est pas
la même chose, mais ça se tient tout autant.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
Il t'arrive souvent de décrire ce que tu as vu comme si c'était ce que
tout le monde fait...
Je ne saurais pour ma part prétendre savoir ce que tout le monde fait.
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais quand
même que j'ai certainement vu plus de programmeurs faire la même chose
que moi, que toi tu n'en as vu dans toute ta vie faire du C++ (bon,
c'est parce qu'il n'avait pas le choix, mais tout de même ! :-)
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
Tiens tu vois que tu penses comme ma solution c ci-haut :-)
Dans news:,On ne modifie pas la variable de contrôle d'un for dans la boucle.
Bien sûr. Tout comme on ne fait pas la guerre pour rien... :-)
On parle d'élèves et d'apprentissage ici.
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir de
la boucle quand i<N est faux donc si i >= N.
Est-ce que tu penses qu'il veut continuer dans la boucle si i > N ?
Si i > N, anything goes, il y a une erreur dans le programme. Je
préfère continuer si ça permet de mieux m'en rendre compte...
Ce n'est pas aussi précis que d'écrire i!=N qui indique que
j'arrêterai quand i==N. Avec i!=N, je sais exactement pourquoi je
suis sorti et quelle était la valeur de i.
C'est donc un espèce d'invariant sur ce qui suit la boucle. L'idée
vaut la peine d'être considérée.
L'argument serait plus fort si i existait encore après la boucle.
Exprimer une garantie sur la valeur d'une variable qui n'existe plus
ne me semble pas particulièrement utile:-).
Le i n'existe pas, mais la condition de sortie reste vrai. Par
ailleurs, il arrive qu'on ne déclare pas la variable localement.
int indice;
for (indice=0 ; i!=N && !EstCeQueJeCherche(v[i]); ++i)
{}
if (i==N)
cout << "Pas trouvé ce que je cherchais";
else
cout << "Trouvé à " << indice;
[...]Indiquer quelles boucles feront afficher les valeur entre 1 et
100 :
a) for (int i=0; i < 100; ++i) cout << i << 'n';
b) for (int i=0; i <= 100; ++i) cout << i+1 << 'n';
c) for (int i=0; i != 100; ++i) cout << i+1 << 'n';
d) for (int i=1; i <= 100; ++i) cout << i << 'n';
e) for (int i=1; i != 100; ++i) cout << i << 'n';
f) for (int i=1; i < 100; ++i) cout << i << 'n';
g) for (int i=1; i != 101; ++i) cout << i << 'n';
Je crois que tout le monde serait d'accord que la seule façon
« correcte » d'écrire ce code, c'est d.
Je serais d'accord, mais curieusement c semble plus simple à
plusieurs...
[...]Moi je dirais que ce que je viens d'expliquer c'est qu'on veut
« boucler de 0 à N-1 » non ?
Ce n'est pas vraiment comme ça que je l'entends. On veut boucler sur
tous les éléments d'un tableau de N éléments.
Oui... dont les indices varient de 0 à N-1...
Si les élèves n'ont pas encore compris ce que c'est qu'un intervalle
sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on ne
veut pas i==N comme indice...
[...]Je crois qu'on doit le voir un peu plus abstraitement. On veut
itérer sur un intervalle. Sur le côté fermé, la condition est <= ou=. Sur le côté ouvert, < ou >. Pour un tableau C++, donc, on a 0 < > > i < N. Quand on fait une comparaison, donc, on compare avec < N ou
= 0.
Sans vouloir t'offusquer, il m'apparaît clairement tu décris comment
tu penses; c'est normal, je m'attends bien à ce que tu sois de ton
avis ! Mais peux-tu un instant voir qu'il y a d'autres façons de
penser ?
Si oui, tu verras que ce que je dis se tient tout autant. Ce n'est pas
la même chose, mais ça se tient tout autant.
Le problème se complique pour les boucles déscendantes, parce que
l'affectation, ça établit toujours un rapport == (et donc <= et >=,
mais pas < ou >). L'initialization ne peut se faire donc que sur un
côté fermé. Moi, j'avais toujours cru que la solution classique,
connue et utilisée par tout le monde, c'était donc de maintenir
Il t'arrive souvent de décrire ce que tu as vu comme si c'était ce que
tout le monde fait...
Je ne saurais pour ma part prétendre savoir ce que tout le monde fait.
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais quand
même que j'ai certainement vu plus de programmeurs faire la même chose
que moi, que toi tu n'en as vu dans toute ta vie faire du C++ (bon,
c'est parce qu'il n'avait pas le choix, mais tout de même ! :-)
l'indice décalée d'un, c-à-d d'écrire « for ( int i = N ; i > 0 ;
-- i ) » et d'utiliser i-1 comme indice, mais des discussions
Tiens tu vois que tu penses comme ma solution c ci-haut :-)
le Tuesday 03 February 2004 03:05, écrivit :Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le
tableau dans l'ordre croissant des indices. NB: L'indexation
n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
oui mais i!=N est inutilement explicite.
Si on veut visiter un élément sur 2, on mets i+=2,
et la condition définissant implicitement les i valides reste
inchangé, par contre toi tu seras obligé de chercher quel sera le
dernier indice à tester.
La condition implicite est plus universelle et plus agréable (en
tout cas pour les esprits minimalistes :)
si la boucle se complique encore et qu'on a besoin maintenant de
i += (int) ceil(i*1.12);
la condition i<N est toujours aussi valide,
alors qu'il devient compliqué de trouver le test d'égalité à tester
précisément (et que ce serait de toute façon maladroit de tester une
égalité dans ce cas..)
le Tuesday 03 February 2004 03:05, mm@gdzid.com écrivit :
Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le
tableau dans l'ordre croissant des indices. NB: L'indexation
n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
oui mais i!=N est inutilement explicite.
Si on veut visiter un élément sur 2, on mets i+=2,
et la condition définissant implicitement les i valides reste
inchangé, par contre toi tu seras obligé de chercher quel sera le
dernier indice à tester.
La condition implicite est plus universelle et plus agréable (en
tout cas pour les esprits minimalistes :)
si la boucle se complique encore et qu'on a besoin maintenant de
i += (int) ceil(i*1.12);
la condition i<N est toujours aussi valide,
alors qu'il devient compliqué de trouver le test d'égalité à tester
précisément (et que ce serait de toute façon maladroit de tester une
égalité dans ce cas..)
le Tuesday 03 February 2004 03:05, écrivit :Pour moi, for (int i = 0; i < N; ++i) indique que je veux sortir
de la boucle quand i<N est faux donc si i >= N.
Et c'est ce qu'on vient d'expliquer au débutant : Visite le
tableau dans l'ordre croissant des indices. NB: L'indexation
n'est valable
C'est le ++i qui fait ça. Je mets ++i même avec i!=N...
oui mais i!=N est inutilement explicite.
Si on veut visiter un élément sur 2, on mets i+=2,
et la condition définissant implicitement les i valides reste
inchangé, par contre toi tu seras obligé de chercher quel sera le
dernier indice à tester.
La condition implicite est plus universelle et plus agréable (en
tout cas pour les esprits minimalistes :)
si la boucle se complique encore et qu'on a besoin maintenant de
i += (int) ceil(i*1.12);
la condition i<N est toujours aussi valide,
alors qu'il devient compliqué de trouver le test d'égalité à tester
précisément (et que ce serait de toute façon maladroit de tester une
égalité dans ce cas..)
"Michel Michaud" wrote in message
news:<cBDTb.6717$...On parle d'élèves et d'apprentissage ici.
Mais on parlait de ce qu'on *doit* faire.
Ou dont les indices sont dans l'intervalle mi-ouvert de [0;N[.
C'est la formulation traditionnelle en C. C'est une formulation que
j'approuve -- je n'ai jamais trop aimé la formulation Pascal sur
intervalle fermé.
Mais c'est une formulation traditionnelle. Un programme C qui
utilise des conventions du genre :
T array[ N - 1 ] ;
for ( int i = 0 ; i <= N ; ++ i ) ...
est aussi correct. Pas du tout idiomatique, et à mon avis, pas du
tout aussi robuste, mais tout à fait correct. (Et je me démande si
la robustesse de la formulation que je préfère ne dépend pas au
moins en partie du fait que c'est idiomatique.)Si les élèves n'ont pas encore compris ce que c'est qu'un
intervalle sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on
ne veut pas i==N comme indice...
Ni i == N+1, ni i == N+2, ni ...
Sinon, c'est à prendre comme une technique rhétorique. Ici, il
s'agit d'une discussion entre toi, moi, et Gaby. Nous avons tous
assez d'expérience pour savoir ce qui est une nécessité de base, et
ce qui est une question de style ou de préférence personnelle. Il y
a bien des cas limites, mais ceci n'en fait pas partie (je crois
que tu en seras d'accord). AMA, c'est tellement évident qu'on ne
parle que de nos préférences personnelles qu'il ne me semblait pas
la peine d'ajouter des AMHA sur toutes les phrases.
En fait, j'irais plus loin -- j'argue plutôt pour reflechir que
d'une conviction profonde. L'idiome classique, depuis les premiers
jours de C, c'était bien i<N. Ne serait-ce que parce que c'est ce
que faisait Kernighan et Richie. N'ayant pas vu de motivation
particulière à le récuser, je l'ai adopté ; j'écris mes boucles
comme ça depuis prèsque vingt ans (et comme j'ai dit, je le préfère
nettement à l'autre alternatif que j'avais vu, le i<=N-1 de Pascal).
Maintenant, tu viens, et tu me dis que ce n'est pas bien. Qu'il y a
des raisons concrètes (en dehors de la tradition) pour préférer un
autre style. Alors, je refléchis sur la question. Pour conclure que
tes raisons ne sont pas aussi concluantes que ça. Et qu'il y a
aussi des raisons techniques (en dehors de la tradition) pour
préférer ce que j'ai toujours fait.
Ceci dit, je trouve que dans les deux cas, les raisons techniques
sont bien faibles ; qu'elles ne valent pas assez pour rompre avec la
tradition. La tradition, en fin de compte, c'est ce que le lecteur
du code s'attend à voir. Si tu fais autrement, le lecteur commence
par poser la question « pourquoi » ? Qu'est-ce qu'il y a de
particulier qui fait que tu fais différemment.
Maintenant, il faut bien dire que les traditions dépend d'où tu te
situes. Et qu'elles peuvent aussi évoluer. Moi, je viens de C, et
j'ai toujours vu i<N. Toujours. Mais je conçois bien que sous
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais
quand même que j'ai certainement vu plus de programmeurs faire la
même chose que moi, que toi tu n'en as vu dans toute ta vie faire
du C++ (bon, c'est parce qu'il n'avait pas le choix, mais tout de
même ! :-)
Je ne sais pas. Combien as-tu vu qui le faisait avant la STL ?
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<cBDTb.6717$9U5.412404@news20.bellglobal.com>...
On parle d'élèves et d'apprentissage ici.
Mais on parlait de ce qu'on *doit* faire.
Ou dont les indices sont dans l'intervalle mi-ouvert de [0;N[.
C'est la formulation traditionnelle en C. C'est une formulation que
j'approuve -- je n'ai jamais trop aimé la formulation Pascal sur
intervalle fermé.
Mais c'est une formulation traditionnelle. Un programme C qui
utilise des conventions du genre :
T array[ N - 1 ] ;
for ( int i = 0 ; i <= N ; ++ i ) ...
est aussi correct. Pas du tout idiomatique, et à mon avis, pas du
tout aussi robuste, mais tout à fait correct. (Et je me démande si
la robustesse de la formulation que je préfère ne dépend pas au
moins en partie du fait que c'est idiomatique.)
Si les élèves n'ont pas encore compris ce que c'est qu'un
intervalle sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on
ne veut pas i==N comme indice...
Ni i == N+1, ni i == N+2, ni ...
Sinon, c'est à prendre comme une technique rhétorique. Ici, il
s'agit d'une discussion entre toi, moi, et Gaby. Nous avons tous
assez d'expérience pour savoir ce qui est une nécessité de base, et
ce qui est une question de style ou de préférence personnelle. Il y
a bien des cas limites, mais ceci n'en fait pas partie (je crois
que tu en seras d'accord). AMA, c'est tellement évident qu'on ne
parle que de nos préférences personnelles qu'il ne me semblait pas
la peine d'ajouter des AMHA sur toutes les phrases.
En fait, j'irais plus loin -- j'argue plutôt pour reflechir que
d'une conviction profonde. L'idiome classique, depuis les premiers
jours de C, c'était bien i<N. Ne serait-ce que parce que c'est ce
que faisait Kernighan et Richie. N'ayant pas vu de motivation
particulière à le récuser, je l'ai adopté ; j'écris mes boucles
comme ça depuis prèsque vingt ans (et comme j'ai dit, je le préfère
nettement à l'autre alternatif que j'avais vu, le i<=N-1 de Pascal).
Maintenant, tu viens, et tu me dis que ce n'est pas bien. Qu'il y a
des raisons concrètes (en dehors de la tradition) pour préférer un
autre style. Alors, je refléchis sur la question. Pour conclure que
tes raisons ne sont pas aussi concluantes que ça. Et qu'il y a
aussi des raisons techniques (en dehors de la tradition) pour
préférer ce que j'ai toujours fait.
Ceci dit, je trouve que dans les deux cas, les raisons techniques
sont bien faibles ; qu'elles ne valent pas assez pour rompre avec la
tradition. La tradition, en fin de compte, c'est ce que le lecteur
du code s'attend à voir. Si tu fais autrement, le lecteur commence
par poser la question « pourquoi » ? Qu'est-ce qu'il y a de
particulier qui fait que tu fais différemment.
Maintenant, il faut bien dire que les traditions dépend d'où tu te
situes. Et qu'elles peuvent aussi évoluer. Moi, je viens de C, et
j'ai toujours vu i<N. Toujours. Mais je conçois bien que sous
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais
quand même que j'ai certainement vu plus de programmeurs faire la
même chose que moi, que toi tu n'en as vu dans toute ta vie faire
du C++ (bon, c'est parce qu'il n'avait pas le choix, mais tout de
même ! :-)
Je ne sais pas. Combien as-tu vu qui le faisait avant la STL ?
"Michel Michaud" wrote in message
news:<cBDTb.6717$...On parle d'élèves et d'apprentissage ici.
Mais on parlait de ce qu'on *doit* faire.
Ou dont les indices sont dans l'intervalle mi-ouvert de [0;N[.
C'est la formulation traditionnelle en C. C'est une formulation que
j'approuve -- je n'ai jamais trop aimé la formulation Pascal sur
intervalle fermé.
Mais c'est une formulation traditionnelle. Un programme C qui
utilise des conventions du genre :
T array[ N - 1 ] ;
for ( int i = 0 ; i <= N ; ++ i ) ...
est aussi correct. Pas du tout idiomatique, et à mon avis, pas du
tout aussi robuste, mais tout à fait correct. (Et je me démande si
la robustesse de la formulation que je préfère ne dépend pas au
moins en partie du fait que c'est idiomatique.)Si les élèves n'ont pas encore compris ce que c'est qu'un
intervalle sémi-ouvert, c'est perdu d'avance.
Mais justement ! i=0 au départ donc i==0 au départ, par contre on
ne veut pas i==N comme indice...
Ni i == N+1, ni i == N+2, ni ...
Sinon, c'est à prendre comme une technique rhétorique. Ici, il
s'agit d'une discussion entre toi, moi, et Gaby. Nous avons tous
assez d'expérience pour savoir ce qui est une nécessité de base, et
ce qui est une question de style ou de préférence personnelle. Il y
a bien des cas limites, mais ceci n'en fait pas partie (je crois
que tu en seras d'accord). AMA, c'est tellement évident qu'on ne
parle que de nos préférences personnelles qu'il ne me semblait pas
la peine d'ajouter des AMHA sur toutes les phrases.
En fait, j'irais plus loin -- j'argue plutôt pour reflechir que
d'une conviction profonde. L'idiome classique, depuis les premiers
jours de C, c'était bien i<N. Ne serait-ce que parce que c'est ce
que faisait Kernighan et Richie. N'ayant pas vu de motivation
particulière à le récuser, je l'ai adopté ; j'écris mes boucles
comme ça depuis prèsque vingt ans (et comme j'ai dit, je le préfère
nettement à l'autre alternatif que j'avais vu, le i<=N-1 de Pascal).
Maintenant, tu viens, et tu me dis que ce n'est pas bien. Qu'il y a
des raisons concrètes (en dehors de la tradition) pour préférer un
autre style. Alors, je refléchis sur la question. Pour conclure que
tes raisons ne sont pas aussi concluantes que ça. Et qu'il y a
aussi des raisons techniques (en dehors de la tradition) pour
préférer ce que j'ai toujours fait.
Ceci dit, je trouve que dans les deux cas, les raisons techniques
sont bien faibles ; qu'elles ne valent pas assez pour rompre avec la
tradition. La tradition, en fin de compte, c'est ce que le lecteur
du code s'attend à voir. Si tu fais autrement, le lecteur commence
par poser la question « pourquoi » ? Qu'est-ce qu'il y a de
particulier qui fait que tu fais différemment.
Maintenant, il faut bien dire que les traditions dépend d'où tu te
situes. Et qu'elles peuvent aussi évoluer. Moi, je viens de C, et
j'ai toujours vu i<N. Toujours. Mais je conçois bien que sous
Je peux seulement dire ce que je vois dans les livres de personnes
bien considérés et sur les forums comme clc++m... Je te dirais
quand même que j'ai certainement vu plus de programmeurs faire la
même chose que moi, que toi tu n'en as vu dans toute ta vie faire
du C++ (bon, c'est parce qu'il n'avait pas le choix, mais tout de
même ! :-)
Je ne sais pas. Combien as-tu vu qui le faisait avant la STL ?