3 ms·
> I prefer busy beaver numbers to undecidability. Can you clarify what you mean by this? You prefer one to the other in what circumstances? > Now, the busy be
by twiceaday 3y ago
> I prefer busy beaver numbers to undecidability.
Can you clarify what you mean by this? You prefer one to the other in what circumstances?
> Now, the busy beaver numbers are enormous and we will likely never solve even BB(6). But that’s not for reasons of logical paradoxes like “this sentence is false” or “the smallest positive integer not definable in under sixty letters”.
Also please clarify this. BB is hard to compute because it is essentially defined in terms of solving the halting problem (that's known to be pretty hard). You alluded to a proof of that fact. What is your point? And what is your problem with those kinds of proofs? What do BBs have to do with undecidability besides being directly defined in terms of an undecidable operation?
- srcreigh 3y agoThere’s no known reason why we can’t compute any specific busy beaver number. We just can’t write code to list them indefinitely. No known reason why we can’t solve the first 100k, for example. Whereas the halting problem is known to be unsolvable. I just prefer things that are solvable in theory to things that aren’t.
- twiceaday 3y agoI am reading your original comment as "I prefer the color green to the number seven" coupled with an implication that it is common to compare green to seven, and that there are obvious situations where green can be used instead of seven. I don't see why anybody would compare green to seven, enough to state it and the conversation to gain traction. Your explanation here is akin to 'I like green because green can be seen but you can never truly see seven.' Okay, these words make sense in that order, but they don't explain the above implications. Are you simply saying that you prefer the aesthetic of one of these two vaguely related things? It sounds like you are implying that there is some way to do all the work with undecidability but using BB instead. Show your work. There is no known reason why we can't tell if any specific program halts. We just can't write code to tell if an arbitrary program halts. This result is exactly what you are using when talking about preferring BB(k) for some fixed k, each k requires solving a bunch of halting problems. The paradox proofs you seem to dislike are only needed for the general case, the general halting problem or, and this is to me the confusing part, the general BB(n). So you are comparing BB(k) for some fixed k to something infinitely more general in the general halting problem. So, again, why would you compare these two things? When is that a useful thing to do?