Penguencoding 4.5 Mystery Cache

The cache is not at the posted coordinates. Solve the puzzle below to find the final location.

Penguin Professor Patricia rested after her first encoding, using Huffman's algorithm, happy with its elegance and compression, but disappointed that no one seemed to care. If 8 bits are needed for each ASCII character, then N00 00.000 W000 00.000 requires 22 bytes, whereas her compression resulted in 11 bytes for the encoding, a 50% reduction! But she thought she could do better for her next encoding, so researched some more. Finding inspiration in some videos, she went to a new algorithm that converts symbols into fractions of bits, called arithmetic encoding.

In this encoding, she explained (to again no one listening, since Peter and Paul, now awake, had brought out reams of paper trying to make sense of her last encoding), we again need the percentage chance of each symbol. She used the same example.

 
Now however, this algorithm executes the following steps:

1. Sort the symbols (alphanumeric is fine)
2. Assign a range greater-than-or-equal-to zero or the previous end-range (see below) up to but not including the amount of the symbol probability (i.e. 0.00 <= range < 0.30 if probability is 30%).
3. Repeat, stacking for each symbol range, such that the total range is 0.00 ≤ range < 1.00
4. Now, for encoding do the following loop for each symbol to be encoded, starting with the range in question as 0.00 ≤ range < 1.00
   1. Take the symbol's range and multiply it by the current active range size
   2. Add the symbol range low and range high to the current active range low
   3. That becomes the new active range
5. The final result should be a narrow range. Any value within that range can be the final fractional representation.

For this example, the range creation steps would be:

    step 0 (sort)
        _     30%
        A     15%
        B     5%
        C     5%
        D     20%
        E     25%

    step 1 (create ranges)
        _     0.00≤range(_)<0.30
        A     0.30≤range(A)<0.45
        B     0.45≤range(B)<0.50
        C     0.50≤range(C)<0.55
        D     0.55≤range(D)<0.75
        E     0.75≤range(E)<1.00

Now, if the message is ACE BAD DAD, the range creation steps would be:

    step 0, encode A, 0.00≤range<1.00: apply 0.30≤range(A)<0.45
    step 1, encode C, 0.30≤range<0.45: apply 0.50≤range(C)<0.55
        range low  = 0.30+0.15*0.50 = 0.375
        range high = 0.30+0.15*0.55 = 0.3825
    step 2, encode E, 0.375≤range<0.3825: apply 0.75≤range(E)<1.00
        range low  = 0.375+0.0075*0.75 = 0.380625
        range high = 0.375+0.0075*1.00 = 0.3825
    step 3, encode _, 0.380625≤range<0.3825: apply 0.00≤range(_)<0.30
        range low  = 0.380625+0.001875*0.00 = 0.380625
        range high = 0.380625+0.001875*0.30 = 0.3811875
    step 4, encode B, 0.380625≤range<0.3811875: apply 0.45≤range(B)<0.50
        range low  = 0.380625+0.0005625*0.45 = 0.380878125
        range high = 0.380625+0.0005625*0.50 = 0.38090625
    etc.

Assuming the final range is 0.38088904140≤range<0.38088904291, we can choose any value that encodes the smallest, say 0.380889042 which encodes into hexadecimal as 0.6181F1BB (16).

Looking at the statistical likelihood of the characters as given in Patricia's previous encoding, she realized she could simplify even more. "What was I thinking?" thought Patricia, referring to her first attempt. "Still so wasteful! This is a geocaching puzzle so of course the answer doesn't require so much data!" So she analyzed the probably of the coordinates *within two miles* of the posted coordinates and came up with a different probability for each of the 22 character locations. They can be summarized, hopefully clearly, in this table:

You can validate your puzzle solution with certitude.

 
Congratulations to Team Ottlet for FTF and the FTS!