임의의 적합한 카드 데이터를 압축하여 엔트로피 인코딩 스토리지에 접근, 일치 또는 이길 수 있습니까? 그렇다면 어떻게?

시뮬레이션 카드 게임에 사용중인 실제 데이터가 있습니다. 나는 소송이 아닌 카드의 등급에만 관심이 있습니다. 그러나 표준 카드 덱이므로 덱에는 개의 등급 만 있습니다. 데크는 각 손에 대해 잘 섞은 다음 전체 데크를 파일로 출력합니다. 따라서 출력 파일에는 가능한 기호 만 있습니다 . ( = 10 등급). 물론 심볼 당 비트를 사용하여 비트 팩을 비트 팩 할 수 있지만 가능한 가지 인코딩 중 를 낭비하고 있습니다. 한 번에 심볼을 그룹화 한 다음 압축하면 더 잘 수행 할 수 있습니다.$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$

좋아, 여기 내가 생각하는 것입니다. 이 데이터는 완전히 무작위가 아닙니다. 우리 는 각 카드 블록에 각 등급의 가 있다는 것을 알고 있으므로 (셔플 데크라고 함) 몇 가지 가정과 최적화를 할 수 있습니다. 우리는 마지막 카드를 인코딩 할 필요가 없습니다. 왜냐하면 카드가 무엇인지 알아야하기 때문입니다. 우리가 단일 순위에서 끝날 경우 또 다른 절감 효과가 있습니다. 마지막 예를 들어, 갑판에서 카드가 , 우리는 디코더가 그 시점에 계산 카드를하고 다른 모든 순위가 작성되어있는 것을 볼 것이기 때문에 사람들을 인코딩 할 필요가 없습니다 것입니다, 그리고 가정 할 것이다 " missing "카드는 모두 초입니다.$4$$52$$3$$777$$3$$7$

따라서이 사이트에 대한 나의 질문은이 유형의 데이터에 대해 더 작은 출력 파일을 얻을 수있는 다른 최적화 방법이며, 사용하는 경우 심볼 당 비트 의 이론적 (간단한) 비트 패킹 엔트로피를 평균적으로 심볼 당 약 3.2 비트 의 최대 엔트로피 한계에 접근 합니까? 그렇다면 어떻게?$3.70044$$3.2$

ZIP 유형 프로그램 (예 : WinZip)을 사용할 때 $2:1$ 압축 만 볼 수 있습니다 . 이는 단지 "게으른" 비트 팩을 $4$ 비트로하고 있음을 나타냅니다. 내 자신의 비트 팩킹을 사용하여 데이터를 "사전 압축"하면 압축 프로그램을 통해 데이터를 실행할 때 $2:1$ 압축 이 약간 초과되기 때문에 더 좋아 보입니다 . 내가 생각하는 것은 모든 압축을 직접하지 않는 이유입니다 (Zip 프로그램보다 데이터에 대한 지식이 많기 때문입니다). log ( $13$ ) / log ( $2$ ) = 3.70044 의 엔트로피 "제한"을 이길 수 있는지 궁금합니다.$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

샘플 데이터의 첫 번째 데크를 인코딩하기 위해 비트를 보여주는 좋은 알고리즘이 있습니다. 이 데이터는 Fisher-Yates 셔플 알고리즘을 사용하여 임의로 생성되었습니다. 실제 무작위 데이터이므로 새로 작성된 알고리즘이 매우 잘 작동하는 것 같습니다.$168$

압축 "도전"과 관련하여 현재 데크 당 약 160 비트입니다. 나는 아마도 158로 내려갈 수 있다고 생각한다. 그렇다. 나는 시도했고 갑판 당 158.43 비트를 얻었다. 나는 알고리즘의 한계에 가까워져 갑판 당 166 비트 아래로 떨어지는 데 성공했지만 카드 당 3 비트 인 156 비트를 얻지 못했지만 재미있는 운동이었습니다. 아마도 미래에는 각 데크를 평균 2.43 비트 이상 줄이려고 생각할 것입니다.

고려해야 할 또 다른 사항 : 수백만 개의 데크 전체를 압축하는 데 관심이 있고 순서가 신경 쓰지 않는 경우 데크 세트의 순서에 대한 정보를 삭제하여 추가 인코딩 유연성을 얻을 수 있습니다 . 예를 들어, 모든 데크를 열거하고 처리하기 위해 세트를로드해야하지만 처리 순서를 신경 쓰지 않는 경우가 여기에 해당합니다.

