I thank all who responded to my rather unusual idea.   The characters I was
considering compressing was A-Z plus 0-9.   From the responses and thinking
about over the weekend I realized that yes its possible but to make the
results a Image key of 9 to 10 bytes in length but the results would not be
acceptable because key would be a binary value with very few ASCII characters
produced from the result which is not acceptable to a large portion of my
software.   I was researching this possibility as a short term solution so I
didn't have to increase the size of one of my manual master Turboimage keys.
This data set has more than a 100 programs hung on to it so it's quite
expensive to upgrade.   This key is also is other data bases as well so it
easily turns into a major project just for a key that's to small.   I'm
currently researching a cross-referencing technique from a large 17 character
field to a 9(10 actually) character field using Turboimage data set to keep
track of translation.   The 17 character keys are being produced from an
external system which I have no control over so I'm researching all my
options.   Thanks again, you are a great group!


Kimber Renk
HMO Nebraska
Email: [log in to unmask]
Phone: (402)392-4222
------------------( Forwarded letter 1 follows )--------------------
Date:         Mon, 27 Sep 1999 17:44:46 -0400
To: [log in to unmask]
From: Len.Bargent[lbargent]@HDCL.COM
Sender: [log in to unmask]
Reply-To: Len.Bargent[lbargent]@HDCL.COM
Subject: Re: Help with data compression.

Might help if you clarified the range of ASCII data involved.  Is it upper
 case
only?
Are other "special" characters used - like (,),%,$,[,],... etc?

I think it might be feasible with A-Z ONLY.

You need basically a 2:1 "compression". One way or another you need to put
two characters in the space of one.  If you try to use the "left side" of the
 byte
for the first character and the right side for the next, you have only 4 bits
available for each source character.  By my math, 4 bits can only give you 16
combinations.

So, I think representing just 26 capital letters needs 5 bits, although that
allows for 32 combinations, wasting 6 values, per 5 bit segment.  If the
 target is
9 bytes, which is 72 bits, it can be broken down into 14, 5-bit pieces.

But we're short 3 source characters right?  Those 3 need 26 combinations each
totalling 78 values.  If you use the "wasted" 6 values per 5 bit segment and
 there
are 14 of them in the target, I think you have 6*14 values "available" which
allows 84.

In other words, I think it might be possible, but I don't know who would have
coded this.

Also, this method would produce some characters which would NOT be easily
displayable without translation. ( Any bytes with decimal 0 through 31, for
example.)

Len B.




Kimber Renk wrote:

> I have a situation where I need to fit 17 ASCII alphanumeric characters into
 9
> byte field and must still be a ASCII alphanumeric representation.   Does
> anyone know of a good  algorithm to use to solve this problem or a web site
 to
> get me going?
>
> Thanks in advance,
>
> Kimber Renk
> HMO Nebraska
> Email: [log in to unmask]