Jump to content

Talk:Proxmap sort

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Time Complexity

[edit]

This is an interesting algorithm. The algorithm summary box states the best case running time is O(1), in fact all the running times seem to be out by a factor of n. Further down the page the best case is shown to be O(n) which sounds more reasonable! --Mrtimuk (talk) 10:16, 10 May 2011 (UTC)[reply]

It also states that the search algorithm is O(1), which is also not true. Making array bigger (n), the time will grow, for the constant number of buckets. So it seems that more accurate to talk about O(N/K) complexity, where K is the number of key buckets. 195.208.141.148 (talk) 04:23, 10 September 2024 (UTC)[reply]

Move?

[edit]
The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: not moved —Scott5114 [EXACT CHANGE ONLY] 23:49, 14 June 2011 (UTC)[reply]


Proxmap sortProxmapSort and ProxmapSearchRelisted. Vegaswikian (talk) 18:25, 5 June 2011 (UTC)[reply]

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Comparison with comparison sort

[edit]

If keys are "well distributed" among the subarrays, sorting occurs in linear time, much faster than comparison-based sorting, which can do no better than .

If keys are in order, even insertion sort takes linear time, so comparison sorts can certainly do better than . What the intro should be explaining is that in the average case this algorithm takes linear time, while a linear-time average is impossible for comparison sort. QVVERTYVS (hm?) 12:57, 15 June 2014 (UTC)[reply]