다른 답변에서 방법을 설명했듯이 각 데크를 개별적으로 인코딩하여 시작합니다. 그런 다음 인코딩 된 값을 정렬하십시오. 정렬 된 인코딩 된 값 (첫 번째 차이는 인코딩 된 데크 '0'에서 시작) 사이에 일련의 차이를 저장하십시오. 데크가 많으면 차이가 전체 인코딩 범위보다 작은 경향이 있으므로 작은 차이를 효율적으로 저장하면서 일부 형태의 바 린트 인코딩을 사용하여 가끔 큰 차이를 처리 할 수 ​​있습니다. 적절한 varint 구성표는 세트에있는 데크의 수에 따라 다릅니다 (따라서 평균 차이 크기를 결정합니다).

불행히도 이것이 압축에 얼마나 도움이 될지에 대한 수학을 모르지만이 아이디어가 고려하는 것이 유용 할 것이라고 생각했습니다.

이론적 한계에 도달하는 완전한 알고리즘은 다음과 같습니다.

프롤로그 : 정수 시퀀스 인코딩

13 개의 정수 시퀀스 "상한이 인 정수, 상한이 b - 1 인 정수,"상한이 c - 1 인 정수, 상한이 d - 1 인 정수, ... 상한이 m - 1 인 정수 " 항상 완벽한 효율성으로 코딩 할 수 있습니다.$a-1$$b-1$$c-1$$d-1$$m-1$

1. 첫 번째 정수에 곱하고 , 두 번째에 곱하고, 결과에 c를 곱하고, 세 번째에 더하고, 결과에 d 를 곱하고, 결과에 m을 곱한 다음 , 13을 더하십시오. 그러면 0 사이의 고유 한 숫자가 생성됩니다. 및 a b c d e f g h i j k l m - 1 .$b$$c$$d$$m$$0$$abcdefghijklm-1$
2. 이 숫자를 이진수로 기록하십시오.

반대로도 쉽습니다. 나누면 나머지는 13 번째 정수입니다. 결과를 나누면 나머지는 12 번째 정수입니다. 로 나눌 때까지 계속 하십시오. 나머지는 두 번째 정수이고 몫은 첫 번째 정수입니다.l $m$$l$$b$

따라서 가능한 최상의 방식으로 카드를 코딩하려면 13 개의 정수 시퀀스 (상한이 주어진 상태)와 셔플 카드 배열 사이의 완벽한 대응 관계를 찾아야합니다.

방법은 다음과 같습니다.

셔플 링과 정수 시퀀스의 대응

앞의 테이블에서 일련의 0 장의 카드로 시작하십시오.

1 단계

팩에있는 4 개의 2를 가져 와서 테이블 위에 놓으십시오.

어떤 선택이 있습니까? 카드는 이미 테이블에있는 순서의 시작 부분이나 해당 순서의 카드 중 하나 뒤에 배치 될 수 있습니다. 이 경우 이는 카드를 넣을 수있는 장소 가 것을 의미합니다 .$1+0=1$

1 개 장소에 4 장의 카드를 배치하는 총 방법 수는 입니다. 각 방법을 과 사이의 숫자로 인코딩하십시오 . 그러한 숫자는 1입니다.$1$$0$$1-1$

0을 5 정수의 합계로 쓰는 방법을 고려하여 1을 얻었습니다. 입니다.$\frac{4\times 3\times 2 \times 1}{4!}$

2 단계

당신의 팩에있는 4 개의 3을 가지고 테이블에 놓으십시오.

어떤 선택이 있습니까? 카드는 이미 테이블에있는 순서의 시작 부분이나 해당 순서의 카드 중 하나 뒤에 배치 될 수 있습니다. 이 경우 카드를 넣을 수있는 장소 가 라는 의미입니다 .$1+4=5$

5 개 장소에 4 장의 카드를 배치하는 총 방법 수는 입니다. 사이의 값으로 이러한 방식으로 각각 인코딩 0 과 70 - 1 . 70 개의 숫자가 있습니다.$70$$0$$70-1$

4를 5 정수의 합으로 쓰는 방법을 고려하여 70을 얻었습니다 .$\frac{8\times 7\times 6 \times 5}{4!}$

3 단계

당신의 팩에있는 4 개의 4를 가지고 테이블에 놓으십시오.

