Commentaires sur : Sommes Egales de Nombres Premiers Consécutifs

Par : Dr. Goulu

Dr. Goulu — Wed, 04 Jun 2008 12:26:24 +0000

Ouaip, juste, c’est plutôt le test de l’étape 4 qui doit être revu. Le plus simple est d’intégrer l’étape 4 dans la boucle du 3. J’ai modifié le code de l’article en conséquence, et ça marche!

Par : b0z0

b0z0 — Wed, 04 Jun 2008 11:57:04 +0000

Oui, j’utilisai la méthode BigInteger.isProbablePrime() qui est basée sur l’algorithme de Miller Rabin (entre autres…). Mais j’avais pris le problème à l’envers, en testant chaque nombre premier pour voir si il correspondait aux contraintes (très bruteforce comme méthodes….).

Je suis tout a fait d’accord avec le principe de l’XP, par contre, je voudrais préciser que modifier le test à l’étape 2 ne changerais probablement rien : si on sort de la boucle a l’origine, c’est parce que le tableau de valeurs n’est plus modifié : en restant dans la boucle après un test plus approfondi, ce tableau restera toujours le même indéfiniment (mais bon, je chipote….)

Par : Dr. Goulu

Dr. Goulu — Wed, 04 Jun 2008 11:07:12 +0000

Est-ce que l’algo auquel vous aviez pensé utilise un test de primalité ( PrimeQ de Mathematica) ? Je pense que beaucoup de programmeurs imaginent qu’un test de primalité est très coûteux, donc l’évitent ou l’implantent eux-mêmes de façon très peu efficace, alors qu’il existe des algos très rapides comme celui-ci expliqué en Java Certains sont effrayés par le fait que ces tests sont « probabilistes », donc peuvent théoriquement se tromper. Ceux là devraient lire le paragraphe 5.5 du livre que je finirai peut-être un jour ...

Par : Dr. Goulu

Dr. Goulu — Wed, 04 Jun 2008 10:56:41 +0000

Oui, vous avez raison mon test de fin de l’algo n’est pas suffisant. Comme je l’indique au point 2, je considère la paresse comme une qualité… ou plus sérieusement, l’eXtreme Programming dont je suis adepte consiste à faire juste ce qu’il faut pour que le programme fasse ce pour quoi il a été conçu (et ça le fait dans mon cas) et ensuite l’étendre au besoin pour couvrir d’autres cas (le votre).

Mais dans ce cas il faut faire simple : pas besoin d’étape 5, il suffit d’améliorer le test à l’étape 2 pour boucler tant que toutes les valeurs ne sont pas égales. On doit pouvoir faire ça très compact en Mathematica, mais je vous laisse le faire en Java

Par : b0z0

b0z0 — Wed, 04 Jun 2008 09:38:57 +0000

Bonjour, j’ai tenté d’implémenter cet algorithme en Java et je doit avouer que j’ai été surpris par son efficacité (bien plus performant que la méthode que j’avais mis au point…). Par contre, j’ai rencontré une petite faille dans l’algorithme : avec mes valeurs (1035,9,5,3) , je me retrouvais dans le cas suivant :

1035 nombres premiers consécutifs a partir du 352ème : 7049621
9 nombres premiers consécutifs a partir du 62706ème : 7049621
5 nombres premiers consécutifs a partir du 107801ème : 7049857
3 nombres premiers consécutifs a partir du 172870ème : 7049879

Les 2 premières valeurs étant identiques et les 2 dernières étant « croissante », l’algorithme s’arrête puisqu’il n’y a plus de modification. Je voudrait donc proposer une 5ème étape, dans laquelle on vérifie si les 2ème, 3ème et 4ème valeurs sont identiques (inutile de le faire pour la première puisque cela et déjà fait par le travail conjoint des étapes 3 et 4). Si ce n’est pas le cas, alors on incrémente le i de la somme 1 et on reboucle. Grâce a cela, j’ai obtenu le résultat suivant :

1035 nombres premiers consécutifs a partir du 356ème : 7086173
9 nombres premiers consécutifs a partir du 63004ème : 7086173
5 nombres premiers consécutifs a partir du 108293ème : 7086173
3 nombres premiers consécutifs a partir du 173696ème : 7086173