It is preferable if the length of the inputs are less than the the log of the size of the array. For instance if I have 256 buckets and I break integers up into 4 bytes then I need to run 4 passes to sort them properly however $log 16=4$ so there is a potential advantage for arrays of length greater than 16. But really all I've said here if we translate this to asymptotic terms is that there is some size for which radix sort will overtake merge sort. I once wrote a radix sort algorithm in C++ that did just the above. I found it was comparable for inputs less than 10000 but after that started to beat the standard libgcc std::sort. On an array of size 1000000 it betbeat it quite well. For small inputs (like inputs less than 1000) std::sort seemed to cream my radix sort no matter what I did. I believe this had to do with the fact that insertion sot was being used on the smaller sections.
It is preferable if the length of the inputs are less than the the log of the size of the array. For instance if I have 256 buckets and I break integers up into 4 bytes then I need to run 4 passes to sort them properly however $log 16=4$ so there is a potential advantage for arrays of length greater than 16. But really all I've said here if we translate this to asymptotic terms is that there is some size for which radix sort will overtake merge sort. I once wrote a radix sort algorithm in C++ that did just the above. I found it was comparable for inputs less than 10000 but after that started to beat the standard libgcc std::sort. On an array of size 1000000 it bet it quite well. For small inputs (like inputs less than 1000) std::sort seemed to cream my radix sort no matter what I did. I believe this had to do with the fact that insertion sot was being used on the smaller sections.
It is preferable if the length of the inputs are less than the the log of the size of the array. For instance if I have 256 buckets and I break integers up into 4 bytes then I need to run 4 passes to sort them properly however $log 16=4$ so there is a potential advantage for arrays of length greater than 16. But really all I've said here if we translate this to asymptotic terms is that there is some size for which radix sort will overtake merge sort. I once wrote a radix sort algorithm in C++ that did just the above. I found it was comparable for inputs less than 10000 but after that started to beat the standard libgcc std::sort. On an array of size 1000000 it beat it quite well. For small inputs (like inputs less than 1000) std::sort seemed to cream my radix sort no matter what I did. I believe this had to do with the fact that insertion sot was being used on the smaller sections.
It is preferable if the length of the inputs are less than the the log of the size of the array. For instance if I have 256 buckets and I break integers up into 4 bytes then I need to run 4 passes to sort them properly however $log 16=4$ so there is a potential advantage for arrays of length greater than 16. But really all I've said here if we translate this to asymptotic terms is that there is some size for which radix sort will overtake merge sort. I once wrote a radix sort algorithm in C++ that did just the above. I found it was comparable for inputs less than 10000 but after that started to beat the standard libgcc std::sort. On an array of size 1000000 it bet it quite well. For small inputs (like inputs less than 1000) std::sort seemed to cream my radix sort no matter what I did. I believe this had to do with the fact that insertion sot was being used on the smaller sections.