Bonsoir ! Pour passer le temps je me suis demandé ce que donnerait un petit programme test en Java qui me permettrait de refoutre n'importe quel mot dans le bon ordre. Genre j'entre toutes les lettres d'un mot choisit au hasard, le programme doit m'afficher le bon mot.

Exemple : Prenons Voiture

J'entre tous les caractères un par un dans un ordre hasardeux :

"e" "i" "t" "v" "o" "u" "r"

A la fin le programme doit m'afficher : Voiture

C'est pas compliqué, j'ai trouvé un document texte qui contient la liste de tous les mots présents dans le dictionnaire Larousse. Idéal pour comparer chaque lettres à chaque entrées. Par contre, je ne sais pas comment l'intégrer à mon programme, enfin, ou je met le chemin qui me permet d'y accéder ?

Merci d'avance

Ben moi je veux bien mais pour les anagrammes c'est comment ?

La solution de Haptaro paraît raisonnable, encoder un dictionnaire sous la forme d'un arbre de préfixes est une façon classique de faire. Ensuite j'aurais plutôt formulé ça comme un algo récursif ce qui permet de passer sous le tapis toutes les histoires de "backtracking" dont on a pas à se soucier, mais au final c'est le même algo

Mais en effet je crois pas que ce soit ça la question

Il faut juste ouvrir ton fichier avec les Classes correspondantes (FileReader je crois, Ou File tout court).

Le fichier, tu l'intégère directement à ton projet (glisser / déposer) et tu l'appelle avec les Classes sus-nommées.
Enfin, rien de bien compliqué en somme

C'est pas une question de "bateau" ou "élaboré", les deux sont classiques et simples à implémenter. Les deux consistent à "tout essayer". Dans un cas on essaye toutes les permutations des lettres qu'on a en entrée et on vérifie si c'est un mot du dico ; dans l'autre on essaye tous les mots du dico et on vérifie si c'est un anagramme des lettres en entrée. La différence, c'est juste est-ce qu'on préfère être linéaire en la taille du dico, ou factoriel en le nombre de lettres en entrée...
Pour le cas de la langue française ici, tester 300 000 mots c'est raisonnable, alors que tester 25! possibilités pour trouver un anagramme de "anticonstitutionnellement" c'est pas faisable. Donc la seconde solution est la meilleure.

Sinon bluepoint ton idée de "compresser" l'arbre des préfixes n'apporte pas grand chose, et je vois pas trop comment tu reconstruis les mots simplement en ayant le nombre d'occurrences de leurs lettres (à part en les stockant en entier aux feuillez ? mais on perd tout l'intérêt). L'arbre des préfixes est déjà bien moins lourd que le fichier de base qui liste tous les mots du Larousse, puisqu'il fait du sharing. L'espace mémoire est pas vraiment un problème

Il y a une solution beaucuop plus simple que ca. Pour que deux mots soient des anagrammes, il suffit que la distribution de leurs lettres soit identique.

Donc, c'est une hashtable que tu veux. Tu peux associer a tous les mots un vecteur a 26 dimension qui dit combien de fois chaque lettre apparait dans le mot. Apres c'est un probleme de lookup dans une hash table.

EDIT: Je viens juste de voir le message de bluepoint qui a une approche similaire.

bluepoint Oui je me suis rendu compte après coup que c'était sans doute ça que tu avais en tête, et comme dit godrik ça revient juste à implémenter de manière un peu bizarre une hashtable. Et quand je disais "on parcourt tous les mots", j'avais en tête la complexité pour une instance du problème mais en effet si fait plusieurs requêtes sur le même dico on a juste à faire un seul pré-traitement au début.

bluepoint, ce n'est pas un probleme que les vecteurs soient creux. Tant que ta fonction de hashage casse la structure du vecteur et genere des hashes distribues identiquement, la table de hashage sera une bonne solution.

On dit juste que ta structure légèrement différente n'apporte a priori ni gain de temps, ni gain d'espace significatif ; donc autant ne pas s'embêter

Cela etant dit, construire la fonction de hashage qui va bien marche, ca pourrait bien etre coton...