Thank you for this thoughtful response. It helpful and inspires new thoughts.
When I was a boy learning C (1976 or 1977, UNIX 6th Edition at Bell Labs via "learn") the definition of qsort() was a new idea for me. The exposure of base and stride so nakedly (after BASIC and FORTRAN and LISP and SAIL and ALGOL60 which hid them behind a name) was new and the role of the comparison function was a surprise in terms of API and the approach of passing in the brain as an argument. At first I did not like it, because it seemed that so many function calls would be expensive and I was sensitized to that. (having used a PDP-8 taught lessons about expensive.) I always was a little iffy about qsort because of this and from time to time would write a custom sort in my programs where the difference made a difference. On the other hand, qsort() always worked and was admirably flexible--serving myself and millions of others now for more than half a century. I've always looked closely at how people thought about reusable sort utilities and efficiency. On IBM mainframes there was a 3rd party sort utility that generated machine code for your comparison function two human generations before JIT. In SmallTalk it was like qsort since everything had compare methods. This was the "old" way. The newer way is different, having a less() method and using it twice to decide about greater() and equal(). That works too...except when it doesn't...as in the case of quiet and signalling NaNs in IEEE floating point. It might be faster too, since "<" is less decisions than "<" or "=" or ">" and the sort code may be in a tight loop of while less() or while greater() and thereby be faster than the old way. The qsort() whole-brain as argument works in all cases because the developer knows how to make the subtle decisions. The newer partial-brain method works in those (vast majority) of cases where the implied rest-of-brain is semantically correct. The downside is that the developer may not realize when this is introducing bugs. (Just as in the qsort() case they might not realize the bug there if they don't handle NaNs properly.) One certain way is to have mathematical statements about meaning, as you list above. Another point of view is to acknowledge floating point as a special thing--not numbers at all--different from integral types because of reserved values with magic meanings when compared, and deal with that specially. All interesting. Thank you! Michael -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
