Grands gros chiffres

25

Tout en essayant de jouer plusieurs de mes réponses, j'ai dû écrire de grands nombres entiers en aussi peu de caractères que possible.

Maintenant, je connais la meilleure façon de le faire: je vais vous faire écrire ce programme.

Le défi

  • Écrivez un programme qui, lorsqu'il reçoit un entier positif, génère un programme qui l'imprime sur stdout ou équivalent.
  • Les programmes de sortie ne doivent pas nécessairement être dans la même langue que le créateur.
  • La sortie doit être d'au plus 128 octets.
  • Vous pouvez accepter l'entrée de stdin ou équivalent (pas d'entrée de fonction)
  • Vous pouvez sortir le programme résultant sur stdout ou équivalent.
  • La sortie numérique doit être décimale (base 10)

Notation

Votre score est égal au plus petit entier positif que votre programme ne peut pas coder.

L'entrée avec le score le plus élevé l'emporte.

Bleu
la source
J'ai ajouté le tag metagolf, car nous jouons au programme de sortie.
orlp
1
@orlp Je l'ai en fait omis exprès, car metagolf est une balise de critère de notation qui dit "le score est la longueur de votre sortie". J'envisage d'ajouter un méta post à ce sujet pour permettre également une sorte de score inverse (ce qui est le cas pour le code le plus rapide par exemple).
Martin Ender
1
@ MartinBüttner Je suppose que nous avons besoin d' une source de méta-restriction :)
orlp
2
En quoi le défi est-il différent de "quelle langue a la plus grande plage d'entiers" ?
nwp
5
@nwp Je pense que vous avez mal compris la question. La question concerne la compression. Il serait utile, mais pas nécessaire, d'utiliser un langage avec une grande plage d'entiers.
pomme de terre

Réponses:

2

Python 3 → CJam, (163 122 - 1) · 255/162 + 1 ≈ 1.213 · 10 270

import sys
n = int(input())
for b in range(163, 1, -1):
    s = []
    m = n
    while m:
        m, r = divmod(m - 93, b)
        if m < 0:
            break
        s.append(r + 93)
    else:
        sys.stdout.buffer.write(b'"%s"%db' % (bytes(s[::-1]), b))
        break
else:
    sys.stdout.buffer.write(b'%d' % n)

Il s'avère que chaque entier de 1023 à (163 122 - 1) · 255/162 peut être représenté au moins d'une manière par une conversion de base b ≤ 163 à partir d'une chaîne d'au plus 122 caractères avec les codes 93 à b + 92, plutôt que l'habituel de 0 à b - 1. Cela évite les caractères gênants 34 (guillemet double) et 92 (barre oblique inverse) sans aucun code de sortie supplémentaire.

Anders Kaseorg
la source
12

Pyth, 252 111 ≈ 3,593 × 10 266

Js[
"ixL-rC1`H``N"
N
s@L-rC1`H``NjQ252
N
"252")$import sys$$sys.stdout.buffer.write(J.encode('iso-8859-1'))$

J'ai dû utiliser un peu de syntaxe Python, car Pyth ne printpeut pas imprimer iso-8859-1.

Le nombre est codé en base 252 et représente chaque chiffre de cette base sous la forme d'un caractère iso-8859-1. Les caractères\ et "auraient besoin de s'échapper et ne sont donc pas utilisés. Le caractère `n'est pas utilisé parce que jouer au golf ... Et en plus, l'octet nul n'est pas non plus utilisé, le compilateur Pyth l'interdit.

La sortie est un programme avec une surcharge de 17 octets:

ixL-rC1`H``N""252

Voici un exemple d'utilisation avec le plus grand nombre possible:

Usage

Explication

du programme de sortie.

ixL-rC1`H``N""252
    rC1`H          create the range of chars: ['\x01', '\x02', ..., '{}']
         ``N       creates a string containing the 3 chars " ' \
   -               remove strings which consists of these 3 chars
 xL         ""     determine the index of each char in "" (encoded number)
i             252  convert from base 253 to base 10
Jakube
la source
1
Ce programme ne parvient pas à encoder 12, car Pyth lit malheureusement CR comme LF .
Anders Kaseorg
10

CJam, 254 109 ≈ 1,34 x 10 262

q~254b{_33>+_91>+c}%`"{_'[>-_'!>-}%254b"

J'encode le nombre dans la base 254 et représente chaque chiffre de cette base sous la forme d'un caractère ISO 8859-1, en sautant "et \. La sortie a une surcharge de 19 octets, ""{_'[>-_'!>-}%254bdonc je peux représenter tout ce qui est inférieur à 254 128-19 , ou explicitement

13392914970384089616967895168962602841770234460440231501234736723328784159136966979592516521814270581662903357791625539571324435618053333498444654631269141250284088221909534717492397543057152353603090337012149759082408143603558512232742912453092885969482645766144

Par exemple, 6153501serait codé comme

"abc"{_'[>-_'!>-}%254b

Voici un programme de test qui imprime l'entier codé, puis imprime sa longueur, puis l'exécute immédiatement pour montrer sa validité (cela évite d'avoir à copier les caractères non imprimables dans un nouveau programme, qui ne fonctionne pas toujours avec l'interprète en ligne).

Martin Ender
la source
8

Perl, 10 216

print"print unpack'h*',q{",(pack'h*',<>),"}"

Encodage également en base 100, légèrement plus élégant. Sortie pour12345678 serait:

print unpack'h*',q{!Ce‡}

Les délimètres {et} correspondent aux valeurs hexadécimalesb7 et d7respectivement, qui ne peuvent pas apparaître dans l'entrée, et donc ne pas besoin d'être échappé.

Il y a 20 octets de surcharge, laissant 108 pour le codage, atteignant une valeur maximale de 10 216 -1.


Perl, 10 206

print"ord=~print\$' for'",(map chr"1$_",<>=~/.{1,2}/g),"'=~/.|/g"

Encodage simple en base 100. La sortie pour 12345678ressemblerait à ceci:

ord=~print$' for'p†œ²'=~/.|/g

Il y a 25 octets de surcharge, laissant 103 pour le codage, atteignant une valeur maximale de 10 206 -1.

primo
la source
6

Lisp commun, 36114 - 1 ~ 2,62 × 10117

(lambda(x)(format t"(lambda()#36r~36r)"x))

Le plus grand nombre est:

262110903510567204510935835404817018532936318707188694632900321233523044002781809113959992952482356206474995078940249429827687987350383362234813840904013801840002194446327847

Utilisez simplement la base 36. Pour la plus grande entrée, la sortie longue de 128 octets est:

(lambda()#36rzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz)
coredump
la source
1

CJam, 233 114 ≈ 7,561⋅10 269

ri233b{Kms/m]_34=+c}%s`"{iKms*}%233b"

Le programme de sortie "…"{iKms*}%233bdécode les caractères 8 bits d'une chaîne en base 233 chiffres avec n ↦ ⌊ n ⋅ sin 20⌋ = ⌊ n ⋅ 0,913⌋. Cette transformation se trouve être surjective sans nécessiter les points de code critiques 34 (guillemet double) et 92 (barre oblique inverse) en entrée.

Anders Kaseorg
la source