Может случайные suitless

У меня есть реальные данные, которые я использую для симуляции карточной игры. Меня интересуют только ряды карт, а не масти. Однако это стандартная колода из карт, так что в колоде возможно только каждого ранга. Колода хорошо перетасовывается для каждой руки, и затем я вывожу всю колоду в файл. Таким образом , существует только возможных символов в выходном файле , которые являются . ( = десять ранга). Поэтому, конечно, мы можем распаковать их, используя бита на символ, но тогда мы тратим из возможных кодировок. Мы можем добиться большего успеха, если сгруппируем символа за раз, а затем сжимаем их, потому что$52$$4$$13$$2,3,4,5,6,7,8,9,T,J,Q,K,A$$T$$4$$3$$16$$4$$13^4$ = и это может вписаться довольно «уютно» в бит вместо . Теоретический предел упаковки битов составляет log ( ) / log ( ) = для данных с случайными символами для каждой возможной карты. Однако у нас не может быть королей, например, в этой колоде. Мы ДОЛЖНЫ иметь только каждого ранга в каждой колоде, поэтому энтропийное кодирование уменьшается примерно на половину бита на символ до .$28,561$$15$$16$$13$$2$$3.70044$$13$$52$$4$$3.2$

Итак, вот что я думаю. Эти данные не являются полностью случайными. Мы знаем, что есть каждого ранга, поэтому в каждом блоке из карт (назовем это перемешанной колодой), поэтому мы можем сделать несколько предположений и оптимизаций. Один из тех, кому мы не должны кодировать самую последнюю карту, потому что мы будем знать, какой она должна быть. Другая экономия была бы, если бы мы закончили на одном звании; например, если последние карты в колоде - , нам не нужно их кодировать, потому что декодер будет считать карты до этого момента и увидит, что все остальные ранги заполнены, и примет " пропущенные "карточки все с.$4$$52$$3$$777$$3$$7$

Поэтому мой вопрос к этому сайту: какие другие оптимизации возможны, чтобы получить еще меньший выходной файл для данных этого типа, и если мы их используем, сможем ли мы когда-нибудь превзойти теоретическую (простую) энтропию упаковки в бита на символ, или даже приблизиться к предельному пределу энтропии в среднем около бит на символ? Если так, то как?$3.70044$$3.2$

Когда я использую программу типа ZIP (например, WinZip), я вижу только сжатие , которое говорит мне, что это просто "ленивый" битпак до бит. Если я «предварительно сжимаю» данные, используя свою собственную битовую упаковку, мне кажется, что это лучше, потому что тогда, когда я запускаю это через zip-программу, я получаю сжатие чуть более . Я думаю, почему бы не сделать все сжатие самостоятельно (потому что я знаю больше данных, чем программа Zip). Мне интересно, смогу ли я энтропийный «предел» log ( ) / log ( ) =$2:1$$4$$2:1$$13$$2$$3.70044$, Я подозреваю, что смогу с несколькими упомянутыми мною «хитростями» и еще несколькими, возможно, узнаю. Разумеется, выходной файл не должен быть «читабельным». Пока кодировка без потерь, она действительна.

Вот ссылка на миллиона читаемых в случайном порядке колод (по на строку). Любой может «попрактиковаться» на небольшом подмножестве этих строк, а затем позволить ему копировать весь файл. Я буду обновлять мой лучший (самый маленький) размер файла на основе этих данных.$3$$1$

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

Кстати, в случае, если вас интересует, для какого типа карточных игр используются эти данные, вот ссылка на мой активный вопрос (с вознаграждением в баллов). Мне говорят, что это сложная проблема (точно), так как она потребует огромного количества места для хранения данных. Несколько моделей согласуются с приблизительными вероятностями. Никаких чисто математических решений предоставлено не было (пока). Наверное, это слишком сложно.$300$

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

У меня есть хороший алгоритм, который показывает бит для кодирования первой колоды в моих данных образца. Эти данные были получены случайным образом с использованием алгоритма случайного перемешивания Фишера-Йейтса. Это реальные случайные данные, поэтому мой недавно созданный алгоритм, кажется, работает ОЧЕНЬ хорошо, что меня радует.$168$

