Votre tâche ici sera de mettre en oeuvre une fonction 1 qui forme une permutation sur les entiers positifs (une bijection des entiers positifs sur eux-mêmes). Cela signifie que chaque entier positif doit apparaître exactement une fois dans la permutation. La capture est votre fonction devrait avoir une plus grande probabilité de sortir un nombre impair qu'un nombre pair.
Maintenant, cela peut sembler étrange ou impossible. Il y a sûrement autant de nombres impairs que de nombres pairs? Et, bien que cette intuition soit correcte pour des ensembles finis, elle ne tient pas pour des ensembles infinis. Par exemple, prenons la permutation suivante:
1 3 2 5 7 4 9 11 6 13 15 8 17 19 10 21 23 12 25 27 14 29 31 16 33 35 18 37 39 20 41 43 22 45 47 24 49 51 26 53 55 ...
Si vous prenez une sous-section de la suite dont la taille est supérieure à vous aurez au moins autant de nombres impairs que de nombres pairs; il semble donc que la probabilité qu'un terme aléatoire soit impair est supérieure à celle d'être pair. Vous noterez également que chaque nombre pair ou impair apparaîtra dans la séquence et ne peut apparaître qu'une seule fois. Ainsi, la séquence est une vraie permutation.
Définition de probabilité
Pour éviter toute confusion ou ambiguïté, je vais expliquer clairement ce que l’on entend par probabilité dans cette question.
Disons que nous avons une fonction . La probabilité qu'un nombre soit impair sera définie comme la limite du ratio membres impairs de l'ensemble à la taille de l'ensemble car tend vers l'infini.
Par exemple, la fonction susmentionnée aurait une probabilité d'être impair de .
C'est un code-golf, donc les réponses seront notées en octets, moins d'octets étant meilleurs.
Défis supplémentaires
Voici quelques idées amusantes à jouer et peut-être à essayer de mettre en œuvre. Ce sont juste pour le plaisir et n'affectent en aucune façon la notation. Certaines d'entre elles ne constituent même pas des solutions valables à ce défi, et une réponse qui ne comprend que des solutions aux défis 2 ou 3 n'est pas une réponse valable et est susceptible d'être supprimée .
Écris une permutation avec une probabilité étrange de . (c'est possible)
Ecrivez une permutation qui a plus de nombres impairs que de nombres pairs dans pour tout mais qui a une probabilité impaire de .
Écris une permutation qui n’a pas de probabilité définie (c’est-à-dire qu’il n’ya pas de limite).
1: Ici, fonction signifie programme ou fonction. C'est juste un morceau de code qui prend une entrée et produit une sortie.
Husk ,
11 à10 octets-1 octet grâce à Leo et une fonction légèrement différente
Cela a une probabilité étrange de
1
Essayez-le en ligne!
Il indexe la séquence:
Explication
la source
Haskell,
353432 octetsImplémente la séquence d'exemple
[1,3,2,5,7,4,9,11,6,13,15,8,17,19,10,21,...]
.Essayez-le en ligne!
Pour référence: ancienne version, 34 octets (-1 octet grâce à @xnor):
Essayez-le en ligne!
la source
(!!)$do ...
Coque , 8 octets
Essayez-le en ligne!
Ceci implémente l'exemple de séquence (
1,3,2,5,7,4...
).Explication
la source
Tout le monde fait le défi 1, alors faisons les deux autres.
Perl 6 , 26 octets - Challenge 2
Essayez-le en ligne!
C'est juste
1 3 2 5 4 7 6...
Dans un nombre pair de termes, il y a toujours 2 plus de nombres impairs que pairs. Dans un nombre impair, 1 de plus. Cependant cela a clairement limite de(n+2)/(2n+2) -> ½
.Perl 6 , 70 bytes - Challenge 3
Essayez-le en ligne!
Certes, c'est horriblement joué au golf. Il indexe une séquence qui contient 2⁰ nombres impairs, puis 2¹ pairs, puis 2² impairs, puis 2³ pairs et ainsi de suite.
La probabilité après n de tels "blocs", si n est impair, est de (2⁰ + 2² + 2⁴ + ... + 2ⁿ⁻¹) / (2ⁿ-1). La somme au numérateur est égale à ⅓ (4 ½ (n + 1) - 1) = ⅓ (2 n + 1 - 1). Donc, la probabilité après le nombre impair de blocs est (dans la limite).
Si nous ajoutons un bloc supplémentaire (et en comptons un nombre pair n + 1), nous n’ajoutons aucun nombre impair (le numérateur reste identique), mais il y a maintenant (2 n + 1 - 1) nombres au total. . Les parenthèses s'annulent et nous obtenons la probabilité de (dans la limite).
Ceci est apparemment supposé avoir 2 points de cluster différents, et ⅔, pour s'assurer que la limite n'existe pas, mais cela ne le prouve pas vraiment. Ma tentative de réaliser une preuve solide et rigoureuse se trouve dans cette réponse de Math.SE: https://math.stackexchange.com/a/2416990/174637 . Les erreurs sont bienvenues.
Perl 6 , 39 octets - Le principal défi.
Essayez-le en ligne!
Bien que j’ai posté cette réponse en raison des défis 2 et 3 qui offraient un joli petit casse-tête mathématique, il est impératif que toutes les réponses contiennent une solution au défi principal. La voici alors.
Ceci est la séquence d'exemple.
la source
Brain-Flak , 120 octets
Essayez-le en ligne!
Effectue la fonction suivante:
Cette fonction génère la séquence
La fonction a une probabilité étrange de
1
la source
R, 82 octets (défi supplémentaire 1)
Essayez-le en ligne!
Si l'entrée est un carré parfait, donne un nombre pair. Sinon, donne un nombre impair. Les carrés parfaits ont une densité naturelle de 0, ce qui signifie que cette séquence donne des nombres impairs avec une probabilité de 1.
la source
C (gcc) , 29 octets
Essayez-le en ligne!
Chaque chiffre est pair:
Défi supplémentaire 1, 52 octets
Essayez-le en ligne!
Retourne 2 * (x + 1) si n est égal à 2 x et des nombres impairs consécutifs sinon:
la source
Brain-Flak ,
140138136 octetsEssayez-le en ligne!
Explication
Cela remplit une fonction similaire à celle suggérée dans la question.
Cela fonctionne principalement sur un extrait que j'ai fait rouler la pile pour les piles de taille 3.
Nous configurons deux piles, l’une avec les valeurs d’accumulateur (deux impaires paires) et l’autre avec les nombres
4 4 2
. A chaque itération, nous lançons les deux piles et ajoutons le haut de la pile de gauche au sommet de la pile de droite.Cela incrémentera chaque nombre impair de 4 et le nombre pair de 2. En effectuant une boucle, nous obtenons un motif de 2 impairs pairs, avec chaque entier positif touché. Ainsi, nous ne faisons que boucler les
n
temps avecn
l’entrée. Cela a une probabilité asymptotique de 2/3 .la source
Gelée , 10 octets
La probabilité de probabilité est de 2/3 .
Essayez-le en ligne!
Comment ça marche
la source
C, 80 octets
Mise en œuvre de l'exemple de permutation de la question.
Essayez-le en ligne!
la source
Lot, 36 octets
Implémente la séquence donnée dans la question.
la source
JavaScript, 23 octets
Sortie: 1, 3, 5, 2, 7, 9, 11, 4, 13, 15, 17, 6, 19, 21, 23, 8 ...
Défi 2:
Sortie: 1, 3, 2, 5, 4, 7, 6, 9, 8, 11, 10, 13, 12, 15, 14
la source
n=>n%4?1.5*n|1:n/2
est 5 octets plus court.CJam (21 octets)
Démo en ligne montrant les 32 premières sorties. Ceci est un bloc anonyme (fonction).
C'est également une solution pour relever le défi 1: les nombres mappés en nombres pairs sont les puissances de 2, de sorte que la densité des nombres pairs dans les n premières sorties est lg (n) / n, ce qui tend à zéro.
Dissection
la source
Perl 40 octets
la source
Brain-Flueue , 88 octets
Essayez-le en ligne!
Explication
Ceci implémente la même fonction que ma dernière réponse mais utilise le modèle FIFO de Brain-Flueue pour couper certains coins. Voici le premier couple de termes qu’il génère.
La première partie du code est juste un peu d’installation, nous mettons
0,-1,-3
la première pile et2,4,4
la deuxième pile. Le2,4,4
sera utilisé pour parcourir les nombres pairs et impairs, exactement comme je l’ai fait dans ma réponse Brain-Flak.On boucle ensuite n fois, en ajoutant chaque fois le haut de la pile de gauche à la pile de droite. Étant donné que Brain-Flueue utilise les files d'attente plutôt que les piles, les valeurs se déroulent naturellement lorsque nous les touchons, ce qui évite d'avoir besoin de code supplémentaire.
la source
-lflueue
argument.Python 2 ,
4610455 octetsEssayez-le en ligne!
A mal interprété la question, elle a correctement implémenté une fonction qui peut être utilisée pour générer une séquence au lieu de celle qui en génère une. Également exclu
0
de l'ensemble des sorties possibles.La probabilité de trouver un entier positif impair converge maintenant vers
1
.la source
0
.Gelée , 9 octets
Essayez-le en ligne!
Implements
1, 3, 2, 5, 7, 4, 9, 11, 6, ...
(probabilité 2/3).la source
05AB1E , 11 octets
Essayez-le en ligne!
la source
Pyth , 9 octets
Essayez-le ici! ou testez plus d'un coup!
Vous pouvez utiliser ce code pour vérifier le rapport des nombres impairs jusqu'à un certain point. Remplacez
10000
par la limite souhaitée (ne la définissez pas beaucoup plus haut, car cela entraînerait des erreurs de mémoire).Essayez ici .
Ce qui précède donne environ 0,667 . La probabilité réelle d’occurrences impaires est de 2/3 . Cette approche est une implémentation équivalente de la réponse de Dennis .
Explication
la source
Java 8, 20 octets
Réponse C du port de @nwellnhof .
Certaines choses que j'ai moi-même essayées ont fini par être plus longues ou légèrement incorrectes.
Implémente:
1,3,5,2,7,9,11,4,13,15,17,6,19,21,23,8,25,27,29,10,31,33,35,12,37,...
avec une probabilité de
3/4
.Essayez ici.
la source
Lua,
6753 octetsExplication à venir quand j'ai fini de jouer au golf :)Ce programme prend en entrée un entier via des arguments de ligne de commande et affiche le nième élément de la séquence exemple dans STDOUT.
Des explications
Les nombres pairs de cette séquence sont à la fois le
n
nombre pair et len
multiple de 3, la formulen%3*2
suffit donc à les générer.Pour les nombres impairs, c'est un peu plus difficile. Basé sur le fait que nous pouvons les trouver en fonction du courant
n
, nous avons le tableau suivant:Appelons la valeur
target-n
i
, nous pouvons voir que chaque foisn%3==2
,i
est incrémenté. Voilà notre formule:Les nombres impairs sont basés
n
sur ceux que nous ajoutonsi
.La valeur des
i
incréments au même taux que la division euclidienne de 3, avec un décalage.math.floor(n/3)
nous donne le taux d'incrément etn%3-1
le décalage, ce qui permet de le fairen%3==2
au lieu den%3==0
.la source
...and (n/...
).and n/3*2or
tout fonctionne parfaitement