User:Earlster/Sandbox

Earlster/Sandbox
	Insertion sorting into buckets during proxmap. Example of insertion sort sorting a list of random numbers.
Class	Sorting algorithm
Data structure	Array
Worst-case performance
Best-case performance
Average performance
Worst-case space complexity	total,

Example of insertion sorting a bucket of random numbers.

Unlike bucket sorting which sorts after all the buckets are filled, the elements are insertion sorted as they are inserted

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 edit

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

Overview edit

Basic Strategy edit

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

Initialize: Create and initialize 4 arrays all of n size, hitCount, proxMap, location, and A2.
Partition: Using a carefully chosen mapKey function, divide the A2 into subarrays or "buckets" using the keys in A
Disperse: Read over A, dropping each key into its bucket in A2, insertion sorting as needed.
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 edit

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).

Array table
A1	6.7	5.9	8.4	1.2	7.3	3.7	11.5	1.1	4.8	0.4	10.5	6.1	1.8
H	1	3	0	1	1	1	2	1	1	0	1	1
P	0	1	-1	4	5	6	7	9	10	-1	11	12
L	7	6	10	1	9	4	12	1	5	0	11	7	1
A2	0.4	1.1	1.2	1.8	3.7	4.8	5.9	6.1	6.7	7.3	8.4	10.5	11.1

Pseudocode edit

for i = 0 to 11 // compute hit counts
H[i] = 0;
for i = 0 to 12
{
pos = MapKey(A[i]);
H[pos] = H[pos] + 1;
}

runningTotal = 0; // compute prox map – location of start of each subarray
for i = 0 to 12
if H[i] = 0
P[i] = 0;
else
P[i] = runningTotal;
runningTotal = runningTotal + H[i];

for i = 0 to 12 // compute location – subarray – in A2 into which each item in A is to be placed
L[i] = P[MapKey(A[i])];

for I = 0 to 12; // sort items
A2[I] = <empty>;
for i = 0 to 12 // insert each item into subarray beginning at start, preserving order
{
start = L[i]; // subarray for this item begins at this location
insertion made = false;
for j = start to an empty cell or the end of A2 is found, and insertion not made
{
if A2[j] == <empty> // if subarray empty, just put item in first position of subarray
A2[j] = A[i];
insertion made = true;
else if key < A2[j] // key belongs at A2[j]
int end = j + 1; // Find end of used part of bucket – where first <empty> is
while (A2[end] != <empty>
end++;
for k = end -1 to j // Move larger keys to the right 1 cell
A2[k+1] = A2[k];
A2[j] = A[i];
insertion made = true; // Add in new key
}
}

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 edit

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 edit

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 edit

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]

Analysis edit

Performance edit

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 edit

Save time: save MapKey(i) values so they don't have have to be recomputed (notice they're recomputed in the code above)
Save space: if clever, A can be reused

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.

Comparison with other sorting algorithms edit

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 edit

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.^[1] 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.

References edit

^ Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms, Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7. Section 8.4: Bucket sort, pp.174–177.

Thomas A. Standish "Using O(n) ProxmapSort and O(1) ProxmapSearch to Motivate CS2 Students (Part I)" from Donald Bren School of Information and Computer Sciences at UC Irvine.
Norman Jacobson "A Synopsis of ProxmapSort & ProxmapSearch" from Donald Bren School of Information and Computer Sciences at UC Irvine.

External links edit

[1] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms, Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7. Section 8.4: Bucket sort, pp.174–177.

[1]

v t e Sorting algorithms
Theory	Computational complexity theory Big O notation Total order Lists Inplacement Stability Comparison sort Adaptive sort Sorting network Integer sorting X + Y sorting Transdichotomous model Quantum sort
Exchange sorts	Bubble sort Cocktail shaker sort Odd–even sort Comb sort Gnome sort Proportion extend sort Quicksort
Selection sorts	Selection sort Heapsort Smoothsort Cartesian tree sort Tournament sort Cycle sort Weak-heap sort
Insertion sorts	Insertion sort Shellsort Splaysort Tree sort Library sort Patience sorting
Merge sorts	Merge sort Cascade merge sort Oscillating merge sort Polyphase merge sort
Distribution sorts	American flag sort Bead sort Bucket sort Burstsort Counting sort Interpolation sort Pigeonhole sort Proxmap sort Radix sort Flashsort
Concurrent sorts	Bitonic sorter Batcher odd–even mergesort Pairwise sorting network Samplesort
Hybrid sorts	Block merge sort Kirkpatrick–Reisch sort Timsort Introsort Spreadsort Merge-insertion sort
Other	Topological sorting Pre-topological order Pancake sorting Spaghetti sort
Impractical sorts	Stooge sort Slowsort Bogosort