Что касается «проблемы» сжатия, то в настоящее время у меня около 160 бит на колоду. Я думаю, что могу опуститься до 158. Да, я попробовал, и я получил 158.43 бит на колоду. Я думаю, что я приближаюсь к пределу моего алгоритма, поэтому мне удалось опуститься ниже 166 бит на колоду, но мне не удалось получить 156 бит, что будет 3 бита на карту, но это было забавное упражнение. Возможно, в будущем я подумаю о том, чтобы уменьшить каждую колоду в среднем на 2,43 бит или более.

Еще одна вещь, которую стоит учесть: если вам нужно только сжать полный набор из нескольких миллионов колод, а также не заботиться о том, в каком порядке они находятся, вы можете получить дополнительную гибкость кодирования, отбрасывая информацию о порядке набора колод. , Это будет иметь место, например, если вам нужно загрузить набор, чтобы перечислить все колоды и обработать их, но не волнует, в каком порядке они обрабатываются.

Вы начинаете с кодирования каждой колоды индивидуально, как другие ответы описали, как это сделать. Затем отсортируйте эти закодированные значения. Сохраните серию различий между отсортированными кодированными значениями (где первое различие начинается с кодированной колоды '0'). Учитывая большое количество колод, различия, как правило, будут меньше, чем полный диапазон кодирования, поэтому вы можете использовать некоторую форму кодирования вариаций для обработки случайных больших различий, при этом сохраняя при этом небольшие различия. Соответствующая схема вартинта будет зависеть от того, сколько колод у вас в наборе (таким образом, определяя средний размер разницы).

К сожалению, я не знаю математики того, насколько это поможет вашему сжатию, но подумал, что эта идея может быть полезной для рассмотрения.

Вот полный алгоритм, который достигает теоретического предела.

Пролог: Кодирование целочисленных последовательностей

13-целочисленная последовательность "целое число с верхним пределом , целое число с верхним пределом b - 1 ," целое число с верхним пределом c - 1 , целое число с верхним пределом d - 1 , ... целое число с верхним пределом m - 1 " всегда можно кодировать с идеальной эффективностью.$a-1$$b-1$$c-1$$d-1$$m-1$

1. Возьмите первое целое число, умножьте его на , добавьте второе, умножьте результат на c , добавьте третье, умножьте результат на d ,… умножьте результат на m , добавьте тринадцатое - и это даст уникальное число между 0 и б с д е е г ч я J к л м - 1 .$b$$c$$d$$m$$0$$abcdefghijklm-1$
2. Запишите это число в двоичном виде.

Обратное тоже легко. Разделите на а остаток - тринадцатое целое число. Разделите результат на l, а остаток - двенадцатое целое число. Продолжайте до тех пор, пока вы не разделите на b : остаток - это второе целое число, а частное - это первое целое число.$m$$l$$b$

Поэтому, чтобы кодировать ваши карты наилучшим образом, все, что нам нужно сделать, - это найти идеальное соответствие между 13-целочисленными последовательностями (с заданными верхними пределами) и расположением ваших перемешанных карт.

Вот как это сделать.

Соответствие между тасовками и целочисленными последовательностями

Начните с последовательности из 0 карт на столе перед вами.

Шаг 1

Возьмите четыре двойки в вашем рюкзаке и положите их на стол.

Какой у вас есть выбор? Карта или карты могут быть помещены либо в начале последовательности, уже находящейся на столе, либо после любой из карт в этой последовательности. В этом случае это означает, что есть возможных мест для размещения карт.$1+0=1$

Общее количество способов размещения 4-х карт в 1-х местах - . Кодируйте каждый из этих способов как число от 0 до 1 - 1 . Есть 1 такой номер.$1$$0$$1-1$

Я получил 1, рассматривая способы записи 0 как сумму 5 целых чисел: это ,$\frac{4\times 3\times 2 \times 1}{4!}$

Шаг 2

Возьмите четыре тройки в вашем рюкзаке и положите их на стол.

Какой у вас есть выбор? Карта или карты могут быть помещены либо в начале последовательности, уже находящейся на столе, либо после любой из карт в этой последовательности. В этом случае это означает, что есть возможных мест для размещения карт.$1+4=5$

Общее количество способов размещения 4 карт в 5 местах - . Кодируйте каждый из этих способов числом от 0 до 70 - 1 . Есть 70 таких номеров.$70$$0$$70-1$

