It occurs to me that a quicksort is such a generally useful sorting procedure that it should be built right into the language. D takes this approach, including a quicksort as part of its standard library, and I think that's a very good idea. There shouldn't be any need for people to create implementation after implementation of the quicksort procedure when it can be done perfectly -- and more efficiently! -- by the language itself. =)
I suggest list.Sort(ascending = 1)
Objects would be sorted by name, tag, or internal ID, checked in that order.
ID:134465
 Jul 8 2006, 5:01 am
|
|
Any hard-coded implementation of a sorting algorithm would be good, as long as it wasn't bogosort.
I'm sure if it really came down to it, a /datum/sortkey() proc could be in place. The unstable sorting would remain an issue, but stable sorts are only needed in limited circumstances; every time I've sorted a list, I have had no need for the former order -- in fact, I've always treated every sorting as destructive, meaning that I treat even stable sorting procedures as unstable. The general usefulness -- and speed comparison, even in its worst-case scenario -- of the quicksort procedure practically begs a default implementation. =) | |
There are two problems with this. 1) It's often desirable to sort by something other than the list entry, so the need for other implementations won't go away. 2) Quicksort is unstable, so for certain applications it is not a desirable choice.
Lummox JR