views:

2044

answers:

16

Do bubble sorts have any real world use? Every time I see one mentioned, it's always either:

  1. A sorting algorithm to learn with.
  2. An example of a sorting algorithm not to use.
+6  A: 

It's probably the fastest for tiny sets.

Speaking of education. A link to the last scene of sorting out sorting, it's amazing. A must-see.

Cristian Libardo
No it is not. It should not be educated to beginning programmers, just like goto's.
Stephan Eggermont
+1 for making me shout "GO QUICKSORT GO!" for the first time in my life.
Juliet
+10  A: 

It doesn't get used much in the real world. It's a good learning tool because it's easy to understand and fast to implement. It has bad (O(n^2)) worst case and average performance. It's has good best case performance when you know the data is almost sorted, but there are plenty of other algorithms that have this property, with better worst and average case performance.

Bill the Lizard
+2  A: 

I think it's a good "teaching" algorithm because it's very easy to understand and implement. It may also be useful for small data sets for the same reason (although some of the O(n lg n) algorithms are pretty easy to implement too).

Jay Conrod
+20  A: 

It depends on the way your data is distributed - if you can make some assumptions.

One of the best links I've found to understand when to use a bubble sort - or some other sort, is this - an animated view on sorting algorithms:

http://vision.bc.edu/~dmartin/teaching/sorting/anim-html/all.html

Remy Sharp
I really like that animation! According to it, it seems like the shell sort is best overall for size 50.
lkessler
Awesome animation
Tom Leys
those animations rock. great site
Johannes Schaub - litb
Dijkstra would have a fit :D
Ellery Newcomer
http://www.sorting-algorithms.com/ also has some good animations too!
RCIX
+6  A: 

I came across a great use for it in an optimisation anecdote recently. A program needed a set of sprites sorted in depth order each frame. The spites order wouldn't change much between frames, so as an optimisation they were bubble sorted with a single pass each frame. This was done in both directions (top to bottom and bottom to top). So the sprites were always almost sorted with a very efficient O(N) algorithm.

workmad3
Actually insertion sort is still better for this. A lot of real time rendering systems use insertion sort for very large lists of things, for the reason that things tend to be "almost" ordered for each frame. Bubble sort is very similar though.
TM
+1  A: 

It is the sort I use most often actually. (In our project, we cannot use any external libraries.)

It is useful when I know for sure that data set is really small, so I do not care one bit about speed and want shortest and simplest code.

Bubble is not the lowest you can go. Recently, I was in a situation when I needed to sort exactly three elements. I wrote something like this:

// Use sort of stooge to sort the three elements by cpFirst

SwapElementsIfNeeded(&elementTop, &elementBottom);
SwapElementsIfNeeded(&elementTop, &elementMiddle);
SwapElementsIfNeeded(&elementMiddle, &elementBottom);

*pelement1 = elementTop;
*pelement2 = elementMiddle;
*pelement3 = elementBottom;
buti-oxa
+3  A: 

It's good for small data sets - which is why some qsort implementations switch to it when the partition size gets small. But insertion sort is still faster, so there's no good reason to use it except as a teaching aid.

Paul
+1  A: 

I used to use it in some cases for small N on the TRS-80 Model 1. Using a for loop, one could implement the complete sort on one program line.

Other than that, it is good for teaching, and sometimes for lists that are nearly in sorted order.

EvilTeach
+1  A: 

I once used it for a case where the vast majority of the time it would be sorting two items.

The next time I saw that code, someone had replaced it with the library sort. I hope they benchmarked it first!

Mark Ransom
@Mark Ransom: sorting two items? `(a < b)? (swap):(do-not-swap)`?
Lazer
@Lazer, although the majority of the time it was 2, it still had to handle the case where there were more than 2. In retrospect I could have treated that as two different cases with different code to handle each, and I've been advised that the library sorts generally work this way anyway.
Mark Ransom
+1  A: 

It's quick and easy to code and (nearly impossible to do wrong). It has it's place if you're not doing heavy lifting and there's no library sorting support.

Brian Knoblauch
+1  A: 

