Date: | October 23, 2003 / year-entry #106 |
Tags: | code |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20031023-00/?p=42063 |
Comments: | 8 |
Summary: | When you are writing a sort comparison function (say, to be passed to ListView_SortItems or *gasp* to be used as an IComparer), your comparison function needs to follow these rules: Reflexivity: Compare(a, a) = 0. Anti-Symmetry: Compare(a, b) has the opposite sign of Compare(b, a), where 0 is considered to be its own opposite. Transitivity:... |
When you are writing a sort comparison function (say, to be passed to
Here are some logical consequences of these rules (all easily proved). The first two are obvious, but the third may be a surprise.
Of the original three rules, the first two are hard to get wrong, but the third rule is often hard to get right if you try to be clever in your comparison function. For one thing, these rules require that you implement a total order. If you merely have a partial order, you must extend your partial order to a total order in a consistent manner. I saw somebody get into trouble when they tried to implement their comparison function on a set of tasks, where some tasks have other tasks as prerequisites. The comparison function implemented the following algorithm:
Sounds great. Then you can sort with this comparison function and you get the tasks listed in some order such that all tasks come after their prerequisites. Except that it doesn't work. Trying to sort with this comparison function results in all the tasks being jumbled together with apparently no regard for which tasks are prerequisites of which. What went wrong? Consider this dependency diagram: a ----> b c Task "a" is a prerequisite for "b", and task "c" is unrelated to both of them. If you used the above comparison function, it would declare that "a = c" and "b = c" (since "c" is unrelated to "a" or "b"), which in turn implies by transitivity that "a = b", which contradicts "a < b", since "a" is a prerequisite for "b". If your comparison function is inconsistent, you will get garbled results. Moral of the story: When you write a comparison function, you really have to know which items are less than which other items. Don't just declare two items "equal" because you don't know which order they should be in. |
Comments (8)
Comments are closed. |
Sorry if this is slightly off-topic, but what is wrong with IComparer?
I would guess that it’s because a .Net interface (or a .Net anything) is normally not seen on this blog. See the tagline at top right! :-)
The solution to the IComparer for Tasks is too compare another task field after the dependency comparison showed nothing. For instance:
int compare(Task a, Task b) {
if (a.dependsOn(b)) return 1;
if (b.dependsOn(a)) return -1;
return strcmp(a.getName(), b.getName());
// or return a.getId() – b.getId(); if you don’t like the sort order depending on the task name which could change.
}
Sorry, Jonathan, that still doesn’t work. Consider this dependency diagram:
c -> a
b
then a<b (no dependency, use alpha sort), and b<c (no dependency, use alpha sort), and c<a (dependency).
raymond, you are wrong, "b<c" is incorrect because there IS a dependency of c on b … dependencies are by definition bi-directional.
The conversion from gotdotnet messed up the formatting. The diagram should be
c -> a
b
there is no dependency betwen b and anything.
With that I’m closing comments since this thread is extremely old.
Files and directories with no time/date are often mistaken for so-called