On apprend plus les suites en Mathématiques à l'école ?
<snip>
Si l'on a compris ça, on a compris la récursivité.
Comprendre comment cela marche ne signifie pas que l'on soit capable d'utiliser, c'es-à-dire de résoudre un problème d'arithmétique (où a priori il n'y a pas de suite ou série visibles) en *introduisant* des suites ou des séries.
Et là, je n'ai pas l'impression que les élèves qui sortent du lycée soient tous capables de le faire (à commencer par moi à l'époque.)
Antoine
Richard Delorme écrivit :
On apprend plus les suites en Mathématiques à l'école ?
<snip>
Si l'on a compris ça, on a compris la récursivité.
Comprendre comment cela marche ne signifie pas que l'on soit capable
d'utiliser, c'es-à-dire de résoudre un problème d'arithmétique (où a
priori il n'y a pas de suite ou série visibles) en *introduisant* des
suites ou des séries.
Et là, je n'ai pas l'impression que les élèves qui sortent du lycée
soient tous capables de le faire (à commencer par moi à l'époque.)
On apprend plus les suites en Mathématiques à l'école ?
<snip>
Si l'on a compris ça, on a compris la récursivité.
Comprendre comment cela marche ne signifie pas que l'on soit capable d'utiliser, c'es-à-dire de résoudre un problème d'arithmétique (où a priori il n'y a pas de suite ou série visibles) en *introduisant* des suites ou des séries.
Et là, je n'ai pas l'impression que les élèves qui sortent du lycée soient tous capables de le faire (à commencer par moi à l'époque.)
Antoine
Antoine Leca
candide a écrit :
Wykaaa a écrit :
[ contexte utile rajouté ] ::: On n'est pas un programmeur nul si on ne maitrise pas la récursivité.
Bin si, justement. Tiens, écrit un éditeur de lien sans utiliser la récursion, juste pour voir...
Et tu crois que tout programmeur C a le background pour écrire un éditeur de liens ? Le programmeur qui écrit un compilateur ou des outils de ce genre n'est pas le programmeur lambda.
Je crois que tu as loupé l'argument de François.
Au début (disons jusque vers 1980, ±15 ans pour me couvrir), les éditeurs de liens n'utilisaient pas de récursivité dans la recherche des symboles indéfinis dans les bibliothèques, et pour palier ce /léger/ problème, les utilisateurs de ces éditeurs devaient jongler avec des outils comme ranlib, lorder/tsort, pour ranger les modules objet « dans le bon ordre » dans les bibliothèques, afin que l'éditeur des liens puisse en une seule passe trouver tous les modules à lier. Et s'il y avait des cycles, la seule solution était de faire manuellement plusieurs passes de ld -r. Hideuse solution, que François attribue à des programmeurs nuls.
T'as un lien vers les sources de ld ou un truc du genre ?
[ contexte utile rajouté ]
::: On n'est pas un programmeur nul si on ne maitrise pas la récursivité.
Bin si, justement. Tiens, écrit un éditeur de lien sans utiliser la
récursion, juste pour voir...
Et tu crois que tout programmeur C a le background pour écrire un
éditeur de liens ? Le programmeur qui écrit un compilateur ou des outils
de ce genre n'est pas le programmeur lambda.
Je crois que tu as loupé l'argument de François.
Au début (disons jusque vers 1980, ±15 ans pour me couvrir), les
éditeurs de liens n'utilisaient pas de récursivité dans la recherche des
symboles indéfinis dans les bibliothèques, et pour palier ce /léger/
problème, les utilisateurs de ces éditeurs devaient jongler avec des
outils comme ranlib, lorder/tsort, pour ranger les modules objet
« dans le bon ordre » dans les bibliothèques, afin que l'éditeur des
liens puisse en une seule passe trouver tous les modules à lier. Et s'il
y avait des cycles, la seule solution était de faire manuellement
plusieurs passes de ld -r. Hideuse solution, que François attribue à des
programmeurs nuls.
T'as un lien vers les sources de ld ou un truc du genre ?
[ contexte utile rajouté ] ::: On n'est pas un programmeur nul si on ne maitrise pas la récursivité.
Bin si, justement. Tiens, écrit un éditeur de lien sans utiliser la récursion, juste pour voir...
Et tu crois que tout programmeur C a le background pour écrire un éditeur de liens ? Le programmeur qui écrit un compilateur ou des outils de ce genre n'est pas le programmeur lambda.
Je crois que tu as loupé l'argument de François.
Au début (disons jusque vers 1980, ±15 ans pour me couvrir), les éditeurs de liens n'utilisaient pas de récursivité dans la recherche des symboles indéfinis dans les bibliothèques, et pour palier ce /léger/ problème, les utilisateurs de ces éditeurs devaient jongler avec des outils comme ranlib, lorder/tsort, pour ranger les modules objet « dans le bon ordre » dans les bibliothèques, afin que l'éditeur des liens puisse en une seule passe trouver tous les modules à lier. Et s'il y avait des cycles, la seule solution était de faire manuellement plusieurs passes de ld -r. Hideuse solution, que François attribue à des programmeurs nuls.
T'as un lien vers les sources de ld ou un truc du genre ?
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je concentre mes efforts vers les algorithmes. Je me concentre vers le langage assembleur. Je ne veux pas approfondir. Avant d'aller plus loin dans la programmation, je veux comprendre ce qui se passe dans la machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil. Les analogies ont toutes leurs limites, alors disons pour simplifier que C a ses raisons d'être pour les pros, mais que débuter avec ça en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main" A moins que les ASM ne se soient simplifiés depuis 10 ans, pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou apprendre à programmer, un langage comme Python est plus approprié que le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe d'excellent livres sur les algorithmes, en C (Algorithms in C de R. Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très peu à l'aide de langage plus abordables.
-- Richard
Le 30/11/2009 11:27, Marc Boyer a écrit :
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, bpascal123@googlemail.com<bpascal123@googlemail.com> a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je
concentre mes efforts vers les algorithmes. Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus
loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil.
Les analogies ont toutes leurs limites, alors disons pour simplifier
que C a ses raisons d'être pour les pros, mais que débuter avec ça
en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main"
A moins que les ASM ne se soient simplifiés depuis 10 ans,
pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou
apprendre à programmer, un langage comme Python est plus approprié que
le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe
d'excellent livres sur les algorithmes, en C (Algorithms in C de R.
Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très
peu à l'aide de langage plus abordables.
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je concentre mes efforts vers les algorithmes. Je me concentre vers le langage assembleur. Je ne veux pas approfondir. Avant d'aller plus loin dans la programmation, je veux comprendre ce qui se passe dans la machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil. Les analogies ont toutes leurs limites, alors disons pour simplifier que C a ses raisons d'être pour les pros, mais que débuter avec ça en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main" A moins que les ASM ne se soient simplifiés depuis 10 ans, pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou apprendre à programmer, un langage comme Python est plus approprié que le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe d'excellent livres sur les algorithmes, en C (Algorithms in C de R. Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très peu à l'aide de langage plus abordables.
-- Richard
Marc Boyer
Le 30-11-2009, Richard Delorme a écrit :
Le 30/11/2009 11:27, Marc Boyer a écrit :
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je concentre mes efforts vers les algorithmes. Je me concentre vers le langage assembleur. Je ne veux pas approfondir. Avant d'aller plus loin dans la programmation, je veux comprendre ce qui se passe dans la machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil. Les analogies ont toutes leurs limites, alors disons pour simplifier que C a ses raisons d'être pour les pros, mais que débuter avec ça en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main" A moins que les ASM ne se soient simplifiés depuis 10 ans, pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou apprendre à programmer, un langage comme Python est plus approprié que le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe d'excellent livres sur les algorithmes, en C (Algorithms in C de R. Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très peu à l'aide de langage plus abordables.
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ? Je n'ai pas d'idée sur celui de Sedgevick que je ne connais pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle a trouver le minimum, le maximum et calculer la moyenne d'une suite de nombres. C'est arriver à contruire un entier en lisant les chiffres pas la gauche ou par la droite. C'est arriver à afficher un nombre en affichant les chiffres un par un.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 30-11-2009, Richard Delorme <abulmo@nospam.fr> a écrit :
Le 30/11/2009 11:27, Marc Boyer a écrit :
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, bpascal123@googlemail.com a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je
concentre mes efforts vers les algorithmes. Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus
loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil.
Les analogies ont toutes leurs limites, alors disons pour simplifier
que C a ses raisons d'être pour les pros, mais que débuter avec ça
en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main"
A moins que les ASM ne se soient simplifiés depuis 10 ans,
pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou
apprendre à programmer, un langage comme Python est plus approprié que
le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe
d'excellent livres sur les algorithmes, en C (Algorithms in C de R.
Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très
peu à l'aide de langage plus abordables.
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ?
Je n'ai pas d'idée sur celui de Sedgevick que je ne connais
pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle
a trouver le minimum, le maximum et calculer la moyenne d'une
suite de nombres. C'est arriver à contruire un entier en lisant
les chiffres pas la gauche ou par la droite. C'est arriver à afficher
un nombre en affichant les chiffres un par un.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Bon, mon passé d'enseignant me fait bondir quand je lit tout ça.
Le 28-11-2009, a écrit :
J'interviens su r ce forum de manière irrégulière, pour l'instant je concentre mes efforts vers les algorithmes. Je me concentre vers le langage assembleur. Je ne veux pas approfondir. Avant d'aller plus loin dans la programmation, je veux comprendre ce qui se passe dans la machine tant que c'est à "porter de mains".
1) Pour apprendre l'algorithmique, le C est un bien mauvais outil. Les analogies ont toutes leurs limites, alors disons pour simplifier que C a ses raisons d'être pour les pros, mais que débuter avec ça en 2009, c'est chercher les complications.
2) L'assembleur, ce n'est justement pas "à portée de main" A moins que les ASM ne se soient simplifiés depuis 10 ans, pleins de pb von se poser au débutant.
Je suis d'accord avec ce que tu dis et pour explorer des algorithmes ou apprendre à programmer, un langage comme Python est plus approprié que le langage C ou l'assembleur. Une nuance néanmoins, c'est qu'il existe d'excellent livres sur les algorithmes, en C (Algorithms in C de R. Sedgevick) ou en Assembleur (The Art of Programming de D. Knuth) et très peu à l'aide de langage plus abordables.
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ? Je n'ai pas d'idée sur celui de Sedgevick que je ne connais pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle a trouver le minimum, le maximum et calculer la moyenne d'une suite de nombres. C'est arriver à contruire un entier en lisant les chiffres pas la gauche ou par la droite. C'est arriver à afficher un nombre en affichant les chiffres un par un.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Wykaaa
Marc Boyer a écrit :
Le 29-11-2009, Wykaaa a écrit :
candide a écrit :
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien compris à la récursivité donc te crois pas obligé de passer par ce pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de comprendre la récursivité quand on est programmeur. Ceci est totalement faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Tout algorithme qui requiert un automate à pile est souvent beaucoup plus facile à coder de façon récursive (exemple : la reconnaissance syntaxique des expressions arithmétiques). Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome NIH (Not Invented Here).
La récursivité est un concept clé de la programmation (et de l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi, et Turing aussi... Est-ce bien nécessaire pour faire un site de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Marc Boyer a écrit :
Le 29-11-2009, Wykaaa <wykaaa@yahoo.fr> a écrit :
candide a écrit :
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est totalement
faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien
plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va
s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome
NIH (Not Invented Here).
La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi,
et Turing aussi... Est-ce bien nécessaire pour faire un site
de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien compris à la récursivité donc te crois pas obligé de passer par ce pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de comprendre la récursivité quand on est programmeur. Ceci est totalement faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Tout algorithme qui requiert un automate à pile est souvent beaucoup plus facile à coder de façon récursive (exemple : la reconnaissance syntaxique des expressions arithmétiques). Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome NIH (Not Invented Here).
La récursivité est un concept clé de la programmation (et de l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi, et Turing aussi... Est-ce bien nécessaire pour faire un site de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Marc Boyer
Le 30-11-2009, Wykaaa a écrit :
Marc Boyer a écrit :
Le 29-11-2009, Wykaaa a écrit :
candide a écrit :
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien compris à la récursivité donc te crois pas obligé de passer par ce pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de comprendre la récursivité quand on est programmeur. Ceci est totalement faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Que cette définition varie suivant celui qui la prononce. Je préfère parler de chemin de progression, et la récursivité n'est pas sur le tout début du chemin. Et l'OP a pas mal de choses à voir avant AMHA.
Tout algorithme qui requiert un automate à pile est souvent beaucoup plus facile à coder de façon récursive (exemple : la reconnaissance syntaxique des expressions arithmétiques). Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome NIH (Not Invented Here).
Ben si j'ai à choisir entre passer 4h sur la récurcivité et passer 4h sur les bienfaits de la réutilisation de code éprouvé, mon choix est vite fait (cf notion de chemin vue avant).
La récursivité est un concept clé de la programmation (et de l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi, et Turing aussi... Est-ce bien nécessaire pour faire un site de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Je ne suis pas expert en bug de WEB 2.0, mais j'aurais tendance à croire que c'est plus à cause de glue mal faites entre composants (ie mauvais emplois de la ré-utilisation, paquetage, encapsulation) que de notions de récursivité mal comprises.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 30-11-2009, Wykaaa <wykaaa@yahoo.fr> a écrit :
Marc Boyer a écrit :
Le 29-11-2009, Wykaaa <wykaaa@yahoo.fr> a écrit :
candide a écrit :
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est totalement
faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Que cette définition varie suivant celui qui la prononce.
Je préfère parler de chemin de progression, et la récursivité
n'est pas sur le tout début du chemin. Et l'OP a pas mal
de choses à voir avant AMHA.
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien
plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va
s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome
NIH (Not Invented Here).
Ben si j'ai à choisir entre passer 4h sur la récurcivité et passer
4h sur les bienfaits de la réutilisation de code éprouvé, mon choix
est vite fait (cf notion de chemin vue avant).
La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi,
et Turing aussi... Est-ce bien nécessaire pour faire un site
de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Je ne suis pas expert en bug de WEB 2.0, mais j'aurais tendance à croire
que c'est plus à cause de glue mal faites entre composants (ie mauvais
emplois de la ré-utilisation, paquetage, encapsulation) que de notions
de récursivité mal comprises.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien compris à la récursivité donc te crois pas obligé de passer par ce pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de comprendre la récursivité quand on est programmeur. Ceci est totalement faux.
Ca dépend de la définition de "programmeur".
Qu'est-ce à dire ?
Que cette définition varie suivant celui qui la prononce. Je préfère parler de chemin de progression, et la récursivité n'est pas sur le tout début du chemin. Et l'OP a pas mal de choses à voir avant AMHA.
Tout algorithme qui requiert un automate à pile est souvent beaucoup plus facile à coder de façon récursive (exemple : la reconnaissance syntaxique des expressions arithmétiques). Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien plus faciles à programmer de façon récursive.
Mais dans la vraie vie, ils ont été empaquetté dans un truc qui va s'appeller std::map, java.util.TreeSet, lex/yak ou un truc du genre.
C'est vrai mais il y en a encore beaucoup qui sont victimes du syndrome NIH (Not Invented Here).
Ben si j'ai à choisir entre passer 4h sur la récurcivité et passer 4h sur les bienfaits de la réutilisation de code éprouvé, mon choix est vite fait (cf notion de chemin vue avant).
La récursivité est un concept clé de la programmation (et de l'informatique et des mathématiques en général).
Oui, la notion de calculabilité aussi, et le typage aussi, et Turing aussi... Est-ce bien nécessaire pour faire un site de e-commerce ?
On ne se plaindra pas du fait que les sites de e-commerce soient bogués :-)
Je ne suis pas expert en bug de WEB 2.0, mais j'aurais tendance à croire que c'est plus à cause de glue mal faites entre composants (ie mauvais emplois de la ré-utilisation, paquetage, encapsulation) que de notions de récursivité mal comprises.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Erwan David
Marc Boyer écrivait :
Le 29-11-2009, Samuel Devulder a écrit :
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce qui coince c'est la ROM et la RAM. Elles sont toutes petites en embarqué, et on préfère de loin, mais vraiment de loin, optimiser en taille (rom/ram) qu'en vitesse.
Je pense qu'il y a différents mondes "embarqués". Chez les avioneurs, on réduit aussi le nombre de CPU (pour diminuer l'alim), et on a tendance à charger la CPU le plus qu'on puisse (en restant déterministe).
Il existe des calculateurs qui sont vraiment très chargés.
mon embarqué était celui des terminaux de paiement bancaire. Là on chercheiat à minimiser l'empreinte mémoire (code, donnée et pile) au détriment peut-être des performances.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 29-11-2009, Samuel Devulder <samuel-dot-devulder@geensys.com> a écrit :
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz
sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui
arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce
qui coince c'est la ROM et la RAM. Elles sont toutes petites en
embarqué, et on préfère de loin, mais vraiment de loin, optimiser en
taille (rom/ram) qu'en vitesse.
Je pense qu'il y a différents mondes "embarqués". Chez les avioneurs,
on réduit aussi le nombre de CPU (pour diminuer l'alim), et on a
tendance à charger la CPU le plus qu'on puisse (en restant déterministe).
Il existe des calculateurs qui sont vraiment très chargés.
mon embarqué était celui des terminaux de paiement bancaire. Là on
chercheiat à minimiser l'empreinte mémoire (code, donnée et pile) au
détriment peut-être des performances.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce qui coince c'est la ROM et la RAM. Elles sont toutes petites en embarqué, et on préfère de loin, mais vraiment de loin, optimiser en taille (rom/ram) qu'en vitesse.
Je pense qu'il y a différents mondes "embarqués". Chez les avioneurs, on réduit aussi le nombre de CPU (pour diminuer l'alim), et on a tendance à charger la CPU le plus qu'on puisse (en restant déterministe).
Il existe des calculateurs qui sont vraiment très chargés.
mon embarqué était celui des terminaux de paiement bancaire. Là on chercheiat à minimiser l'empreinte mémoire (code, donnée et pile) au détriment peut-être des performances.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Non, vax n'est pas passe a elf. C'est pas si simple que ca. Si ces outils n'etaient pas buggues, ca se saurait...
espie
In article , wrote:
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui lui même est relancé par f(1) qui à nouveau appelle f(0). C'est l'empilement des appels. Donc pour chacun de ces appels, l'exécution de la fonction f s'est arrêté à la ligne suivante :
Bonjour, J'ai pu comprendre le concept de récursivité avec votre explication. Je comprends également que pour comprendre des récursions plus "sophistiquées", une compréhension de ce qui se passe en compilation/ assembleur est nécessaire.
Non. C'est necessaire pour comprendre comment ca fonctionne en pratique et comment c'est implemente dans la machine. Ca n'est pas necessaire pour *utiliser* de la recursion sophistiquee.
Je pense à l'accès des données en mémoire.
T'as juste besoin du concept de variable locale. Une fois que tu as saisi que dans une fonction recursive f(int i), ben tu as une variable i *differente* par niveau de recursion, ben tu sais tout. T'as pas besoin de savoir comment la machine gere ca pour t'en servir...
In article <458d9849-cb8d-447f-ac6c-5bae713a45dc@e23g2000yqd.googlegroups.com>,
bpascal123@googlemail.com <bpascal123@googlemail.com> wrote:
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire.
Non. C'est necessaire pour comprendre comment ca fonctionne en pratique
et comment c'est implemente dans la machine. Ca n'est pas necessaire
pour *utiliser* de la recursion sophistiquee.
Je pense à l'accès des données en mémoire.
T'as juste besoin du concept de variable locale. Une fois que tu as saisi
que dans une fonction recursive f(int i), ben tu as une variable i *differente*
par niveau de recursion, ben tu sais tout. T'as pas besoin de savoir comment
la machine gere ca pour t'en servir...
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui lui même est relancé par f(1) qui à nouveau appelle f(0). C'est l'empilement des appels. Donc pour chacun de ces appels, l'exécution de la fonction f s'est arrêté à la ligne suivante :
Bonjour, J'ai pu comprendre le concept de récursivité avec votre explication. Je comprends également que pour comprendre des récursions plus "sophistiquées", une compréhension de ce qui se passe en compilation/ assembleur est nécessaire.
Non. C'est necessaire pour comprendre comment ca fonctionne en pratique et comment c'est implemente dans la machine. Ca n'est pas necessaire pour *utiliser* de la recursion sophistiquee.
Je pense à l'accès des données en mémoire.
T'as juste besoin du concept de variable locale. Une fois que tu as saisi que dans une fonction recursive f(int i), ben tu as une variable i *differente* par niveau de recursion, ben tu sais tout. T'as pas besoin de savoir comment la machine gere ca pour t'en servir...
Richard Delorme
Le 30/11/2009 13:31, Marc Boyer a écrit :
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ? Je n'ai pas d'idée sur celui de Sedgevick que je ne connais pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle a trouver le minimum, le maximum et calculer la moyenne d'une suite de nombres. C'est arriver à contruire un entier en lisant les chiffres pas la gauche ou par la droite. C'est arriver à afficher un nombre en affichant les chiffres un par un.
Je pensait au stade suivant, quand on est plus débutant, mais pas encore un expert.
-- Richard
Le 30/11/2009 13:31, Marc Boyer a écrit :
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ?
Je n'ai pas d'idée sur celui de Sedgevick que je ne connais
pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle
a trouver le minimum, le maximum et calculer la moyenne d'une
suite de nombres. C'est arriver à contruire un entier en lisant
les chiffres pas la gauche ou par la droite. C'est arriver à afficher
un nombre en affichant les chiffres un par un.
Je pensait au stade suivant, quand on est plus débutant, mais pas encore
un expert.
Là encore, qu'appelle-t-on "apprendre l'algorithmique" ? Je n'ai pas d'idée sur celui de Sedgevick que je ne connais pas. Mais celui de Knuth me semble hors de portée d'un débutant.
L'algorithmique du débutant, c'est arriver dans une seule boucle a trouver le minimum, le maximum et calculer la moyenne d'une suite de nombres. C'est arriver à contruire un entier en lisant les chiffres pas la gauche ou par la droite. C'est arriver à afficher un nombre en affichant les chiffres un par un.
Je pensait au stade suivant, quand on est plus débutant, mais pas encore un expert.
