No. The temp variable is typically eliminated by the compiler during its optimization stage. Modern CPUs like x86 have instructions like xchg for switching exchanging/switching data.
>>6
What >>4 means is that bubble sort is an inefficient sort whose only redeeming quality is its ease of implementation. qsort, heap sort, shell sort and so on, perform much better than bubble sort.
However, not every set of numbers that need to be sorted is huge. Assuming the XOR bubble sort I posted was just a standard bubble sort what benefits would be gained from implementing a more complicated algorithm?
>>6
Sure can, there is no reasonable usage of a bubble sort, because virtually EVERY sorting algorithm is better than it. I say virtually every, only because we have stupid stuff like bogosort, which is meant as a joke. The only possible reason for the possible reason for the continued existence of the Bubble sort is as a teaching mechanism, and I would suggest that even then it shouldn't be taught.
>>9
I can't remember the last time I wrote my own sorting routine. qsort and other sorting routines usually come with the standard library of most languages, and you only have to provide a comparator lambda/function to it (the reason there's usually multiple routines is that for certain data structures switching elements may be more costly or certain distribution of the values may be better handled by other sort algorithms).
Name:
Anonymous2010-05-22 15:17
>>10
with a small enough n, bubble sort can outperform algorithms that better asymptotic performance for arbitrary ns because of its lower constant cost. It might be optimal to (for example) use a bubble sort on merge sort's split arrays once they are sufficiently small, rather than splitting all the way down to n = 1.
I bet neither of you can reasonably explain yourselves.
x86 is a over 30 years old peace of garbage that has had shit stacked all over it until it became so bloated that, its instruction set looks worse then perl.
besides, its slow and powerhungry.
the only reason people use x86 is for legacy reasons and because it became a pseudostandard.
>>13
A decent quicksort implementation has a better constant cost on nearly-sorted arrays than bubblesort. There's definitely value in switching to a different algorithm for different input sizes (most optimised sorting implementations do this, including qsort in any half-way decent libc), but bubblesort is always a terrible choice.