Я получил 70, рассматривая способы записи 4 как сумму 5 целых чисел: это ,$\frac{8\times 7\times 6 \times 5}{4!}$

Шаг 3

Возьмите четыре четверки в вашем пакете и положите их на стол.

Какой у вас есть выбор? Карта или карты могут быть помещены либо в начале последовательности, уже находящейся на столе, либо после любой из карт в этой последовательности. В этом случае это означает, что есть возможных мест для размещения карт.$1+8=9$

Общее количество способов размещения 4 карт в 9 местах составляет . Закодируйте каждый из этих способов как число между 0 и 495 - 1 . Есть 495 таких номеров.$495$$0$$495-1$

Я получил 495, рассматривая способы записи 8 как сумму 5 целых чисел: это ,$\frac{12\times 11\times 10 \times 9}{4!}$

И так до тех пор, пока ...

Шаг 13

Возьмите четыре туза из своей колоды и положите их на стол.

Какой у вас есть выбор? Карта или карты могут быть помещены либо в начале последовательности, уже находящейся на столе, либо после любой из карт в этой последовательности. В этом случае это означает, что есть возможных мест для размещения карт.$1+48=49$

Общее количество способов размещения 4 карточек в 49 местах составляет . Закодируйте каждый из этих способов числом от 0 до 270725 - 1 . Есть 270725 таких номеров.$270725$$0$$270725-1$

Я получил 270725, рассматривая способы записи 48 как сумму 5 целых чисел: это ,$\frac{52\times 51\times 50 \times 49}{4!}$

Эта процедура дает соответствие 1: 1 между (а) перетасовкой карточек, где вас не интересует масть, и (б) последовательностями целых чисел, где первая находится в диапазоне от до 1 - 1 , вторая - между 0 и 70 - 1 , третий находится в пределах от 0 и 495 - 1 , и так далее до тринадцатого, которая находится между 0 и 270725 - 1 .$0$$1-1$$0$$70-1$$0$$495-1$$0$$270725-1$

Ссылаясь на «Кодирование целочисленных последовательностей», вы можете видеть, что такая последовательность целых чисел находится в 1-1 соответствии с числами от до ( 1 × 70 × 495 × … × 270725 ) - 1 . Если вы посмотрите на выражение «произведение, деленное на факториал» каждого из целых чисел ( как описано курсивом в конце каждого шага ), то увидите, что это означает числа от 0 до 52 $0$$(1\times 70\times 495\times … \times 270725)-1$$0$который показал мой предыдущий ответ, был наилучшим из возможных.

Таким образом, у нас есть идеальный способ сжатия ваших перемешанных карт.

Алгоритм

Предварительно вычислить список всех способов записать 0 как сумму 5 целых чисел, записать 4 как сумму 5 целых чисел, записать 8 как сумму 5 целых чисел,… записать 48 как сумму 5 целых чисел. Самый длинный список содержит 270725 элементов, поэтому он не особенно большой. (Предварительные вычисления не являются строго необходимыми, потому что вы можете легко синтезировать каждый список по мере необходимости: пробовать с Microsoft QuickBasic, даже прохождение списка из 270725 элементов было быстрее, чем мог видеть глаз)

Чтобы перейти от тасования к последовательности целых чисел:

2s ничего не дают, поэтому давайте их проигнорируем. Запишите число от 0 до 1-1.

3s: сколько 2s есть до первых 3? Сколько перед вторым? третий? 4-й? после 4го? Ответ - 5 целых чисел, которые, очевидно, составляют в целом 4. Итак, посмотрите на эту последовательность из 5 целых чисел в вашем списке «написание 4 как сумма 5 целых» и отметьте его положение в этом списке. Это будет число от 0 до 70-1. Запиши это.

4: сколько 2 или 3 есть до первых 4? Сколько перед вторым? третий? 4-й? после 4го? Ответ - 5 целых чисел, которые, очевидно, составляют в сумме 8. Итак, найдите эту последовательность из 5 целых чисел в вашем списке «написание 8 как сумма 5 целых чисел» и отметьте его положение в этом списке. Это будет число от 0 до 495-1. Запиши это.

И так до тех пор, пока ...

