Les données aléatoires de

J'ai de vraies données que j'utilise pour un jeu de cartes simulé. Je ne m'intéresse qu'aux rangs des cartes, pas aux couleurs. Cependant, il s'agit d'un jeu de cartes standard , il n'y a donc que de chaque rang possible dans le jeu. Le jeu est bien mélangé pour chaque main, puis je renvoie l'ensemble du jeu dans un fichier. Donc , il n'y a que symboles possibles dans le fichier de sortie qui sont . ( = dix rang). Donc, bien sûr, nous pouvons les compresser en utilisant bits par symbole, mais nous gaspillons alors des encodages possibles. Nous pouvons faire mieux si nous groupons symboles à la fois, puis les compressons, car$52$$4$$13$$2,3,4,5,6,7,8,9,T,J,Q,K,A$$T$$4$$3$$16$$4$$13^4$ = et qui peut tenir plutôt "confortablement" en bits au lieu de . La limite théorique de compression des bits est log ( ) / log ( ) = pour les données avec symboles aléatoires pour chaque carte possible. Cependant nous ne pouvons pas avoir rois par exemple dans ce deck. Nous ne devons avoir que de chaque rang dans chaque deck, de sorte que le codage entropique chute d'environ un demi-bit par symbole à environ .$28,561$$15$$16$$13$$2$$3.70044$$13$$52$$4$$3.2$

Ok, voici donc ce que je pense. Ces données ne sont pas totalement aléatoires. Nous savons qu'il y a de chaque rang, donc dans chaque bloc de cartes (appelez cela un jeu mélangé), nous pouvons donc faire plusieurs hypothèses et optimisations. L'un de ceux-ci étant, nous n'avons pas à encoder la toute dernière carte, car nous saurons ce qu'elle devrait être. Une autre économie serait si nous nous retrouvions sur un seul rang; par exemple, si les dernières cartes du jeu sont , nous n'aurions pas à les coder car le décodeur compterait les cartes jusqu'à ce point et verrait que tous les autres rangs ont été remplis, et supposera les " les cartes manquantes sont toutes de s.$4$$52$$3$$777$$3$$7$

Donc, ma question à ce site est, quelles autres optimisations sont possibles pour obtenir un fichier de sortie encore plus petit sur ce type de données, et si nous les utilisons, pouvons-nous jamais battre l'entropie théorique (simple) de bits de bits par symbole, ou même approcher la limite ultime d'entropie d'environ bits par symbole en moyenne? Si c'est le cas, comment?$3.70044$$3.2$

Lorsque j'utilise un programme de type ZIP (WinZip par exemple), je ne vois qu'une compression , ce qui me dit qu'il ne fait qu'un bitpack "paresseux" à bits. Si je «précompresse» les données en utilisant mon propre bitpacking, cela semble mieux, car lorsque je l'exécute via un programme zip, j'obtiens un peu plus de compression. Ce que je pense, c'est pourquoi ne pas faire moi-même toute la compression (parce que je connais mieux les données que le programme Zip). Je me demande si je peux battre la "limite" d'entropie de log ( ) / log ( ) =$2:1$$4$$2:1$$13$$2$$3.70044$. Je soupçonne que je peux avec les quelques "trucs" que j'ai mentionnés et quelques autres que je peux probablement découvrir. Le fichier de sortie ne doit bien sûr pas être "lisible par l'homme". Tant que l'encodage est sans perte, il est valide.

Voici un lien vers millions de jeux mélangés lisibles par l'homme ( par ligne). N'importe qui peut "s'exercer" sur un petit sous-ensemble de ces lignes, puis le laisser déchirer sur l'ensemble du fichier. Je continuerai à mettre à jour ma meilleure (plus petite) taille de fichier en fonction de ces données.$3$$1$

https://drive.google.com/file/d/0BweDAVsuCEM1amhsNmFITnEwd2s/view

Au fait, au cas où vous seriez intéressé par le type de jeu de cartes pour lequel ces données sont utilisées, voici le lien vers ma question active (avec prime de points). On me dit que c'est un problème difficile à résoudre (exactement) car cela nécessiterait une énorme quantité d'espace de stockage de données. Cependant, plusieurs simulations concordent avec les probabilités approximatives. Aucune solution purement mathématique n'a encore été apportée. C'est trop dur, je suppose.$300$

/math/1882705/probability-2-player-card-game-with-multiple-patterns-to-win-who-has-the-advant

J'ai un bon algorithme qui affiche bits pour encoder le premier deck dans mes données d'échantillon. Ces données ont été générées de manière aléatoire en utilisant l'algorithme de shuffle de Fisher-Yates. Ce sont de vraies données aléatoires, donc mon algorithme nouvellement créé semble très bien fonctionner, ce qui me rend heureux.$168$

