On Sat, 09 Aug 2025 12:36:38 -0500, olcott wrote:
On 8/9/2025 11:13 AM, Richard Heathfield wrote:
On 09/08/2025 16:45, olcott wrote:
On 8/9/2025 8:10 AM, Richard Heathfield wrote:
On 09/08/2025 13:56, olcott wrote:
If you try to think of it as a black box then you are unable to see
that DD calls HHH(DD) in recursive simulation that cannot reach its
own "if" statement thus making the "do the opposite" code
unreachable.
No, you can have all the recurive calls you like to DD from inside
HHH, but that's neither here nor there. That's black box stuff.
Nobody cares about all that shit - except you, of course.
The only reason that nobody cares is that they only care about
rebuttal at the expense of truth.
No, they don't care because it truly doesn't matter.
Refuting the proof of the most important computer science theorem that
exists does matter.
That people are unwilling to use first principles https://fs.blog/first-principles/
And prefer to only start on the basis of misconceptions is their error.
What if the definition of the halting problem is found to be
inconsistent with other key principles of the theory of computation?
Your fundamental error:
In x86utm, H simulates D(D), detects the nested recursion as non-halting, aborts, and returns 0 (non-halting). But when D(D) runs for real:
* It calls H(D,D).
* H simulates, aborts the simulation (not the real execution), and returns
0 (non-halting).
* D, receiving 0 (non-halting), halts.
Thus, the actual machine D(D) halts, but H reported "does not halt". H is
wrong about the machine's behavior.
/Flibble
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)