Up, plus je vais loin dans le nombre de "9" utilisés pour décomposer en facteurs premiers, plus je m'aperçois que c'est un bordel monstrueux
Mais j'ai remarqué des choses :
- Déjà, il y a bien des relations entre le nombre de 9 utilisé et les périodes observées, ce qui contraint la découpe des "9" (la borne inférieure d'une période décimale étant le nombre de 0 intercalaires, et le maximum le nombre premier lui-même (np-1), on peut donc "borner" la taille des périodes)
- Il semblerait qu'à grande échelle, ces périodes aient un coefficient en terme logarithmique (c'est à dire qu'on aura le plus souvent un truc du style 10^50 et 10^100 pour 151 chiffres utilisés)
- Enfin, un autre phénomène constaté est que la distribution des chiffres se fait de façon aléatoire, et inégale : ainsi, il y a, pour un total de 250 chiffres utilisés, 8 nombres de taille 56 à période courte, contre un seul de taille 57, et aucun de taille 61
En espérant ne pas vous avoir explosé le cerveau avec mes conneries
Mais j'ai remarqué des choses :
- Déjà, il y a bien des relations entre le nombre de 9 utilisé et les périodes observées, ce qui contraint la découpe des "9" (la borne inférieure d'une période décimale étant le nombre de 0 intercalaires, et le maximum le nombre premier lui-même (np-1), on peut donc "borner" la taille des périodes)
Quand je dis "borner, c'est à dire que si la découpe se fait avec un NP de longueur 13, et qu'il y a 100 chiffres utilisés, eh bien on sait qu'il y aura un nombre de maximum 87 chiffres qui s'ajoutera, et qu'il comportera 87 zéros et seulement 12 chiffres, mention spéciale à ce machin (212158877458214105082975156638861697015962263232575666670500377582336595545516027747130897531745104763279308963402608489579488948174141288057321985065300709739123779635351802073368031960173399741862474936796650491652633364677473730132427004187), qui a pour inverse 47 millions, et 257 chiffres seulement
- Il semblerait qu'à grande échelle, ces périodes aient un coefficient en terme logarithmique (c'est à dire qu'on aura le plus souvent un truc du style 10^50 et 10^100 pour 151 chiffres utilisés)
- Enfin, un autre phénomène constaté est que la distribution des chiffres se fait de façon aléatoire, et inégale : ainsi, il y a, pour un total de 250 chiffres utilisés, 8 nombres de taille 56 à période courte, contre un seul de taille 57, et aucun de taille 61
En espérant ne pas vous avoir explosé le cerveau avec mes conneries
Cela est arrivé
Pour info, dans le projet Euler+ d''Hackerrank, le problème 26 c'est trouver le premier chiffre ayant au moins N répétitions dans son développement décimale périodique, donc t'as potentiellement déjà beaucoup d'algorithme qui te mâchent le travail de trouver les répétitions.
https://www.hackerrank.co[...]problem?isFullScreen=true
Des github du genre à adapter pour ne tester que les nombres premiers et ne mettre à jour que leur nombre de développement plutôt que de rechercher le plus grand :
https://github.com/stbrum[...]lob/master/euler-0026.cpp
Tu m'as envoyé un fichier en MP où je vois que t'as poussé aux premiers jusqu'à 10^341, j'avoue ne même pas encore bien comprendre comment procéder au développement de tels chiffres, pour l'instant je vais me renseigner un peu et je reviens vers toi
Des github du genre à adapter pour ne tester que les nombres premiers et ne mettre à jour que leur nombre de développement plutôt que de rechercher le plus grand :
Tu m'as envoyé un fichier en MP où je vois que t'as poussé aux premiers jusqu'à 10^341, j'avoue ne même pas encore bien comprendre comment procéder au développement de tels chiffres, pour l'instant je vais me renseigner un peu et je reviens vers toi
Pour info, dans le projet Euler+ d''Hackerrank, le problème 26 c'est trouver le premier chiffre ayant au moins N répétitions dans son développement décimale périodique, donc t'as potentiellement déjà beaucoup d'algorithme qui te mâchent le travail de trouver les répétitions.
https://www.hackerrank.co[...]problem?isFullScreen=true
Des github du genre à adapter pour ne tester que les nombres premiers et ne mettre à jour que leur nombre de développement plutôt que de rechercher le plus grand : https://github.com/stbrum[...]lob/master/euler-0026.cpp
Tu m'as envoyé un fichier en MP où je vois que t'as poussé aux premiers jusqu'à 10^341, j'avoue ne même pas encore bien comprendre comment procéder au développement de tels chiffres, pour l'instant je vais me renseigner un peu et je reviens vers toi
Des github du genre à adapter pour ne tester que les nombres premiers et ne mettre à jour que leur nombre de développement plutôt que de rechercher le plus grand :
Tu m'as envoyé un fichier en MP où je vois que t'as poussé aux premiers jusqu'à 10^341, j'avoue ne même pas encore bien comprendre comment procéder au développement de tels chiffres, pour l'instant je vais me renseigner un peu et je reviens vers toi
Mercionche pour le retou
Pour voir le problème, il faut s'abo, ce qui me freine un peu
Pour les algos, justement j'en cherche un plus performant que celui de dcode, car j'ai constaté quelques problèmes techniques (pas d'option pour virer l'affichage des décimales inutiles dans mon cas, ce qui est une perte de temps énorme + bousille les ressources pc ; de plus il procède par des courbes elliptiques pour chercher les nombres qui découpent des suites de "9" ce qui est fastidieux quand tu n'as pas une capacité de traitement énorme [j'ai que 6go
] ), donc j'espère trouver mon bonheur sur git
En fait ces nombres là admettent des périodes très courtes qui seront toujours supérieures à leur échelle logarithmique (en base 10) à cause des zéros, donc en fait à partir de 10^50 et des brouettes, tu as seulement les cas les plus "triviaux" de NP, j'avoue que je n'ai pas les outils nécessaires pour les cas de tels chiffres qui pourraient admettre des périodes de 10^50 chiffres à la suite (que l'on peut même pas écrire soit dit en passant
), actuellement, dcode va jusqu'à 375k pour tout afficher, commence à péter la liste de chiffres entre 375k et 1.7M, puis produit une 503 au delà, ce qui m'a valu un ban temporaire car je consommais trop de ressources serveur
Et du coup je profite pour faire une màj : il y a des "faux NP" qui s'amusent parfois à avoir des périodes qui divisent le NP-1 lui même, alors même qu'ils ne sont pas premiers : c'est le cas de 11649
Pour voir le problème, il faut s'abo, ce qui me freine un peu
Pour les algos, justement j'en cherche un plus performant que celui de dcode, car j'ai constaté quelques problèmes techniques (pas d'option pour virer l'affichage des décimales inutiles dans mon cas, ce qui est une perte de temps énorme + bousille les ressources pc ; de plus il procède par des courbes elliptiques pour chercher les nombres qui découpent des suites de "9" ce qui est fastidieux quand tu n'as pas une capacité de traitement énorme [j'ai que 6go
En fait ces nombres là admettent des périodes très courtes qui seront toujours supérieures à leur échelle logarithmique (en base 10) à cause des zéros, donc en fait à partir de 10^50 et des brouettes, tu as seulement les cas les plus "triviaux" de NP, j'avoue que je n'ai pas les outils nécessaires pour les cas de tels chiffres qui pourraient admettre des périodes de 10^50 chiffres à la suite (que l'on peut même pas écrire soit dit en passant
Et du coup je profite pour faire une màj : il y a des "faux NP" qui s'amusent parfois à avoir des périodes qui divisent le NP-1 lui même, alors même qu'ils ne sont pas premiers : c'est le cas de 11649
Cela est arrivé
J'ai pas la ref
Cela est arrivé
T'utilises quel algorithm sur dcode ?
J'ai tenté
https://www.dcode.fr/number-repeating-decimal
Mais il limite les inputs à 1 milliards. De façon générale je pense que c'est une limite assez dangereuse, après 2Mds tu fais péter les algorithm à 32 bits signés, et à 4M ceux signés. Cela dit, même à 64 bits, aucun algo pas spécifiquement pensé pour les grands nombres t'aiderait à passer le gogol, donc t'as bien trouvé ça.
Je vois aussi "Fraction Finder" qui peut aider à trouver une fraction qui correspondrait à une intuition que t'aurais, et là je vois des résultats beaucoup plus grands que 4Mds au dénominateur assez facilement. Par contre ça inverse la recherche : c'est toi qui donne la fraction en espérant tomber sur un inverse de prime quoi.
J'ai pas encore eu le temps de regarder toutes très trouvailles, je fais ça ce soir en rentrant du boulot si je suis pas décomposé
J'ai tenté
Mais il limite les inputs à 1 milliards. De façon générale je pense que c'est une limite assez dangereuse, après 2Mds tu fais péter les algorithm à 32 bits signés, et à 4M ceux signés. Cela dit, même à 64 bits, aucun algo pas spécifiquement pensé pour les grands nombres t'aiderait à passer le gogol, donc t'as bien trouvé ça.
Je vois aussi "Fraction Finder" qui peut aider à trouver une fraction qui correspondrait à une intuition que t'aurais, et là je vois des résultats beaucoup plus grands que 4Mds au dénominateur assez facilement. Par contre ça inverse la recherche : c'est toi qui donne la fraction en espérant tomber sur un inverse de prime quoi.
J'ai pas encore eu le temps de regarder toutes très trouvailles, je fais ça ce soir en rentrant du boulot si je suis pas décomposé
T'utilises quel algorithm sur dcode ?
J'ai tenté
https://www.dcode.fr/number-repeating-decimal
Mais il limite les inputs à 1 milliards. De façon générale je pense que c'est une limite assez dangereuse, après 2Mds tu fais péter les algorithm à 32 bits signés, et à 4M ceux signés. Cela dit, même à 64 bits, aucun algo pas spécifiquement pensé pour les grands nombres t'aiderait à passer le gogol, donc t'as bien trouvé ça.
Je vois aussi "Fraction Finder" qui peut aider à trouver une fraction qui correspondrait à une intuition que t'aurais, et là je vois des résultats beaucoup plus grands que 4Mds au dénominateur assez facilement. Par contre ça inverse la recherche : c'est toi qui donne la fraction en espérant tomber sur un inverse de prime quoi.
J'ai pas encore eu le temps de regarder toutes très trouvailles, je fais ça ce soir en rentrant du boulot si je suis pas décomposé
J'ai tenté
Mais il limite les inputs à 1 milliards. De façon générale je pense que c'est une limite assez dangereuse, après 2Mds tu fais péter les algorithm à 32 bits signés, et à 4M ceux signés. Cela dit, même à 64 bits, aucun algo pas spécifiquement pensé pour les grands nombres t'aiderait à passer le gogol, donc t'as bien trouvé ça.
Je vois aussi "Fraction Finder" qui peut aider à trouver une fraction qui correspondrait à une intuition que t'aurais, et là je vois des résultats beaucoup plus grands que 4Mds au dénominateur assez facilement. Par contre ça inverse la recherche : c'est toi qui donne la fraction en espérant tomber sur un inverse de prime quoi.
J'ai pas encore eu le temps de regarder toutes très trouvailles, je fais ça ce soir en rentrant du boulot si je suis pas décomposé
En effet, c'est cet outil que j'utilise, et j'ai déjà fait péter l'algo en tapant des nombres > 4M
Pour les très gros nombres, je tape plein de 9 en ajoutant un nombre après l'autre, ce qui permet de trouver des nombres énormes, car les premiers qui les constituent se révèlent dans une liste
Mais même cette stratégie a ses limites : ça devient un peu incertain à partir de 353 "9" à la suite
Pour le "fraction finder", je vois pas exactement en quoi l'outil me permettrait de déduire des répétitions avec de très gros nombres ?
Pour trouver des premiers, j'ai en réalité jusqu'à 1000 milliards avec ce site => http://compoasso.free.fr/[...]ge/prime/liste_online.php
Et sur la découpe en nombre premiers, en effet c'est au petit bonheur la chance, le tout est de pouvoir établir leur période, ce qui n'est pas une mince affaire
+ pour trouver les périodes, avec de petits NP (inférieurs à des milliards), j'utilisait une technique barbare consistant à circuler dans sa période jusqu'à atteindre d'abord les "0" intercalaires, puis les "9" qui découpent sa période en 2, dans les cas où ils étaient présents
Sur dcode on peut aller jusqu'à 100 000 donc c'est pas trop mal pour circuler dans des nombres > 4M (suffit de répéter le process x20 au max) mais c'est long et peu intéressant compte tenu du nombre important de NP présents à ce niveau
Et d'accord, tu me dis
Pour les très gros nombres, je tape plein de 9 en ajoutant un nombre après l'autre, ce qui permet de trouver des nombres énormes, car les premiers qui les constituent se révèlent dans une liste
Mais même cette stratégie a ses limites : ça devient un peu incertain à partir de 353 "9" à la suite
Pour le "fraction finder", je vois pas exactement en quoi l'outil me permettrait de déduire des répétitions avec de très gros nombres ?
Pour trouver des premiers, j'ai en réalité jusqu'à 1000 milliards avec ce site => http://compoasso.free.fr/[...]ge/prime/liste_online.php
Et sur la découpe en nombre premiers, en effet c'est au petit bonheur la chance, le tout est de pouvoir établir leur période, ce qui n'est pas une mince affaire
+ pour trouver les périodes, avec de petits NP (inférieurs à des milliards), j'utilisait une technique barbare consistant à circuler dans sa période jusqu'à atteindre d'abord les "0" intercalaires, puis les "9" qui découpent sa période en 2, dans les cas où ils étaient présents
Sur dcode on peut aller jusqu'à 100 000 donc c'est pas trop mal pour circuler dans des nombres > 4M (suffit de répéter le process x20 au max) mais c'est long et peu intéressant compte tenu du nombre important de NP présents à ce niveau
Et d'accord, tu me dis
Cela est arrivé