Okay, I got through his later sections. I do approve of the bit on sorting floats, and sorting negative floats. Basically, his approach here is "don't be afra

Okay, I got through his later sections. I do approve of the bit on sorting floats, and sorting negative floats. Basically, his approach here is "don't be afraid of IEEE floats, just read the damn format and use your brain and do the work". Absolutely. I mean, I assume every reader of this comment is, in the case of sorting, better off using library routines, but I approve of the general principle. His section on "reducing the complexity" is, while factually correct, basically trivial and a waste of reading time. Unless you work in an incredibly constrained environment, in a very primitive language, with no libraries. In which case, okay, that's good trick. The bit on "Temporal Coherence"... sigh. First of all, I have never heard of this name ("temporal coherence") for this property. Maybe that's my fault? The property (of performing well on sorted input) is interesting, but it's even more interesting to perform well on nearly-sorted data. Go look at insertion sort for small data, or timsort for large data. (Or just use timsort for everything all the time, honestly). His optimization costs an extra n comparisons, and occasionally saves a lot of time but mostly saves no time. Whether it's worth it depends on your expected input data. I dunno, I'm not impressed. As for his "nice side effect of temporal coherence", I confess I didn't entirely understand his example, as evidence by the fact that I'm doubtful that his code sample works, but either way the property is already achieved by your choice of: * any stable sort * any library sorting routine that doesn't completely suck So, touting this as a special benefit is a little stupid. I think. Unless I missed his point here, which I probably did. His Applications section is just stupid. I don't need suggestions on what I could use a sort for.