Concernant le "challenge" de compression, je suis actuellement à environ 160 bits par platine. Je pense que je peux descendre à peut-être 158. Oui, j'ai essayé et j'ai obtenu 158,43 bits par platine. Je pense que je me rapproche de la limite de mon algorithme, j'ai donc réussi à descendre en dessous de 166 bits par jeu, mais je n'ai pas réussi à obtenir 156 bits, ce qui serait 3 bits par carte, mais c'était un exercice amusant. Peut-être qu'à l'avenir, je penserai à quelque chose pour réduire chaque platine en moyenne de 2,43 bits ou plus.

Une autre chose à considérer: si vous vous souciez uniquement de compresser un ensemble complet de plusieurs millions de decks et que vous ne vous souciez pas non plus de l'ordre dans lequel ils se trouvent, vous pouvez gagner une flexibilité d'encodage supplémentaire en supprimant les informations sur la commande de l'ensemble de decks . Ce serait le cas, par exemple, si vous devez charger l'ensemble pour énumérer tous les decks et les traiter, mais peu importe l'ordre dans lequel ils sont traités.

Vous commencez par encoder chaque deck individuellement, comme d'autres réponses ont décrit comment procéder. Ensuite, triez ces valeurs codées. Stockez une série de différences entre les valeurs codées triées (où la première différence commence à partir du pont codé «0»). Étant donné un grand nombre de decks, les différences auront tendance à être plus petites que la plage de codage complète, vous pouvez donc utiliser une forme de codage varint pour gérer les grandes différences occasionnelles tout en stockant les différences plus petites de manière efficace. Le schéma de varint approprié dépendrait du nombre de decks que vous avez dans l'ensemble (déterminant ainsi la taille moyenne de la différence.)

Je ne sais malheureusement pas à quel point cela pourrait aider votre compression, mais j'ai pensé que cette idée pourrait être utile à considérer.

Voici un algorithme complet qui atteint la limite théorique.

Prologue: encodage de séquences entières

Une séquence de 13 entiers "entier avec limite supérieure , entier avec limite supérieure b - 1 ," entier avec limite supérieure c - 1 , entier avec limite supérieure d - 1 , ... entier avec limite supérieure m - 1 " peut toujours être codé avec une efficacité parfaite.$a-1$$b-1$$c-1$$d-1$$m-1$

1. Prenez le premier entier, multipliez-le par , ajoutez le second, multipliez le résultat par c , ajoutez le troisième, multipliez le résultat par d ,… multipliez le résultat par m , ajoutez le treizième - et cela produira un nombre unique entre 0 et a b c d e f g h i j k l m - 1 .$b$$c$$d$$m$$0$$abcdefghijklm-1$
2. Notez ce nombre en binaire.

L'inverse est également facile. Divisez par et le reste est le treizième entier. Divisez le résultat par l et le reste est le douzième entier. Continuez jusqu'à ce que vous ayez divisé par b : le reste est le deuxième entier et le quotient est le premier entier.$m$$l$$b$

Donc, pour coder vos cartes de la meilleure façon possible, tout ce que nous avons à faire est de trouver une correspondance parfaite entre des séquences de 13 entiers (avec des limites supérieures données) et les dispositions de vos cartes mélangées.

Voici comment faire.

Correspondance entre les réarrangements et les séquences entières

Commencez avec une séquence de 0 cartes sur la table devant vous.

Étape 1

Prenez les quatre 2 dans votre sac et placez-les sur la table.

Quels choix avez-vous? Une ou plusieurs cartes peuvent être placées soit au début de la séquence déjà sur la table, soit après l'une des cartes de cette séquence. Dans ce cas, cela signifie qu'il y a emplacements possibles pour mettre des cartes.$1+0=1$

Le nombre total de façons de placer 4 cartes à 1 endroits est de . Encodez chacune de ces façons sous la forme d'un nombre compris entre 0 et 1 - 1 . Il y en a 1.$1$$0$$1-1$

J'ai obtenu 1 en considérant les façons d'écrire 0 comme la somme de 5 entiers: c'est .$\frac{4\times 3\times 2 \times 1}{4!}$

Étape 2

Prenez les quatre 3 dans votre sac et placez-les sur la table.

Quels choix avez-vous? Une ou plusieurs cartes peuvent être placées soit au début de la séquence déjà sur la table, soit après l'une des cartes de cette séquence. Dans ce cas, cela signifie qu'il y a emplacements possibles pour mettre des cartes.$1+4=5$

Le nombre total de façons de placer 4 cartes à 5 endroits est de . Encodez chacune de ces façons sous la forme d'un nombre compris entre 0 et 70 - 1 . Il y en a 70.$70$$0$$70-1$

J'ai obtenu 70 en considérant les façons d'écrire 4 comme la somme de 5 entiers: c'est .$\frac{8\times 7\times 6 \times 5}{4!}$

Étape 3

Prenez les quatre 4 dans votre sac et placez-les sur la table.

Quels choix avez-vous? Une ou plusieurs cartes peuvent être placées soit au début de la séquence déjà sur la table, soit après l'une des cartes de cette séquence. Dans ce cas, cela signifie qu'il y a emplacements possibles pour mettre des cartes.$1+8=9$

