Proxmap sort

Basic strategy

In general: Given an array A with n keys:

map a key to a subarray of the destination array A2, by applying the map key function to each array item

determine how many keys will map to the same subarray, 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, using an array of "proxmaps," P

for each key, compute the subarray it will map to, using an array of "locations," L

for each key, look up its location, place it into that cell of A2; if it collides with a key already in that position, insertion sort the key into place, moving keys greater than this key to the right by one to make 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 2 arrays of n size: hitCount, proxMap, and 2 arrays of A.length: location, and A2.
2. Partition: Using a carefully chosen mapKey function, divide the A2 into subarrays 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 subarrays in order and put all the elements back into the original array, or simply 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 ProxMapSort 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 map key function is defined as mapKey(key) = floor(K).

Pseudocode

Here A is the array to be sorted and the mapKey functions determines the number of subarrays to use. For example, floor(K) will simply assign as many subarrays as there are integers from the data in A. Dividing the key by a constant reduces the number of subarrays; different functions can be used to translate the range of elements in A to subarrays, such as converting the letters A–Z to 0–25 or returning the first character (0–255) for sorting strings. Subarrays are sorted as the data comes in, not after all data has been placed into the subarray, as is typical in bucket sorting.

Proxmap Searching

ProxmapSearch uses the proxMap array generated by a previously done ProxmapSort to find keys in the sorted array A2 in constant time.

Basic strategy

Sort the keys using ProxmapSort, keeping theMapKey function, and the P and A2 arrays

To search for a key, go to P[MapKey(k)], the start of the subarray that contains the key, if that key is in the data set

Sequentially search the subarray; if the key is found, return it (and associated information); if find a value greater than the key, the key is not in the data set

Computing P[MapKey(k)] takes O ( 1 ) time. If a map key that gives a good distribution of keys was used during the sort, 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 ProxmapSearch is O ( 1 ) . If the worst map key was used, all keys are in the same subarray, so ProxmapSearch, in this worst case, will require O ( n ) comparisons.

Pseudocode

function mapKey(key) return floor(key) proxMap ← previously generated proxmap array of size n A2 ← previously sorted array of size nfunction 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 one subarray, resulting in a standard insertion sort, and time of O ( n 2 ) .

Best case: MapKey delivers the same small number of items to each subarray in an order where the best case of insertion sort occurs. Each insertion sort is O ( c ) , c the size of the subarrays; there are p subarrays thus p * c = n, so the insertion phase take O(n); thus, ProxmapSort is O ( n ) .

Average case: Each subarray is at most size c, a constant; insertion sort for each subarray is then O(c^2) at worst – a constant. (The actual time can be 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 ) = 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

1. Save time: Save the MapKey(i) values so they don't have to be recomputed (as they are in the code above)
2. Save space: The proxMaps can be stored in the hitCount array,as the hit counts are not needed once the proxmap is computed; the data can be sorted back into A, instead of using A2, if one takes care to note which A values are have been sorted so far, and which not.

Comparison with other sorting algorithms

Since ProxmapSort is not a comparison sort, the Ω(n log n) lower bound is inapplicable. Its speed can be attributed to it not being comparison-based and using arrays instead of dynamically allocated objects and pointers that must be followed, such as is done with when using a binary search tree.

ProxmapSort allows for the use of ProxmapSearch. Despite the O(n) build time, ProxMapSearch makes up for it with its O ( 1 ) average access time, making it very appealing for large databases. 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 ProxmapSort

Like ProxmapSort, 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, ProxmapSort 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 performance will be severely diminished. This behavior also holds for ProxmapSort: if the buckets are too large, its performance will degrade severely.