어떤 선택이 있습니까? 카드는 이미 테이블에있는 순서의 시작 부분이나 해당 순서의 카드 중 하나 뒤에 배치 될 수 있습니다. 이 경우 카드를 넣을 수있는 장소 는 입니다.$1+8=9$

9 개 장소에 4 장의 카드를 배치하는 총 방법 수는 입니다. 사이의 숫자로 그 각각의 방법을 인코딩 0 과 (495) - (1) . 495 개의 숫자가 있습니다.$495$$0$$495-1$

8을 5 정수의 합으로 쓰는 방법을 고려하여 495를 얻었습니다 .$\frac{12\times 11\times 10 \times 9}{4!}$

그리고 계속해서 ...

13 단계

팩에있는 4 개의 에이스를 가져 와서 테이블 위에 놓습니다.

어떤 선택이 있습니까? 카드는 이미 테이블에있는 순서의 시작 부분이나 해당 순서의 카드 중 하나 뒤에 배치 될 수 있습니다. 이 경우 카드를 넣을 수있는 장소 는 입니다.$1+48=49$

49 개 장소에 4 장의 카드를 배치하는 총 방법은 입니다. 사이의 값으로 이러한 방식으로 각각 인코딩 0 및 270,725 - 1 . 270725 개의 숫자가 있습니다.$270725$$0$$270725-1$

나는 5 개 정수의 합으로 (48)를 작성하는 방법을 고려하여 270,725을 가지고 : 그것이 .$\frac{52\times 51\times 50 \times 49}{4!}$

---

이 절차는 사이에 1 대 1 대응을 산출 (가) 당신이이 사이에 처음으로 정장 및 정수의 (b)의 시퀀스에 대한 상관 없어 카드의 shufflings 과 1 - 1 , 두 번째는 사이에 0 과 70 - 1 , 세 번째 사이에 0 과 495 - 1 등 사이 인 13 일까지에 0 과 27만7백25 - 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$내 이전 대답했다 최상의이었다.

$$\frac{52!}{(4!)^{13}}-1\text,$$

셔플 카드를 압축하는 완벽한 방법이 있습니다.

---

알고리즘

0을 5 개의 정수의 합계로 쓰고, 4를 5 개의 정수의 합계로 쓰고, 8을 5 개의 정수의 합계로 쓰고, 48을 5 개의 정수의 합계로 쓰는 모든 방법의 목록을 미리 계산 하십시오. 가장 긴 목록에는 270725 개의 요소가 있으므로 특별히 크지는 않습니다. (각 목록을 필요할 때마다 쉽게 합성 할 수 있기 때문에 사전 계산이 반드시 필요한 것은 아닙니다. Microsoft QuickBasic을 사용하면 270725 요소 목록을 살펴 보는 것이 눈에 보이는 것보다 빠릅니다.)

셔플 링에서 정수 시퀀스로 가져 오려면 :

2는 아무 것도 기여하지 않으므로 무시하십시오. 0과 1-1 사이의 숫자를 기록하십시오.

3 : 첫 3 전에 몇이 있습니까? 두 번째 전에 몇 명입니까? 세 번째? 넷째? 4 일 이후? 정답은 4를 더한 5 개의 정수입니다. 따라서 "4를 5 개의 정수의 합계로 작성"목록에서 5 개의 정수 시퀀스를 찾아 해당 목록의 위치를 ​​확인하십시오. 0에서 70-1 사이의 숫자입니다. 받아 적어.

The 4s : 첫 4 개 전에 몇 개나 3 개가 있습니까? 두 번째 전에 몇 명입니까? 세 번째? 넷째? 4 일 이후? 정답은 8을 더한 5 개의 정수입니다. 따라서 "5 개의 정수의 합으로 8을 작성"목록에서 5 개의 정수 시퀀스를 찾아 해당 목록의 위치를 ​​확인하십시오. 0에서 495-1 사이의 숫자입니다. 받아 적어.

그리고 계속해서 ...

에이스 : 첫 에이스 전에 몇 개의 비-에이스 카드가 있습니까? 두 번째 전에 몇 명입니까? 세 번째? 넷째? 4 일 이후? 답은 5 개의 정수로, 분명히 48을 더한 것입니다. 따라서 "48을 5 개의 정수의 합으로 작성"목록에서 5 개의 정수 시퀀스를 찾아 해당 목록의 위치를 ​​기록하십시오. 0에서 270725-1 사이의 숫자입니다. 받아 적어.