Тузы: Сколько карт не туза до первого туза? Сколько перед вторым? третий? 4-й? после 4го? Ответ - 5 целых чисел, которые, очевидно, составляют в сумме 48. Итак, посмотрите на эту последовательность из 5 целых чисел в вашем списке «запись 48 как сумма 5 целых чисел» и отметьте его положение в этом списке. Это будет число от 0 до 270725-1. Запиши это.

Вы сейчас записали 13 целых чисел. Закодируйте их (как описано выше) в одно число от до 52 $0$ . Запишите это число в двоичном виде. Это займет чуть менее 166 бит.$\frac{52!}{(4!)^{13}}$

Это наилучшее возможное сжатие, поскольку оно достигает информационно-теоретического предела.

Декомпрессия проста: перейдите от большого числа к последовательности из 13 целых чисел, а затем используйте их для построения последовательности карт, как уже описано.

Вместо того, чтобы пытаться кодировать каждую карту отдельно в 3 или 4 бита, я предлагаю вам кодировать состояние всей колоды в 166 бит. Как объясняет Мартин Кочански , существует менее возможных расположений карт без учета мастей, что означает, что состояние всей колоды может быть сохранено в 166 битах.$2^{166}$

Как вы делаете это сжатие и распаковку алгоритмически, эффективным способом? Я предлагаю использовать лексикографическое упорядочение и бинарный поиск. Это позволит вам эффективно выполнять сжатие и распаковку (как в пространстве, так и во времени), не требуя большой справочной таблицы или других нереалистичных предположений.

Более подробно: давайте упорядочим колоды, используя лексикографическое упорядочение несжатого представления колоды, т. Е. Колода представлена ​​в несжатом виде в виде строки, например 22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA; Вы можете заказать их в соответствии с лексикографическим порядком. Теперь предположим, что у вас есть процедура, которая дает колоду , подсчитывает количество колод, предшествующих ей (в лексикографическом порядке). Затем вы можете использовать эту процедуру для сжатия колоды: с учетом колоды D вы сжимаете до 166-битного числа, считая количество колод, предшествующих ей, и затем выводя это число. Это число является сжатым представлением колоды.$D$$D$

Чтобы распаковать, используйте бинарный поиск. Учитывая число , вы хотите найти n- ю колоду в лексикографическом порядке всех колод. Вы можете сделать это, используя процедуру, аналогичную бинарному поиску: выбрать колоду D 0 , сосчитать количество колод до D 0 и сравнить это с n . Это скажет вам, нужно ли корректировать D $n$$n$$D_0$$D_0$$n$$D_0$прийти раньше или позже. Я предлагаю вам попытаться итеративно получить правильный символ: если вы хотите восстановить строку типа 22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA, сначала выполните поиск, чтобы найти то, что использовать в качестве первого символа в строке (просто попробуйте все 12 возможностей или используйте бинарный поиск по 12 возможностям ), затем, когда вы нашли правильное значение для первого символа, выполните поиск, чтобы найти второй символ, и так далее.

Все , что остается , чтобы придумать эффективную процедуру для подсчета количества колод , которые приходят лексикографический перед тем . Это выглядит как прямое, но утомительное комбинаторное упражнение. В частности, я предлагаю вам создать подпрограмму для следующей задачи: учитывая префикс (например, 222234), подсчитайте количество колод, которые начинаются с этого префикса. Ответ на эту проблему выглядит как довольно простое упражнение с биномиальными коэффициентами и факториалами. Затем, вы можете вызвать эту подпрограмму небольшое число раз , чтобы подсчитать число колод , которые приходят , прежде чем D .$D$$D$

Количество возможных расстановок карт без учета мастей - чья логарифмическая база 2 равна 165,976 или 3,1919 бит на карту, что лучше, чем установленный вами предел.

Любое фиксированное кодирование «битов на карту» не будет иметь смысла, поскольку, как вы заметили, последняя карта всегда может быть закодирована в битах, и во многих случаях также могут быть последние несколько карт. Это означает, что для довольно быстрого перехода к «хвосту» колоды количество битов, необходимых для каждой карты, будет намного меньше, чем вы думаете.$0$

Безусловно, наилучшим способом сжатия данных было бы найти 59 битов других данных, которые вы все равно хотите упаковать с данными вашей карты (на самом деле 59,6 бит), и записать эти 59 битов как 13-значное число по модулю 24 (= ), присвоить костюм каждой карте (одна цифра выбирает между 4 ! способов присвоения костюмов для асов, другой делает то же самое для царей, и так далее). Тогда у вас есть колода из 52 совершенно разных карт. 52 ! Возможности могут быть очень легко закодированы в 225,58 бит.$4!$$4!$$52!$

