User:Earlster/Sandbox

Proxmap Sorting, or Proxmap, is a sorting and searching algorithm that works by partitioning an array of data items, or keys, into a number of buckets. The name is short for computing a "proximity map," which indicates for each key K, the beginning of a subarray in the array A where K will reside in the final sorted order. Keys are dropped into each bucket using insertion sort. If keys are "well distributed" amongst the buckets, sorting occurs in $$O(n)$$ time, much faster than comparison-based sorting, which can do no better than $$O(nlogn)$$. The computational complexity estimates involve the number of buckets and the key used. During generation a proxmap is created, which is used to find keys in an average of $$O(1.5)$$ time. It is a form of bucket and radix sort. The algorithm also scales up well with large data.

History

 * Invented late 1980's by Thomas A. Standish, Prof. Emeritus, Bren School of ICS

Basic Strategy
In general: Given an array A with n keys:
 * map a key to a subarray of the destination array A2, by applying a "mapkey" function to each array item
 * determine how many keys will map to the same subarray or "bucket," using an array of "hit counts," H
 * determine where each subarray will begin in the destination array so that each bucket is exactly the right size to hold all the keys that will map to it, an array of "proxmaps," P
 * for each key, compute the bucket it will map to, an array of "locations," L
 * for each key, look up it's location, place it into that cell of A2, if it keys with a key already in that position, insertion sort the key while maintaining the order of keys. Moving keys > this key to the right by one will free up a space for this key. Since the subarray is big enough to hold all the keys mapped to it, such movement will never cause the keys to overflow into the following subarray.

Simplied version: Given an array A with n keys
 * 1) Initialize: Create and initialize 4 arrays all of n size, hitCount, proxMap, location, and A2.
 * 2) Partition: Using a carefully chosen mapKey function, divide the A2 into subarrays or "buckets" using the keys in A
 * 3) Disperse: Read over A, dropping each key into its bucket in A2, insertion sorting as needed.
 * 4) Collect: Visit the buckets in order and put all the elements back into the original array, or delete A and use A2.

Note: "keys" may also contain other data, for instance an array of Student objects that contain the key plus a student ID and name. This makes proxmap suitable for organizing groups of objects, not just keys themselves.

Example
Consider a full array: A[0 to n-1] with n keys. Let i be an index of A. Sort A's keys into array A2 of equal size.

The MapKey(key) function will be defined as mapKey(key) = floor(K).

Pseudocode
Here A is the array to be sorted and the mapKey functions basically determines the number of buckets to use. For example, floor(K) will simply assign as many buckets as there are integers from the data in A. Dividing the key by a constant like 10, or floor(K/10) reduces the number of buckets; different functions can be used to translate the range of elements in A to buckets, such as converting the letters A–Z to 0–25 or returning the first character (0–255) for sorting strings. Buckets get sorted as the data comes in, not all at the end like bucket sorting typically does.

Proxmap Searching
Typically, proxmap sorting is used along with proxmap searching, which uses the proxMap array generated by the proxmap sort to find keys in the sorted array, or A2 in constant time.

Basic Strategy

 * Build the proxMap structure, keeping MapKey function, P and A2
 * To search for a key, go to P[MapKey(k)], the start of the subarray that contains the key, if it is in the data set
 * Sequential search the subarray; if key found, return it (and associated information), if found a value > key, key is not in the data set
 * Computing P[MapKey(k)] takes $$O(1)$$. If a mapkey that gives a good distribution of keys was used, each subarray is bounded above by a constant c, so at most c comparisons are needed to find the key or know it is not present; therefore proxmap search is $$O(1)$$, once proxmap has been built. If the worst mapkey was used, all keys are in the same subarray, so proxmap search, in this worst case, will require $$O(n)$$ comparisons, once proxmap has been built.

Pseudocode
function mapKey(key) return floor(key)

proxMap ← previously generated proxmap array of size n  A2 ← previously sorted array of size n function proxmap-search(key) for i = proxMap[mapKey(key)] to (length(array)-1    if (sortedArray[i].key == key)       return sortedArray[i]

Performance
Computing H, P, and L all take $$O(n)$$ time. Each is computed with one pass through an array, with constant time spent at each array location.
 * Worst case: MapKey places all items into 1 subarray so there's standard insertion sort, and time of $$O(n^2)$$.
 * Best case: MapKey delivers the same small number of items to each part of the array in an order where the best case of insertion sort occurs. Each insertion sort is $$O(c)$$, c the size of the parts; there are p parts thus p * c = n, so insertion sorts take O(n); thus, building the proxMap is $$O(n)$$.
 * Average case: Say size of each subarray is at most c, a constant; insertion sort is then O(c^2) at worst – a constant! (actually much better, since c items are not sorted until the last item is placed in the bucket). Total time is the number of buckets, (n/c), times $$O(c^2)$$ = roughly n/c * c^2= n * c, so time is $$O(n)$$.

Having a good MapKey function is imperative for avoiding the worst case. We must know something about the distribution of the data to come up with a good key.

Optimizations
Many optimizations including these use the same array to store the sorted data, as well as reusing the hitCount, proxMap, and location arrays used to sort the data.
 * 1) Save time: save MapKey(i) values so they don't have have to be recomputed (notice they're recomputed in the code above)
 * 2) Save space: if clever, A can be reused

Comparison with other sorting algorithms
Since proxmap sort is not a comparison sort, the Ω(n log n) lower bound is inapplicable. Generally, it works relatively fast when compared to other sorting algorithms as its not comparison-based and it uses arrays instead of dynamically allocated objects and pointers to follow, like binary search tree nodes. The function is nearly constant access time which makes it very appealing for large databases. Despite the O(n) build time, it makes up for it with its $$O(1.5)$$ average access time. If the data doesn't need to be updated often, the access time may make this function more favorable than other non-comparison sorting based sorts.

Generic bucket sort related to Proxmap
Like proxmap, bucket sort generally operates on a list of n numeric inputs between zero and some maximum key or value M and divides the value range into n buckets each of size M/n. If each bucket is sorted using insertion sort, proxmap and bucket sort can be shown to run in predicted linear time. However, the performance of this sort degrades with clustering (or too few buckets with too many keys); if many values occur close together, they will all fall into a single bucket and be performance severely diminished. This holds a similar story with Proxmap, if the buckets are too large or too small then the performance of the function will degrade severely.