이제 13 개의 정수를 기록했습니다. (앞서 설명한 것처럼) 에서 52 사이의 단일 숫자로 인코딩하십시오 $0$ . 이 숫자를 이진수로 쓰십시오. 166 비트 미만이 소요됩니다.$\frac{52!}{(4!)^{13}}$

정보 이론적 한계에 도달하기 때문에 가능한 최상의 압축입니다.

압축 해제는 간단합니다. 큰 숫자에서 13 개의 정수 시퀀스로 이동 한 다음이를 사용하여 이미 설명한대로 카드 시퀀스를 빌드하십시오.

각 카드를 3 ​​비트 또는 4 비트로 개별적으로 인코딩하는 대신 전체 데크의 상태를 166 비트로 인코딩하는 것이 좋습니다. 마틴 Kochanski 같이 설명 미만의 존재 전체 갑판의 상태 비트 (166)에 저장 될 수 있다는 것을 의미하므로 슈트 무시 카드의 배열이 가능.$2^{166}$

이 압축 및 압축 풀기를 어떻게 효율적으로 알고리즘 적으로 수행합니까? 사전 식 순서와 이진 검색을 사용하는 것이 좋습니다. 이렇게하면 큰 조회 테이블이나 기타 비현실적인 가정없이 공간과 시간 모두에서 효율적으로 압축 및 압축 해제를 수행 할 수 있습니다.

세부 사항 : 압축되지 않은 데크 표시에 사전 식 순서를 사용하여 데크를 주문하십시오. 즉, 데크는 압축되지 않은 형식으로 22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA와 같은 문자열로 표시됩니다. 사전 순서에 따라 주문할 수 있습니다. 이제 데크 가 주어지고 그 앞에 오는 데크 수를 사전 식 순서로 계산 하는 절차가 있다고 가정하십시오 . 그런 다음이 절차를 사용하여 데크를 압축 할 수 있습니다. 데크 D가 주어진 경우 압축은 덱의 수를 세고 그 수를 출력하여 166- 비트 수입니다. 이 숫자는 데크의 압축 표현입니다.$D$$D$

압축을 풀려면 이진 검색을 사용하십시오. 숫자 주어지면 모든 데크의 사전 순서에서 n 번째 데크 를 찾고 싶습니다 . 당신은 이진 검색의 라인을 따라 절차를 사용하여이 작업을 수행 할 수 있습니다 갑판의 선택 D 0 , 전에 데크의 수를 계산 D 0 , 및 해당 비교 N . D 0 조정 여부를 알려줍니다$n$$n$$D_0$$D_0$$n$$D_0$일찍 또는 나중에 올 것이다. 반복적으로 기호를 올바르게 얻으려고 제안하십시오 .22223333444455556666777788889999TTTTJJJJQQQQKKKKAAAA와 같은 문자열을 복구하려면 먼저 문자열의 첫 번째 기호로 사용할 항목을 찾기 위해 검색하십시오 (12 가지 가능성 모두를 시도하거나 12 가지 가능성에 대한 이진 검색 사용) )를 찾은 다음 첫 번째 기호에 대한 올바른 값을 찾으면 두 번째 기호 등을 찾기 위해 검색하십시오.

남아있는 것은 이전에 사 전적으로 오는 데크 수를 계산하는 효율적인 절차를 마련하는 것 입니다. 이것은 간단하지만 지루한 조합 운동처럼 보입니다. 특히 다음과 같은 문제에 대한 서브 루틴을 빌드하는 것이 좋습니다. 접두사 (예 : 222234)가 있으면 해당 접두사로 시작하는 데크 수를 세십시오. 이 문제에 대한 답은 이항 계수와 계승에서 매우 쉬운 운동처럼 보입니다. 그런 다음이 서브 루틴을 약간 호출하여 D 앞에 오는 데크 수를 계산할 수 있습니다.$D$$D$

슈트를 무시 하는 카드의 가능한 배열의 수 는 로그 밑이 2 인 165.976 또는 카드 당 3.1919 비트로, 지정한 한도보다 낫습니다.

$$\frac{52!}{(4!)^{13}}\text,$$