Но сделать это без возможности кодирования этих дополнительных битов также возможно в некоторой степени, и я подумаю об этом, как, я уверен, все остальные. Спасибо за действительно интересную проблему!

Это давно решенная проблема.

Когда вы разыгрываете колоду из 52 карт, каждая раздача карт имеет один из 13 рядов с известной вероятностью. Вероятности меняются с каждой раздачей карт. Это оптимально обрабатывается с использованием древней методики, называемой адаптивным арифметическим кодированием, улучшением кодирования Хаффмана. Обычно это используется для известных, неизменных вероятностей, но также может использоваться для изменения вероятностей. Прочитайте статью в Википедии об арифметическом кодировании:

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

Как DW, так и Martin Kochanski уже описали алгоритмы построения биекции между сделками и целыми числами в диапазоне , но, похоже, ни один из них не уменьшил проблему до самой простой формы. (Примечание 1)$[0, {52!\over(4!)^{13}})$

Предположим, у нас есть (частичная) колода, описываемая упорядоченным списком , где a i - количество карт типа i . В OP начальная колода описывается списком из 13 элементов, каждый из которых имеет значение 4. Число различных перемешиваний такой колоды равно$a$$a_i$$i$

что является простым обобщением биномиальных коэффициентов и действительно может быть доказано простым упорядочением объектов по одному типу за раз, как это было предложено Мартином Кочански. (См. Примечание 2 ниже)

Теперь для любой такой (частичной) колоды мы можем выбрать одну карту за раз, используя любую для которой a i > 0 . Количество уникальных тасов, начинающихся с i, составляет$i$$a_i>0$$i$

и по приведенной выше формуле мы имеем

Затем мы можем повторять (или повторять) всю колоду до тех пор, пока перемешивание не будет завершено, наблюдая, что число перемешиваний, соответствующих префиксу, лексикографически меньшему, чем префикс до равно$i$

Я написал это на Python, чтобы проиллюстрировать алгоритм; Python такой же разумный псевдокод, как и любой другой. Обратите внимание, что большая часть арифметики включает в себя расширенную точность; значения (представляющие порядковый номер тасования) и n (общее количество возможных тасов для оставшейся частичной колоды) являются 166-битовыми значениями. Чтобы перевести код на другой язык, необходимо будет использовать какую-то библиотеку bignum.$k$$n$

Кроме того, я просто использую список целых чисел, а не имен карт, и - в отличие от приведенной выше математики - целые числа основаны на 0.

Чтобы закодировать перемешивание, мы проходим по перемешиванию, накапливая в каждой точке количество перемешиваний, которые начинаются с меньшей карты, используя приведенную выше формулу:

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

Декодирование 166-битного числа является простым обратным. На каждом шаге у нас есть описание частичной колоды и порядковый номер; нам нужно пропустить перемешивание, начиная с карточек меньшего размера, чем та, которая соответствует порядковому номеру, а затем мы вычисляем вывод выбранной карточки, удаляем ее из оставшейся колоды и корректируем количество возможных перемешиваний с выбранным префиксом:

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

Я не пытался оптимизировать приведенный выше код. Я запустил его для всего файла 3mil.TXT, проверив, что encode(decode(line))привело к оригинальной кодировке; это заняло чуть менее 300 секунд. (Семь строк можно увидеть в онлайн-тесте на ideone .) Переписывание на языке более низкого уровня и оптимизация деления (что возможно), вероятно, сократило бы это время до чего-то управляемого.

Поскольку закодированное значение является просто целым числом, оно может быть выведено в 166 битах. Нет смысла удалять начальные нули, так как тогда не было бы никакой возможности узнать, где завершилась кодировка, так что это действительно 166-битная кодировка.

Однако стоит отметить, что в практическом приложении, вероятно, никогда не нужно кодировать случайный случай; случайный случайный порядок может быть сгенерирован путем генерации случайного 166-битного числа и его декодирования. И совсем не обязательно, чтобы все 166 бит были случайными; было бы возможно, например, начать с 32-битного случайного целого числа, а затем заполнить 166 битов, используя любой стандартный RNG, засеянный 32-битным числом. Таким образом, если цель состоит в том, чтобы просто иметь возможность воспроизводить большое количество случайных тасов, вы можете более или менее произвольно уменьшить требования к хранилищу для каждой сделки.

