Live data from Hacker News

On anthropomorphism in science (1985)

cs.utexas.edu

61–64 of 64 posts

Re: On anthropomorphism in science (1985)

#61
post #30
post #21

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…

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)

#62
post #61
post #30

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. 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.

> if a system's behavior can be characterized with a set of equations, use the equations to talk about the behavior

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)

#63
post #61
post #30

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. 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.

As a separate point from my other post, characterizing the system's behavior isn't enough. You also need to characterize the requirements that the system is supposed to meet. Even if you have equations for the former, you might not for the latter. So your equations might completely and precisely predict system behavior that turns out not to do what the user actually wants. I think that's part of what Knuth's quote is talking about.

Re: On anthropomorphism in science (1985)

#64

Earlier 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.

That code is making an array of primes and iterating through it. It's just that the array is stored in instruction memory, and there is no explicit fiddling with indices or pointers.

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.

Post reply on HN