Finally, we talk about stability. This is really one of the rules of the game but

it's much easier to talk about in the context of the real algorithms that we've

seen so far. And really it doesn't make sense if you don't know about comparators

which we just introduced. So, the typical application that I just used as an example

is say the set of student records. So we have them sorted by name and this is say,

something that we do just before assigning final grades. Maybe the third line there

is the final grade. So it's all fine sorted by name and but then in order to

distribute it out to the people leading it to the sections, what we want to do is

sort by the second fields, sort by section. The problem is that when we do

that, it messes up the sort by name and that's annoying. You might assume that

once you have it sorted by name, then when you sorted by the second field then it

should maintain the sort of by name for all that have equal keys in that second

field. Actually not all sorts preserve that property that is called stability.

And clearly, it's worthwhile to think about for your application whether you

want or need a stable sort. And so, it's an annoying surprise for many people and

many applications. So a stable sort is a sort that preserves the relative order of

items with equal keys. Whichever sort are stable? That's an interesting question

that we'll take a look at now. The quick bottom line is that insertion sort and

mergesort are stable but not selection sort or Shellsort. And even within that

bottom line, there's implementations that maybe are not stable. You have to

carefully check the code to be sure. Always, in this class, we have an exercise

or exam question is this version of this sort stable or not? So, students learn to

recognize whether the code is stable. So this is just another typical example where

we've got things sorted by time, and then what we want to do is maybe these are

important events. People buying tickets to a rock concert and I'm going to sort by

location what we'd hope is that it would keep the sort by time but this is a

non-stable sort that doesn't do bad so then out in the location they're going to

have to resort it if they use one of these. But if they use a stable sort, then

it stay sorted by time and lots of applications you want stability. Alright,

so let's just look at each of the algorithms that we've considered so far.

Insertion Sort. Insertion Sort is stable. Why is it stable? Well, we never move

equal items pass one another. In this example here, when we get A1, well that's

so in this case, the index is just one that appears in the array, it's just A's

and B's. When we get our second A, we stop the sort as long as we're not less. We're

equal, we're not less, we stop it so we never move an equal item pass another one.

If this less or less than or equal, then it wouldn't work. Or if we did the other

way around and proceeded accordingly. So, equal items never move past each other in

this code so therefore insertion sort is stable. But selection sort is not stable.

Usually way, the way to show that a sort is not stable and it's just to see if it

has a long distance exchange that might move an item pass some equal item. So,

[cough] in this case, for example, for selection sort, when we do that first

exchange oops, [cough] where we found the minimum A and B is in position zero. We

did a long distance exchange and that catapulted that first item past any item

that it might be equal putting them out of order. And that's may not get fixed so

that sort is not stable. It might move items past some equal item and leave a

result where items that are equal or in different order than they were originally

in the file. Selection Sort is not stable. Shellsort also has long distance exchange

and so it's not stable. It moves keys past other keys that could be equal and so its

easy to construct examples showing that Selection Sort is not stable. And what

about Mergesort? Mergesort is stable well, it's stable as long as the merge operation

is stable and that operation is going to be stable depending on how we code it.

And, and in our code, if the two keys are equal, it takes from the left subarray so

that means that, it will always take the, if there's a two sets of equal keys, it

will preserve the relative order and that's enough to show that the merge

operation is stable and then therefore Mergesort is stable. Stability is an

important property in sorting algorithms. Mergesort is not only efficient, it's also