Quoi que, je me suis amusé à faire un peu de statistiques dans le cas fort long de la recherche des facteurs premiers de 9999999967, il faut que mon code génére autant que possible des nombre premiers jusqu'à environ 99999 (~ 1E6)
Si l'on évite de tester les multiples de 2,3 et 5 (donc par pas de 3à comme dans le code exposé ci-dessus) on se rend compte que seulement 36% des "facteurs p" testés sont premiers. C'est à dire à peine plus d'un tier. C'est à dire que la calculatrice passe environ les deux tiers du temps de recherche à re-tester des multiples de facteurs premiers déjà testés !
Il y a donc là peut-être une piste pour augmenter les performances du programme ?
Si l'on utilise l'astuce avec les multiples de 2, 3, 5 et 7 (donc 210) on arrive alors seulement à env. 42% et 46.5% avec 2,3,5,7 et 11 (donc 2310), Il faut utiliser 2,3,5,7,11 et 13 (soit 30030) pour péniblement atteindre 58%. On pourrait espérer 71% de facteur testé premiers, en tenant compte de 2,3,5,7,11,13 et 17 (soit 510510). On a une chance de faire 2x plus vite ? Mais il y a alors près 10000 termes dans la somme de la boucle. Difficile de programmer cela sur un Pocket sans gestion de fichiers.
Et tant qu'à utiliser des fichiers importants, autant utiliser directement la liste des nombres premiers, on fera alors 100% de tests avec des facteurs premiers et on aura alors réellement optimisé le temps de recherche des facteurs.
J'attends toujours avec impatience l'algorithme de gege, car comme il le souligner, la recherche de la décomposition en facteur premiers n'est pas exactement un test de primalité.
Code : Tout sélectionner
+1 10%
+2