I can't resist responding to any remarks on bubble sort by mentioning the faster (seems to be O(nlogn), but this is not really proven) Comb Sort. Note that Comb sort is a bit faster if you use a precomputed table. Comb sort is exactly the same as bubble sort except that it doesn't initially start by swapping adjacent elements. It's almost as easy to implement/understand as bubble sort.

Brian
A: 

Oh yes, it is a good selection mechanism. If you find it in code written by someone, you don't hire him.

Stephan Eggermont
Even if it works perfect in specific suituation?
pierr
Yes. If you can tune the situation so that bubblesort is the perfect answer, you should have been able to tune the situation so that it isn't.
Stephan Eggermont
haha, I have already used this criteria to reject candidate :)
sergdev
Incredible, how many negative votes this gets...
Stephan Eggermont
@Stephan: It gets negative votes (including mine) because blanket rules like that aren't just silly, they're downright _wrong_. Bubblesort takes very few instructions while in many cases being "fast enough". I certainly wouldn't hire anyone for an embedded project that couldn't envision those properties being useful.
Nicholas Knight
I find it works pretty well. In real life the reason it is used is because they don't know their algorithms.
Stephan Eggermont
+2  A: 

we recently used bubblesort in an optimality proof for an algorithm. We had to transform an arbitrary optimal solution represented by a sequence of objects into a solution that was found by our algorithm. Because our algorithm was just "Sort by this criteria", we had to prove that we can sort an optimal solution without making it worse. In this case, bubble sort was a very good algorithm to use, because it has the nice invariant of just swapping two elements that are next to each other and are in the wrong order. Using more complicated algorithms there would have melted brains, I think.

Greetings.

Tetha
+1  A: 

Bubble sort is easy to implement and it is fast enough when you have small data sets.

Bubble sort is fast enough when your set is almost sorted (e.g. one or several elements are not in the correct positions), in this case you better to interlace traverses from 0-index to n-index and from n-index to 0-index. Using C++ it can be implemented in the following way:

void bubbleSort(vector<int>& v) { // sort in ascending order
  bool go = true;
  while (go) {
    go = false;
    for (int i = 0; i+1 < v.size(); ++i)
      if (v[i] > v[i+1]) {
         swap(v[i], v[j]);
         go = true;
      }
    for (int i = (int)v.size()-1; i > 0; --i) 
      if (v[i-1] > v[i]) {
         swap(v[i-1], v[i]);
         go = true;
      }
  }
}

It can be good if swap of two adjacent items is chip and swap of arbitrary items is expensive.

Donald Knuth, in his famous "The Art of Computer Programming", concluded that "the bubble sort seems to have nothing to recommend it, except a catchy name and the fact that it leads to some interesting theoretical problems".

Since this algorithm is easy to implement it is easy to support, and it is important in real application life cycle to reduce effort for support.

sergdev
It is not easy to support. Every real programmer will feel an almost unsurmountable urge to replace it as soon as possible :)
Stephan Eggermont
A: 

Mostly nothing. Use QuickSort or SelectionSort instead...!

Thomas Hansen
+8  A: 

Bubble sort is (provably) the fastest sort available under a very specific circumstance. It originally became well known primarily because it was one of the first algorithms (of any kind) that was rigorously analyzed, and the proof was found that it was optimal under its limited circumstance.

Consider a file stored on a tape drive, and so little random access memory (or such large keys) that you can only load two records into memory at any given time. Rewinding the tape is slow enough that doing random access within the file is generally impractical -- if possible, you want to process records sequentially, no more than two at a time.

Back when tape drives were common, and machines with only a few thousand (words|bytes) of RAM (of whatever sort) were common, that was sufficiently realistic to be worth studying. That circumstance is now rare, so studying bubble sort makes little sense at all -- but even worse, the circumstance when it's optimal isn't taught anyway, so even when/if the right situation arose, almost nobody would realize it.

As far as being the fastest on an extremely small and/or nearly sorted set of data, while that can cover up the weakness of bubble sort (to at least some degree), an insertion sort will essentially always be better for either/both of those.

Jerry Coffin