Le nombre total de façons de placer 4 cartes à 9 endroits est de . Encodez chacune de ces façons sous la forme d'un nombre compris entre 0 et 495 - 1 . Il en existe 495.$495$$0$$495-1$

J'ai obtenu 495 en considérant les façons d'écrire 8 comme la somme de 5 entiers: c'est .$\frac{12\times 11\times 10 \times 9}{4!}$

Et ainsi de suite, jusqu'à ce que ...

Étape 13

Prenez les quatre as dans votre sac et placez-les sur la table.

Quels choix avez-vous? Une ou plusieurs cartes peuvent être placées soit au début de la séquence déjà sur la table, soit après l'une des cartes de cette séquence. Dans ce cas, cela signifie qu'il y a emplacements possibles pour mettre des cartes.$1+48=49$

Le nombre total de façons de placer 4 cartes à 49 endroits est de . Encodez chacune de ces façons sous la forme d'un nombre compris entre 0 et 270725 - 1 . Il y en a 270725.$270725$$0$$270725-1$

J'ai obtenu 270725 en considérant les façons d'écrire 48 comme la somme de 5 entiers: c'est .$\frac{52\times 51\times 50 \times 49}{4!}$

Cette procédure produit une correspondance 1 à 1 entre (a) des mélanges de cartes où vous ne vous souciez pas de la couleur et (b) des séquences d'entiers où le premier est compris entre et 1 - 1 , le second est entre 0 et 70 - 1 , le troisième est compris entre 0 et 495 - 1 , et ainsi de suite jusqu'au treizième, qui est compris entre 0 et 270725 - 1 .$0$$1-1$$0$$70-1$$0$$495-1$$0$$270725-1$

En se référant à "Encodage de séquences entières", vous pouvez voir qu'une telle séquence d'entiers est en correspondance 1-1 avec les nombres entre et ( 1 × 70 × 495 × … × 270725 ) - 1 . Si vous regardez l'expression "produit divisé par une factorielle" de chacun des entiers ( comme décrit en italique à la fin de chaque étape ), vous verrez que cela signifie les nombres entre 0 et 52 $0$$(1\times 70\times 495\times … \times 270725)-1$$0$ce que ma réponse précédente a montré était le meilleur possible.

Nous avons donc une méthode parfaite pour compresser vos cartes mélangées.

L'algorithme

Précalculez une liste de toutes les façons d'écrire 0 comme la somme de 5 entiers, d'écrire 4 comme la somme de 5 entiers, d'écrire 8 comme la somme de 5 entiers,… d'écrire 48 comme la somme de 5 entiers. La liste la plus longue contient 270725 éléments, elle n'est donc pas particulièrement longue. (Le pré-calcul n'est pas strictement nécessaire car vous pouvez facilement synthétiser chaque liste au fur et à mesure de vos besoins: essayer avec Microsoft QuickBasic, même parcourir la liste des éléments 270725 était plus rapide que l'œil ne pouvait le voir)

Pour passer d'un mélange à une séquence d'entiers:

Les 2 ne contribuent à rien, alors ignorons-les. Notez un nombre entre 0 et 1-1.

Les 3: Combien y a-t-il de 2 avant les 3 premiers? Combien avant la seconde? le troisième? le 4? après le 4? La réponse est 5 entiers, ce qui correspond évidemment à 4. Alors recherchez cette séquence de 5 entiers dans votre liste "écrit 4 comme la somme de 5 entiers" et notez sa position dans cette liste. Ce sera un nombre compris entre 0 et 70-1. Écris le.

Les 4: Combien y a - t-il de 2 ou 3 avant les 4 premiers? Combien avant la seconde? le troisième? le 4? après le 4? La réponse est 5 nombres entiers qui, évidemment, totalisent 8. Donc, recherchez cette séquence de 5 nombres entiers dans votre liste "écrire 8 comme la somme de 5 nombres entiers" et notez sa position dans cette liste. Ce sera un nombre compris entre 0 et 495-1. Écris le.

Et ainsi de suite, jusqu'à ce que…

Les as: Combien de cartes non-as y a-t-il avant le premier as? Combien avant la seconde? le troisième? le 4? après le 4? La réponse est 5 nombres entiers qui totalisent évidemment 48. Recherchez donc cette séquence de 5 nombres entiers dans votre liste "écrire 48 comme la somme de 5 nombres entiers" et notez sa position dans cette liste. Ce sera un nombre compris entre 0 et 270725-1. Écris le.

Vous avez maintenant noté 13 entiers. Encodez-les (comme décrit précédemment) en un seul numéro entre et 52 $0$ . Écrivez ce nombre en binaire. Cela prendra un peu moins de 166 bits.$\frac{52!}{(4!)^{13}}$

Il s'agit de la meilleure compression possible, car elle atteint la limite théorique de l'information.

La décompression est simple: passez du grand nombre à la séquence de 13 entiers, puis utilisez-les pour construire la séquence de cartes comme déjà décrit.

