A savoir:
Tout d'abord, les numéros porte-bonheur.
Les numéros porte-bonheur sont générés comme suit:
Prenez tous les nombres naturels:
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20...
Ensuite, supprimez chaque deuxième numéro.
1, 3, 5, 7, 9, 11, 13, 15, 17, 19, 21, 23, 25, 27, 29, 31, 33, 35, 37, 39...
Maintenant, 3
c'est sûr.
Supprimez chaque 3e numéro:
1, 3, 7, 9, 13, 15, 19, 21, 25, 27, 31, 33, 37, 39, 43, 45, 49, 51, 55, 59...
Maintenant, 7
c'est sûr.
Supprimez tous les 7 numéros.
Continuez et supprimez chaque n
numéro, où n
est le premier numéro sûr après une élimination.
La liste finale des numéros sûrs est les numéros porte-bonheur.
Les nombres malchanceux sont composés de listes distinctes de nombres, qui le sont [U1, U2, U3... Un]
.
U1
est le premier ensemble de chiffres retiré des "candidats" chanceux, ils sont donc:
2, 4, 6, 8, 10, 12, 14, 16, 18, 20...
U2
est le deuxième ensemble de nombres supprimé:
5, 11, 17, 23, 29, 35, 41, 47, 53, 59...
Et ainsi de suite et ainsi de suite ( U3
est la troisième liste, U4
est la quatrième, etc.)
Défi:
Votre tâche consiste, lorsque deux entrées sont données m
et n
, à générer le m
numéro e dans la liste Un
.
Exemples d'entrées et sorties:
(5, 2) -> 29
(10, 1) -> 20
Spécifications:
- Votre programme doit fonctionner
m
jusqu'à1e6
etn
jusqu'à100
.- Vous êtes assuré que les deux
m
etn
sont des entiers positifs. - Si vous êtes curieux,
U(1e6, 100)
=5,333,213,163
. (Merci @pacholik!)
- Vous êtes assuré que les deux
- Votre programme doit calculer cela en 1 jour sur un ordinateur moderne et raisonnable.
C'est le code-golf , donc le code le plus court en octets gagne!
PS: Ce serait bien si quelqu'un venait avec une formule générale pour les générer. Si vous avez une formule, veuillez la mettre dans votre réponse!
(1e6,1e6)
?n=1
cas? Comme c'est spécial - pour tous les autres cas, l'index basé sur 0 du prochain numéro porte-bonheur estn-1
.Réponses:
CJam , 74 octets
Essayez-le en ligne! Expirera pour les cas plus gros, plus sur les contraintes de temps ci-dessous.
Explication:
Notre programme emprunte sans vergogne le code d' Aditsu pour générer une liste de N numéros porte-bonheur, remplacer 1 par un 2 donne l'incrément dans chaque phase du tamis. Le code restant diminue sur chaque élément jusqu'à ce qu'un zéro soit trouvé (en découpant et en ajoutant une queue non décrémentée) et compte efficacement les étapes dans chacune des N phases du tamis à la fois.
Timing:
Si vous devez absolument exécuter le programme dans le navigateur pour un plus grand nombre, vous pouvez utiliser cet interpréteur et permettre au script de continuer si vous y êtes invité, mais cela peut être trop lent pour être qualifié. L'utilisation de ( M , N ) = (100,100) prend ~ 247s. L'itération des programmes est relativement linéaire en termes de M , donc le calcul (1e6,100) pourrait prendre environ 29 jours.
En utilisant l'interpréteur de commandes shell sur un PC, le programme calcule (100,100) en ~ 6s et calcule (1e4,100) en ~ 463s. Le programme devrait être capable de calculer (1e6,100) en ~ 13-17hrs. Dans ce cas, je suppose que le programme est admissible.
Notez que tous les temps ont été arrondis dans les mesures et les calculs.
la source
Perl,
87858281 octetsComprend +4 pour
-pX
Donnez une entrée sur STDIN comme une ligne avec n en premier (notez que c'est l'inverse de l'ordre suggéré dans le défi). Donc pour calculer
U(1000000, 100)
:Algorithme basé sur aditsu « s nombres chanceux répondent La complexité de temps est
O(n^2)
il est assez rapide pour la gamme requise. L'100, 1000000
affaire donne5333213163
en 0,7 secondes. En raison des problèmes que Perl a avec lado$0
récursivité basée, il utilise beaucoup de mémoire. La réécrire en tant que fonction rendrait l'utilisation de la mémoireO(n)
mais est un nombre d'octets plus longunlucky.pl
:Cela fonctionne comme indiqué, mais utilisez le littéral
^S
pour obtenir le score réclamé.Je ne suis au courant d'aucune utilisation antérieure de
$^S
in perlgolf.la source
(1e6,100)
?do$0
elle, elle est pratiquement inaccessible sur tout ordinateur réaliste. Mais si tant de mémoire existait environ 2 ans. Je n'ai pas vraiment écrit et testé une version basée sur un sous-programme normal, mais je m'attends à ce que cela se termine dans quelques mois et s'exécute même sur des ordinateurs avec très peu de mémoire. C'est donc une bonne chose que ces valeurs ne soient pas dans la plage requise pour ce défi.(1e6,100)
en une journée? Que voulez-vous dire que ces valeurs ne sont pas obligatoires?n
etm
sont donnés dans l'ordre inverse. L'100 1000000
entrée calculeU(1000000, 100)
et donne5,333,213,163
en 0,7 seconde. C'est de loin le programme le plus rapide de ces programmes actuellement publié(100,1e6)
à être beaucoup plus rapide que(1e6,100)
, et j'ai pensé que c'était l'explication du rapide comme l'éclair de 0,7 seconde!Python 3, 170
La fonction L génère la ligne de nombres porte-bonheur possibles (si k est Vrai) ou Un (si Faux). Évalué paresseusement (donc je n'ai pas à générer n-1 listes infinies si je veux Un ).
Fonction de temporisation U .
La vitesse
U (1 000 000; 100) prend environ 1 h 45 pour fonctionner sur ma machine avec PyPy. Je soupçonne environ quatre heures avec CPython. (Oui, 4h 20min pour être précis.)
Si j'utilisais une liste au lieu de générateurs, je gagnerais peut-être en vitesse, mais j'aurais besoin d'une liste de plus grande taille que Python ne me le permet. Et si c'était le cas, il lui faudrait des dizaines de gigaoctets de RAM.
Oui, et U (1.000.000; 100) = 5.333.213.163 .
la source
Haskell
Impossible de calculer pour n = 1:
175160 octetsUne fois compilé, il a fallu 2h 35m à mon ordinateur pour calculer une entrée d'
(1000000,100)
utilisation de ceci:J'ai essayé de débarrasser les
where
modules, mais ils semblent affecter la vitesse et je ne sais pas pourquoi ... Mais je pense qu'il y a plus d'élagage à faire ici.La méthode à utiliser consiste
m?n
à interroger la réponse en fonction d'unm
etn
.Non golfé
Je pense qu'il peut être possible de combiner les fonctions «skipeverynth» et «everynth» en une seule fonction qui renvoie une paire.
J'ai utilisé le code de cette personne aimable pour sauter chaque nième élément. Je l'ai fait moi-même plusieurs fois, mais c'était toujours beaucoup plus inefficace et je n'arrivais pas à comprendre pourquoi.
Capable de calculer pour tous n: 170 octets
C'est fondamentalement la même chose, mais quelques
max
fonctions ont dû être ajoutées pour gérer le cas spécial den=1
.la source
R 82 octets
Usage
Cela doit avoir un vecteur suffisamment grand pour commencer, donc il reste suffisamment de nombres pour renvoyer la valeur. Le vecteur créé est déjà d'environ 800 Mo et la fonction peut gérer jusqu'à m = 1e4 et n = 100, donc encore bien en deçà de l'objectif.
Pour créer un vecteur suffisamment grand pour calculer f (1e6,100), il faudrait un vecteur de départ de 1: 2e10. En raison des procédures d'allocation de données Rs, cela crée un vecteur> 70 Go qui ne peut pas être exécuté sur n'importe quel ordinateur que je connais bien que le code s'exécute.
Pour référence f (1e4,100) s'exécute en environ 30 secondes environ. Sur cette base, et quelques tests plus petits f (1e6,100) prendraient environ une heure.
la source
Raquette 332 octets
Version non golfée:
Essai:
Sortie:
la source
Clojure, 221 octets
Mighty long mais gère le boîtier
(f 1)
. Sans ce cas particulier, il s'agissait de 183 octets. C'était trop d'efforts pour ne pas l'avoir affiché.Exemples de sorties:
1000000 100 cas a été calculé en environ 4,7 heures, au moins il ne s'est pas écrasé.
la source