I want to give my users a concise, base-64 alphanumeric code, to represent the choice they make when choosing 1024 candidates in order from a ballot of 1024 candidates. (This is a worst-case ... I can probably live with < 256).
What are my options?
A naive approach tells me that if each of the 1024 element can be represented by a unique ordinal (2 ^ 10), and I need a series of 1024 ordinals, then 10-bits x 1024 positions = 10,240 bits would do the trick. But that's still 1707 radix-64 digits, which is a bit longer than I was hoping for, and it feels like I am wasting bits 9 bits to represent '1' (though I am probably wrong about that).
Classic permutation theory ought to tell me the number of possibilities - nPr (order is significant, no duplicates). But the number is so very big, it bothers my small brain, and overwhelms my dec<->bin calculators. Do I get away with fewer bits if I do it this way? (Why not? Math sucks eh?)
Bonus points for Java code so I can tinker with n and r to find the number of bits required, and the number of radix-64 digits. :-)
PS. This is feasibility-testing for my serious proposal for a voting system which uses paper for an audit trail, and computers for fast counting.