My input string is going to be totally numeric -> the string can contain
only '0' to '9' &
nothing else. My compressed string needs to be alphanumeric. i.e. 'A' to 'Z'
& '0' to '9'.
Can someone point me to some public domain algorithms for this & what extent
of compression
I can hope to achieve.
Just to add, my output limit is fixed & rather small - around 6 or 8 bytes.
So I am looking for
algorithms which will let me use this limit for transmitting much bigger
numbers
than those can be fit into 6 to 8 bytes without compression/encoding.
For eg. with 6 bytes, the biggest number I can transmit is 999999. I am
looking
to use this 6 bytes to transmit as big a number as possible.
Exactly which characters are allowed ? Or rather, how many ?
Then, you can easily calculate how large a number you can send.
Simply take the number of allowed characters to the power of 6 (or 8).
For example, if you can really only sen A to Z and 0 to 9, that's 36
possibilities. With 6 symbols, the largest number you can send is
36^6=2176782336 (somewhat over 9 digits).
If you could also send a-z (lowercase) you have 62 possibilities.
Now you can send 62^6=56800235584, so that's a bit over 10 digits long.
If you want some public domain algo, look into base conversion routines.
Although that's doable in a few lines of code, really, expecially for small
numbers like that. (8 bytes fits into a 64-bit int).
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Input will always be '0' to '9'.
Only 'A' to 'Z' & '0' to '9' in the output.
And a total of 6 to 8 characters in the output.
>
> Then, you can easily calculate how large a number you can send.
> Simply take the number of allowed characters to the power of 6 (or 8).
>
> For example, if you can really only sen A to Z and 0 to 9, that's 36
> possibilities. With 6 symbols, the largest number you can send is
> 36^6=2176782336 (somewhat over 9 digits).
>
> If you could also send a-z (lowercase) you have 62 possibilities.
> Now you can send 62^6=56800235584, so that's a bit over 10 digits long.
>
> If you want some public domain algo, look into base conversion routines.
> Although that's doable in a few lines of code, really, expecially for
> small
> numbers like that. (8 bytes fits into a 64-bit int).
I went in this direction originally - base36 was what I considered.
Even with base36 I can only fit a 10 digit number in 6 bytes.
Hence I was wondering if there is anything better - I can't think
of too many things one can do here better than base36.
There is nothing better than base36 in this case.
>> For example, if you can really only sen A to Z and 0 to 9, that's 36
>> possibilities. With 6 symbols, the largest number you can send is
>> 36^6=2176782336 (somewhat over 9 digits).
(snip)
> I went in this direction originally - base36 was what I considered.
> Even with base36 I can only fit a 10 digit number in 6 bytes.
In this case, it is just recoding of the data. The usual compression
algorithms are statistical, based on the data patterns that occur
more often. If all numbers are equally likely then recoding is your
best option.
In the case of video or audio, most people prefer simple images
and sounds over random bits or white noise.
-- glen