En effet, judicieuse remarque.
Cependant, je trouve ça un tantinet moins clair pour le lecteur, et j'ai toujours peur en Perl de faire des bêtises, vu que c'est assez permissif 

Bonjour,

Je ne suis pas sûr de bien avoir saisi ton problème, mais à première vue (et vu les tailles envisagées), tu pourrais :
- charger ton ancien dictionnaire en mémoire (dans une table de hash, par exemple) :

Code:

my %hash = ();
...
$hash{$mot} = undef;

- charger dans la même table de hash, le dictionnaire que tu veux merger :

Code:

$hash{$mot} = undef;

Le mécanisme de table de hash garantit l'unicité des clés, donc des entrées du dictionnaire.
Ensuite, quelque chose comme :

Code:

foreach (sort { $a cmp $b } (keys %hash)) {
  print NEWDICO ("$_\n");
}

ce qui devrait te trier au passage ton nouveau fichier.

Je n'ai rien testé et c'est brut de décoffrage, mais je pense que cela coûte grosso modo le temps de lecture des fichiers de départ (une fois chacun), le temps d'écriture du fichier résultat, et bien sûr le temps de trier une liste de 50M éléments (aucune idée de ce que cela représente en Perl), c'est-à-dire de l'ordre de quelques minutes. Je veux bien un retour sur ce point
Pour parler de performances que je maîtrise mieux, je suis quasiment certain qu'un programme C utilisant qsort (quitte à passer un peu de temps à virer les entrées doubles après le tri au moment de l'écriture) remplit ce rôle en moins de 5 minutes.
Dans tous les cas, 2 heures pour faire ça me semble astronomique.

Petite remarque : la puissance de Perl permet de faire le tri avec à peu près n'importe quoi, on peut imaginer utiliser dans le foreach :

Code:

sort { length($a) <=> length($b) } (keys %hash)       # pour faire le tri sur la longueur des chaînes
sort { comparison_function() } (keys %hash)            # pour appeler une fonction de comparaison maison (on peut toujours "inliner" le code à la main si on s'en sent le courage

Une fois le fichier trié, la recherche d'un mot par dichotomie est quasi instantanée si le fichier est en RAM (pour 30 M de lignes, il faut au pire 25 essais). Si les fichiers ne tiennent pas en RAM, il faut en effet commencer à ruser en les découpant suivant la première lettre, les 2 premières lettres, ou utiliser des fonctions de hashages de faible entropie (8 bits, par exemple). La dernière solution est fun, mais ça ne simplifie pas du tout l'élaboration des dictionnaires.

Bref, tout ça pour dire que je ne suis pas certain d'avoir fait avancer le schimilibilillick.

Je crois qu'il y a 14 pages de topic qui parlent de ça. 

De rien, mais tu as comme tu dis, déjà trouvé la solution. Tu devrais l'essayer 

C'est d'ailleurs un des deux que tu as cité ^^

C'est d'ailleurs amusant que pour 1 choix sur 3 l'intuition indique cette stratégie, tandis qu'en remplaçant 3 par 100 vous ne trouverez personne pour se tromper.

Imaginons le même jeu avec 100 boîtes, on en choisit une au hasard, et ensuite le présentateur en montre 98 vides. Il ne viendrait à l'idée de personne de conserver son choix...

42 

Bon, d'accord, la faille est évidente

Heeeeey, en fait, d'un point de vue d'algébriste, pas si évidente que ça.  
Il se cache en sous-main le fait qu'on a deux plongements de Q( \sqrt{-1} ) dans le corps des complexes, namely le premier qui envoie \sqrt{-1} sur i, le second sur -i... Ou d'un point de vue analytique, que la fonction d'élévation au carré induit une fibration de degré 2 sur le cercle unité du plan complexe. Ou encore, si on veut triturer jusqu'au bout, qu'il n'existe pas de détermination holomorphe (donc continue) du logarithme sur C \ {0}.
En particulier, si exp(i \pi) est bien égal à exp(-i \pi) ( = 1/ exp(i\pi) ), la "racine" de ces deux nombres n'est pas égale.

C'est une notation très utilisée en théorie des nombres (et utilisée par Cardan pour les résolutions d'équations de degré 3 par radicaux à l'époque où la racine de X²+1 n'avait pas de nom - pour montrer des résultats justes, ce qui est remarquable), et à ce titre, ce "paradoxe" est très instructif.

Ouais enfin, je crois pas que Baal était sérieux, faudrait arrêter de péter plus haut que son derrière.

Euh...
Pour moi le problème est qu'un int prend des valeurs de -2^31 à 2^31, et essentiellement, pour C, ou à peu de choses près, (2^31)+1 = -2^31. Quand le nombre devient trop grand, on pourrait très bien obtenir 2989^34567 = 0...
Il serait surprenant que ce genre de bugs amène un résultat avec une quelconque signification  

Persévère
Il n'y a aucune raison que tu n'y arrives pas manuellement, en utilisant toute ta tête.

Soit la clé est trop longue, soit le texte est trop court (soit j'ai tout faux), mais dans tous les cas, t'as été vache, BAAL

Est-ce qu'on peut avoir la 691è et la 692è lettre du texte clair ? 

combien de décimales comportent x_M et y_M

Une infinité ? (à peu près)

Peut-être que mettre directement les codes html, comme '&lt;' pour '<', etc, fonctionne ?