> Arguments about the quality of compiler optimizations vs. hand coding > are pointless, because programmers optimize programs in ways that compilers > are (correctly) forbidden to do; by changing the algorithm. > > For example, if I happen to know "x" will always be an integer > from 0 to 359, I can replace sin(x) with a table lookup. No compiler > can ever do that, even if I include assert(x>=0 && x<360) in the code > somewhere (which would be a good idea even if I "know" it).
Unless the assert is part of the language, such as in Eiffel and other languages with contracts. (Though I'm not aware of any language that uses contracts in the optimization stage.) I tried (not hard enough, and failed) to push for design-by-contract extensions into C++ TR2, and even the author of the proposal seemed surprised when I said better optimization was a key feature: it seems everybody sees design by contract as all about safety. But it is about describing the problem more accurately to the computer so that it can not just find more bugs at compile-time but also so it can generate better code at compile-time. Darren -- Darren Cook http://dcook.org/mlsn/ (English-Japanese-German-Chinese free dictionary) http://dcook.org/work/ (About me and my work) http://dcook.org/work/charts/ (My flash charting demos) _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