마지막으로 카드를 항상 비트로 인코딩 할 수 있고 대부분의 경우 마지막 몇 카드도 가능 하기 때문에 고정 된 "카드 당 비트"인코딩은 의미가 없습니다 . 즉, 팩의 "꼬리"를 향한 방법으로 각 카드에 필요한 비트 수가 생각보다 훨씬 적습니다.$0$

지금까지 데이터를 압축하는 가장 좋은 방법은 카드 데이터로 압축하려는 다른 데이터의 59 비트 (실제로 59.6 비트)를 찾아 해당 59 비트를 13 자리 숫자 모듈로 24 (= ), 사이 각 카드 (한 자리 선택한다면에 정장 지정 4 ! 에이스로 정장을 할당하는 방법을, 다른 하나는, 등)에 왕에 대해 동일한 작업을 수행합니다. 그런 다음 52 개의 완전히 다른 카드 팩이 있습니다. 52 ! 가능성은 실제로 매우 쉽게 225.58 비트로 인코딩 될 수 있습니다.$4!$$4!$$52!$

그러나 여분의 비트를 인코딩 할 기회를 얻지 않고 그것을 수행하는 것도 어느 ​​정도 가능하며 다른 모든 사람들이 확신하기 때문에 그것에 대해 생각할 것입니다. 정말 흥미로운 문제에 감사드립니다!

이것은 오랫동안 해결 된 문제입니다.

당신이 52 장의 카드를 처리 할 때, 당신이 취급하는 모든 카드는 알려진 확률로 최대 13 개의 등급 중 하나를가집니다. 처리 할 때마다 확률이 바뀝니다. 그것은 허프만 코딩의 개선 인 적응 적 산술 코딩 (adaptive arithmetic coding)이라 불리는 고대 기술을 사용하여 최적으로 처리된다. 일반적으로 알려진 변경되지 않은 확률에 사용되지만 확률을 변경하는 데에도 사용할 수 있습니다. 산술 코딩에 대한 Wikipedia 기사를 읽으십시오.

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

DW와 Martin Kochanski는 이미 [ 0 , 52] 범위의 거래와 정수 사이의 궤적을 구성하는 알고리즘을 설명했습니다 .그러나 그들 중 어느 것도 문제를 가장 단순한 형태로 줄인 것 같지 않습니다. (주 1)$[0, {52!\over(4!)^{13}})$

우리가 정렬 된 목록의 설명 (부분) 갑판 있다고 가정 , 내가 유형의 카드의 수 난을 . OP에서 초기 데크는 13 개의 요소 목록으로 설명되며 각 요소는 값이 4입니다. 이러한 데크의 개별 셔플 수는 다음과 같습니다.$a$$a_i$$i$

$$c(a) = {(\sum a_i)! \over \prod a_i!}$$

이것은 이항 계수의 간단한 일반화이며 실제로 Martin Kochanski가 제안한 것처럼 한 번에 한 가지 유형의 객체를 정렬하여 증명할 수 있습니다. (아래 참고 2 참조)

이제 이러한 (부분) 덱의 경우 i > 0 인 를 사용하여 한 번에 하나의 카드 셔플을 선택할 수 있습니다 . i 로 시작하는 고유 셔플 수 는$i$$a_i>0$$i$

$$\begin{cases}0 & \text{if } a_i = 0 \\ c(\langle a_1,...,a_{i-1},a_i-1,a_{i+1},...,a_n \rangle) & \text{if } a_i > 0. \end{cases}$$

위의 공식으로, 우리는

$$c(\langle a_1,...,a_{i-1},a_i-1,a_{i+1},...,a_n \rangle) = {a_ic(a)\over\sum a_i}$$

그런 다음 접두사보다 보다 작은 접두사에 해당하는 접두사의 수 는$i$

$${c(a)\sum\limits_{j=1}^i a_j}\over\sum\limits_{j=1}^n a_j$$

알고리즘을 설명하기 위해 이것을 파이썬으로 작성했습니다. 파이썬은 의사 코드만큼이나 합리적입니다. 대부분의 산술에는 확장 된 정밀도가 포함됩니다. 값 (셔플 서수를 나타냄)와 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 초도 채 걸리지 않았습니다. ( ideon 에 대한 온라인 테스트에서 7 개의 라인을 볼 수 있습니다 .) 낮은 수준의 언어로 다시 작성하고 나누기 (가능한 경우)를 최적화하면 해당 시간을 관리하기 쉬운 것으로 줄일 수 있습니다.

