It's always been pretty mind-blowing to me that you can store over 225 bits of information just in an ordering of one deck of cards. A standard way to store data in this way is a factoradic encoding like Lehmer coding:<p><a href="https://en.wikipedia.org/wiki/Lehmer_code" rel="nofollow">https://en.wikipedia.org/wiki/Lehmer_code</a><p>The python library 'permutation' has some functionality around this that's fun to play with:<p><a href="https://permutation.readthedocs.io/en/stable/#permutation.Permutation.lehmer" rel="nofollow">https://permutation.readthedocs.io/en/stable/#permutation.Pe...</a><p>I found new joy in shuffling a deck of cards, after learning that every (proper) shuffle that every human's ever done has returned a unique deck that nobody's ever held before.<p>edit: I just remembered a guy who made a javascript demo that encodes small strings into a card deck order: <a href="https://jerde.net/peter/cards/cards.html" rel="nofollow">https://jerde.net/peter/cards/cards.html</a> (explanation page linked)
This reminds me of Pontifex, the playing card based cipher designed by Bruce Schneier for Neal Stephenson's <i>Cryptonomicon</i>.<p><a href="https://www.schneier.com/academic/solitaire/" rel="nofollow">https://www.schneier.com/academic/solitaire/</a>
I don't understand the claim that this is more efficient, it's trivial to find a method that's information-theoretically optimal: choose an arbitrary order for the cards, and encode log(52!)/log(2) bits as the lexicographic order of the permutation, doing a binary search each time.<p>Shouldn't be too hard to do even with pen and paper since the 2-adic eval of 52! is large.
This reminded me of the De Bruijn Sequence card trick.<p><a href="https://sites.math.washington.edu/~billey/classes/562.winter.2018/problem.sets/debruijn.trick.pdf" rel="nofollow">https://sites.math.washington.edu/~billey/classes/562.winter...</a>
This reminded me of T-Codes, a form of variable-length self-synchronising codes for communicating based on letter and word frequency.<p><a href="https://web.archive.org/web/20180329104930/http://tcode.auckland.ac.nz/~mark/T-codes:%20Intro.html" rel="nofollow">https://web.archive.org/web/20180329104930/http://tcode.auck...</a>
This is cool (especially the encryption), but certain sequences of bits can’t be encoded. If you have n items left in the sequence then you cannot encode a run of n zeros. So it’s not a general encoding scheme.
First thing that came to mind: <a href="https://www.imdb.com/title/tt0060581" rel="nofollow">https://www.imdb.com/title/tt0060581</a><p>Of course that information would be redundant.
see also <a href="https://www.cabinetmagazine.org/issues/40/sherman.php" rel="nofollow">https://www.cabinetmagazine.org/issues/40/sherman.php</a>