Plutôt que d'essayer d'encoder chaque carte séparément en 3 ou 4 bits, je vous suggère de coder l'état de l'ensemble du jeu en 166 bits. Comme Martin Kochanski explique , il y a moins de arrangements possibles des cartes ignorant costumes, de sorte que les moyens de l'état du pont entier peut être stocké dans 166 morceaux.$2^{166}$

Comment effectuez-vous cette compression et décompression de manière algorithmique, de manière efficace? Je suggère d'utiliser l'ordre lexicographique et la recherche binaire. Cela vous permettra d'effectuer efficacement la compression et la décompression (à la fois dans l'espace et dans le temps), sans nécessiter une grande table de recherche ou d'autres hypothèses irréalistes.

Plus en détail: Ordonnons les decks en utilisant l'ordre lexicographique sur la représentation non compressée du deck, c'est-à-dire qu'un deck est représenté sous forme non compressée sous la forme d'une chaîne comme 22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA; vous pouvez les commander selon l'ordre lexicographique. Supposons maintenant que vous ayez une procédure qui, étant donné un deck , compte le nombre de decks qui le précèdent (dans l'ordre lexicographique). Ensuite, vous pouvez utiliser cette procédure pour compresser un deck: étant donné un deck D , vous compressez à un nombre de 166 bits en comptant le nombre de decks qui le précèdent puis en sortant ce nombre. Ce nombre est la représentation compressée du jeu.$D$$D$

Pour décompresser, utilisez la recherche binaire. Étant donné un nombre , vous voulez trouver le n ème jeu dans l'ordre lexicographique de tous les jeux. Vous pouvez le faire en utilisant une procédure dans le sens de la recherche binaire: choisissez un jeu D 0 , comptez le nombre de jeux avant D 0 et comparez-le à n . Cela vous dira si vous souhaitez ajuster D $n$$n$$D_0$$D_0$$n$$D_0$à venir plus tôt ou plus tard. Je vous suggère d'essayer d'obtenir le symbole de manière itérative: si vous souhaitez récupérer une chaîne comme 22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA, commencez par rechercher pour trouver quoi utiliser comme premier symbole de la chaîne (essayez simplement les 12 possibilités ou utilisez la recherche binaire sur les 12 possibilités) ), puis lorsque vous avez trouvé la bonne valeur pour le premier symbole, recherchez le deuxième symbole, etc.

Tout ce qui reste est de trouver une procédure efficace pour compter le nombre de ponts qui viennent lexicographique avant . Cela ressemble à un exercice combinatoire simple mais fastidieux. En particulier, je vous suggère de créer un sous-programme pour le problème suivant: étant donné un préfixe (comme 222234), comptez le nombre de ponts qui commencent par ce préfixe. La réponse à ce problème ressemble à un exercice assez facile de coefficients binomiaux et factoriels. Ensuite, vous pouvez appeler ce sous - programme un petit nombre de fois pour compter le nombre de ponts qui viennent avant D .$D$$D$

Le nombre d'arrangements possibles des cartes ignorant les combinaisons est de dont la base de logarithme 2 est 165,976, soit 3,1919 bits par carte, ce qui est mieux que la limite que vous avez donnée.

Tout fixe le codage « bits par carte » ne sera pas de sens parce que, comme vous le notez, la dernière carte peut toujours être codée en bits , et dans de nombreux cas , les dernières quelques cartes peuvent être aussi bien. Cela signifie que pour un certain chemin vers la "queue" du pack, le nombre de bits nécessaires pour chaque carte sera bien inférieur à ce que vous pensez.$0$

