JKB a écrit :
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
JKB a écrit :
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
JKB a écrit :
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
ST a écrit :On 9/23/10 9:08 PM, JKB wrote:Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
surtout que le conteneur en question ,en théorie et à algo de tri
identique , c'est juste un pointeur qui pointe sur la valeur à tri,
que dalle en somme,et si l'on veut être pervers ,cela se résume à
quelques chargements de pages, en plus par rapport à un tri spécifique
ou couplé à un type de données ,houa mais c'est horrible
ST a écrit :
On 9/23/10 9:08 PM, JKB wrote:
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
surtout que le conteneur en question ,en théorie et à algo de tri
identique , c'est juste un pointeur qui pointe sur la valeur à tri,
que dalle en somme,et si l'on veut être pervers ,cela se résume à
quelques chargements de pages, en plus par rapport à un tri spécifique
ou couplé à un type de données ,houa mais c'est horrible
ST a écrit :On 9/23/10 9:08 PM, JKB wrote:Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
Le truc justement, c'est que NON, ca ne fait pas beaucoup d'argent. Et
ca a meme de fortes chances de couter bien moins cher que l'inge qui a
passe 2 mois a re-inventer la lune et qui va en repasser 2 a corriger
ses bugs.
surtout que le conteneur en question ,en théorie et à algo de tri
identique , c'est juste un pointeur qui pointe sur la valeur à tri,
que dalle en somme,et si l'on veut être pervers ,cela se résume à
quelques chargements de pages, en plus par rapport à un tri spécifique
ou couplé à un type de données ,houa mais c'est horrible
Le Thu, 23 Sep 2010 15:46:50 +0200,
remy écrivait :JKB a écrit :Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la ba se
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacit é de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de mà ©thode de
traitement, à méthode (algo de tri )identique le fait de tri er des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
Exemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp ()
qui s'arrête dès qu'on arrive à donner le signe du rà ©sultat, il y a
déjà une sacrée différence.
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet géné rique, le
résultat est aussi très mauvais.
En d'autres termes, un algorithme est _toujours_ adapté aux donnà ©es
à traiter.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
Je n'ai rien compris.
JKB
Le Thu, 23 Sep 2010 15:46:50 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la ba se
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacit é de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de mà ©thode de
traitement, à méthode (algo de tri )identique le fait de tri er des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
Exemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp ()
qui s'arrête dès qu'on arrive à donner le signe du rà ©sultat, il y a
déjà une sacrée différence.
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet géné rique, le
résultat est aussi très mauvais.
En d'autres termes, un algorithme est _toujours_ adapté aux donnà ©es
à traiter.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
Je n'ai rien compris.
JKB
Le Thu, 23 Sep 2010 15:46:50 +0200,
remy écrivait :JKB a écrit :Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la ba se
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacit é de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de mà ©thode de
traitement, à méthode (algo de tri )identique le fait de tri er des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
Exemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp ()
qui s'arrête dès qu'on arrive à donner le signe du rà ©sultat, il y a
déjà une sacrée différence.
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet géné rique, le
résultat est aussi très mauvais.
En d'autres termes, un algorithme est _toujours_ adapté aux donnà ©es
à traiter.
en fin de compte, l'incompétence n'est pas si chère
puisque dans 18 mois il passe de 1 à 5 et trois ans après de 1 à 2.5
pour un contexte somme toute peu banal
Je n'ai rien compris.
JKB
JKB a écrit :Le Thu, 23 Sep 2010 15:46:50 +0200,
remy écrivait :JKB a écrit :Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
donc on ne parle pas de la même chose
maintenant si tu veux oui une ferrari n'est pas faite pour labourer le
champ d'en faceExemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp()
qui s'arrête dès qu'on arrive à donner le signe du résultat, il y a
déjà une sacrée différence.
rien compris, ta chaine tu l'as copie si cela te fait plaisir en c
pourquoi pas ,mais tu ne t'arrêtes jamais en plein milieu c'est quoi ces
conneries
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet générique, le
résultat est aussi très mauvais.
mais cela n'existe pas un tri qui opère par copie,
réveille toi ma puce,
la copie elle ne se fait qu'à la fin et encore la plupart du temps
c'est un tableau de pointeurs, tu ne t'amuses pas à déplacer les données
En d'autres termes, un algorithme est _toujours_ adapté aux données
à traiter.
tu le fais exprès c'est pas possible je te parle
d'une couche d'abstraction qui va te permettre d'opérer un tri sur une
donnée avec un type (int ,string ,...) et c'est cette surcouche qui va
te permettre de faire ce tri sur n'importe quel type de données, le côté
modulaire tu te souviens, et toi tu me dis que ce sont des conneries
parce que cela rame et qu'il vaut mieux avoir à traiter les données
directement ce à quoi je te réponds que cela ne rame pas tant que cela
les pouillemes tu te souviens
après que ton algo soit codé comme un goret ou par le jdk de base je
m'en fous il ne rentre pas en ligne de compte puisque , j'ai supposé et
toi normalement aussi que la différence réside dans la notion
d'abstraction et non pas dans la qualité du codage de l'algo de tri
JKB a écrit :
Le Thu, 23 Sep 2010 15:46:50 +0200,
remy <remy@fctpas.fr> écrivait :
JKB a écrit :
Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
donc on ne parle pas de la même chose
maintenant si tu veux oui une ferrari n'est pas faite pour labourer le
champ d'en face
Exemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp()
qui s'arrête dès qu'on arrive à donner le signe du résultat, il y a
déjà une sacrée différence.
rien compris, ta chaine tu l'as copie si cela te fait plaisir en c
pourquoi pas ,mais tu ne t'arrêtes jamais en plein milieu c'est quoi ces
conneries
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet générique, le
résultat est aussi très mauvais.
mais cela n'existe pas un tri qui opère par copie,
réveille toi ma puce,
la copie elle ne se fait qu'à la fin et encore la plupart du temps
c'est un tableau de pointeurs, tu ne t'amuses pas à déplacer les données
En d'autres termes, un algorithme est _toujours_ adapté aux données
à traiter.
tu le fais exprès c'est pas possible je te parle
d'une couche d'abstraction qui va te permettre d'opérer un tri sur une
donnée avec un type (int ,string ,...) et c'est cette surcouche qui va
te permettre de faire ce tri sur n'importe quel type de données, le côté
modulaire tu te souviens, et toi tu me dis que ce sont des conneries
parce que cela rame et qu'il vaut mieux avoir à traiter les données
directement ce à quoi je te réponds que cela ne rame pas tant que cela
les pouillemes tu te souviens
après que ton algo soit codé comme un goret ou par le jdk de base je
m'en fous il ne rentre pas en ligne de compte puisque , j'ai supposé et
toi normalement aussi que la différence réside dans la notion
d'abstraction et non pas dans la qualité du codage de l'algo de tri
JKB a écrit :Le Thu, 23 Sep 2010 15:46:50 +0200,
remy écrivait :JKB a écrit :Je vais juste te donner un exemple parce que vu ton niveau
d'abstraction, il n'y a que ça que tu peux comprendre. Si j'ai un
algorithme de conversion d'une adresse postale en (x,y) et que je
m'appelle par exemple Mappy, j'ai une base de données de 10 Go
contenant toutes les voies françaises (c'est la taille de la base
NavTeq que j'ai sur ma machine). Si je gagne ne serait-ce que
10% dans les traitements parce que je n'ai pas écrit un tri
générique avec mon pied gauche, je gagne 10% de la capacité de mes
serveurs, ce qui est immédiatement _beaucoup_ d'argent.
déjà pour commencer, je parle d'abstraction et non pas de méthode de
traitement, à méthode (algo de tri )identique le fait de trier des
conteneurs ou des données brutes ,cela m'étonnerait beaucoup que tu ais
un rapport de 1 à 10 ,au mieux le mec est juste incompétent, et il a
comme tu dis utilisé le tri inadapté.
Tu peux très bien avoir un rapport de 1 à 10 parce que ton
algorithme n'est pas adapté du tout à ton tri.
donc on ne parle pas de la même chose
maintenant si tu veux oui une ferrari n'est pas faite pour labourer le
champ d'en faceExemple (parce que tu ne comprends que ça) :
tri d'une chaîne de caractères par ordre alphabétique.
Entre le strcmp() brutal qui va au bout de la chaîne et le strcmp()
qui s'arrête dès qu'on arrive à donner le signe du résultat, il y a
déjà une sacrée différence.
rien compris, ta chaine tu l'as copie si cela te fait plaisir en c
pourquoi pas ,mais tu ne t'arrêtes jamais en plein milieu c'est quoi ces
conneries
Maintenant, si ton tri opère par copie de chaîne plutôt que par
copie de pointeur parce qu'il ne connaît qu'un objet générique, le
résultat est aussi très mauvais.
mais cela n'existe pas un tri qui opère par copie,
réveille toi ma puce,
la copie elle ne se fait qu'à la fin et encore la plupart du temps
c'est un tableau de pointeurs, tu ne t'amuses pas à déplacer les données
En d'autres termes, un algorithme est _toujours_ adapté aux données
à traiter.
tu le fais exprès c'est pas possible je te parle
d'une couche d'abstraction qui va te permettre d'opérer un tri sur une
donnée avec un type (int ,string ,...) et c'est cette surcouche qui va
te permettre de faire ce tri sur n'importe quel type de données, le côté
modulaire tu te souviens, et toi tu me dis que ce sont des conneries
parce que cela rame et qu'il vaut mieux avoir à traiter les données
directement ce à quoi je te réponds que cela ne rame pas tant que cela
les pouillemes tu te souviens
après que ton algo soit codé comme un goret ou par le jdk de base je
m'en fous il ne rentre pas en ligne de compte puisque , j'ai supposé et
toi normalement aussi que la différence réside dans la notion
d'abstraction et non pas dans la qualité du codage de l'algo de tri
Si tu danses comme tu t'exprimes, tu dois te marcher sur les pieds.
Je reprends mon raisonnement une dernière fois : l'objet, c'est u n
truc pour rajouter une couche d'abstraction. Ce n'est pas mauvais en
soit, ce qui est mauvais, c'est l'écriture d'algorithmes soi-disa nt
génériques que permet cette couche d'abstraction. Si tu n'as pas
compris ce point, pas la peine de continuer.
Si tu danses comme tu t'exprimes, tu dois te marcher sur les pieds.
Je reprends mon raisonnement une dernière fois : l'objet, c'est u n
truc pour rajouter une couche d'abstraction. Ce n'est pas mauvais en
soit, ce qui est mauvais, c'est l'écriture d'algorithmes soi-disa nt
génériques que permet cette couche d'abstraction. Si tu n'as pas
compris ce point, pas la peine de continuer.
Si tu danses comme tu t'exprimes, tu dois te marcher sur les pieds.
Je reprends mon raisonnement une dernière fois : l'objet, c'est u n
truc pour rajouter une couche d'abstraction. Ce n'est pas mauvais en
soit, ce qui est mauvais, c'est l'écriture d'algorithmes soi-disa nt
génériques que permet cette couche d'abstraction. Si tu n'as pas
compris ce point, pas la peine de continuer.
Le Wed, 22 Sep 2010 23:32:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Le Wed, 22 Sep 2010 22:16:02 +0200,
Stephane CARPENTIER écrivait :Il y a 30 ans, tu pouvais demander à un jeune ingénieur de fai re des
multiplications avec une règle à calcul alors que maintenant, il te
demandera ce que c'est. La formation évolue, elle s'adapte.
Mauvais exemple : une multiplication, qu'elle se fasse sur un
cercle, une règle, un papier ou une calculette, ça reste une
multiplication.
Regarde le nombre d'ingénieurs capables de poser une division à la main.
Un truc comme 249/23 et tu verras que mon exemple n'est pas si mauva is
que ça.
Les ingénieurs ont appris ce qu'était une division, ils savent t oujours
ce que c'est, mais ils ont oublié comment ça se calculait (oui, j'ai
remplacé multiplication par division parce que c'est plus vrai, ma is le
principe est là).
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
Le Wed, 22 Sep 2010 23:32:15 +0200,
Stephane CARPENTIER <stef.carpentier@free.fr> écrivait :
JKB a écrit:
Le Wed, 22 Sep 2010 22:16:02 +0200,
Stephane CARPENTIER <stef.carpentier@free.fr> écrivait :
Il y a 30 ans, tu pouvais demander à un jeune ingénieur de fai re des
multiplications avec une règle à calcul alors que maintenant, il te
demandera ce que c'est. La formation évolue, elle s'adapte.
Mauvais exemple : une multiplication, qu'elle se fasse sur un
cercle, une règle, un papier ou une calculette, ça reste une
multiplication.
Regarde le nombre d'ingénieurs capables de poser une division à la main.
Un truc comme 249/23 et tu verras que mon exemple n'est pas si mauva is
que ça.
Les ingénieurs ont appris ce qu'était une division, ils savent t oujours
ce que c'est, mais ils ont oublié comment ça se calculait (oui, j'ai
remplacé multiplication par division parce que c'est plus vrai, ma is le
principe est là).
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
Le Wed, 22 Sep 2010 23:32:15 +0200,
Stephane CARPENTIER écrivait :JKB a écrit:Le Wed, 22 Sep 2010 22:16:02 +0200,
Stephane CARPENTIER écrivait :Il y a 30 ans, tu pouvais demander à un jeune ingénieur de fai re des
multiplications avec une règle à calcul alors que maintenant, il te
demandera ce que c'est. La formation évolue, elle s'adapte.
Mauvais exemple : une multiplication, qu'elle se fasse sur un
cercle, une règle, un papier ou une calculette, ça reste une
multiplication.
Regarde le nombre d'ingénieurs capables de poser une division à la main.
Un truc comme 249/23 et tu verras que mon exemple n'est pas si mauva is
que ça.
Les ingénieurs ont appris ce qu'était une division, ils savent t oujours
ce que c'est, mais ils ont oublié comment ça se calculait (oui, j'ai
remplacé multiplication par division parce que c'est plus vrai, ma is le
principe est là).
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseud o
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseud o
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseud o
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
L'étude des tris fait partie de la base de l'algorithmique. Ne pas aller
dans les détails et ne pas étudier certains tris n'est pas étonnant. Mais
qu'il n'y ait plus d'étude d'algorithmes dans la majorité des formations est
étonnant.Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
Pour toi qui fais du calcul et tu as besoins d'optimiser les ressources ou
les performances en fonction des cas. Mais pour la majorité des programmes,
vu la puissance des processeurs actuels par rapport au nombre de données à
trier, un mauvais choix d'algorithme ne se verra pas souvent.
JKB a écrit:
Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
L'étude des tris fait partie de la base de l'algorithmique. Ne pas aller
dans les détails et ne pas étudier certains tris n'est pas étonnant. Mais
qu'il n'y ait plus d'étude d'algorithmes dans la majorité des formations est
étonnant.
Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
Pour toi qui fais du calcul et tu as besoins d'optimiser les ressources ou
les performances en fonction des cas. Mais pour la majorité des programmes,
vu la puissance des processeurs actuels par rapport au nombre de données à
trier, un mauvais choix d'algorithme ne se verra pas souvent.
JKB a écrit:Est-ce que tu vois la subtile différence entre un tri à la
shell-Metzner et une division ? Lorsque tu parles division à un
ingénieur, il sait de quoi tu parles. Lorsque tu cause tri
shell-Metzner à un ingénieur, il te regarde avec des grands yeux
vides. Il n'a _jamais_ entendu parlé
Ça m'étonne un peu. Que certain ingénieurs n'en aient jamais entendus parler
ne m'étonne pas. Mais que la majorité des formations n'en parle plus, me
surprend.
L'étude des tris fait partie de la base de l'algorithmique. Ne pas aller
dans les détails et ne pas étudier certains tris n'est pas étonnant. Mais
qu'il n'y ait plus d'étude d'algorithmes dans la majorité des formations est
étonnant.Sauf que ne sachant
pas quelles sont les différences entre tous ces tris, il va très
rapidement dans le mur.
Pour toi qui fais du calcul et tu as besoins d'optimiser les ressources ou
les performances en fonction des cas. Mais pour la majorité des programmes,
vu la puissance des processeurs actuels par rapport au nombre de données à
trier, un mauvais choix d'algorithme ne se verra pas souvent.
Michel Talon a écrit:J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseudo
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
Parce qui'il faut moins de temps pour développer un gros programme en java
qu'en assembleur,
parce qu'il est plus simple de débugger un gros programme
en java qu'en assembleur,
parce que les ordinateurs actuels sont
suffisemment puissants pour que la majorité des programmes actuels n'aient
plus besoins d'être optimisés.
Michel Talon a écrit:
J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseudo
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
Parce qui'il faut moins de temps pour développer un gros programme en java
qu'en assembleur,
parce qu'il est plus simple de débugger un gros programme
en java qu'en assembleur,
parce que les ordinateurs actuels sont
suffisemment puissants pour que la majorité des programmes actuels n'aient
plus besoins d'être optimisés.
Michel Talon a écrit:J'ai l'impression que ceci
a été largement remplacé par un formattage aux techniques pseudo
psychos, programmation objet, design patterns, etc. pour des raisons que
j'ignore.
Parce qui'il faut moins de temps pour développer un gros programme en java
qu'en assembleur,
parce qu'il est plus simple de débugger un gros programme
en java qu'en assembleur,
parce que les ordinateurs actuels sont
suffisemment puissants pour que la majorité des programmes actuels n'aient
plus besoins d'être optimisés.
Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un truc
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un truc
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
Le type qui a codé un algorithme de tri dans une
base comme Postgre, crois-tu qu'il a utilisé bêtement un truc
existant ? Non, il l'a codé avec ses petites mimines pour que son
algorithme de tri colle au mieux à ses données. Faire autre chose
est une connerie incommensurable.