Если вы хотите , чтобы кодировать большое число фактических сделок (генерируемых каким - либо другим способом) , но не заботиться о порядке сделок, вы можете дельта-кодирование отсортированный список номеров, сэкономив примерно войти 2 N битов для каждого число. (Экономия является результатом того факта, что отсортированная последовательность имеет меньшую энтропию, чем несортированная последовательность. Она не уменьшает энтропию одного значения в последовательности.)$N$$\log_2 N$

Предполагая, что нам нужно закодировать отсортированный список из k- битных чисел, мы можем действовать следующим образом:$N$ $k$

1. Выберите в качестве целого числа, близкого к log 2 N (пол или потолок будут работать; обычно я иду к потолку).$p$$\log_2 N$

2. Мы неявно делим диапазон чисел на интервала двоичным префиксом. Каждый к номеру -битный делится на р -битных префикса и к - р -битный суффикс; выписываем только суффиксы (по порядку). Это требует N ∗ ( k - p ) битов.$2^p$$k$$p$$k-p$$N*(k-p)$

3. Кроме того, мы создаем битовую последовательность: для каждого из префиксов (кроме префикса 0 ) мы записываем 0 для каждого числа с этим префиксом (если есть), за которым следует 1 . Эта последовательность, очевидно, имеет 2 p + N битов: 2 p 1 с и N 0 с.$2^p$$0$$0$$1$$2^p+N$$2^p$ $1$$N$ $0$

Чтобы декодировать числа, мы запускаем счетчик префиксов с 0 и переходим к работе с битовой последовательностью. Когда мы видим , мы выводим текущий префикс и следующий суффикс из списка суффиксов; когда мы видим 1 , мы увеличиваем текущий префикс.$0$$1$

Общая длина кодирования составляет что очень близко к N ∗ ( k - p ) + N + N или N ∗ ( k - p + 2 ) для среднего значения из к - р + 2 бита на значение.$N*(k-p) + N + 2^p$$N*(k-p) + N + N$$N*(k-p+2)$$k-p+2$

Примечания

