Discussion :

[LiquidHuk]

Bonjour !

J'ai cod� un algorithme A* qui fonctionne tr�s bien, mais que j'aimerais optimiser car il devra � terme tourner sur une Raspberry Pi. Le temps d'initialisation (chargement de graphe par exemple) peut �tre long tant que les recherches de chemin derri�re sont rapides. L'objectif serait d'obtenir une recherche de chemin sur une surface de 200*300 avec des pas de 20, en plus d'un lissage post A* afin d'�viter les d�placements saccad�s. Est-ce r�aliste de viser un temps de calcul de l'ordre de la demi-seconde ?

J'avais au d�part une cr�ation � la vol�e des noeuds � chaque recherche de chemin, que j'ai modifi� pour qu'ils soient tous cr��s dans le constructeur. J'ai rang� les noeuds dans un std::vector, et je les retrouve � l'aide de leur id.
Je me demandais si ce ne serait pas plus int�ressant de cr�er un tableau � deux dimensions dans lequel je placerais les noeuds � la case correspondant � leur coordonn�e sur la surface, quitte � diviser les coordonn�es par 20 (le pas) afin d'�viter les cases de tableau vides ?

Afin d'assurer l'absence de fuite de m�moires, j'utilise des shared_ptr pour manipuler les noeuds, est-ce que cela all�gerait notablement les calculs d'utiliser de simples pointeurs ?

Merci d'avance pour vos r�ponses !

[ternel]

Bonjour,

Attention, vector risque d'�tre trop lent, si tu fais juste un find.
Pr�f�re au choix: un arbre ou un binary_search sur un vector tri�.

La grille est envisageable, elle aussi, renseigne-toi sur le quad-tree.

Si tu as juste une liste constante, un vecteur de pointeurs nus, c'est plus rapide (moins de controles)
Si en plus, tous tes n�uds sont de la meme classe, un vecteur de n�ud est encore mieux.

[LiquidHuk]

Merci pour tes conseils. Le quad_tree est vraiment int�ressant.

Quand tu dis :

Si en plus, tous tes n�uds sont de la meme classe, un vecteur de n�ud est encore mieux.

Tu parles d'un std::vector<Noeud> au lieu de std::vector<Noeud*> ?

[Iradrille]

Attention, vector risque d'�tre trop lent, si tu fais juste un find.
Pr�f�re au choix: un arbre ou un binary_search sur un vector tri�.

Ou un unordered_set vu que la recherche se fait par id.

(binary_search je connaissais pas, je recodais une recherche dichotomique d�s que j'avais un vector tri�, merci �a va m'�viter de refaire �a � chaque fois.)

Tu parles d'un std::vector<Noeud> au lieu de std::vector<Noeud*> ?

Oui, un d�r�fencement de pointeur en moins � chaque acc�s.

(edit: bouh binary_search ne retourne pas d'it�rateur sur l'�l�ment trouv�. Une fonction �quivalente existe retournant un it�rateur ?)

[LiquidHuk]

Je suis d�sol�, mais je vais revenir sur l'id�e de ma grille.

Il se trouve que quand je recherche un noeud, je poss�de ses coordonn�es sur la surface (je calcule leur id en fonction des coordonn�es). Si je range les noeuds de la mani�re suivante :

Noeud(x,y) dans grille[x/pas][y/pas].

Je n'aurais plus � parcourir la grille afin de trouver mon noeud : il me suffira � partir d'une coordonn�e (x,y) sur la surface de faire noeud = grille[x/pas][y/pas].

Je ne vois pas comment parcourir un quad_tree pourrait �tre plus rapide ?

Par contre, je pense pencher pour le unordered_set pour les autres listes de noeuds. Je pense que lequad_tree pourrait �tre utile pour une gestion des obstacles dynamiques, dans le cas o� les obstacles ne sont pas connus � l'avance (dans ce cas on v�rifie � chaque noeud s'il est sur un obstacle).

[ternel]

C'est l'id�e du quad-tree, en effet.

Si ta grille est pleine (math: pour tout (i,j) de la grille, grille(i,j) est un n�ud) alors un tableau est rentable.
Dans ce cas, regarde cette entr�e de la faq, et la suivante.

Sinon, une unsorted-map<Coord, N�ud> (de boost/C++11) permet un acces direct aux entr�es.

Autre possibilit�, en te basant sur le code de map que tu trouveras dans ton compilo, impl�menter une map2D. Cependant, pour avoir essayez, c'est assez gal�re d'avoir une s�mantique coh�rente.

En fait, ton probl�me vient d'autre chose: tu n'as pas de classe ou conteneur adapt� � ton besoin.
Cherche la s�mantique et les usages voulus de ta grille, et �cris l'interface d'une classe qui la proposerait.
Quand tu nous l'auras pr�sent�e, il sera bien plus facile de te guider.

[LiquidHuk]

Toutes les cases de la grille ne seraient pas utilis�es car les cases cens�es contenir des n�uds positionn�s sur des coordonn�es o� il y a un obstacle seront vides.
Par exemple si un obstacle empi�te sur la coordonn�e (40,40), la case grille[2][2] sera vide.
Je vais donc regarder les unordered_map.

Par curiosit�, j'ai lu les deux articles de la FAQ mais il me reste une question. Sur l'exemple donn�, la valeur de _data n'est pas stock�e, le r�sultat retourn� par matrix(x,y) est directement calcul� en fonction des coordonn�es. Si je veux stocker mes noeuds, j'utiliserais une structure de type tableau de tableau, non ?

[victor_gasgas]

Bonjour !

J'ai cod� un algorithme A* qui fonctionne tr�s bien, mais que j'aimerais optimiser car il devra � terme tourner sur une Raspberry Pi. Le temps d'initialisation (chargement de graphe par exemple) peut �tre long tant que les recherches de chemin derri�re sont rapides. L'objectif serait d'obtenir une recherche de chemin sur une surface de 200*300 avec des pas de 20, en plus d'un lissage post A* afin d'�viter les d�placements saccad�s. Est-ce r�aliste de viser un temps de calcul de l'ordre de la demi-seconde ?

Merci d'avance pour vos r�ponses !

Hum c'est bizarre mais la CPU utilis�e, la taille de la carte et le lissage me font �trangement penser � la coupe de France de robotique

Connais-tu boost.graph, qui propose l'algo A*? Tu devrais voir s'il n'est pas plus rapide que ton impl�mentation maison!! http://www.boost.org/doc/libs/1_53_0...tar-cities.cpp

[LiquidHuk]

Hum c'est bizarre mais la CPU utilis�e, la taille de la carte et le lissage me font �trangement penser � la coupe de France de robotique

Je ne vois pas du tout de quoi tu veux parler !
J'ai particip� l'an dernier et, m�me si je viendrais aussi cette ann�e, j'ai tr�s peu particip� au projet. Je compte faire un pathfinding solide pour les ann�es � venir

Je vais regarder boost.graph, merci !