Conference rusure::math

You could do it like this:

    (1,1)     -> -300
    (1,2)     -> -299
    (1,3)     -> -298
    ...
    (1,400)   ->  ...
    (2,1)     ->  ...
    ...
    (2,400)   ->  ...
    (3,1)     ->  ...
    ...
    (200,399) ->  299
    (200,400) ->  300

This takes the 200*400 possible combinations of numbers and maps them
to the 601 possible values that you can store.

That is, if the two numbers you want to store are x and y, and are in
the ranges 1..200 and 1..400, you can compute the value to store as:

	z = (x-1) * 400 + (y-1) - 300.

And you can get the x and y values back again:

	x = 1 + ((z + 300) div 400)	(divide, and truncate to an integer)
	y = 1 + ((z + 300) mod 400)	(p mod q = p - q*(p div q))

     If you have 200 "first" numbers and 400 "second" numbers
     then you have 200 * 400 = 80,000 possible pairs of numbers.
     In order to extract the original two numbers from the
     "packed" value, you must have at least 80,000 different
     packed values.  They won't fit into the range -300 to
     +300, unless you use fractions.
     
     Dan

    So, are you saying that there is no way?
    
    If I figure out a way, I'll post it.  Unless someone beats me to
    it!
    
    Thanks for trying, but don't give up now.
    
    Gerry
    

    Re .5:
    
    It is _impossible_ to pack an integer from 1 to 200 and an integer from
    1 to 400 into an integer from -300 to 300 -- at least if you expect to
    get them both out later.
    
    If you are not working with integers or there are other characteristics
    of the numbers, then tell us what they are.
    
    
    				-- edp 

>    It is _impossible_ to pack an integer from 1 to 200 and an integer from
>    1 to 400 into an integer from -300 to 300 -- at least if you expect to
>    get them both out later.

Maybe I'm missing the point here, but how about
	1..200		-300..-101
	{1..100		-99..0}
	{101-400	1..300}
with -100 left over?

    It is _impossible_ to pack an integer from 1 to 200 *AND* an integer
    from 1 to 400 into an integer from -300 to 300.

    Lynn showed how to pack an integer from 1..200 *OR* an integer from
    1..400 into an integer from -300..300.

    value = Pack (flag, number) is defined as:
	if flag
	then if (number < 1) or (number > 200)
    	     then raise error
	     else return number - 301
	else if (number < 1) or (number > 400)
    	     then raise error
	     else return number - 100

    (flag,number) = Unpack (value) is defined as:
	if (value < -300) or (value = -100) or (value > 300)
        then raise error
        else if value < -100
             then return (true,  value + 301)
             else return (false, value + 100)

    It sure does seem inpossible to me also.  I guess it's the word
    _impossible_ that I hate.
    
    Thanks to all.
    
    Gerry
    

>    I have a range of numbers from say -300 to +300 this gives me
>    about 600 numbers to play with.  What I want to do is pack two
>    different numbers into this range and then extract them later.
>    
>    I want to combine a number from the 1 to 200 range and a number
>    from the 1 to 400 range into this one number from range -300 to
>    +300.  I thought I read about this somewhere but I could be just
>    insane.  I thought it was a complex formula.

As previous replies have pointed out, there is no pair of functions that can
make a one-to-one correspondence between the ordered pairs you start
with and the number range you want to end up with.  The cardinalities
of the sets are different.

If, however, you know something about the statistics of the process
that generates the ordered pairs (for example, some pairs occur
much more frequently than others), then you may be able to use some
technique like Huffman encoding to pack sets of these ordered pairs into
smaller blocks of encoded data, but the encoded block will require decoding
from the beginning in order to recover the data.

    Can you tell me more about the Huffman encoding.  Maybe I can
    use it.
    
    Thanks
    
    Gerry
    

>    Can you tell me more about the Huffman encoding.  Maybe I can
>    use it.

Ref:	'Algorithms' by Robert Sedgewick, Aug 1984 reprint,
	ch. 22, p. 286-293

Huffman encoding assigns a separable codeword to each input symbol.
The length of each codeword is shorter for the more commonly occurring
input symbols and longer for the less frequently occurring input symbols.

The encoded data is more compact than the original data because the total
length of the encoded text is

Sum_of( number_of_occurrences_of_input_symbol[ i ] *
        length_of_codeword_for_input_symbol[ i ] ) over all i input symbols
   						   in the plaintext

and the encoding arranges for the most frequently occurring input symbols
to have the shortest encodings.

To use Huffman encoding effectively, you need some prior knowledge about
the relative frequency of occurrence of your various input symbols, or
you must dynamically evaluate the frequency of occurrence and use different
coding trees for different data sets.

From the description of your problem, I can see at least two ways that
you might use Huffman encoding.

Way 1:
If each of the two coordinates you are trying to pack separately show
tendencies for certain values to occur more frequently, then you can
use separate coding trees for each coordinate and store the encodings
in two blocks.

Way 2:
If certain combinations of the coordinates occur more frequently than
most other combinations, then use a coding tree for the combined
coordinates.