bonjour,
j'ai réussi a trouver une implementation de l’algorithme de dijkstra sous Excel,
Il faudrait remplir juste remplir la procédure (sub dijkstra())
Merci
Cordialement
Version imprimable
bonjour,
j'ai réussi a trouver une implementation de l’algorithme de dijkstra sous Excel,
Il faudrait remplir juste remplir la procédure (sub dijkstra())
Merci
Cordialement
Euh, c'est une question ? Une contribution ?
Tu dis que tu as trouvé une implémentation mais après tu en demandes une. Pas très clair ton message.
le probleme c'est que l'implementation n'est pas complete
et je voudrais juste savoir si quelqu'un pourrai bien m'aider à l'achever
Soit il y a un expert de cet algorithme sur le forum, soit il va falloir que tu l'expliques un peu. On peut t'aider pour l'implémentation, mais ce n'est pas à nous de chercher sur Google tous les détails...
bein en fait je l'ai realisé , mais il me reste juste une petite procedure a faire ( je bloque la dessus )
je veux bien attacher le fichier .xlms mais je c pas comment faire !?!?
le voila
Le fichier que tu avais attaché a été supprimé car selon les règles du forum, on n'attache pas un fichier à la première discussion. C'est seulement si une fois le problème bien posé et le code fourni, on a vraiment besoin du fichier pour résoudre le problème. Ça évite de surcharger les serveurs et c'est mieux pour des questions de sécurité.
Je t'encourage d'ailleurs vivement à lire les règles du forum.
Pour ce qui est de ta question, je veux bien t'aider, mais que doit faire ta procédure !!! :cry:
Imagine que je vienne te voir en te demandant : "S'il te plait, tu peux me fabriquer un truc ?". Tu pourras être le meilleur bricoleur du monde, il y a peu de chances que tu me fabriques ce à quoi je m'attends !!!
hhh , bein monsieur j'aimerais bien relaiser l’implémentation de l'algorithme de dijkstra sous excel (en vba)
voila!!!!
ect ce que vous pouvez m'aider :):):):):)
Bon, puisque ton sujet était marrant, j'ai fait un truc en reprenant tout simplement l'algorithme donné par Wikipédia. Par contre, je suis désolé, je n'ai pas fait l'effort de comprendre les classes que tu avais déjà créées, je m'en suis créées d'autres, c'était plus simple pour moi.
En tout cas ça marche, j'ai vérifié avec l'exemple de Wikipédia. Je te laisse décortiquer tout ça.
Par contre, pour t'expliquer mes remarques précédentes : ici, c'est un forum d'entraide où en général on répond à un problème précis lié à VBA. Il y a donc deux types de sujets auxquels la plupart des contributeurs n'aiment pas répondre :
- Celui qui vient avec en gros : "mon boss m'a demandé de faire ça en VBA, je n'y connais rien et j'ai la flemme de m'y mettre, vous pouvez me le faire ?"
- Celui qui vient avec un sujet qui est plus "fonctionnel" que "technique", sans donner de précisions sur le coté fonctionnel justement
Dans ton cas, on ne savait pas trop si ton problème était le VBA ou le fait que tu ne comprenais pas l'algorithme. L'idéal aurait été d'expliquer l'algorithme dans ton message.
Enfin j'arrête de t'embêter, au final tu m'as fais faire des recherches intéressantes :ccool:
Sebastien ur amazing , i'm greatfull
Bonjour !
Je préfère toujours utiliser Excel comme un tableau (worksheet) plutôt que comme support de macro : problème de virus, problème de lisibilité, difficulté pour voir comment ils fonctionnent, ...
Les outils proposés sur le net pour appliquer l'algorithme de Dijkstra (qui permet de trouver le chemin pondéré le plus court d'un point du graphe à tout autre) sont souvent à base de programmes procéduraux.
Voici un outil excel simple, sans macro ou VBasic, accompagné de quelques outils de saisie adaptés à différentes situations: graphe connu par sa matrice, graphe non orienté, graphe avec relativement peu de segments.
J'ai privilégié la compacité, notamment en bannissant les tables intermédiaires, au prix d'une complexité de certaines formules, je le concède.
Il reprend le format enseigné en fac/école ou en spécialité au lycée. Son fonctionnement est relativement facile à décrypter, plus en tout cas que la version procédure. Il faut quand même bien connaître l'algorithme (être capable de le faire à la main par exemple). On sait comment l'algorithme à travaillé grâce à la matrice de calcul des résultats.
Il est facile à étendre à des matrices plus grandes.
Enjoy !
Bonjour,
Ton fichier est intéressant, une autre manière de procéder.
Par contre, j'avoue que je ne partage pas ton point de vue sur l'utilisation d'Excel.
Virus : Si tu crées toi-même les procédures, aucun risque. Au pire si tu reprends des fichiers trouvés sur le net, il faut vérifier un peu le code, je te l'accorde. Mais je n'ai encore jamais trouvé de code malveillant.
Lisibilité : Cela dépend fortement de la personne qui fait le code (ou le classeur). Je ne sais plus si je l'avais fait pour cet exemple, mais si on commente correctement le code et que l'on nomme les variables intelligemment, c'est très clair. Il est plus facile de comprendre dans un code
queCode:Vitesse = Distance / Temps
par exemple. Surtout quand les calculs deviennent compliqués, le faire via du code permet de le décomposer en plusieurs étapes.Code:=F27/DonneesTemps!G12
Dans cet exemple précis, si on estime que pour mieux comprendre il est intéressant de visualiser la construction de la matrice, on peut très bien rajouter dans le code quelques lignes pour l'affichage. Mais l'aspect procédural permet de décomposer les différentes étapes, alors que si on regarde seulement les formules, il n'est pas toujours évident de comprendre dans quel sens il faut les lire (outre le fait qu'il faut toujours regarder à quoi correspond un G25 ou un B18 ;))
Fonctionnement : VBA est doté d'un mode pas à pas, d'espions, d'un fenêtre de debug. Autant d'outils qui permettent de détailler tout ce qui se passe de manière très simple.
Voilà, c'est un débat intéressant et je voulais ajouter mon point de vue à d'éventuels lecteurs intéressés.
D'ailleurs parfois, le plus intéressant si l'on recherche le coté didactique, sera un juste équilibre entre formules et code.
Le débat VBA ou plain Excel est intéressant.
En fait, il y a un "historique" à ma pratique qui me pousse à ne pas utiliser les macros/VBA que je sais construire : j'ai souvent vu des gars se lancer dans une programmation VBA simplement par ce qu'ils ne savaient pas utiliser les fonctions les plus puissantes du tableur (fonctions de bases de données, recherches, tables, fonctions matricielles, ...) et de partir dans des délires qu'ils ne savaient pas gérer.
Ensuite, je le confesse, j'ai vu des gars se prétendre être des "dieux" (sic) en Excel alors qu'ils étaient tout juste corrects. Peut-être qu'utiliser les fonctions les plus avancées de manière atypique me permet inconsciemment de me différencier des "dieux" !
Plus sérieusement:
Sécurité : Ouvrir à l'exécution des macros, même pour ses propres macros, est une ouverture pour d'autres macros. De plus, l'intérêt aussi des macros/VBA, c'est de pouvoir utiliser des outils faits par d'autres. Là, je n'ai aucune crainte par rapport à des outils tiers écrits à partir de formules seulement.
Rapidité : on a aussi un bonus net pour ce qui est fait sur la seule worksheet. videmment, cela est d'autant plus sensible que l'on a à traiter de grande quantité d'information.
Rapidité de développement : J'ai observé que souvent je développais plus vite une maquette avec le tableur qu'en procédural. La transformation en boucles n'est pas le seul moyen de penser l'algorithmique (même si c'est le mode le plus fréquent) . On peut découper autrement les différentes étapes pour atteindre un résultat.
Lisibilité : Je trouve que les formules, dans une certaine mesure, sont plus proches d'un idéal "déclaratif". Il est plus facile de comprendre l'architecture d'un projet.
Modifications : Là aussi, je trouve beaucoup plus facile de faire subir une évolution à une worksheet avec des données déjà installées et d'améliorer de manière incrémentale. C'est souvent robuste (à part les fonctions recherchev() ) par rapport à ces évolutions.
Maintenant, il y a de nombreuses limites à l'exécution d'"Excel plain" pour des applications complexes.
Nommage : La limite relevée par ZèbreLoup du nommage des variables peut tout aussi bien se régler avec la définition de nom et on arrive strictement au même résultat.
Déverminage : On dispose de moins d'outils dans le déverminage, c'est clair et bien dommage. Même si on arrive à se débrouiller et que le besoin est par construction moindre : en effet, les "bouts de fonction" sont plus gros et plus faciles à déverminer de manière unitaire.
Fonctions manquantes : Les formules dans les cases ne peuvent malheureusement pas contenir de petits bouts "procéduraux" et c'est dommage. Ainsi, si au lieu de répéter une fonction comme danson pouvait rentrer dans une celluleCode:si ( recherchev(...) ; recherchev(...) ; ...)
cela favoriserait la lisibilité dans bien des cas. D'autres fonctions manquent comme un opérateur de concaténation qui pourrait englober un nombre variable de cellules à concaténer - comme il y a une fonction "somme".Code:temp:= recherchev(...) ; si (temp; temp ; ... )
Projets de taille : Le bricolage n'est plus adapté, tout juste sur des portions que l'on voudrait expérimenter avant de les transformer en bonnes vieilles procédures. Cela fournit aussi des comparaisons pour vérifier les résultats produits.
Pour de petits projets, savoir utiliser toutes les ressources des fonctions excel de la worksheet permet de s'en sortir bien et surtout vite y compris pour des données d'assez grande taille.
Cela dit, on n'a pas fini de voir des programme en VBA sans que cela soit "nécessaire" . Faut croire qu'il est plus facile de faire une procédure que d'utiliser les outils worksheet de Excel : la preuve d'une faiblesse, ... *
* provisoire, à corriger ?