Earlier quoted context omitted.
Dijkstra wanted us to think on paper, use abstractions that accurately describe real-world systems, and arrive at answers methodically with a trail of checkable work. If our data and methods are sound our answers will always be correct. Using just-so stories does nothing to aid in the methodical derivation of conclusions from premises; and can serve to obfuscate and confuse the issues.
> Dijkstra wanted us to think on paper, use abstractions that accurately describe real-world systems, and arrive at answers methodically with a trail of checkable work. If our data and methods are sound our answers will always be correct. I understand the aspiration, but I always think of the counterpoint implicit in Knuth's famous statement: "Beware of bugs in the above code; I have only proved it correct, not tried…
On anthropomorphism in science (1985)
61–64 of 64 posts
Re: On anthropomorphism in science (1985)
#62Earlier quoted context omitted.
> Dijkstra wanted us to think on paper, use abstractions that accurately describe real-world systems, and arrive at answers methodically with a trail of checkable work. If our data and methods are sound our answers will always be correct. I understand the aspiration, but I always think of the counterpoint implicit in Knuth's famous statement: "Beware of bugs in the above code; I have only proved it correct, not tried…
The point is, if a system's behavior can be characterized with a set of equations, use the equations to talk about the behavior -- not a flawed metaphor for human cognition. If you find out that your equations incorrectly or incompletely characterize the system's behavior, Occam's razor requires you to assume that what you need is a better set of equations.
I agree, and I don't think Knuth's quote was saying anything different.
> If you find out that your equations incorrectly or incompletely characterize the system's behavior, Occam's razor requires you to assume that what you need is a better set of equations.
Yes, but you might not have them, and they might not be easy to find. So you might have to face the fact that, now and for the foreseeable future, you might not be able to use your equations to completely predict or characterize the system's behavior, so you need to actually test your code instead of just proving it correct, as Knuth said.
Re: On anthropomorphism in science (1985)
#63Earlier quoted context omitted.
> Dijkstra wanted us to think on paper, use abstractions that accurately describe real-world systems, and arrive at answers methodically with a trail of checkable work. If our data and methods are sound our answers will always be correct. I understand the aspiration, but I always think of the counterpoint implicit in Knuth's famous statement: "Beware of bugs in the above code; I have only proved it correct, not tried…
The point is, if a system's behavior can be characterized with a set of equations, use the equations to talk about the behavior -- not a flawed metaphor for human cognition. If you find out that your equations incorrectly or incompletely characterize the system's behavior, Occam's razor requires you to assume that what you need is a better set of equations.
Re: On anthropomorphism in science (1985)
#64Earlier quoted context omitted.
Actually the first example looks perfectly reasonable to me. I would have used changes of "if () return" instead of a huge OR, but the result would have been the same. The second example I can't judge. Probalby the variable name is bad, but not extraordinarily so. It's a lookup table, I can't tell if it is a good or bad idea without know what is being looked up.
Would could possibly be the advantage of hard coding divisibility checks against every prime number? There's so many problems with this. The simplest thing would be to just make an array of primes and iterate through it. There's also faster algorithms to check for primality.
As for more advanced primality testing methods, I guess it depends on where the the fancier algorithms begin to pay off. It would not surprise me if this simple algorithm was the fastest for any input small enough to be stored in a single machine word.