인코딩 된 값은 단순히 정수이므로 166 비트로 출력 될 수 있습니다. 인코딩이 끝나는 위치를 알 수있는 방법이 없으므로 실제로는 166 비트 인코딩이므로 선행 0을 삭제하는 데 아무런 가치가 없습니다.

그러나 실제 응용 프로그램에서는 셔플을 인코딩 할 필요가 없습니다. 랜덤 셔플은 랜덤 166- 비트 수를 생성하고 디코딩함으로써 생성 될 수있다. 그리고 166 비트가 모두 무작위 일 필요는 없습니다. 예를 들어 32 비트 임의의 정수로 시작한 다음 32 비트 숫자로 시드 된 표준 RNG를 사용하여 166 비트를 채울 수 있습니다. 따라서 목표가 단순히 많은 수의 임의 셔플을 재현 가능하게 저장할 수 있다면 거래 별 저장 요구 사항을 임의로 줄일 수 있습니다.

당신은 많은 수의 인코딩하려면 약 절약, (다른 방식으로 생성 된) 실제 거래를하지만, 당신은 델타 인코딩 숫자의 정렬 된 목록 수있는 거래의 순서에 대해 걱정하지 않는다 로그 2 개 N 각 비트를 번호. 정렬 된 시퀀스는 정렬되지 않은 시퀀스보다 엔트로피가 적기 때문에 절약 효과가 있습니다. 시퀀스에서 단일 값의 엔트로피를 줄이지 않습니다.$N$$\log_2 N$

정렬 된 k 비트 숫자 목록을 인코딩해야한다고 가정하면 다음과 같이 진행할 수 있습니다.$N$ $k$

1. 를 log 2 N에 가까운 정수로 선택하십시오 (바닥이나 천장이 작동합니다. 보통 천장으로갑니다).$p$$\log_2 N$

2. 우리는 암시 적으로 숫자의 범위를 분할 이진 접두어로 간격. 각각의 k- 비트 수는 p- 비트 접두사와 k - p- 비트 접미사 로 나뉩니다 . 접미사 만 (순서대로) 작성합니다. 이를 위해서는 N * ( k - p ) 비트가 필요합니다.$2^p$$k$$p$$k-p$$N*(k-p)$

3. 또한, 우리는 비트 시퀀스를 생성합니다 : 접두사 (접두사 0 제외 ) 각각에 대해 접두사 (있는 경우) 뒤에 1이 오는 각 숫자에 대해 0 을 씁니다 . 이 시퀀스는 분명히 2 p + N 비트 : 2 p 1 s 및 N 0 s를 갖습니다 .$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 ) 평균 들면 의 K - P + 2 값당 비트.$N*(k-p) + N + 2^p$$N*(k-p) + N + N$$N*(k-p+2)$$k-p+2$

노트

1. 은92024242230271040357108320801872044844750000000000이고로그252입니다$52!\over(4!)^{13}$$92024242230271040357108320801872044844750000000000$ 은 약165.9765입니다. 본문에서 나는 때때로 2 진 대수가 실제로166 인것처럼 가장합니다. 범위 내에서 임의의 서수를 생성하는 경우, 생성 된 난수를 거의 거부하지 않는 거부 알고리즘을 사용할 수 있습니다.$\log_2 {52!\over(4!)^{13}}$$165.9765$$166$
2. 편의를 위해 물품 위한 N Σ는 난 = 케이 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}!}}$

$$\prod\limits_{i=1}^n S_i! \over \prod\limits_{i=1}^n a_i! S_{i+1}!$$

위의 공식으로 단순화됩니다.

이 문제에 대한 대체 솔루션으로, 내 알고리즘은 남아있는 채워지지 않은 순위 수에 따라 데크의 카드 그룹에 대해 카드 당 복합 소수 (비정 수) 비트를 사용합니다. 다소 우아한 알고리즘입니다. 인코딩 알고리즘을 손으로 확인했는데 좋아 보인다. 인코더가 올바른 비트 스트링 (간단 성을 위해 바이트 형식)으로 보이는 것을 출력하고 있습니다.

$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$

