Roy Smith wrote: > In article <mailman.4882.1388808283.18130.python-l...@python.org>, > Mark Lawrence <breamore...@yahoo.co.uk> wrote: > >> Surely everybody prefers fast but incorrect code in >> preference to something that is correct but slow? > > I realize I'm taking this statement out of context, but yes, sometimes > fast is more important than correct.
I know somebody who was once touring in the States, and ended up travelling cross-country by road with the roadies rather than flying. She tells me of the time someone pointed out that they were travelling in the wrong direction, away from their destination. The roadie driving replied "Who cares? We're making fantastic time!" (Ah, the seventies. So many drugs...) Fast is never more important than correct. It's just that sometimes you might compromise a little (or a lot) on what counts as correct in order for some speed. To give an example, say you want to solve the Travelling Salesman Problem, and find the shortest path through a whole lot of cities A, B, C, ..., Z. That's a Hard Problem, expensive to solve correctly. But if you loosen the requirements so that a correct solution no longer has to be the absolutely shortest path, and instead accept solutions which are nearly always close to the shortest (but without any guarantee of how close), then you can make the problem considerably easier to solve. But regardless of how fast your path-finder algorithm might become, you're unlikely to be satisfied with a solution that travels around in a circle from A to B a million times then shoots off straight to Z without passing through any of the other cities. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