1. -92024242230271040357108320801872044844750000000000иlog252$52!\over(4!)^{13}$$92024242230271040357108320801872044844750000000000$ составляет примерно165,9765. В тексте я иногда притворяюсь, что логарифм base-2 действительно166; в случае генерации случайных порядковых чисел в пределах диапазона может использоваться алгоритм отклонения, который очень редко отклоняет сгенерированное случайное число.$\log_2 {52!\over(4!)^{13}}$$165.9765$$166$
2. Для удобства я пишу для n ∑ i = k a i ; затем через 1 объекты типа 1 могут быть помещены в ( S $S_k$$\sum\limits_{i=k}^n a_i$$a_1$$1$пути, а затем объекты типа2могут быть размещены в(S$S_1 \choose a_1$$2$пути и тд. Так как ( S$S_2 \choose a_2$, что приводит к общему количеству${S_i \choose a_i}={S_i! \over a_i!(S_i - a_i)!}={S_i!\over {a_i!S_{i+1}!}}$

что упрощает формулу выше.

В качестве альтернативного решения этой проблемы мой алгоритм использует составные дробные (нецелые) биты на карту для групп карт в колоде на основе количества оставшихся незаполненных рангов. Это довольно элегантный алгоритм. Я проверил мой алгоритм кодирования вручную, и он выглядит хорошо. Кодировщик выводит то, что представляется правильными цепочками битов (в байтовой форме для простоты).

Обзор моего алгоритма состоит в том, что он использует комбинацию групп карт и составное дробное кодирование битов. Например, в моем общем тестовом файле, состоящем из миллионов перемешанных колод, первая имеет первые 7 карт 54 A 236 Дж . Причина, по которой я выбрал 7- карточный размер блока, когда возможно 13 рядов карт, заключается в том, что 13 7 «рожков для обуви» (плотно прилегают) в 26 бит (так как 13 7 = 62 , 748 , 517 и 2 26 = 67 , 108 $3$$7$$54A236J$$7$$13$$13^7$$26$$13^7$$62,748,517$$2^{26}$ ). В идеале мы хотим, чтобы эти 2 числа были как можно ближе (но с силой 2 числа немного выше), чтобы не тратить впустую больше, чем очень маленькую долю в процессе упаковки битов. Обратите внимание, что я мог бы также выбрать размер группы 4 при кодировании 13 рангов, поскольку 13 4 = 28 , 561 и 2 15 = 32 , 768 . Это не так туго припадоктак как +15 / 4 = 3,75 , но +26 / +7 = $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$

Вот мой полный список затрат (количество бит на карту) для всех возможных количеств рангов:

$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. Если колода заканчивается парой (например, 77), тройной / сет (например, 777) или четверкой (например, 7777), мы получаем дополнительную экономию для этой колоды, используя мой алгоритм.

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

В первой колоде файла данных кодирование карточек выглядит следующим образом (схема будет представлена ​​позже). Формат (размер группы, биты, режим кодирования ранга):

$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$карта осталась. Это важно, потому что это делает процесс кодирования более эффективным, когда декодер может делать правильные предположения без необходимости передавать ему дополнительные сообщения.

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

54 A 236 J 87726 Q 3 3969 A A A Q J K 7 $~~~~~~~~~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$биты. Обратите внимание, что мы получили только один 4 в конце колоды, но если бы вместо этого мы получили все четыре 4, это лучший случай, и нам потребовалось бы только 161 бит для кодирования этой колоды, случай, когда упаковка фактически побеждает энтропия прямого двоичного кода его порядкового положения.

Теперь у меня есть код, реализованный для расчета требований к битам, и он показывает мне в среднем около 175 бит на деку с минимумом 155 и максимумом 183 для тестового файла с 3 миллионами колод. Таким образом, мой алгоритм использует 9 дополнительных бит на деку по сравнению с прямым двоичным кодированием метода порядкового положения. Не так уж плохо, только на 5,5% требуется дополнительное место для хранения. 176 бит это ровно 22 байта, так что это немного лучше, чем 52 байта на деку. Колода в лучшем случае (не показанная в тестовом файле с 3 миллионами колод) упаковывается в 136 битов, а колода в худшем случае (показанная в тестовом файле 8206 раз) составляет 183 бита. Анализ показывает, что наихудший случай - когда мы не получаем первый четырехугольник до тех пор, пока он не приблизится к (или не достигнет) 40-й карты. Затем, когда режим кодирования хочет быстро упасть, мы «застряли», заполняя блоки (размером до 7 карт) в более высокий режим кодирования битов. Кто-то может подумать, что не получить никаких квадов до 40-й карты было бы довольно редко, если использовать хорошо перемешанную колоду, но моя программа сообщает мне, что это произошло 321 раз в тестовом файле из 3 миллионов колод, так что это примерно 1 из каждых 9346 колод. Это чаще, чем я ожидал. Я мог бы проверить этот случай и обработать его с меньшим количеством битов, но это настолько редко, что это не повлияет на средние биты достаточно.

Также здесь есть кое-что еще очень интересное. Если я сортирую колоду по необработанным данным колоды, длина префиксов, которые повторяются значительное количество раз, составляет всего около 6 (например, 222244). Однако с упакованными данными эта длина увеличивается примерно до 16. Это означает, что если я отсортирую упакованные данные, я смогу получить значительную экономию, просто указав декодеру 16-битный префикс, а затем просто выведу оставшуюся часть колод (минус повторяющийся префикс), которые имеют тот же префикс, затем перейдите к следующему префиксу и повторите. Предполагая, что я сохраню даже 10 бит на колоду, я должен побить 166 бит на колоду. С техникой перечисления, заявленной другими, я не уверен, будет ли префикс таким же длинным, как в моем алгоритме. Также скорость упаковки и распаковки по моему алгоритму удивительно хороша.

Что касается 2-го уровня сжатия, где я сортирую выходные битовые строки моего алгоритма, а затем использую «разностную» кодировку: очень простой метод заключается в кодировании 61 278 уникальных 16-битных префиксов, которые отображаются как минимум дважды в выходных данных (и максимум 89 раз) просто в качестве начального бита 0 в выходных данных, чтобы указать декомпрессору 2-го уровня, что мы кодируем префикс (например, 0000111100001111), и затем любые упакованные колоды с таким же префиксом будут следовать с 1 начальным битом указать не префиксную часть упакованной колоды. Среднее количество упакованных колод с одинаковым префиксом составляет около 49 для каждого префикса, не считая нескольких уникальных (только одна колода имеет этот конкретный префикс). Похоже, я могу сэкономить около 15 бит на колоду, используя эту простую стратегию (сохраняя общие префиксы один раз).

После 2-го уровня сжатия с использованием разностного (префиксного) кодирования отсортированного вывода цепочки битов первого кодера я получаю около 160 бит на деку. Я использую префикс длины 18 и просто храню его без изменений. Поскольку почти все (245013 из 262144 = 93,5%) из этих возможных 18-битных префиксов отображаются, было бы еще лучше кодировать префиксы. Возможно, я могу использовать 2 бита, чтобы закодировать, какой тип данных у меня есть. 00 = обычный префикс 18 длины сохранен, 01 = «1 префикс up» (такой же, как предыдущий префикс, кроме 1 добавленного), 11 = прямое кодирование из упаковки 1-го уровня (в среднем около 175 бит). 10 = будущее расширение, когда я думаю о чем-то еще, чтобы кодировать, чтобы сохранить биты.

Кто-нибудь еще побил 160 бит на колоду? Я думаю, что смогу немного снизить мой уровень, экспериментируя и используя 2-битные дескрипторы, которые я упоминал выше. Возможно, он достигнет дна на 158-м. Моя цель - получить 156 бит (или лучше), потому что это будет 3 бита на карту или меньше. Очень впечатляюще. Много экспериментов, чтобы довести его до этого уровня, потому что если я изменю кодировку первого уровня, то мне придется повторно протестировать, которая является лучшей кодировкой 2-го уровня, и есть много комбинаций, которые можно попробовать. Некоторые изменения, которые я делаю, могут быть полезны для других подобных случайных данных, но некоторые могут быть смещены в сторону этого набора данных. Не совсем уверен, но если я получу желание, я могу попробовать другой набор данных из трех миллионов колод, чтобы посмотреть, что произойдет, если я получу аналогичные результаты на нем.

$10^{50}$

У кого-нибудь есть идеи о том, как сделать мой алгоритм лучше, например, какие другие случаи я должен кодировать, чтобы уменьшить объем памяти для каждой колоды в среднем? Кто-нибудь?

Еще 2 вещи: 1) Я несколько разочарован тем, что больше людей не одобрили мое решение, которое, хотя и не является оптимальным по пространству, все же является приличным и довольно простым для реализации (у меня все работает нормально). 2) Я выполнил анализ своего файла данных с 3 миллионами колод и заметил, что наиболее часто встречающаяся карта с заполнением 1-го ранга (например, 4444) находится на карте 26. Это происходит примерно в 6,711% времени (для 201322 из 3 миллионов колод) ). Я надеялся использовать эту информацию, чтобы сжать больше, например, начать в режиме 12-символьного кодирования, так как мы знаем, что в среднем мы не видим каждый ранг до середины колоды, но этот метод не сжимал ни одного, поскольку его издержки превышали экономию. Я ищу некоторые изменения в моем алгоритме, которые могут реально сохранить биты.

Так есть ли у кого-нибудь идеи, что мне следует попробовать, чтобы сэкономить несколько бит на колоду, используя мой алгоритм? Я ищу паттерн, который встречается достаточно часто, чтобы я мог уменьшить количество бит на деку даже после дополнительных затрат на указание декодеру, какой паттерн ожидать. Я думал что-то с ожидаемой вероятностью оставшихся невидимых карт и складывал все оставшиеся одиночные карты в одно ведро. Это позволит мне быстрее перейти в режим более низкого кодирования и, возможно, сохранить некоторые биты, но я сомневаюсь в этом.

Кроме того, к вашему сведению, я сгенерировал 10 миллионов случайных перемешиваний и сохранил их в базе данных для удобства анализа. Только 488 из них заканчиваются квадом (например, 5555). Если я упаковываю только те, которые используют мой алгоритм, я получаю в среднем 165.71712 бит с низким 157 битам и высоким 173 битам. Чуть ниже 166 бит, используя другой метод кодирования. Я несколько удивлен тем, насколько редок этот случай (примерно 1 из каждых 20 492 тасовок в среднем).