Tim writes: > Almost all sorts you're likely > to use in real life are stable in order to support this, whether it's > clicking on an email-metadata column in Outlook, or sorting an array of data > by a contained column in Excel. Guido tries it out: > I experimented a bit with the version of Outlook I have, and it seems > to always use the delivery date/time as the second key, and always in > descending order. Which is simply evidence that Outlook is poorly designed, and that Microsoft should have hired Tim to help with design specs. Although Outlook lacks this feature, I have FREQUENTLY desired it, and been annoyed at its absence. Tim in a later email: > It depends some on the current view, but I misremembered Outlook's UI > anyway: to get a multi-heading sort, you have to be depress the shift key > when clicking on the 2nd (and 3rd, etc) column (and click twice (not > double-click!) to reverse the sort order on the current column; the shift > key applies there too if you want a multi-key sort order). Well well... it's nice to learn that! I find Tim's (and other's) arguments quite convincing. We can go with a stable sort... ie, compare the keys, then fall back on stability and NEVER try comparing the objects themselves, and I think it will make complete sense. After all, sorting with a "key" parameter provided is *NOT* really a DSU algorithm... it's a new sort feature which happens to be _implemented_ using DSU. Should that new feature sort on "just the key" (leaving ties stable) or should it sort on "the key and then the objects themselves". I'd say both make sense, and in fact "just the key" is more obvious to me. -- Michael Chermside
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4