그래서보고 , 우리는 단순히 우리의 마스터 "에서 그 계급의 서수 위치를 찾아 23456789 T J Q K "정렬 된 계급의 목록을. 예를 들어, 첫 번째 실제 카드 순위 5 는 순위 조회 문자열에서 조회 위치가 4 입니다. 우리는이 7 순위 위치 를 0으로 시작 하는 기본 13 숫자 로 취급합니다 (따라서 이전에 얻은 위치 4는 실제로 3이됩니다). (확인 목적으로) 기본 10으로 다시 변환 하면 15 , 565 , 975가 됩니다. 에서 $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$에스. 데크가 쌍 (예 : 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$

$~~~~~~~~~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 개 4 개가 모두있는 경우 더 나은 경우이며 해당 데크를 인코딩하는 데 161 비트 만 있으면됩니다. 패킹이 실제로 그것의 서수 위치의 직선 이진 인코딩의 엔트로피.

이제 비트 요구 사항을 계산하기 위해 코드를 구현했으며 3 백만 데크 테스트 파일의 경우 데크 당 약 175 비트, 155의 낮은 값과 183의 높은 값을 보여줍니다. 그래서 내 알고리즘은 데크 당 9 개의 추가 비트와 서수 위치 방법의 직선 이진 인코딩을 사용하는 것으로 보입니다. 5.5 %의 추가 스토리지 공간 만 있으면 나쁘지 않습니다. 176 비트는 정확히 22 바이트이므로 데크 당 52 바이트보다 훨씬 낫습니다. 최상의 경우 데크 (3 백만 개의 데크 테스트 파일에 표시되지 않음)를 136 비트로 압축하고 최악의 경우 데크 (테스트 파일에 8206 번 표시됨)는 183 비트입니다. 분석에 따르면 최악의 경우는 카드 40에 가까워 질 때까지 첫 번째 쿼드를 얻지 못하는 경우입니다. 그런 다음 인코딩 모드가 빠르게 떨어지기를 원할 때 블록에 (7 카드만큼 큰) 채우기 블록이 "고정"됩니다 더 높은 비트 인코딩 모드. 잘 섞인 데크를 사용하여 카드 40까지 쿼드를 얻는 것은 매우 드물다고 생각할 수도 있지만, 내 프로그램은 3 백만 데크의 테스트 파일에서 321 번 발생하여 9346 데크마다 약 1 번 발생한다고 알려줍니다. 내가 예상했던 것보다 더 자주입니다. 이 경우를 확인하고 더 적은 비트로 처리 할 수는 있지만 평균 비트에 충분히 영향을 미치지 않는 경우는 거의 없습니다.

여기 또 다른 흥미로운 것이 있습니다. 원시 데크 데이터에서 데크를 정렬하면 상당한 횟수의 반복되는 접두사 길이는 길이가 약 6 (예 : 222244)입니다. 그러나 압축 된 데이터의 경우 길이는 약 16으로 증가합니다. 즉, 압축 된 데이터를 정렬하면 디코더에 16 비트 접두사를 표시 한 다음 데크의 나머지를 출력하여 상당한 비용을 절감 할 수 있습니다. 동일한 접두사를 가진 (반복 접두사 빼기) 다음 접두사로 이동하여 반복하십시오. 이 방법으로 데크 당 10 비트 만 절약한다고 가정하면 데크 당 166 비트를 이길 수 있습니다. 다른 사람들이 열거 한 열거 기술을 사용하면 접두사가 내 알고리즘만큼 길어질 지 확실하지 않습니다. 또한 내 알고리즘을 사용하여 포장 및 포장 풀기 속도가 놀랍도록 좋습니다.

알고리즘의 출력 비트 열을 정렬하는 두 번째 압축 수준과 관련하여 "차이"인코딩을 사용합니다. 매우 간단한 방법은 출력 데이터에 최소 두 번 표시되는 61,278 개의 고유 한 16 비트 접두사를 인코딩하는 것입니다. 두 번째 레벨 압축 풀기 프로그램에 프리픽스 (예 : 0000111100001111)를 인코딩하고 동일한 프리픽스가있는 팩킹 된 데크는 포장 된 데크의 접두사가 아닌 부분을 나타냅니다. 프리픽스가 동일한 팩킹 된 데크의 평균 수는 각 프리픽스에 대해 약 49 개이며 고유 한 것을 포함하지 않습니다 (1 개의 데크에만 해당 프리픽스가 있음). 이 간단한 전략을 사용하여 데크 당 약 15 비트를 절약 할 수 있습니다 (공통 접두사를 한 번 저장).

첫 번째 인코더의 정렬 된 비트 문자열 출력의 차이 (접두사) 인코딩을 사용하여 두 번째 압축 수준을 얻은 후 데크 당 약 160 비트를 얻습니다. 길이 18 접두사를 사용하고 그대로 저장합니다. 가능한 18 비트 접두사 중 거의 모든 것이 (262144 중에서 245013 = 93.5 %) 나타나기 때문에 접두사를 인코딩하는 것이 훨씬 좋습니다. 아마도 2 비트를 사용하여 어떤 유형의 데이터를 인코딩 할 수 있습니다. 00 = 일반 길이 18 접두사 저장, 01 = "1 업 접두사"(1이 추가 된 것을 제외하고 이전 접두사와 동일), 11 = 첫 번째 레벨 패킹에서 평균 인코딩 (평균 약 175 비트). 10 = 비트를 절약 할 다른 인코딩을 생각할 때 미래 확장.

다른 사람이 아직 갑판 당 160 비트를 이겼습니까? 나는 위에서 언급 한 2 비트 디스크립터를 실험하고 사용하여 조금 더 나아질 수 있다고 생각한다. 아마도 158ish에 바닥이 될 것입니다. 내 목표는 카드 당 3 비트 이하이기 때문에 156 비트 (또는 더 나은)로 만드는 것입니다. 매우 인상적. 첫 번째 레벨 인코딩을 변경하면 최상의 2 레벨 인코딩이며 다시 시도해야 할 조합이 많기 때문에 그 수준으로 낮추기 위해 많은 실험을했습니다. 내가 변경 한 일부 변경 내용은 다른 유사한 임의 데이터에 유용 할 수 있지만 일부는이 데이터 세트에 편향 될 수 있습니다. 확실하지는 않지만 충동이 생기면 비슷한 결과를 얻을 때 어떤 일이 일어나는지 확인하기 위해 3 백만 데크 데이터 세트를 시도 할 수 있습니다.

$10^{50}$

누구든지 평균적으로 각 데크의 스토리지 비트를 줄 이도록 인코딩 해야하는 다른 경우와 같이 알고리즘을 개선하는 방법에 대한 아이디어가 있습니까? 누군가?

2 더 많은 것들 : 1) 나는 더 많은 사람들이 공간에서 최적은 아니지만 여전히 구현하기에 적당하고 상당히 쉬운 내 솔루션을 공표하지 않았다는 것에 다소 실망했다. 2) 3 백만 개의 데크 데이터 파일을 분석 한 결과 1444 위와 같이 1 순위가 채워지는 가장 자주 발생하는 카드는 26 번 카드라는 것을 알았습니다.이 시간은 약 6.711 % (300 만 데크 중 201322) ). 나는이 정보를 사용하여 12 개의 심볼 인코딩 모드에서 시작하는 등 더 압축하기를 바랐습니다. 왜냐하면 평균 데크까지 모든 순위를 볼 수는 없기 때문에이 방법은 오버 헤드가 절약을 초과하여 압축하지 못했습니다. 실제로 비트를 저장할 수있는 알고리즘에 대한 조정을 찾고 있습니다.

