Talk:Radix sort

message: Maybe I am missing something here, but in the C-based iterative implementation, the line while (m / exp > 0) looks like a bug to me. (If all the integers in the array were negative, the loop would never execute, as m / exp would be negative.) I think we need while (m > exp)  here, but I won't change it in case I'm wrong.
quicksort is not n (log n), its n^2, I fixed this
- quicksort utilizing a random pivot can be shown to be (Big Theta)(n*log n) as instead of one decision tree for the program there exist many. As one makes n arbitrarily large, the probability of picking a tree which perfectly matches the sortedness of the data set such that the pivot is always "worst case" (and thus yields a n^2 run) becomes increasingly small. Since when we perform algorithmic analysis we are looking at the limit as n goes to infinity we can state that this probability goes to 0 and thus that quicksort is indeed (Big Theta)(n*(log n)).
  
Nonsense! You must state in advance whether you like to discuss/consider/analyze average, or worst case, or what-ever behaviour!! 
BTW: When talking Radix-sort one should also mention its generalization, Hash-sort, which
is on average asymptotically the fastest known sorting method, O(n), due to the fact that it uses knowledge about the to-be-expected distribution of the keys. With a good chosen hash-function it's run time is C*n + o(n). Enlighting example: sort N uniform and independend distributed random numbers in the halv-open intervall [0,1[ --- or even more instructiv: sort a permutation of the first N natural numbers! Last can be done optimally because of sufficient knowledge of the to-be-expected data.  
This character seems to be off-base on a number of counts.  Worst case is the conventional way of discussing algorithms.~JMK
std::sort is based on quicksort and heapsort, and is O(n(log(n)).  Stop knocking quicksort; yes, it's really O(n*n), but std::sort fixes that problem, and for real problems even raw quicksort is theta(nlog(n)).
You are incorrect. Not all std implementations use introsort, and in fact introsort is a rather sophisticated algorithm that is still not widely known.  Further, quicksort doesn't generally degrade all the way to n*n but it can often perform somewhat worse than N Log(N).  I love quicksort dearly, but in many cases, or in most, a well implemented radix is strictly better time-wise, and strictly worse space-wise. ~JMK
Hashsort is O(2k(n))http://arxiv.org/abs/cs.DS/0408040, which is not O(n) for large k.  When you compare realistic sorting algorithms that involve radix or hash-based sorting, you must assume both large n and large k.  Bucketsort obviously is O(n) when log(n) > k, but it's impractical for k >> log(n), which a major set of problems (some would argue most problems).  Hashsort is slower than std::sort for large k with collisions.
Now, if you would like a comparison of hashsort vs. Spreadsort or some other practical general algorithm, I'd be happy to make one.Cuberoot31 00:07, 2 December 2006 (UTC)
thread_title: Possible errors

message: In the section "Incremental Trie-based Radix sort", there is a sentence with this as its subject: "The sorted lists of other non-incremental radix sorting algorithms that sort all of the keys in a batch". I hope its obvious that this needs to be improved. I would do it myself, but I have no idea what it's trying to say. Can someone please attend to this? Thanks. Danielx 16:15, 13 August 2006 (UTC)
thread_title: Style Improvement Request

message: Ed, I really don't believe it's useful to assume constant memory when talking about the asymptotic behavior of an algorithm. That would make every algorithm run in O(1) space and O(1) time, if you think it through.  If you disagree, point me to an algorithms textbook that assumes constant memory.
The only thing close to that that I can think of is something you may have touched on: sometimes you do assume each memory access happens in constant time, just to simplify things, even though it's not true. rspeer / ɹəədsɹ  16:17, 9 December 2006 (UTC)
thread_title:  Constant memory 

message: I love Slashdot.  History of the Article page so far in 2007: edits on Jan 15,24,26 and Feb 17th.  Then there's a Slashdot story (http://it.slashdot.org/it/07/02/25/1848200.shtml) about a supposedly "new" sort algorithm which, in reality, appears to be the good old Radix sort and we get (so far) four edits today. (Feb 25th).   Thomas Dzubin Talk 22:46, 25 February 2007 (UTC)
thread_title:  Slashdot sending editors here 

message: The LSD example provided seems rather poor, in that it is unnecessary to sort by the 1s place to achieve correct ordering. Perhaps someone could revise the example to make 1s place ordering a necessary component?
PS I realize the 1s place ordering is necessary for the radix sort. But the example itself doesn't need this ordering, so it might make the radix sort seem a bit less useful than it really is. My two cents.168.39.166.127 19:04, 27 February 2007 (UTC)
thread_title: Example?

message: Graphics from bucket sort might be useful, but the mention of insertion sort in it reminds me of a horrible sorting method I devised in high school. (Index keys by the number of keys they are superior to). I'm not sure that inferior methods like bubble sort are not instructive or useful in a pinch or a variation. BrewJay (talk) 09:20, 25 July 2008 (UTC)
thread_title:  Merge from [[bucket sort]]. 

message: What on earth is this section about?  Oli Filth(talk|contribs) 16:51, 15 May 2010 (UTC)
replies: text: Well, I've deleted it now.  If it can be salvaged, please do so, but only if you can make it clear!  Oli Filth(talk|contribs) 07:21, 18 May 2010 (UTC)
replies: text:  I agree. Tb (talk) 17:30, 18 May 2010 (UTC)
thread_title:  "Unstable implementations of in-place sorting" section? 

message: I don't know if it still applies, but this article is claimed to be useless:
: "Unfortunately, the Wikipedia article on radix sort is useless. The section about an in-place variant is complete rubbish."
--Mortense (talk) 15:19, 4 January 2013 (UTC)
thread_title:  Useless article (?) 

message: I was wondering if some of the information from here (http://codercorner.com/RadixSortRevisited.htm) could be integrated into this article about sorting floating point numbers with radix sort?  — Preceding unsigned comment added by 150.135.222.234 (talk) 20:12, 15 February 2013 (UTC)
thread_title:  Radix sort for floats 

message: Is there some reason that in some places (for example in the section "Least significant digit radix sorts") omega is used while "Big-O" is used elsewhere?  Gwideman (talk) 00:43, 22 October 2013 (UTC)
thread_title:  Why Omega? 

message: There's a score of different implementation: 3 for C++! none of which are very clear; especially the C version. I propose that the various implementations be deleted and instead a proper description of the algorithm be inserted, both for LSD and MSD, independent of any programming language.  — Preceding unsigned comment added by 212.130.79.38 (talk) 21:05, 26 March 2015 (UTC)
replies: text: I second this, especially as the C++14 example won't even compile with certain compilers without modifications. (Works under g++ 4.8.2, fails on msvc 12 and clang 3.4.1) I think the key here should be proper description instead of psuedocode sillyness. --70.15.250.196 (talk) 13:59, 6 April 2015 (UTC)
replies: text:  There's a reason why the example specifically stated C++14: MSVC 12 and Clang 3.4.x are not C++14 compilers. Not that it matters too much now, but there was significant syntactical difference between the two language versions that one could argue warranted a separate, more succint, example.  — Preceding unsigned comment added by 203.213.88.195 (talk) 14:19, 1 July 2015 (UTC)
thread_title:  Call for abstract algorithm, instead of implemetations 

message: It seems to me this article became a playground for two individuals wanting to talk in detail about their own implementations and articles.
That's not really what a general encyclopedia should be focused on.
I tried to pare it down to history (expanded), 2 simple examples, a Java thing that actually works, a short discussion of MSD and LSD, and left the specialist stuff at the end for those still interested. I ripped out most of the perf talk, no citations. Perf is contextual, asymptotics aside, and if we want to have a section about it, links to real implementations/articles with real benchmarks would be a starting point.
I didn't know what to make of the Snow White stuff, except to say that Tries, Trees, and Traversals all have their own articles, and that section wasn't focused on on the sorting part of radix sort.
Cronholm144 05:09, 31 August 2019 (UTC)
thread_title:  I made a major edit 

message: Java example is not an LSD sort since we start with the highest bytes. Also, it's not the correct sort. As far as I understand if you want to operate without buckets using single array you have to do a recursive sort for the part of an array where all high bytes are equal. The current example breaks the layout of a higher level sorted by the previous step.
It works similar to:
[0b00, 0b01, 0b10, 0b10] -> sort by high bit -> [0b00, 0b01] + [0b10, 0b10] -> [0b00, 0b01, 0b10, 0b10] (same as original)
[0b00, 0b01, 0b10, 0b10] -> sort by low bit -> [0b00, 0b10, 0b10] + [0b01] -> [0b00, 0b10, 0b10, 0b01] = [0, 2, 2, 1] (not sorted!)
If you adapt this part to the example, the array to test will be [0, 1, 256, 256]. Result [0, 256, 256, 1] - not sorted.
Live example with the online compiler: https://www.jdoodle.com/embed/v0/1ufh
Ruslo (talk) 18:09, 4 September 2019 (UTC)
thread_title:  Java example is not working