si je suppose que le c++ est encore en train de trainer dans les bars
=E0 la recherche de son domaine d'application ,=E0 mon avis il
est trop tard et il finira alcolo tout comme le caml ou ocaml
un truc qui a le m=E9rite d'exister et c'est d=E9j=E0 pas mal
que java depuis le rachat de sun a un avenir incertain
la programmation obj a tout de m=EAme un domaine de pr=E9dilection
les interfaces graphiques ou programmations =E9v=E8nementielles
et pourtant il y a un autre domaine o=F9 il pourrait =EAtre super utile
au hasard les os
par exemple un langage obj multi thread
comment faire en 3 coups de cuill=E8re =E0 pot un os minimaliste
4 fifo (4 niveaux de priorit=E9)
1 thread maitre qui parcourt les fifos et lance les thread
qui sont dans le fifo
un thread qui remplit le fifo
et un petit dernier qui alloue les zones m=E9moire
et pour faire plaisir =E0 jdk on ne l'appellera pas garbage collector
(je plaisante )
puisque dans un thread, on a tout ce qu'il nous faut pour suspendre
arr=EAter ou lancer un processus, avec en plus des m=E9canismes de
protection m=E9moire li=E9s au concept obj, donc pourquoi s'en passer
en gros l'id=E9e consiste =E0 gagner du temps processeur
en d=E9finissant en statique "d=E9finition du langage" tous les contr=F4l=
es
qui sont actuellement faits en dynamique contr=F4le sur les signaux
protection m=E9moire etc
en plus si les threads sont bien pens=E9s l'on peut faire du scalaire ou
du vrai parall=E9lisme
quand pensez vous ?
sans compter que pour les nostalgiques on peut le faire en c mais avec
des r=E8gles li=E9es aux biblioth=E8ques
Le 07-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 06-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
dit différemment la meilleure optimisation qui soit c'est la lisibilité du code
Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un bout de code, surtout en calcul intensif, ce n'est pas la lisibilité du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu verras que c'est même assez souvent orthogonal comme notion.
oui mais le calcul intensif ne représente pas grand chose en terme de quantité de lignes écrites,l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul
Gnîii ? Comme tu travailles sur une représentation finie, je te mets au défi de séparer le calcul théorique de sa représentation infromatique sans un jour ou l'autre se tirer une balle dans le pied !
donc on est d'accord
Tu as écrit exactement le contraire deux lignes au-dessus, mais passons.
c'est moi qui suis bourré ou tu me lis mal
Je cite :
"l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul"
Je pense que tu en es au point où tu ne comprends plus ce que tu écris (et ne t'étonne pas alors de ne pas être compris par d'autres).
quand je lis "l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul"
pour moi cela implique que l'optimisation de la transposition ou de l'écriture du calcul en langage pour ordinateur passé par la moulinette du compilateur n'est pas une nécessité absolue tu comprends quoi toi ?
Encore moins que la première fois. Si tu danses comme tu t'exprimes, tu dois te marcher sur les pieds.
tiens un exemple posté il n'y a pas longtemps sur fsm tu peux optimiser tout ce que tu veux "code pondu à l'arraché"
si je ne le fais pas, c'est pas toi qui le ferra :-)
Surtout vu le contenu de l'enfilade...
je m'en fou de l'enfilade ,je prends juste un exemple et une question qui restent en suspens pour moi, qui en plus rentre parfaitement dans le cadre, l'on a bien un calcul intensif et une non-optimisation ,se compliquer la vie ne sert pas à grand chose sauf à se faire plaisir
Et à bouffer dix fois moins de mémoire (300 Mo contre 3 Go) et à donner un résultat en trois heures au lieu d'une grosse journée. Sinon, effectivement, ça ne change rien.
je n'en suis absolument pas convaincu cela voudrait dire que ceux qui ont écrit le code sont mauvais ,ils ne sont peut être pas au paroxysme de leur art, mais certainement pas mauvais, si c'est le cas ,c'est que tes choix sont à revoir ou mal adaptés ou que cela n'existe pas encore
Je n'ai jamais prétendu qu'ils sont mauvais. Je te dis juste qu'une bibliothèque d'usage générique ne peut pas être optimale.
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le traitement, de la donnée traitée
Ce qui est une connerie monumentale. Explique-moi sans rire comment optimiser un code sans utiliser au mieux les données du problème ou leur structure. Séparer le fond de la forme lorsqu'on cherche l'efficacité, c'est un non-sens.
un machin incompréhensible et un conteneur et toi tu n'implémentes que le conteneur ,le code qui le traite c'est pas ton problème (cela ne te regarde pas) ,il a été dans une vie antérieure la prise de tête de quelqu'un d'autre que je suppose compétent
Je n'ai jamais dit que cette personne n'était pas compétente. Je prétends simplement, preuves à l'appui (et démonstrations mathématiques, mais avec toi, ça ne servirait à rien) que la résolution d'un problème générique est toujours plus complexe que celle d'un problème identique sur lequel tu as plus d'hypothèses. Je devrais te renvoyer relire Dieu.
Je te donne encore un exemple, ce sera le dernier. Lorsque tu égalise un canal en transmission, tu as très souvent des grosses matrices à inverser (du style 1E6 * 1E6 éléments complexes, cas courant pour les Rake2D un peu chiadés de l'UMTS, côté station de base). Comme tu suréchantillonnes d'un facteur 2 (la plupart du temps), ta matrice n'a aucune raison d'être inversible. Mais tu as de la chance, il y a du bruit sur le canal de transmission et tu _sais_ par construction que ta matrice _sera_ inversible parce que ce bruit est décorrélé. Tu as donc deux solutions : 1/ utiliser une routine existante, bête et méchante, qui effectue l'inversion. Elle effectue même tellement bien l'inversion qu'elle regarde à chaque étape si la matrice est de rang plein (et oui, vu la taille de la matrice, elle ne peut pas partir du principe que le calcul de la condition de la matrice au début du calcul est significatif...) ; 2/ calculer une pseudo-inverse ; 3/ utiliser une routine qui ne fait pas cette vérification mais qui ne peut pas être générique. Il serait de _très_ mauvais goût qu'une inversion de matrice de type
[[ 1 2 ] 1 2 ]]
te renvoie une exception !
À ton avis, quelle est la différence de vitesse d'exécution ? Je t'aide, la différence n'est pas à la marge ni dans le trait de crayon. Si maintenant, tu découpes ton problème parce que tu as vu que ta matrice est une matrice diagonale bande au bruit près, tu peux coder ton inversion en décomposant ta matrice en LDU, ce qui revient à dire que ton inversion de matrice se résout à un coefficient multiplicatif près en deux filtres convolutifs de longueur la moitié de la longueur de la bande diagonale. Tu passes donc d'un algorithme qui est au moins en N**3 en quelque chose qui est en N**2. Lorsque N vaut quelques millions, c'est loin d'être négligeable. Mais cette inversion est encore moins utilisable pour un algorithme générique puisqu'il suppose juste l'existence d'une décomposition LDU de la matrice initiale.
bon tu l'as fait péter la valda sur ton A*
Des exemples, j'en ai plein. En revanche, tu as l'air chagriné par le A*.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 07-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 06-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
dit différemment
la meilleure optimisation qui soit
c'est la lisibilité du code
Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un
bout de code, surtout en calcul intensif, ce n'est pas la lisibilité
du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu
verras que c'est même assez souvent orthogonal comme notion.
oui mais le calcul intensif ne représente pas grand chose en terme
de quantité de lignes écrites,l'optimisation réside plus dans la méthode
de calcul que dans l'écriture du calcul
Gnîii ? Comme tu travailles sur une représentation finie, je te mets
au défi de séparer le calcul théorique de sa représentation
infromatique sans un jour ou l'autre se tirer une balle dans le
pied !
donc on est d'accord
Tu as écrit exactement le contraire deux lignes au-dessus, mais
passons.
c'est moi qui suis bourré ou tu me lis mal
Je cite :
"l'optimisation réside plus dans la méthode de calcul que dans
l'écriture du calcul"
Je pense que tu en es au point où tu ne comprends plus ce que tu
écris (et ne t'étonne pas alors de ne pas être compris par
d'autres).
quand je lis "l'optimisation réside plus dans la méthode de
calcul que dans l'écriture du calcul"
pour moi cela implique que l'optimisation de la transposition ou
de l'écriture du calcul en langage pour ordinateur passé par la
moulinette du compilateur n'est pas une nécessité absolue
tu comprends quoi toi ?
Encore moins que la première fois. Si tu danses comme tu t'exprimes,
tu dois te marcher sur les pieds.
tiens un exemple posté il n'y a pas longtemps sur fsm
tu peux optimiser tout ce que tu veux "code pondu à l'arraché"
si je ne le fais pas, c'est pas toi qui le ferra :-)
Surtout vu le contenu
de l'enfilade...
je m'en fou de l'enfilade ,je prends juste un exemple et une question
qui restent en suspens pour moi, qui en plus rentre parfaitement dans le
cadre, l'on a bien un calcul intensif et une non-optimisation ,se
compliquer la vie ne sert pas à grand chose sauf à se faire plaisir
Et à bouffer dix fois moins de mémoire (300 Mo contre 3 Go) et à
donner un résultat en trois heures au lieu d'une grosse journée.
Sinon, effectivement, ça ne change rien.
je n'en suis absolument pas convaincu cela voudrait dire que ceux qui
ont écrit le code sont mauvais ,ils ne sont peut être pas au paroxysme
de leur art, mais certainement pas mauvais, si c'est le cas ,c'est que
tes choix sont à revoir ou mal adaptés ou que cela n'existe pas encore
Je n'ai jamais prétendu qu'ils sont mauvais. Je te dis juste qu'une
bibliothèque d'usage générique ne peut pas être optimale.
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le
traitement, de la donnée traitée
Ce qui est une connerie monumentale. Explique-moi sans rire comment
optimiser un code sans utiliser au mieux les données du problème ou
leur structure. Séparer le fond de la forme lorsqu'on cherche
l'efficacité, c'est un non-sens.
un machin incompréhensible et un conteneur
et toi tu n'implémentes que le conteneur ,le code qui le traite c'est
pas ton problème (cela ne te regarde pas) ,il a été dans une vie
antérieure la prise de tête de quelqu'un d'autre que je suppose
compétent
Je n'ai jamais dit que cette personne n'était pas compétente. Je
prétends simplement, preuves à l'appui (et démonstrations
mathématiques, mais avec toi, ça ne servirait à rien) que la
résolution d'un problème générique est toujours plus complexe que
celle d'un problème identique sur lequel tu as plus d'hypothèses.
Je devrais te renvoyer relire Dieu.
Je te donne encore un exemple, ce sera le dernier. Lorsque tu
égalise un canal en transmission, tu as très souvent des grosses
matrices à inverser (du style 1E6 * 1E6 éléments complexes, cas
courant pour les Rake2D un peu chiadés de l'UMTS, côté station de
base). Comme tu suréchantillonnes d'un facteur 2 (la plupart du
temps), ta matrice n'a aucune raison d'être inversible. Mais tu as
de la chance, il y a du bruit sur le canal de transmission et tu
_sais_ par construction que ta matrice _sera_ inversible parce que
ce bruit est décorrélé. Tu as donc deux solutions :
1/ utiliser une routine existante, bête et méchante, qui effectue
l'inversion. Elle effectue même tellement bien l'inversion qu'elle
regarde à chaque étape si la matrice est de rang plein (et oui, vu
la taille de la matrice, elle ne peut pas partir du principe que le
calcul de la condition de la matrice au début du calcul est
significatif...) ;
2/ calculer une pseudo-inverse ;
3/ utiliser une routine qui ne fait pas cette vérification mais qui
ne peut pas être générique. Il serait de _très_ mauvais goût qu'une
inversion de matrice de type
[[ 1 2 ]
1 2 ]]
te renvoie une exception !
À ton avis, quelle est la différence de vitesse d'exécution ?
Je t'aide, la différence n'est pas à la marge ni dans le trait de
crayon. Si maintenant, tu découpes ton problème parce que tu as vu
que ta matrice est une matrice diagonale bande au bruit près, tu
peux coder ton inversion en décomposant ta matrice en LDU, ce qui
revient à dire que ton inversion de matrice se résout à un
coefficient multiplicatif près en deux filtres convolutifs de
longueur la moitié de la longueur de la bande diagonale. Tu passes
donc d'un algorithme qui est au moins en N**3 en quelque chose
qui est en N**2. Lorsque N vaut quelques millions, c'est
loin d'être négligeable. Mais cette inversion est encore moins
utilisable pour un algorithme générique puisqu'il suppose juste
l'existence d'une décomposition LDU de la matrice initiale.
bon tu l'as fait péter la valda sur ton A*
Des exemples, j'en ai plein. En revanche, tu as l'air chagriné par
le A*.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 07-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
Le 06-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
JKB a écrit :
dit différemment la meilleure optimisation qui soit c'est la lisibilité du code
Venant de toi, on ne peut s'attendre à mieux. L'optimisation d'un bout de code, surtout en calcul intensif, ce n'est pas la lisibilité du code. Si tu ouvres n'importe quel bouquin d'analyse numérique, tu verras que c'est même assez souvent orthogonal comme notion.
oui mais le calcul intensif ne représente pas grand chose en terme de quantité de lignes écrites,l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul
Gnîii ? Comme tu travailles sur une représentation finie, je te mets au défi de séparer le calcul théorique de sa représentation infromatique sans un jour ou l'autre se tirer une balle dans le pied !
donc on est d'accord
Tu as écrit exactement le contraire deux lignes au-dessus, mais passons.
c'est moi qui suis bourré ou tu me lis mal
Je cite :
"l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul"
Je pense que tu en es au point où tu ne comprends plus ce que tu écris (et ne t'étonne pas alors de ne pas être compris par d'autres).
quand je lis "l'optimisation réside plus dans la méthode de calcul que dans l'écriture du calcul"
pour moi cela implique que l'optimisation de la transposition ou de l'écriture du calcul en langage pour ordinateur passé par la moulinette du compilateur n'est pas une nécessité absolue tu comprends quoi toi ?
Encore moins que la première fois. Si tu danses comme tu t'exprimes, tu dois te marcher sur les pieds.
tiens un exemple posté il n'y a pas longtemps sur fsm tu peux optimiser tout ce que tu veux "code pondu à l'arraché"
si je ne le fais pas, c'est pas toi qui le ferra :-)
Surtout vu le contenu de l'enfilade...
je m'en fou de l'enfilade ,je prends juste un exemple et une question qui restent en suspens pour moi, qui en plus rentre parfaitement dans le cadre, l'on a bien un calcul intensif et une non-optimisation ,se compliquer la vie ne sert pas à grand chose sauf à se faire plaisir
Et à bouffer dix fois moins de mémoire (300 Mo contre 3 Go) et à donner un résultat en trois heures au lieu d'une grosse journée. Sinon, effectivement, ça ne change rien.
je n'en suis absolument pas convaincu cela voudrait dire que ceux qui ont écrit le code sont mauvais ,ils ne sont peut être pas au paroxysme de leur art, mais certainement pas mauvais, si c'est le cas ,c'est que tes choix sont à revoir ou mal adaptés ou que cela n'existe pas encore
Je n'ai jamais prétendu qu'ils sont mauvais. Je te dis juste qu'une bibliothèque d'usage générique ne peut pas être optimale.
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le traitement, de la donnée traitée
Ce qui est une connerie monumentale. Explique-moi sans rire comment optimiser un code sans utiliser au mieux les données du problème ou leur structure. Séparer le fond de la forme lorsqu'on cherche l'efficacité, c'est un non-sens.
un machin incompréhensible et un conteneur et toi tu n'implémentes que le conteneur ,le code qui le traite c'est pas ton problème (cela ne te regarde pas) ,il a été dans une vie antérieure la prise de tête de quelqu'un d'autre que je suppose compétent
Je n'ai jamais dit que cette personne n'était pas compétente. Je prétends simplement, preuves à l'appui (et démonstrations mathématiques, mais avec toi, ça ne servirait à rien) que la résolution d'un problème générique est toujours plus complexe que celle d'un problème identique sur lequel tu as plus d'hypothèses. Je devrais te renvoyer relire Dieu.
Je te donne encore un exemple, ce sera le dernier. Lorsque tu égalise un canal en transmission, tu as très souvent des grosses matrices à inverser (du style 1E6 * 1E6 éléments complexes, cas courant pour les Rake2D un peu chiadés de l'UMTS, côté station de base). Comme tu suréchantillonnes d'un facteur 2 (la plupart du temps), ta matrice n'a aucune raison d'être inversible. Mais tu as de la chance, il y a du bruit sur le canal de transmission et tu _sais_ par construction que ta matrice _sera_ inversible parce que ce bruit est décorrélé. Tu as donc deux solutions : 1/ utiliser une routine existante, bête et méchante, qui effectue l'inversion. Elle effectue même tellement bien l'inversion qu'elle regarde à chaque étape si la matrice est de rang plein (et oui, vu la taille de la matrice, elle ne peut pas partir du principe que le calcul de la condition de la matrice au début du calcul est significatif...) ; 2/ calculer une pseudo-inverse ; 3/ utiliser une routine qui ne fait pas cette vérification mais qui ne peut pas être générique. Il serait de _très_ mauvais goût qu'une inversion de matrice de type
[[ 1 2 ] 1 2 ]]
te renvoie une exception !
À ton avis, quelle est la différence de vitesse d'exécution ? Je t'aide, la différence n'est pas à la marge ni dans le trait de crayon. Si maintenant, tu découpes ton problème parce que tu as vu que ta matrice est une matrice diagonale bande au bruit près, tu peux coder ton inversion en décomposant ta matrice en LDU, ce qui revient à dire que ton inversion de matrice se résout à un coefficient multiplicatif près en deux filtres convolutifs de longueur la moitié de la longueur de la bande diagonale. Tu passes donc d'un algorithme qui est au moins en N**3 en quelque chose qui est en N**2. Lorsque N vaut quelques millions, c'est loin d'être négligeable. Mais cette inversion est encore moins utilisable pour un algorithme générique puisqu'il suppose juste l'existence d'une décomposition LDU de la matrice initiale.
bon tu l'as fait péter la valda sur ton A*
Des exemples, j'en ai plein. En revanche, tu as l'air chagriné par le A*.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
remy
debug this fifo a écrit :
remy wrote:
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le traitement, de la donnée traitée
j'crois que c'est clair...
un machin incompréhensible et un conteneur et toi tu n'implémentes que le conteneur ,le code qui le traite c'es t pas ton problème (cela ne te regarde pas) ,il a été dans une vie antérieure la prise de tête de quelqu'un d'autre que je suppose compétent
...je ne comprends pas le remysien.
bon en gros et à l'arrachée une interface
public interface Comparator { int compare(T Object); }
un obj pour mes données
public class Mydonnee implement Comparator { Integer a; Mydonnee(Integer a) { this.a=a; } int compare(T Object) { //0=egale,1=plus grand,-1=plus petit return a.compareTo(t); } }
le code principal
import MonAlgodeTriaLaCon.*;
public class Main { public static void main(String args[]) throws IOException {
//creation de l'obj MonAlgodeTriaLaCon tri=new MonAlgodeTriaLaCon();
//init de la structure for(int i=0;i<10;i++) { tri.add(new Mydonnee(new Integer(i))); }
//recuperation de la sortie Vector v=trie.getsortieCroissante(); Vector v=trie.getsortieDecroissante(); }
fin du code principal
et voilà je ne connais pas l'algo de l'obj MonAlgodeTriaLaCon
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le
traitement, de la donnée traitée
j'crois que c'est clair...
un machin incompréhensible et un conteneur
et toi tu n'implémentes que le conteneur ,le code qui le traite c'es t
pas ton problème (cela ne te regarde pas) ,il a été dans une vie
antérieure la prise de tête de quelqu'un d'autre que je suppose
compétent
...je ne comprends pas le remysien.
bon en gros et à l'arrachée
une interface
public interface Comparator
{
int compare(T Object);
}
un obj pour mes données
public class Mydonnee implement Comparator
{
Integer a;
Mydonnee(Integer a)
{
this.a=a;
}
int compare(T Object)
{
//0=egale,1=plus grand,-1=plus petit
return a.compareTo(t);
}
}
le code principal
import MonAlgodeTriaLaCon.*;
public class Main
{
public static void main(String args[]) throws IOException
{
//creation de l'obj
MonAlgodeTriaLaCon tri=new MonAlgodeTriaLaCon();
//init de la structure
for(int i=0;i<10;i++)
{
tri.add(new Mydonnee(new Integer(i)));
}
//recuperation de la sortie
Vector v=trie.getsortieCroissante();
Vector v=trie.getsortieDecroissante();
}
fin du code principal
et voilà je ne connais pas l'algo de l'obj
MonAlgodeTriaLaCon
sauf en langage obj où l'on peut, doit, ou espérer, dissocier le traitement, de la donnée traitée
j'crois que c'est clair...
un machin incompréhensible et un conteneur et toi tu n'implémentes que le conteneur ,le code qui le traite c'es t pas ton problème (cela ne te regarde pas) ,il a été dans une vie antérieure la prise de tête de quelqu'un d'autre que je suppose compétent
...je ne comprends pas le remysien.
bon en gros et à l'arrachée une interface
public interface Comparator { int compare(T Object); }
un obj pour mes données
public class Mydonnee implement Comparator { Integer a; Mydonnee(Integer a) { this.a=a; } int compare(T Object) { //0=egale,1=plus grand,-1=plus petit return a.compareTo(t); } }
le code principal
import MonAlgodeTriaLaCon.*;
public class Main { public static void main(String args[]) throws IOException {
//creation de l'obj MonAlgodeTriaLaCon tri=new MonAlgodeTriaLaCon();
//init de la structure for(int i=0;i<10;i++) { tri.add(new Mydonnee(new Integer(i))); }
//recuperation de la sortie Vector v=trie.getsortieCroissante(); Vector v=trie.getsortieDecroissante(); }
fin du code principal
et voilà je ne connais pas l'algo de l'obj MonAlgodeTriaLaCon
je peut faire un tri sur la taille des strings, des entiers, des bigInteger des bigdecimal ou autre
$ man 3 qsort
:~$ man a* No manual entry for a* :~$ man A* No manual entry for A* :~$
:-(
-- http://remyaumeunier.chez-alice.fr/
JKB
Le 07-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
voila voili
je peut faire un tri sur la taille des strings, des entiers, des bigInteger des bigdecimal ou autre
$ man 3 qsort
:~$ man a* No manual entry for a* :~$ man A* No manual entry for A* :~$
:-(
Est-ce que tu es bête ou est-ce que tu le fais exprès ? Tu ouvres ton navigateur préféré et tu tapes astar. L'A* est une évolution de l'algorithme de Dijkstra, optimal mais souvent non utilisable sur des cas concrets. L'immense majorité est implantations est faite en C++, parce que c'est simple. Tu remarqueras que je n'en disconviens pas. Par contre, lorsque tu groupes la représentation du graphe et l'algorithme en utilisant les propriétés de l'un pour optimiser l'autre, tu obtiens de bien meilleurs résultats.
Idem d'ailleurs pour le quick sort. Le quick sort est un bon algorithme, mais dans un cas moyen. Dans certains cas, il peut être largement pire que le tri bulle !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 07-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
voila voili
je peut faire un tri sur la taille des strings,
des entiers, des bigInteger des bigdecimal ou autre
$ man 3 qsort
remy@remy:~$ man a*
No manual entry for a*
remy@remy:~$ man A*
No manual entry for A*
remy@remy:~$
:-(
Est-ce que tu es bête ou est-ce que tu le fais exprès ? Tu ouvres
ton navigateur préféré et tu tapes astar. L'A* est une évolution de
l'algorithme de Dijkstra, optimal mais souvent non utilisable sur
des cas concrets. L'immense majorité est implantations est faite en
C++, parce que c'est simple. Tu remarqueras que je n'en disconviens
pas. Par contre, lorsque tu groupes la représentation du graphe et
l'algorithme en utilisant les propriétés de l'un pour optimiser
l'autre, tu obtiens de bien meilleurs résultats.
Idem d'ailleurs pour le quick sort. Le quick sort est un bon
algorithme, mais dans un cas moyen. Dans certains cas, il peut être
largement pire que le tri bulle !
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 07-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
voila voili
je peut faire un tri sur la taille des strings, des entiers, des bigInteger des bigdecimal ou autre
$ man 3 qsort
:~$ man a* No manual entry for a* :~$ man A* No manual entry for A* :~$
:-(
Est-ce que tu es bête ou est-ce que tu le fais exprès ? Tu ouvres ton navigateur préféré et tu tapes astar. L'A* est une évolution de l'algorithme de Dijkstra, optimal mais souvent non utilisable sur des cas concrets. L'immense majorité est implantations est faite en C++, parce que c'est simple. Tu remarqueras que je n'en disconviens pas. Par contre, lorsque tu groupes la représentation du graphe et l'algorithme en utilisant les propriétés de l'un pour optimiser l'autre, tu obtiens de bien meilleurs résultats.
Idem d'ailleurs pour le quick sort. Le quick sort est un bon algorithme, mais dans un cas moyen. Dans certains cas, il peut être largement pire que le tri bulle !
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
remy
JKB a écrit :
Le 07-04-2010, ? propos de Re: os et concept de langage, remy ?crivait dans fr.comp.os.linux.debats :
debug this fifo a écrit :
remy wrote:
voila voili
je peut faire un tri sur la taille des strings, des entiers, des bigInteger des bigdecimal ou autre
$ man 3 qsort
:~$ man a* No manual entry for a* :~$ man A* No manual entry for A* :~$
:-(
Est-ce que tu es bête ou est-ce que tu le fais exprès ? Tu ouvres ton navigateur préféré et tu tapes astar.
Maze maze = new Maze(20, 20); maze.draw(); maze.findBestPath(); }
}
quoi mais c'est super simple ton machin tu crées un graphe avec du random tu le dessines et tu cherches le meilleur chemin
il y a aussi http://www.cuspy.com/software/pathfinder/
Écoute, ce sera ma dernière contribution (sauf si tu indiques des résultats) parce que tu n'en vaux pas la peine :
1/ personne ne prétend ici (en tout cas pas moi), que la programmation objet ne donne pas un code source compact ; 2/ je prétends (et je peux le prouver au besoin) que ton code n'est pas efficace pour toutes les raisons que je t'ai données ; 3/ tu ne comprends visiblement pas le français ; 4/ tu n'as strictement rien compris aux exemples que je t'ai donnés ; 5/ tu ne comprends pas ce qu'est une preuve.
Au passage, j'aimerais que tu me calcules un trajet allant de Bayonne à Strasbourg avec ton algorithme en Java et que tu m'indiques le temps de calcul et l'occupation mémoire du truc. En C++ avec Boost et pgrouting, il faut quelques minutes et plus de 2 Go de mémoire rien que pour le stockage du graphe (sur mon core2duo 2,2 GHz muni de 4 Go de mémoire). Je l'ai fait aussi en Java, c'est _pire_. Actuellement, je fais de genre de choses avec un algorithme aux petits oignons sur un T1 à 1 GHz (donc un truc pas du tout rapide en monothread) en deux secondes une fois le graphe digéré. D'ailleurs Le graphe ne prend que 300 Mo de mémoire, ce qui permet d'utiliser les 32 voies du serveur dans commencer à utiliser la mémoire virtuelle, ce qui est non négligeable. L'algorithme est écrit en RPL/2 et RPL/C. Pour ton information, le graphe des voies carrossables compte un peu plus de 7 millions d'arêtes et je tiens compte des sens interdits, donc au final, tu as largement plus de 7 millions d'arêtes.
J'attends avec impatience tes résultats puisque tu ne sais pas ce qu'est une preuve.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 07-04-2010, ? propos de
Re: os et concept de langage,
remy ?crivait dans fr.comp.os.linux.debats :
tiens juste pour te faire râler ou relancer le troll
Maze maze = new Maze(20, 20);
maze.draw();
maze.findBestPath();
}
}
quoi mais c'est super simple ton machin
tu crées un graphe avec du random
tu le dessines
et tu cherches le meilleur chemin
il y a aussi
http://www.cuspy.com/software/pathfinder/
Écoute, ce sera ma dernière contribution (sauf si tu indiques des
résultats) parce que tu n'en vaux pas la peine :
1/ personne ne prétend ici (en tout cas pas moi), que la
programmation objet ne donne pas un code source compact ;
2/ je prétends (et je peux le prouver au besoin) que ton code n'est
pas efficace pour toutes les raisons que je t'ai données ;
3/ tu ne comprends visiblement pas le français ;
4/ tu n'as strictement rien compris aux exemples que je t'ai donnés ;
5/ tu ne comprends pas ce qu'est une preuve.
Au passage, j'aimerais que tu me calcules un trajet allant de
Bayonne à Strasbourg avec ton algorithme en Java et que tu
m'indiques le temps de calcul et l'occupation mémoire du truc.
En C++ avec Boost et pgrouting, il faut quelques minutes et plus de
2 Go de mémoire rien que pour le stockage du graphe (sur mon
core2duo 2,2 GHz muni de 4 Go de mémoire). Je l'ai fait aussi en Java,
c'est _pire_. Actuellement, je fais de genre de choses
avec un algorithme aux petits oignons sur un T1 à 1 GHz (donc un truc
pas du tout rapide en monothread) en deux secondes une fois le graphe
digéré. D'ailleurs Le graphe ne prend que 300 Mo de mémoire, ce qui
permet d'utiliser les 32 voies du serveur dans commencer à utiliser
la mémoire virtuelle, ce qui est non négligeable. L'algorithme est
écrit en RPL/2 et RPL/C. Pour ton information, le graphe des voies
carrossables compte un peu plus de 7 millions d'arêtes et je tiens
compte des sens interdits, donc au final, tu as largement plus de 7
millions d'arêtes.
J'attends avec impatience tes résultats puisque tu ne sais pas ce
qu'est une preuve.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Maze maze = new Maze(20, 20); maze.draw(); maze.findBestPath(); }
}
quoi mais c'est super simple ton machin tu crées un graphe avec du random tu le dessines et tu cherches le meilleur chemin
il y a aussi http://www.cuspy.com/software/pathfinder/
Écoute, ce sera ma dernière contribution (sauf si tu indiques des résultats) parce que tu n'en vaux pas la peine :
1/ personne ne prétend ici (en tout cas pas moi), que la programmation objet ne donne pas un code source compact ; 2/ je prétends (et je peux le prouver au besoin) que ton code n'est pas efficace pour toutes les raisons que je t'ai données ; 3/ tu ne comprends visiblement pas le français ; 4/ tu n'as strictement rien compris aux exemples que je t'ai donnés ; 5/ tu ne comprends pas ce qu'est une preuve.
Au passage, j'aimerais que tu me calcules un trajet allant de Bayonne à Strasbourg avec ton algorithme en Java et que tu m'indiques le temps de calcul et l'occupation mémoire du truc. En C++ avec Boost et pgrouting, il faut quelques minutes et plus de 2 Go de mémoire rien que pour le stockage du graphe (sur mon core2duo 2,2 GHz muni de 4 Go de mémoire). Je l'ai fait aussi en Java, c'est _pire_. Actuellement, je fais de genre de choses avec un algorithme aux petits oignons sur un T1 à 1 GHz (donc un truc pas du tout rapide en monothread) en deux secondes une fois le graphe digéré. D'ailleurs Le graphe ne prend que 300 Mo de mémoire, ce qui permet d'utiliser les 32 voies du serveur dans commencer à utiliser la mémoire virtuelle, ce qui est non négligeable. L'algorithme est écrit en RPL/2 et RPL/C. Pour ton information, le graphe des voies carrossables compte un peu plus de 7 millions d'arêtes et je tiens compte des sens interdits, donc au final, tu as largement plus de 7 millions d'arêtes.
J'attends avec impatience tes résultats puisque tu ne sais pas ce qu'est une preuve.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