내 알고리즘을 사용하여 데크 당 몇 비트를 절약하기 위해 다음에 시도해야 할 아이디어가 있습니까? 디코더가 어떤 패턴을 기대해야하는지에 대한 과도한 오버 헤드 후에도 데크 당 비트를 줄일 수 있도록 자주 발생하는 패턴을 찾고 있습니다. 나는 보이지 않는 나머지 카드의 예상 확률을 가진 무언가를 생각하고 남아있는 모든 단일 카드를 단일 버킷으로 묶습니다. 이렇게하면 낮은 인코딩 모드로 더 빨리 떨어질 수 있으며 비트를 절약 할 수는 있지만 의심합니다.

또한 참고로, 1 천만 개의 임의 셔플을 생성하여 데이터베이스에 저장하여 쉽게 분석 할 수있었습니다. 그중 488 개만 쿼드 (예 : 5555)로 끝납니다. 내 알고리즘을 사용하여 그것들을 포장하면 평균 165.71712 비트가 157 비트의 낮은 비트와 173 비트의 높은 비트를 얻습니다. 다른 인코딩 방법을 사용하면 166 비트 바로 아래에 있습니다. 나는이 사건이 얼마나 드문 지에 대해 다소 놀랐습니다 (평균 20,492 건의 셔플 중 약 1 건).