De loin, la meilleure façon de compresser les données serait de trouver de toute façon 59 bits d'autres données que vous souhaitez emballer avec vos données de carte (59,6 bits, en fait) et, en écrivant ces 59 bits sous la forme d'un nombre à 13 chiffres modulo 24 (= ), Attribuez une couleur à chaque carte (un chiffre choisit entre les 4 ! Façons d'affecter des couleurs aux as, un autre fait de même pour les rois, etc.). Ensuite, vous avez un pack de 52 cartes totalement distinctes. 52 ! les possibilités peuvent être encodées en 225,58 bits très facilement.$4!$$4!$$52!$

Mais le faire sans saisir l'occasion de coder ces bits supplémentaires est également possible dans une certaine mesure, et j'y penserai comme je suis sûr que tout le monde l'est. Merci pour un problème vraiment intéressant!

Il s'agit d'un problème résolu depuis longtemps.

Lorsque vous distribuez un jeu de 52 cartes, chaque carte que vous distribuez possède l'un des 13 rangs avec les probabilités connues. Les probabilités changent avec chaque carte distribuée. Cela est géré de manière optimale en utilisant une technique ancienne appelée codage arithmétique adaptatif, une amélioration du codage Huffman. Habituellement, cela est utilisé pour les probabilités connues et immuables, mais il peut tout aussi bien être utilisé pour changer les probabilités. Lisez l'article de wikipedia sur le codage arithmétique:

https://en.wikipedia.org/wiki/Arithmetic_coding

DW et Martin Kochanski ont déjà décrit des algorithmes pour construire une bijection entre des offres et des entiers dans la plage , mais il semble qu'aucun d'eux n'ait réduit le problème à sa forme la plus simple. (Note 1)$[0, {52!\over(4!)^{13}})$

Supposons que nous ayons un jeu (partiel) décrit par la liste ordonnée , où a i est le nombre de cartes de type i . Dans le PO, le jeu initial est décrit par une liste de 13 éléments, chacun avec la valeur 4. Le nombre de shuffles distincts d'un tel jeu est$a$$a_i$$i$

qui est une simple généralisation des coefficients binomiaux, et pourrait en effet être prouvée en disposant simplement les objets un type à la fois, comme l'a suggéré Martin Kochanski. (Voir ci-dessous, note 2)

Maintenant, pour toute plate - forme (partielle), on peut sélectionner une lecture aléatoire d' une carte à la fois, en utilisant tout pour lequel un i > 0 . Le nombre de shuffles uniques commençant par i est$i$$a_i>0$$i$

et par la formule ci-dessus, nous avons

Nous pouvons ensuite recurse (ou itérer) à travers le jeu jusqu'à ce que le shuffle soit terminé en observant que le nombre de shuffles correspondant à un préfixe lexicographiquement plus petit que le préfixe jusqu'à est$i$

J'ai écrit ceci en Python pour illustrer l'algorithme; Python est un pseudocode aussi raisonnable que n'importe quel autre. Notez que la plupart de l'arithmétique implique une précision étendue; les valeurs (représentant l'ordinal du shuffle) et n (le nombre total de shuffles possibles pour le paquet partiel restant) sont toutes deux des bignums de 166 bits. Pour traduire le code dans une autre langue, il sera nécessaire d'utiliser une sorte de bibliothèque bignum.$k$$n$

De plus, j'utilise simplement une liste d'entiers plutôt que des noms de carte, et - contrairement aux calculs ci-dessus - les entiers sont basés sur 0.

Pour encoder un shuffle, nous parcourons le shuffle, en accumulant à chaque point le nombre de shuffles qui commencent par une carte plus petite en utilisant la formule ci-dessus:

from math import factorial
T = factorial(52) // factorial(4) ** 13

def encode(vec):
    a = [4] * 13
    cards = sum(a)
    n = T
    k = 0
    for idx in vec:
        k += sum(a[:idx]) * n // cards
        n = a[idx] * n // cards
        a[idx] -= 1
        cards -= 1
    return k

Le décodage d'un nombre de 166 bits est l'inverse simple. À chaque étape, nous avons la description d'un paquet partiel et d'un ordinal; nous devons sauter les shuffles en commençant par des cartes plus petites que celle qui correspond à l'ordinal, puis nous calculons la sortie de la carte sélectionnée, la supprimons du jeu restant et ajustons le nombre de shuffles possibles avec le préfixe sélectionné:

def decode(k):
    vec = []
    a = [4] * 13
    cards = sum(a)
    n = T
    while cards > 0:
        i = cards * k // n
        accum = 0
        for idx in range(len(a)):
            if i < accum + a[idx]:
                k -= accum * n // cards
                n = a[idx] * n // cards
                a[idx] -= 1
                vec.append(idx)
                break
            accum += a[idx]
        cards -= 1
    return vec

Je n'ai pas vraiment tenté d'optimiser le code ci-dessus. Je l'ai exécuté sur l'intégralité du fichier 3mil.TXT, en vérifiant qu'il en encode(decode(line))résultait l'encodage d'origine; cela a pris un peu moins de 300 secondes. (Sept des lignes peuvent être vues dans le test en ligne sur ideone .) La réécriture dans un langage de niveau inférieur et l'optimisation de la division (ce qui est possible) réduirait probablement ce temps à quelque chose de gérable.

Comme la valeur codée est simplement un entier, elle peut être sortie en 166 bits. Il n'y a aucune valeur à supprimer les zéros de tête, car il n'y aurait alors aucun moyen de savoir où un codage s'est terminé, il s'agit donc vraiment d'un codage de 166 bits.

Cependant, il convient de noter que dans une application pratique, il n'est probablement jamais nécessaire de coder un shuffle; un mélange aléatoire peut être généré en générant un nombre aléatoire de 166 bits et en le décodant. Et il n'est pas vraiment nécessaire que les 166 bits soient aléatoires; il serait possible, par exemple, de commencer avec un entier aléatoire de 32 bits, puis de remplir les 166 bits en utilisant n'importe quel RNG standard prédéfini avec le nombre de 32 bits. Donc, si l'objectif est simplement de pouvoir stocker de manière reproductible un grand nombre de shuffles aléatoires, vous pouvez réduire plus ou moins arbitrairement l'exigence de stockage par transaction.

Si vous souhaitez coder un grand nombre de transactions réelles (générées d'une autre manière) mais que vous ne vous souciez pas de l'ordre des transactions, vous pouvez coder en delta la liste triée de nombres, en économisant environ 2 N bits de journal pour chaque nombre. (Les économies résultent du fait qu'une séquence triée a moins d'entropie qu'une séquence non triée. Elle ne réduit pas l'entropie d'une valeur unique dans la séquence.)$N$$\log_2 N$

En supposant que nous devons coder une liste triée de k bits, nous pouvons procéder comme suit:$N$ $k$

1. Choisissez comme un entier proche de log 2 N (soit le sol, soit le plafond fonctionnera; j'opte généralement pour le plafond).$p$$\log_2 N$

2. Nous divisons implicitement la plage de nombres en intervalles de par préfixe binaire. Chaque numéro à k bits est divisé en un préfixe à p bits et un suffixe à k - p bits; nous n'écrivons que les suffixes (dans l'ordre). Cela nécessite N ∗ ( k - p ) bits.$2^p$$k$$p$$k-p$$N*(k-p)$

3. De plus, nous créons une séquence de bits: pour chacun des préfixes (sauf le préfixe 0 ), nous écrivons un 0 pour chaque numéro avec ce préfixe (le cas échéant) suivi d'un 1 . Cette séquence comporte évidemment 2 p + N bits: 2 p 1 s et N 0 s.$2^p$$0$$0$$1$$2^p+N$$2^p$ $1$$N$ $0$

Pour décoder les nombres, nous commençons un compteur de préfixes à 0 et procédons à la séquence de bits. Quand nous voyons un , nous sortons le préfixe actuel et le suffixe suivant de la liste des suffixes; lorsque nous voyons un 1 , nous incrémentons le préfixe actuel.$0$$1$

La longueur totale du codage est qui est très proche de N ∗ ( k - p ) + N + N , ou N ∗ ( k - p + 2 ) , pour une moyenne de k - p + 2 bits par valeur.$N*(k-p) + N + 2^p$$N*(k-p) + N + N$$N*(k-p+2)$$k-p+2$

Remarques

1. est92024242230271040357108320801872044844750000000000etlog252$52!\over(4!)^{13}$$92024242230271040357108320801872044844750000000000$ est environ165,9765. Dans le texte, je prétends parfois que le logarithme en base 2 est vraiment166; dans le cas de la génération d'ordinaires aléatoires dans la plage, un algorithme de rejet pourrait être utilisé qui ne rejetterait que très rarement un nombre aléatoire généré.$\log_2 {52!\over(4!)^{13}}$$165.9765$$166$
2. Par commodité, j'écris pour n ∑ i = k a i ; puis l' un 1 des objets de type 1 peuvent être placés dans ( S $S_k$$\sum\limits_{i=k}^n a_i$$a_1$$1$façons, puis les objets de type2peuvent être placés dans(S$S_1 \choose a_1$$2$façons, et ainsi de suite. Depuis ( S$S_2 \choose a_2$, ce qui conduit au nombre total${S_i \choose a_i}={S_i! \over a_i!(S_i - a_i)!}={S_i!\over {a_i!S_{i+1}!}}$

ce qui simplifie la formule ci-dessus.

Comme solution alternative à ce problème, mon algorithme utilise des bits fractionnaires composés (non entiers) par carte pour des groupes de cartes dans le jeu en fonction du nombre de rangs non remplis qui restent. C'est un algorithme assez élégant. J'ai vérifié mon algorithme d'encodage à la main et il a l'air bien. L'encodeur sort ce qui semble être des chaînes de bits correctes (sous forme d'octets pour plus de simplicité).

$3$$7$$54A236J$$7$$13$$13^7$$26$$13^7$$62,748,517$$2^{26}$$67,108,864$$2$$4$$13$$13^4$$28,561$$2^{15}$$32,768$$15/4 = 3.75$$26/7 = 3.714$$26/7$

$54A236J$$23456789TJQKA$$5$$4$$7$$13$$10$$15,565,975$$26$$00111011011000010010010111$

$26$$15,565,975$$13$$54A236J$$7$

$13, 12, 11 ..., 2, 1)$$13,12,11...$$2$$13$$12$$12$$2$$12^5$$248,832$$2^{18}$$262,144$$18/5$$3.6$$13$$26/7$$3.714$$5555$$3333$

Voici ma liste complète des coûts (# de bits par carte) pour tous les # possibles de rangs à voir:

$13~~~~26/7 = 3.714 = 3~~5/7$
$12~~~~18/5 = 3.600 = 3~~3/5$
$11~~~~~~7/2 = 3.500 = 3~~1/2$
$10~~~~10/3 = 3.333 = 3~~1/3$
$~~9~~~~16/5 = 3.200 = 3~~1/5$
$~~8~~~~~~3/1 = 3.000 = 3$
$~~7~~~~17/6 = 2.833 = 2~~5/6$
$~~6~~~~13/5 = 2.600 = 2~~3/5$
$~~5~~~~~~7/3 = 2.333 = 2~~1/3$
$~~4~~~~~~2/1 = 2.000 = 2$
$~~3~~~~~~5/3 = 1.667 = 1~~2/3$
$~~2~~~~~~1/1 = 1.000 = 1$
$~~1~~~~~~0/1..4 = 0.0 = 0$

$7$$5,6,7,7,7,7,K$$K$$13$$12$$7$$13$$K$$2$$1,2,3...$$3$$13$$1$$7$$20$

$168$$13, 12, 11$

$1$$0$$7777$$48$$7$$4$$7$s. Si le jeu se termine sur une paire (comme 77), triple / set (comme 777) ou un quad (comme 7777), nous obtenons des économies supplémentaires pour ce jeu en utilisant mon algorithme.

$32$$2^{26}$$13$$16$$32$$32$

Dans le premier deck du fichier de données, l'encodage des cartes est le suivant (schéma à venir plus tard). Le format est (taille de groupe, bits, mode d'encodage de rang):

$7,26,13$$7$$26$$13$
$7,26,13$
$7,26,13$
$5,18,12$
$5,18,12$
$3,10,10$
$3,~~9,~~8$
$6,17,~~7$
$5,13,~~6$
$3,~~5,~~3$
$1,~~0,~~1$

$52$$168$$3.23$

$18$$1/3$$3.2$$3.2$$54545454722772277...$$3$$22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA$$4$$0$

$1$$10$$3,7$$K$$8$$10$$1$carte restante. Ceci est important car il rend le processus d'encodage plus efficace lorsque le décodeur peut émettre des hypothèses correctes sans que l'encodeur n'ait à lui transmettre des messages supplémentaires.

$3$$13$$12$$11$$10$

$~~~~~~~~~26~~~~~~~~~~~~~26~~~~~~~~~~~~~26~~~~~~~~~~~~18~~~~~~~~~18~~~~~~~10~~~~~~9~~~~~~~~~~17~~~~~~~~~~~13~~~~~~~~5~~~~~0$
$~~~~54A236J~~87726Q3~~3969AAA~~QJK7T~~9292Q~~36K~~J57~~~T8TKJ4~~48Q8T~~55K~~4$
$13~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~12~~~~~~~~~~~~~~~~~~~~xy~~~~~98~~~~~~~~~7~~~~~~~~~~~~~~6~~~~~~~~543~~~~~2~1~~0$

$2$$166$$175$$168$morceaux. Notez que nous n'avons obtenu qu'un seul 4 à la fin du jeu, mais si au lieu de cela, nous avons tous les quatre 4, c'est un meilleur cas et nous n'aurions eu besoin que de 161 bits pour coder ce jeu, un cas où l'emballage bat réellement le entropie d'un codage binaire droit de la position ordinale de celui-ci.

J'ai maintenant le code implémenté pour calculer les exigences en bits et il me montre en moyenne environ 175 bits par deck avec un minimum de 155 et un maximum de 183 pour le fichier de test de 3 millions de deck. Mon algorithme semble donc utiliser 9 bits supplémentaires par jeu par rapport au codage binaire droit de la méthode de position ordinale. Pas trop mal avec seulement 5,5% d'espace de stockage supplémentaire requis. 176 bits est exactement 22 octets, ce qui est un peu mieux que 52 octets par platine. Le meilleur paquet de cas (n'apparaissait pas dans 3 millions de fichiers de test de paquet) contient 136 bits et le pire cas (il est apparu dans le fichier de test 8206 fois), est de 183 bits. L'analyse montre que le pire des cas est lorsque nous n'obtenons le premier quadruple que près (ou au niveau) de la carte 40. Ensuite, comme le mode d'encodage veut tomber rapidement, nous sommes "bloqués" en remplissant des blocs (jusqu'à 7 cartes) dans un mode de codage de bits supérieur. On pourrait penser que ne pas obtenir de quads avant la carte 40 serait assez rare en utilisant un deck bien mélangé, mais mon programme me dit que cela s'est produit 321 fois dans le fichier de test de 3 millions de decks, ce qui fait environ 1 sur 9346 decks. C'est plus souvent que je m'y attendais. Je pourrais vérifier ce cas et le gérer avec moins de bits, mais il est si rare qu'il n'affecterait pas suffisamment les bits moyens.

Voici aussi autre chose de très intéressant. Si je trie le jeu sur les données brutes du jeu, la longueur des préfixes qui se répètent un nombre significatif de fois n'est que de la longueur 6 (comme 222244). Cependant, avec les données compressées, cette longueur augmente à environ 16. Cela signifie que si je trie les données compressées, je devrais être en mesure de réaliser des économies importantes en indiquant simplement au décodeur un préfixe de 16 bits, puis en sortant simplement le reste des ponts (moins le préfixe répétitif) qui ont le même préfixe, puis passez au préfixe suivant et répétez. En supposant que j'économise même seulement 10 bits par deck de cette façon, je devrais battre les 166 bits par deck. Avec la technique d'énumération indiquée par d'autres, je ne sais pas si le préfixe serait aussi long qu'avec mon algorithme. De plus, la vitesse d'emballage et de déballage en utilisant mon algorithme est étonnamment bonne.

Concernant le 2ème niveau de compression où je trie les chaînes de bits de sortie de mon algorithme, puis j'utilise un codage "différence": Une méthode très simple serait de coder les 61.278 préfixes 16 bits uniques qui apparaissent au moins deux fois dans les données de sortie (et un maximum de 89 fois rapporté) simplement comme un bit de tête de 0 dans la sortie pour indiquer au décompresseur de 2e niveau que nous encodons un préfixe (tel que 0000111100001111), puis tous les ponts emballés avec ce même préfixe suivront avec un bit de tête de 1 à indiquer la partie non préfixe du paquet emballé. Le nombre moyen de decks emballés avec le même préfixe est d'environ 49 pour chaque préfixe, sans compter les quelques uns qui sont uniques (seulement 1 deck a ce préfixe particulier). Il semble que je puisse économiser environ 15 bits par jeu en utilisant cette stratégie simple (en stockant une fois les préfixes communs).

Après le 2ème niveau de compression utilisant le codage de différence (préfixe) de la sortie de chaîne de bits triée du premier codeur, j'obtiens maintenant environ 160 bits par platine. J'utilise le préfixe de longueur 18 et je le stocke intact. Étant donné que presque tous (245013 sur 262144 = 93,5%) de ces préfixes 18 bits possibles apparaissent, il serait encore mieux de coder les préfixes. Je peux peut-être utiliser 2 bits pour coder le type de données dont je dispose. 00 = longueur régulière 18 préfixe stocké, 01 = "1 préfixe supérieur" (identique au préfixe précédent sauf 1 ajouté), 11 = codage direct à partir d'un emballage de 1er niveau (environ 175 bits en moyenne). 10 = extension future quand je pense à autre chose à encoder qui sauvera des bits.

Quelqu'un d'autre a-t-il déjà battu 160 bits par jeu? Je pense que je peux obtenir le mien un peu plus bas avec quelques expériences et en utilisant les descripteurs 2 bits que j'ai mentionnés ci-dessus. Peut-être qu'il atteindra un creux à 158ish. Mon objectif est de l'amener à 156 bits (ou mieux) car ce serait 3 bits par carte ou moins. Très impressionnant. Beaucoup d'expérimentations pour descendre à ce niveau car si je change l'encodage de premier niveau, je dois retester qui est le meilleur encodage de 2ème niveau et il y a beaucoup de combinaisons à essayer. Certaines modifications que je fais peuvent être bonnes pour d'autres données aléatoires similaires, mais certaines peuvent être biaisées vers cet ensemble de données. Pas vraiment sûr, mais si j'ai envie, je peux essayer un autre ensemble de données de 3 millions de jeux pour voir ce qui se passe si j'obtiens des résultats similaires.

$10^{50}$

Quelqu'un a-t-il des idées sur la façon d'améliorer mon algorithme, comme les autres cas que je devrais encoder, ce qui réduirait en moyenne les bits de stockage pour chaque deck? N'importe qui?

2 autres choses: 1) Je suis quelque peu déçu que plus de gens n'aient pas voté pour ma solution qui, bien qu'elle ne soit pas optimale dans l'espace, est toujours décente et assez facile à mettre en œuvre (la mienne fonctionnait bien). 2) J'ai fait une analyse sur mon fichier de données de 3 millions de deck et j'ai remarqué que la carte la plus fréquente où le premier rang se remplit (comme 4444) est à la carte 26. Cela se produit environ 6,711% du temps (pour 201322 des 3 millions de decks ). J'espérais utiliser ces informations pour compresser davantage, comme commencer en mode d'encodage à 12 symboles, car nous savons qu'en moyenne, nous ne verrons pas tous les rangs jusqu'à environ middeck, mais cette méthode n'a pas réussi à compresser tout car les frais généraux dépassaient les économies. Je cherche quelques ajustements à mon algorithme qui peuvent réellement sauver des bits.

Alors, quelqu'un a-t-il des idées sur ce que je devrais essayer ensuite pour économiser quelques bits par jeu en utilisant mon algorithme? Je recherche un modèle qui se produit assez fréquemment pour que je puisse réduire les bits par platine même après la surcharge supplémentaire de dire au décodeur quel modèle à attendre. Je pensais à quelque chose avec les probabilités attendues des cartes invisibles restantes et je regroupais toutes les cartes restantes dans un seul seau. Cela me permettra de passer plus rapidement en mode d'encodage inférieur et peut-être d'enregistrer quelques bits mais j'en doute.

Aussi, pour info, j'ai généré 10 millions de shuffles aléatoires et les ai stockés dans une base de données pour une analyse facile. Seuls 488 d'entre eux se terminent en quad (comme 5555). Si je n'emballe que ceux qui utilisent mon algorithme, j'obtiens 165.71712 bits en moyenne avec un minimum de 157 bits et un maximum de 173 bits. Juste légèrement en dessous des 166 bits en utilisant l'autre méthode de codage. Je suis quelque peu surpris de la rareté de ce cas (environ 1 sur 20 492 shuffles en moyenne).