On 8/9/2025 2:30 PM, Richard Heathfield wrote:
On 09/08/2025 20:23, olcott wrote:
When we boil all of the abstractions down to the
concrete notion of x86 machines we attain the
unequivocal proof that the pathological self-reference
relationship of all of the standard proofs makes
the behavior of the directly executed machine different
than the behavior of the correctly emulated machine
description.
If you can prove that the behavior of the directly executed
machine is different to the behavior of the correctly emulated
machine description, you will have proved that emulation is a
flawed technique, because it fails to derive the expected results.
I'd like to see that proof.
Finally !!!
On 8/9/2025 3:09 PM, Richard Heathfield wrote:
On 09/08/2025 20:47, olcott wrote:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
On 09/08/2025 20:23, olcott wrote:
When we boil all of the abstractions down to the
concrete notion of x86 machines we attain the
unequivocal proof that the pathological self-reference
relationship of all of the standard proofs makes
the behavior of the directly executed machine different
than the behavior of the correctly emulated machine
description.
If you can prove that the behavior of the directly executed
machine is different to the behavior of the correctly
emulated machine description, you will have proved that
emulation is a flawed technique, because it fails to derive
the expected results.
I'd like to see that proof.
Finally !!!
Don't get your hopes up.
Let us assume for the sake of argument that you have proved
that the behaviour of the directly executed machine is
different to the behaviour of the correctly emulated machine
description.
But what does that mean?
It only means that you have proved that emulation is a flawed
technique,
You have to go through the whole proof not merely
leap to a conclusion on the basis of presuming
"that emulation is a flawed technique".
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
You get the wrong numbers out. It don't get much more flawed
than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it
doesn't. If you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:You are the one that claimed:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
Ah so you are dishonest. That is what I expected.
You get the wrong numbers out. It don't get much more flawed than
that.
At this point you are essentially saying that the emulation is
flawed because everyone knows that "push ebp" really means "jmp
00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it doesn't. >>>>>> If you get the wrong one, your emulation is broken.
WHAT?
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] 6862210000
push 00002162 // push DD [0000216b] e862f4ffff call 000015d2 //
call HHH [00002170] 83c404 add esp,+04 [00002173]
8945fc mov [ebp-04],eax [00002176] 837dfc00 cmp dword
[ebp-04],+00 [0000217a] 7402 jz 0000217e [0000217c]
ebfe jmp 0000217c [0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp [00002183] 5d pop
ebp [00002184] c3 ret Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line knowing that each
time HHH is called it creates a separate process context to emulate an
instance of DD and then emulate an instance of itself emulating DD
when DD calls HHH(DD).
Within this you must show exactly how the original emulated DD reaches
past its own machine address of [0000216b].
Why?
Haven't you already done it?
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
I now believe that you are dishonest because I have been through this
same thing before many times.
Claims that I am wrong, request to point out the exact error and no
error is ever pointed out.
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed
than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it
doesn't. If you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more
flawed than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it
doesn't. If you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
You are the one that claimed:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
I now believe that you are dishonest
because I have
been through this same thing before many times.
Claims that I am wrong, request to point out
the exact error and no error is ever pointed out.
On 8/9/2025 4:45 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 16:38:41 -0500, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:You are the one that claimed:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
Ah so you are dishonest. That is what I expected.
You get the wrong numbers out. It don't get much more flawed than >>>>>>>> that.
At this point you are essentially saying that the emulation is >>>>>>>>> flawed because everyone knows that "push ebp" really means "jmp >>>>>>>>> 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>
Those are your only two possible results: it stops, or it
doesn't.
If you get the wrong one, your emulation is broken.
WHAT?
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] 6862210000
push 00002162 // push DD [0000216b] e862f4ffff call 000015d2 // >>>>> call HHH [00002170] 83c404 add esp,+04 [00002173]
8945fc mov [ebp-04],eax [00002176] 837dfc00 cmp dword
[ebp-04],+00 [0000217a] 7402 jz 0000217e [0000217c] >>>>> ebfe jmp 0000217c [0000217e] 8b45fc mov
eax,[ebp-04] [00002181] 8be5 mov esp,ebp [00002183] >>>>> 5d pop ebp [00002184] c3 ret Size in
bytes:(0035) [00002184]
You have to go through the above code line-by-line knowing that each >>>>> time HHH is called it creates a separate process context to emulate
an instance of DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original emulated DD
reaches past its own machine address of [0000216b].
Why?
Haven't you already done it?
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
> you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
I now believe that you are dishonest because I have been through this
same thing before many times.
Claims that I am wrong, request to point out the exact error and no
error is ever pointed out.
There is a flaw in your work of 22 years though, a fundamental one:
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
You are one of the smartest ones here you may be able to understand my complete proof.
We cannot get to that key second step of the proof until it is first understood that DD emulated by HHH according to the semantics of the x86 language (the ultimate measure of correct simulation) cannot possibly
reach its own emulated "ret" instruction final halt state.
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the
direct execution, as you claimed: "the behavior of the directly
executed machine different than the behavior of the correctly
emulated machine description."
Yes so within the assumption that they must be the same
I would be incorrect.
I proved that the assumption is false
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed than that. >>>>
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1.
Those are your only two possible results: it stops, or it doesn't.
If you get the wrong one, your emulation is broken.
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
*If you don't know how to do this that is OK*
On 8/9/2025 5:01 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 16:50:52 -0500, olcott wrote:
On 8/9/2025 4:45 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 16:38:41 -0500, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:You are the one that claimed:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
Ah so you are dishonest. That is what I expected.
You get the wrong numbers out. It don't get much more flawed >>>>>>>>>> than that.
At this point you are essentially saying that the emulation is >>>>>>>>>>> flawed because everyone knows that "push ebp" really means >>>>>>>>>>> "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>>>
Those are your only two possible results: it stops, or it
doesn't.
If you get the wrong one, your emulation is broken.
WHAT?
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] 6862210000
push 00002162 // push DD [0000216b] e862f4ffff call 000015d2 >>>>>>> //
call HHH [00002170] 83c404 add esp,+04 [00002173] >>>>>>> 8945fc mov [ebp-04],eax [00002176] 837dfc00 cmp
dword [ebp-04],+00 [0000217a] 7402 jz 0000217e >>>>>>> [0000217c] ebfe jmp 0000217c [0000217e] 8b45fc
mov eax,[ebp-04] [00002181] 8be5 mov esp,ebp [00002183]
5d pop ebp [00002184] c3 ret Size in
bytes:(0035) [00002184]
You have to go through the above code line-by-line knowing that
each time HHH is called it creates a separate process context to >>>>>>> emulate an instance of DD and then emulate an instance of itself >>>>>>> emulating DD when DD calls HHH(DD).
Within this you must show exactly how the original emulated DD
reaches past its own machine address of [0000216b].
Why?
Haven't you already done it?
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
> you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
I now believe that you are dishonest because I have been through
this same thing before many times.
Claims that I am wrong, request to point out the exact error and no
error is ever pointed out.
There is a flaw in your work of 22 years though, a fundamental one:
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
You are one of the smartest ones here you may be able to understand my
complete proof.
We cannot get to that key second step of the proof until it is first
understood that DD emulated by HHH according to the semantics of the
x86 language (the ultimate measure of correct simulation) cannot
possibly reach its own emulated "ret" instruction final halt state.
If H(D,D) returns non-halting then D(D) must also never halt,
When you fully understand the subject matter of this thread you will understand that assumption is false.
On 8/9/2025 5:25 PM, Richard Heathfield wrote:
On 09/08/2025 23:09, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
<snip>
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated
machine description."
Yes so within the assumption that they must be the same
That's not an assumption. That's a pre-condition.
I would be incorrect.
Yup. You nailed it there.
I proved that the assumption is false
No, you proved that your code is screwed.
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
I didn't even have to look. You already found the problem.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
The proof that you're wrong is that you get a different answer to the
direct execution.
It may seem that way until you bother to pay enough attention.
The semantics of the x86 language overrules anything that
disagrees.
Is the real issue that you don't even have a slight clue
about semantics of the x86 language ?
On 8/9/2025 5:45 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 17:12:54 -0500, olcott wrote:
On 8/9/2025 5:01 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 16:50:52 -0500, olcott wrote:
On 8/9/2025 4:45 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 16:38:41 -0500, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:You are the one that claimed:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
Ah so you are dishonest. That is what I expected.
You get the wrong numbers out. It don't get much more flawed >>>>>>>>>>>> than that.
At this point you are essentially saying that the emulation is >>>>>>>>>>>>> flawed because everyone knows that "push ebp" really means >>>>>>>>>>>>> "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>>>>>
Those are your only two possible results: it stops, or it >>>>>>>>>>>> doesn't.
If you get the wrong one, your emulation is broken.
WHAT?
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] 6862210000
push 00002162 // push DD [0000216b] e862f4ffff call 000015d2 >>>>>>>>> //
call HHH [00002170] 83c404 add esp,+04 [00002173] >>>>>>>>> 8945fc mov [ebp-04],eax [00002176] 837dfc00 cmp
dword [ebp-04],+00 [0000217a] 7402 jz 0000217e >>>>>>>>> [0000217c] ebfe jmp 0000217c [0000217e] 8b45fc >>>>>>>>> mov eax,[ebp-04] [00002181] 8be5 mov esp,ebp [00002183]
5d pop ebp [00002184] c3 ret Size in
bytes:(0035) [00002184]
You have to go through the above code line-by-line knowing that >>>>>>>>> each time HHH is called it creates a separate process context to >>>>>>>>> emulate an instance of DD and then emulate an instance of itself >>>>>>>>> emulating DD when DD calls HHH(DD).
Within this you must show exactly how the original emulated DD >>>>>>>>> reaches past its own machine address of [0000216b].
Why?
Haven't you already done it?
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
> you will have proved that emulation is a flawed technique, >>>>>>>
So it is up to you to point out the exact flaw.
I now believe that you are dishonest because I have been through >>>>>>> this same thing before many times.
Claims that I am wrong, request to point out the exact error and no >>>>>>> error is ever pointed out.
There is a flaw in your work of 22 years though, a fundamental one: >>>>>>
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
You are one of the smartest ones here you may be able to understand my >>>>> complete proof.
We cannot get to that key second step of the proof until it is first >>>>> understood that DD emulated by HHH according to the semantics of the >>>>> x86 language (the ultimate measure of correct simulation) cannot
possibly reach its own emulated "ret" instruction final halt state.
If H(D,D) returns non-halting then D(D) must also never halt,
When you fully understand the subject matter of this thread you will
understand that assumption is false.
You don't know what you are talking about.
/Flibble
It would sure seem that way on the basis
of not fully understanding what I am saying.
I came up with the term "ignorance squared"
30 years ago to account for the case that
someone does not know that they do not know.
Until you bother to put in the effort to understand
that the behavior of DD correctly simulated by HHH
is different than the behavior of the directly executed
DD() you will not be able to begin to understand the
next step of my proof.
On 8/9/2025 5:41 PM, dbush wrote:
On 8/9/2025 6:38 PM, olcott wrote:
On 8/9/2025 5:22 PM, dbush wrote:
On 8/9/2025 6:09 PM, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed >>>>>>>>>>>> than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>>>>>
Those are your only two possible results: it stops, or it >>>>>>>>>>>> doesn't. If you get the wrong one, your emulation is broken. >>>>>>>>>>>>
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
You are the one that claimed:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated
machine description."
Yes so within the assumption that they must be the same
I would be incorrect.
I proved that the assumption is false on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
And since the halting problem is about direct execution:
And the notion of computable functions disagrees.
False, because the halting function is not a computable function:
The issue is the false assumption that the direct
execution of a Turing machine must have identical
behavior to the correct simulation of the machine
description correctly simulated by its simulating
halt decider.
If anyone in the last 89 years ever noticed that
then they would have never said that a halt decider
must report on the behavior of an element outside
of the domain of Turing machines.
Try and respond with reasoning instead of dogma
if you have any actual reasoning.
You are like this:
"textbooks are the infallible word of God therefore
anyone that disagrees is necessarily incorrect"
On 8/9/2025 5:25 PM, Richard Heathfield wrote:
On 09/08/2025 23:09, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
<snip>
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the
direct execution, as you claimed: "the behavior of the
directly executed machine different than the behavior of the
correctly emulated machine description."
Yes so within the assumption that they must be the same
That's not an assumption. That's a pre-condition.
I would be incorrect.
Yup. You nailed it there.
I proved that the assumption is false
No, you proved that your code is screwed.
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
I didn't even have to look. You already found the problem.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
The proof that you're wrong is that you get a different answer
to the direct execution.
It may seem that way
until you bother to pay enough attention.
The semantics of the x86 language overrules anything that
disagrees.
Is the real issue that you don't even have a slight clue
about semantics of the x86 language ?
On 8/9/2025 5:50 PM, dbush wrote:
On 8/9/2025 6:49 PM, olcott wrote:
On 8/9/2025 5:41 PM, dbush wrote:
On 8/9/2025 6:38 PM, olcott wrote:
On 8/9/2025 5:22 PM, dbush wrote:
On 8/9/2025 6:09 PM, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more >>>>>>>>>>>>>> flawed than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 ! >>>>>>>>>>>>>> = 1.
Those are your only two possible results: it stops, or it >>>>>>>>>>>>>> doesn't. If you get the wrong one, your emulation is broken. >>>>>>>>>>>>>>
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
You are the one that claimed:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique, >>>>>>>>>So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the
direct execution, as you claimed: "the behavior of the directly >>>>>>>> executed machine different than the behavior of the correctly
emulated machine description."
Yes so within the assumption that they must be the same
I would be incorrect.
I proved that the assumption is false on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
And since the halting problem is about direct execution:
And the notion of computable functions disagrees.
False, because the halting function is not a computable function:
The issue is the false assumption that the direct
execution of a Turing machine must have identical
behavior to the correct simulation of the machine
description correctly simulated by its simulating
halt decider.
In other words, you're saying there exists an X such that the direct
execution of X() and UTM(X) are different.
Show it.
*I am not saying exactly that*
Ĥ.embedded_H is based on a UTM that simulates
a finite number of moves.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
On 8/9/2025 5:22 PM, dbush wrote:
On 8/9/2025 6:09 PM, olcott wrote:And the notion of computable functions disagrees.
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:Yes so within the assumption that they must be the same I would be
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:You are the one that claimed:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
Ah so you are dishonest. That is what I expected.
You get the wrong numbers out. It don't get much more flawed >>>>>>>>>> than that.
At this point you are essentially saying that the emulation is >>>>>>>>>>> flawed because everyone knows that "push ebp" really means >>>>>>>>>>> "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>>>
Those are your only two possible results: it stops, or it
doesn't. If you get the wrong one, your emulation is broken. >>>>>>>>>>
WHAT?
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] >>>>>>> 6862210000 push 00002162 // push DD [0000216b] e862f4ffff
call 000015d2 // call HHH [00002170] 83c404 add esp,+04 >>>>>>> [00002173] 8945fc mov [ebp-04],eax [00002176]
837dfc00 cmp dword [ebp-04],+00 [0000217a] 7402 jz
0000217e [0000217c] ebfe jmp 0000217c [0000217e] >>>>>>> 8b45fc mov eax,[ebp-04] [00002181] 8be5 mov
esp,ebp [00002183] 5d pop ebp [00002184] >>>>>>> c3 ret Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line knowing that
each time HHH is called it creates a separate process context to >>>>>>> emulate an instance of DD and then emulate an instance of itself >>>>>>> emulating DD when DD calls HHH(DD).
Within this you must show exactly how the original emulated DD
reaches past its own machine address of [0000216b].
Why?
Haven't you already done it?
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated machine
description."
incorrect.
I proved that the assumption is false on the basis of the ultimate
measure of correct simulation (the semantics of the x86 language) and
you failed to find any error.
And since the halting problem is about direct execution:
Until you bother to put in the effort to understand that the behavior of
DD correctly simulated by HHH is different than the behavior of the
directly executed DD() you will not be able to begin to understand the
next step of my proof.
On 8/9/2025 5:22 PM, dbush wrote:
On 8/9/2025 6:09 PM, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
You get the wrong numbers out. It don't get much more flawed >>>>>>>>>> than that.
At this point you are essentially saying that
the emulation is flawed because everyone knows
that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that 0 != 1. >>>>>>>>>>
Those are your only two possible results: it stops, or it
doesn't. If you get the wrong one, your emulation is broken. >>>>>>>>>>
Ah so you are dishonest. That is what I expected.
WHAT?
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
You are the one that claimed:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique,
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated
machine description."
Yes so within the assumption that they must be the same
I would be incorrect.
I proved that the assumption is false on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
And since the halting problem is about direct execution:
And the notion of computable functions disagrees.
Until you bother to put in the effort to understand
that the behavior of DD correctly simulated by HHH
is different than the behavior of the directly executed
DD() you will not be able to begin to understand the
next step of my proof.
On 8/9/2025 5:44 PM, dbush wrote:
On 8/9/2025 6:42 PM, olcott wrote:
On 8/9/2025 5:25 PM, Richard Heathfield wrote:
On 09/08/2025 23:09, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
<snip>
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated
machine description."
Yes so within the assumption that they must be the same
That's not an assumption. That's a pre-condition.
I would be incorrect.
Yup. You nailed it there.
I proved that the assumption is false
No, you proved that your code is screwed.
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
I didn't even have to look. You already found the problem.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
The proof that you're wrong is that you get a different answer to
the direct execution.
It may seem that way until you bother to pay enough attention.
The semantics of the x86 language overrules anything that
disagrees.
And the semantics of the x86 language say that when DD is actually run
on an actual x86 processor or simulated correctly by UTM that it will
halt.
When DD is run without pathological self-reference
then its behavior will be different than when it is
correctly simulated with pathological self-reference.
If DD called main() instead of HHH then it would
exhibit the same sort of non-halting behavior.
I just tested this. I am correct.
On 8/9/2025 5:59 PM, dbush wrote:
On 8/9/2025 6:57 PM, olcott wrote:
On 8/9/2025 5:44 PM, dbush wrote:
On 8/9/2025 6:42 PM, olcott wrote:
On 8/9/2025 5:25 PM, Richard Heathfield wrote:
On 09/08/2025 23:09, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
<snip>
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the
direct execution, as you claimed: "the behavior of the directly >>>>>>>> executed machine different than the behavior of the correctly
emulated machine description."
Yes so within the assumption that they must be the same
That's not an assumption. That's a pre-condition.
I would be incorrect.
Yup. You nailed it there.
I proved that the assumption is false
No, you proved that your code is screwed.
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
I didn't even have to look. You already found the problem.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
The proof that you're wrong is that you get a different answer to
the direct execution.
It may seem that way until you bother to pay enough attention.
The semantics of the x86 language overrules anything that
disagrees.
And the semantics of the x86 language say that when DD is actually
run on an actual x86 processor or simulated correctly by UTM that it
will halt.
When DD is run without pathological self-reference
then its behavior will be different than when it is
correctly simulated with pathological self-reference.
You only think that because you change the input.
Changing the input is not allowed.
I am not changing the input.
I am simultaneously evaluating infinite sets of cases.
All of those cases where simulating termination analyzer
H correctly simulates input D that calls H(D) ...
On 8/9/2025 6:03 PM, Richard Heathfield wrote:
On 09/08/2025 23:38, olcott wrote:
Until you bother to put in the effort to understand
that the behavior of DD correctly simulated by HHH
is different than the behavior of the directly executed
DD() you will not be able to begin to understand the
next step of my proof.
Since your prerequisite is manifestly absurd, I don't see anyone
understanding your proof any time soon.
I will be generous and take this to mean that
you do not understand the x86 language at all.
These three LLM systems figured out that the input to
HHH(DD) matches the
*recursive simulation non-halting behavior pattern*
at the C level all on their own without being prompted.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/9/2025 6:08 PM, Richard Heathfield wrote:
On 09/08/2025 23:42, olcott wrote:
On 8/9/2025 5:25 PM, Richard Heathfield wrote:
On 09/08/2025 23:09, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
<snip>
So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the direct
execution, as you claimed: "the behavior of the directly executed
machine different than the behavior of the correctly emulated
machine description."
Yes so within the assumption that they must be the same
That's not an assumption. That's a pre-condition.
I would be incorrect.
Yup. You nailed it there.
I proved that the assumption is false
No, you proved that your code is screwed.
on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
I didn't even have to look. You already found the problem.
If "push ebp" really means "jmp 00002184" then this
would prove that I am wrong.
The proof that you're wrong is that you get a different answer to
the direct execution.
It may seem that way
Indeed it does.
until you bother to pay enough attention.
I paid enough attention to notice when you announced that your
simulation code has a bug.
The semantics of the x86 language overrules anything that
disagrees.
When you have a bug, that isn't the semantics of any language
overruling anything. It's just your code that's screwed.
Is the real issue that you don't even have a slight clue
about semantics of the x86 language ?
Neither do you, clearly, if you're confusing "semantic" with "bug-
ridden".
If the code had a bug then it could be specifically
pointed out. That you did not do this seems to prove
that you know there is no bug.
On 8/9/2025 6:12 PM, dbush wrote:
On 8/9/2025 7:03 PM, Richard Heathfield wrote:Everything that I said prior to one week ago has
On 09/08/2025 23:38, olcott wrote:
Until you bother to put in the effort to understand
that the behavior of DD correctly simulated by HHH
is different than the behavior of the directly executed
DD() you will not be able to begin to understand the
next step of my proof.
Since your prerequisite is manifestly absurd, I don't see anyone
understanding your proof any time soon.
He has admitted in the past
been deprecated.
On 8/9/2025 6:08 PM, dbush wrote:
On 8/9/2025 7:05 PM, olcott wrote:
On 8/9/2025 5:50 PM, dbush wrote:
On 8/9/2025 6:49 PM, olcott wrote:
On 8/9/2025 5:41 PM, dbush wrote:
On 8/9/2025 6:38 PM, olcott wrote:
On 8/9/2025 5:22 PM, dbush wrote:
On 8/9/2025 6:09 PM, olcott wrote:
On 8/9/2025 5:00 PM, Richard Heathfield wrote:
On 09/08/2025 22:38, olcott wrote:
On 8/9/2025 4:26 PM, Richard Heathfield wrote:
On 09/08/2025 22:22, olcott wrote:
On 8/9/2025 4:12 PM, Richard Heathfield wrote:
On 09/08/2025 21:46, olcott wrote:_DD()
On 8/9/2025 3:41 PM, Richard Heathfield wrote:
<snip>
WHAT?
You get the wrong numbers out. It don't get much more >>>>>>>>>>>>>>>> flawed than that.
At this point you are essentially saying that >>>>>>>>>>>>>>>>> the emulation is flawed because everyone knows >>>>>>>>>>>>>>>>> that "push ebp" really means "jmp 00002155".
No, I'm saying it's flawed because everyone knows that >>>>>>>>>>>>>>>> 0 ! = 1.
Those are your only two possible results: it stops, or >>>>>>>>>>>>>>>> it doesn't. If you get the wrong one, your emulation is >>>>>>>>>>>>>>>> broken.
Ah so you are dishonest. That is what I expected. >>>>>>>>>>>>>>
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD >>>>>>>>>>>>> [0000216b] e862f4ffff call 000015d2 // call HHH >>>>>>>>>>>>> [00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00 >>>>>>>>>>>>> [0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You have to go through the above code line-by-line
knowing that each time HHH is called it creates a
separate process context to emulate an instance of
DD and then emulate an instance of itself emulating
DD when DD calls HHH(DD).
Within this you must show exactly how the original
emulated DD reaches past its own machine address of
[0000216b].
Why?
Haven't you already done it?
You are the one that claimed:
On 8/9/2025 2:30 PM, Richard Heathfield wrote:
you will have proved that emulation is a flawed technique, >>>>>>>>>>>So it is up to you to point out the exact flaw.
Oh, I see.
The exact flaw is that you get a different result from the >>>>>>>>>> direct execution, as you claimed: "the behavior of the
directly executed machine different than the behavior of the >>>>>>>>>> correctly emulated machine description."
Yes so within the assumption that they must be the same
I would be incorrect.
I proved that the assumption is false on the basis of
the ultimate measure of correct simulation (the semantics
of the x86 language) and you failed to find any error.
And since the halting problem is about direct execution:
And the notion of computable functions disagrees.
False, because the halting function is not a computable function:
The issue is the false assumption that the direct
execution of a Turing machine must have identical
behavior to the correct simulation of the machine
description correctly simulated by its simulating
halt decider.
In other words, you're saying there exists an X such that the direct
execution of X() and UTM(X) are different.
Show it.
*I am not saying exactly that*
Ĥ.embedded_H is based on a UTM that simulates
a finite number of moves.
So it's not a UTM, and therefore is not definitive about the behavior
of the input.
Until it stops simulating the behavior of the
simulated input is identical to that simulated
by a UTM because Ĥ.embedded_H is based on a UTM.
That you refuse to understand the
*recursive simulation non-halting behavior pattern*
makes all of your rebuttals baseless.
On 8/9/2025 6:41 PM, dbush wrote:
On 8/9/2025 7:25 PM, olcott wrote:>>
Until it stops simulating the behavior of the
simulated input is identical to that simulated
by a UTM because Ĥ.embedded_H is based on a UTM.
And because it stops its simulation is non definitive.
That you refuse to understand the
*recursive simulation non-halting behavior pattern*
makes all of your rebuttals baseless.
That the pattern exists in the halting program DDD means it is not a
non-halting pattern.
Three LLM systems figured this pattern out on their
own without prompting.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/9/2025 6:41 PM, dbush wrote:eedd0f09e141
On 8/9/2025 7:25 PM, olcott wrote:>>
Until it stops simulating the behavior of the simulated input is
identical to that simulated by a UTM because Ĥ.embedded_H is based on
a UTM.
And because it stops its simulation is non definitive.
That you refuse to understand the *recursive simulation non-haltingThat the pattern exists in the halting program DDD means it is not a
behavior pattern*
makes all of your rebuttals baseless.
non-halting pattern.
Three LLM systems figured this pattern out on their own without
prompting.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
On 8/9/2025 6:53 PM, Mr Flibble wrote:
On Sat, 09 Aug 2025 18:48:51 -0500, olcott wrote:
On 8/9/2025 6:41 PM, dbush wrote:eedd0f09e141
On 8/9/2025 7:25 PM, olcott wrote:>>
Until it stops simulating the behavior of the simulated input is
identical to that simulated by a UTM because Ĥ.embedded_H is based on >>>>> a UTM.
And because it stops its simulation is non definitive.
That you refuse to understand the *recursive simulation non-haltingThat the pattern exists in the halting program DDD means it is not a
behavior pattern*
makes all of your rebuttals baseless.
non-halting pattern.
Three LLM systems figured this pattern out on their own without
prompting.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
https://grok.com/share/bGVnYWN5_d28b35c2-58c6-4596-8e92-06546f175e93
"HHH(DD) correctly returns 0 per its specification (detecting non-
terminating simulation behavior), but this shows HHH is not a correct
halt
decider, as DD halts, aligning with the halting problem's
undecidability."
/Flibble
Great like I said you do seem to be the smartest one here.
I will wait until a few others see the light about this
before I address your very important point.
On 8/9/2025 6:08 PM, Richard Heathfield wrote:<snip>
On 09/08/2025 23:42, olcott wrote:
Is the real issue that you don't even have a slight clue
about semantics of the x86 language ?
Neither do you, clearly, if you're confusing "semantic" with
"bug-ridden".
If the code had a bug then it could be specifically
pointed out.
That you did not do this seems to prove
that you know there is no bug.
On 8/9/2025 9:46 PM, Richard Heathfield wrote:
On 10/08/2025 00:23, olcott wrote:
If the code had a bug then it could be specifically
pointed out.
You specifically pointed out that the code had a bug when you
specifically pointed out that the code produces the wrong result.
So you are not very good at coding?
On 8/10/2025 12:49 AM, Richard Heathfield wrote:
On 10/08/2025 05:27, olcott wrote:
On 8/9/2025 9:46 PM, Richard Heathfield wrote:
On 10/08/2025 00:23, olcott wrote:
<snip>
If the code had a bug then it could be specifically
pointed out.
You specifically pointed out that the code had a bug when you
specifically pointed out that the code produces the wrong
result.
So you are not very good at coding?
I'm not the one with the bug.
Because you could not point to any specific
error
I formed the conclusion that you might
not have a software engineering level of
understanding of what a bug is.
On 8/9/2025 9:46 PM, Richard Heathfield wrote:
On 10/08/2025 00:23, olcott wrote:
On 8/9/2025 6:08 PM, Richard Heathfield wrote:<snip>
On 09/08/2025 23:42, olcott wrote:
Is the real issue that you don't even have a slight clue
about semantics of the x86 language ?
Neither do you, clearly, if you're confusing "semantic" with "bug-
ridden".
If the code had a bug then it could be specifically
pointed out.
You specifically pointed out that the code had a bug when you
specifically pointed out that the code produces the wrong result.
So you are not very good at coding?
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
That you did not do this seems to prove
that you know there is no bug.
You said there was a bug. When you call your own code into question,
I'm inclined to believe you.
On 8/10/2025 12:49 AM, Richard Heathfield wrote:
On 10/08/2025 05:27, olcott wrote:
On 8/9/2025 9:46 PM, Richard Heathfield wrote:
On 10/08/2025 00:23, olcott wrote:
<snip>
If the code had a bug then it could be specifically
pointed out.
You specifically pointed out that the code had a bug when you
specifically pointed out that the code produces the wrong result.
So you are not very good at coding?
I'm not the one with the bug.
Because you could not point to any specific
error I formed the conclusion that you might
not have a software engineering level of
understanding of what a bug is.
fixing any bugs
won't solve the basic problem.
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the real issue; if anything it's
a distraction. The real issue is what happens after HHH has made its decision and returned.
On 8/10/2025 8:00 PM, Mike Terry wrote:
On 11/08/2025 00:28, Richard Heathfield wrote:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the real issue; if anything
it's a distraction. The real issue is what happens after HHH has made its decision and returned.
Right. In terms of a concrete bug, PO's "infinite recursive emulation" test is what leads
directly to HHH's incorrect halting decision.
It has never been incorrect for at least three years
when the measure of the behavior of the input to HHH(DD)
is DD correctly emulated by HHH.
I cannot ever explain why this is the correct measure and
all other measures are incorrect because I keep getting
stonewalled on the above point.
You yourself said that DD correctly emulated by HHH
would halt on its own if we just wait long enough.
<..snip chatbot details..>So this is the bug. Fixes include completely deleting the test, or alternatively replacing it
with something that only matches /infinite/ recursive emulation. [Not sure whether that could
even be achieved in any useful fashion?! For sure PO isn't going to do it.] >>
The effect of all such fixes would be the same - fixed HHH will not detect any non-halting
patterns in its new DD, and so neither HHH nor DD will ever halt. This is no use for PO, but is
what all (partial)SHDs inevitably end up doing when analysing their 'impossible input'. The fixed
test might correctly detect non-halting in other inputs, so could be worthwhile, but not when it
comes to analysing DD.
At least it would mean fixed HHH matches the code description PO keeps quoting and asking about!
If a claimed PSHD /does/ match a halting/non- halting pattern when analysing its impossible input,
as with PO's HHH, that indicates a bug.
Mike.
Three different LLM systems
On 8/10/2025 8:00 PM, Mike Terry wrote:
On 11/08/2025 00:28, Richard Heathfield wrote:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't
the real issue; if anything it's a distraction. The real issue is
what happens after HHH has made its decision and returned.
Right. In terms of a concrete bug, PO's "infinite recursive
emulation" test is what leads directly to HHH's incorrect halting
decision.
It has never been incorrect for at least three years
when the measure of the behavior of the input to HHH(DD)
is DD correctly emulated by HHH.
I cannot ever explain why this is the correct measure and
all other measures are incorrect because I keep getting
stonewalled on the above point.
You yourself said that DD correctly emulated by HHH
would halt on its own if we just wait long enough.
So this is the bug. Fixes include completely deleting the test, or
alternatively replacing it with something that only matches /infinite/
recursive emulation. [Not sure whether that could even be achieved in
any useful fashion?! For sure PO isn't going to do it.]
The effect of all such fixes would be the same - fixed HHH will not
detect any non-halting patterns in its new DD, and so neither HHH nor
DD will ever halt. This is no use for PO, but is what all
(partial)SHDs inevitably end up doing when analysing their 'impossible
input'. The fixed test might correctly detect non-halting in other
inputs, so could be worthwhile, but not when it comes to analysing DD.
At least it would mean fixed HHH matches the code description PO keeps
quoting and asking about! If a claimed PSHD /does/ match a halting/
non- halting pattern when analysing its impossible input, as with PO's
HHH, that indicates a bug.
Mike.
Three different LLM systems figured out all on their
own that DD correctly simulated by HHH does meet the
*recursive simulation non-halting behavior pattern*
and I gave them no hint that this pattern even exists.
They each also all agreed that HHH(DD)==0 on that basis
and I did not even give them a hint that this is the
value that I expected.
Claude AI proved why HHH(DD)==0 is correct in terms that
any expert C programmer can understand.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/10/2025 9:07 PM, wij wrote:
On Sun, 2025-08-10 at 20:31 -0500, olcott wrote:
On 8/10/2025 8:00 PM, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the >>>>> real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
That is an excellent degree of professionalism.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The x86utm operating system enables one C function HHH
to emulate the x86 machine code of another C function DD
in debug step mode. This also allows HHH to emulate an
instance of itself emulating an instance of DD until
OOM error.
On this basis DD correctly emulated by HHH really cannot
possibly reach its own "return" statement final halt state.
Thus when HHH is reporting on the basis of DD correctly
emulated by HHH then HHH(DD)==0 is correct.
I have no problem with the your 'exact' words (it is tautology, no
meaning).
To be short, you cannot communicate with people if basic logic is
involved.
That "cats" <are> "animals" is a semantic tautology
that provides "cats" and "animals" with one aspect
of their meaning.
I know the philosophical foundations of logic better
than anyone.
https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma
Have you ever heard of that?
It is very easy to refute once you have the correct
philosophical foundations of logic.
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is
therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists in
the program DD that halts, therefore the pattern is not non-halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is
therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists in
the program DD that halts, therefore the pattern is not non-halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
On 8/10/2025 9:47 PM, wij wrote:
On Sun, 2025-08-10 at 21:36 -0500, olcott wrote:
On 8/10/2025 9:27 PM, wij wrote:
On Sun, 2025-08-10 at 21:20 -0500, olcott wrote:
On 8/10/2025 9:07 PM, wij wrote:
On Sun, 2025-08-10 at 20:31 -0500, olcott wrote:
On 8/10/2025 8:00 PM, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate >>>>>>>>> isn't the
real issue; if anything it's a distraction. The real issue is what >>>>>>>>> happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I >>>>>>>> have not analyzed his code.
That is an excellent degree of professionalism.
olcott seems to be claiming that his simulator performs correct >>>>>>>> simulations, while simultaneously acknowledging that it does not. >>>>>>>typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The x86utm operating system enables one C function HHH
to emulate the x86 machine code of another C function DD
in debug step mode. This also allows HHH to emulate an
instance of itself emulating an instance of DD until
OOM error.
On this basis DD correctly emulated by HHH really cannot
possibly reach its own "return" statement final halt state.
Thus when HHH is reporting on the basis of DD correctly
emulated by HHH then HHH(DD)==0 is correct.
I have no problem with the your 'exact' words (it is tautology, no >>>>>> meaning).
To be short, you cannot communicate with people if basic logic is
involved.
That "cats" <are> "animals" is a semantic tautology
that provides "cats" and "animals" with one aspect
of their meaning.
I know the philosophical foundations of logic better
than anyone.
https://en.wikipedia.org/wiki/M%C3%BCnchhausen_trilemma
Have you ever heard of that?
It is very easy to refute once you have the correct
philosophical foundations of logic.
Q1: What time is it? Yes or no.
Q2: Jack is a bachelor. Does Jack hit his wife?
What is the correct answer of Q1,Q2?
I am the originator of those two questions
as my basis for proving that incorrect
questions exist.
Logic qestion Q1,Q2 ask for yes/no, does/does not.
So, what is the correct answer of Q1,Q2? (and why?)
Keep re-reading my prior reply as many times as
it takes to totally understand the meaning of my words.
(Otherwise I will write you off as a bot stuck in rebuttal mode).
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the
real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
He might have a less obviously invalid argument if he stopped
claiming that his "simulator" is really a perfect simulator, or
used a different word than "simulator" to describe it.
He also
makes arguments based on how C code should behave, when he's clearly
writing code that goes beyond what the C standard guarantees; these
arguments would be more nearly valid if he acknowledged that he's
not writing valid C, and defined the characteristics of the C-like
language he's using.
Imagine that you want to create an algorithm that, given a
representation of any procedure/input pair as input, correctly
determines whether the argument represents a halting algorithm
or not. This is obviously easy enough to do in limited cases: `printf("hello\n");` halts, and `while (1){}` doesn't. But you
want to make that determination for all possible inputs. And you
think that the proofs that this is impossible are incorrect.
A correct algorithm cannot work by correctly simulating its input
algorithm to completion. A halt decider must halt and give a correct
result. Correct simulation of a non-halting procedure does not halt.
But an algorithm that performs partial simulation of its input
might conceivably do the job. Suppose you can *start* simulating
the input. If that simulation halts in fewer than some specified
number of steps, you're done. If it doesn't, then maybe the
algorithm can perform some analysis on its input and on how the
simulation has proceeded so far, and reliably determine that the
procedure with the given input will or will not eventually halt.
(This is precisely what has been proven to be impossible.)
This is doable for a subset of inputs: those that halt after some
small number of steps, and those like `while (1){}` whose non-halting
is sufficiently obvious by inspection. One can *imagine* extending
the latter to cover all inputs.
Is this what olcott is trying to do?
If you assert that the simulated procedure can have only a finite
number of states, you can run the simulation for a number of steps
equal to the number of states, and determine whether any state has
repeated (impractical if the number of states is, say, 2**524288
for a system whose current state is represented in 64 kilo-octets
of storage). But the halting problem isn't about finite systems.
On 8/11/2025 10:54 AM, dbush wrote:They don't, as they include HHH. Alternatively, they call different HHHs.
On 8/11/2025 11:52 AM, olcott wrote:
On 8/11/2025 10:45 AM, dbush wrote:
And that one fixed element is not the same as the given algorithm DDYes it is. HHH/DD is one pair of fixed finite strings of the infinite
which consists of the fixed code of the function DD, the fixed code
of the function HHH, and the fixed code of everything HHH calls down
to the OS level.
set. The machine code bytes of DD remain the same across every element
of this infinite set.
False, as algorithm DD consists of the fixed code of the function DD,For each element of the infinite set of HHH/DD pairs.
the fixed code of the function HHH, and the fixed code of everything
HHH calls down to the OS level.
*Forbids the complete simulation of a non-terminating input*
On 11/08/2025 02:00, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the
real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
He might have a less obviously invalid argument if he stopped
claiming that his "simulator" is really a perfect simulator, or
used a different word than "simulator" to describe it.
PO and everybody else here knows that PO's simulation is only a /partial/ simulation. When PO
claims his simulation is correct, he could be claiming one of two things:
a) his partial simulation correctly simulates each instruction it simulates.
b) As for (a), but additionally that the subsequent halt decision by
the decider is correct.
Not sure which of these PO thinks is entailed by the phrase "correct simulation", but its obvious he
is NOT claiming his simulations are complete. His halt decider may abandon its (partial) simulation
activity at any time and do something else like return its halt decision. This is what posters here
mean by the decider "aborting" the simulation.
I don't recall PO acknowledging that his deciders do NOT perform correct simulations - that's
something that some posters here may say. They could mean:
a) some instruction is simulated but with incorrect outcome (e.g. registers not set correctly)
b) instructions were simulated OK, but the decider stopped simulating before the simulation
halted. (PO never has always made clear his simulations are partial!)
c) instructions were simulated correctly, but then the decider returned the wrong halting
status. (Is that the /simulation/ that was wrong or the /decider/? People have
different usages for the terminology.)
Posters may say PO acknowledges his simulation is incorrect, but really they're saying that /they/
have inferred (a) or (b) or (c) above from something PO said.
He also
makes arguments based on how C code should behave, when he's clearly
writing code that goes beyond what the C standard guarantees; these
arguments would be more nearly valid if he acknowledged that he's
not writing valid C, and defined the characteristics of the C-like
language he's using.
Fair point. In the distant past I think he has said his C code is just for the MSVC (2017?) C
compiler, but that gets forgotten. His work is nothing really to do with C, and he might just as
well have used Fortran or something else, as long as there's a repeatable process to turn that into
a COFF file he can feed to his x86utm.exe. (x86utm isn't C specific, although it was written to
work for one specific case: his halt7.obj file built by MSVC. His claims are not really about C,
but about the halting problem, although his demo code is "C based".)
Imagine that you want to create an algorithm that, given a
representation of any procedure/input pair as input, correctly
determines whether the argument represents a halting algorithm
or not. This is obviously easy enough to do in limited cases:
`printf("hello\n");` halts, and `while (1){}` doesn't. But you
want to make that determination for all possible inputs. And you
think that the proofs that this is impossible are incorrect.
A correct algorithm cannot work by correctly simulating its input
algorithm to completion. A halt decider must halt and give a correct
result. Correct simulation of a non-halting procedure does not halt.
Ah, I see you are in the (b) camp above! :) PO has never claimed he simulates too completion. His
code's halting decisions are based on a combination of simulation and (simulation trace) analysis.
But an algorithm that performs partial simulation of its input
might conceivably do the job. Suppose you can *start* simulating
the input. If that simulation halts in fewer than some specified
number of steps, you're done. If it doesn't, then maybe the
algorithm can perform some analysis on its input and on how the
simulation has proceeded so far, and reliably determine that the
procedure with the given input will or will not eventually halt.
(This is precisely what has been proven to be impossible.)
This is doable for a subset of inputs: those that halt after some
small number of steps, and those like `while (1){}` whose non-halting
is sufficiently obvious by inspection. One can *imagine* extending
the latter to cover all inputs.
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the one input he needs, but
it decides incorrectly, saying that it never halts when in fact the input is easily seen to halt.
[His so-called "non-termination pattern" matches, even though the computation being simulated halts.
So his decider aborts the simulation and incorrectly returns 0 [never halts].]
Mike.
(Right.)
If you assert that the simulated procedure can have only a finite
number of states, you can run the simulation for a number of steps
equal to the number of states, and determine whether any state has
repeated (impractical if the number of states is, say, 2**524288
for a system whose current state is represented in 64 kilo-octets
of storage). But the halting problem isn't about finite systems.
Mike.
On 8/11/2025 12:21 PM, Richard Heathfield wrote:
On 11/08/2025 17:58, olcott wrote:
<snip>
*Forbids the complete simulation of a non-terminating input*
It's not forbidden. It's just not possible. There's a difference.
<snip>
It is ridiculously stupid to require a simulating
termination analyzer to simulate a non-terminating
input to its non-existent completion.
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is
therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
That you cannot possibly point out any specific mistake
seems to prove that there is none.
All of the most honest rebuttals have never been anchored
in anything more than: "I just don't believe it".
Then there are the dishonest reviews that disagree
with verified facts.
On 8/11/2025 6:53 AM, dbush wrote:
On 8/10/2025 11:20 PM, olcott wrote:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and
is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists in
the program DD that halts, therefore the pattern is not non-halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
The point at which HHH aborts is where the incorrect emulation occurs,
as that means the last instruction to be emulated wasn't emulated
correctly because the following instruction wasn't emulated as per the
x86 language.
According to the x86 language, part of the execution of any
instruction other than a terminal instruction such as HLT is executing
the next instruction.
This also means that the correct emulation of a non-halting program is
also non-halting, however a halt decider / termination analyzer must
still make a decision so it must predict was the correct emulation,
i.e. that done by UTM, will do.
The correct emulation of DD, i.e. UTM(DD), halts, so HHH(DD)==0 is wrong.
Counter-factual.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
Generically HHH(DD) specifies
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)...
Cannot possibly terminate normally
On 8/11/2025 10:08 AM, dbush wrote:
On 8/11/2025 11:06 AM, olcott wrote:
On 8/11/2025 10:03 AM, dbush wrote:
On 8/11/2025 10:18 AM, olcott wrote:
On 8/11/2025 6:53 AM, dbush wrote:
On 8/10/2025 11:20 PM, olcott wrote:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting exists >>>>>>>> in the program DD that halts, therefore the pattern is not non- >>>>>>>> halting.
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts >>>>>>>>>> and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. >>>>>>>>
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
The point at which HHH aborts is where the incorrect emulation
occurs, as that means the last instruction to be emulated wasn't
emulated correctly because the following instruction wasn't
emulated as per the x86 language.
According to the x86 language, part of the execution of any
instruction other than a terminal instruction such as HLT is
executing the next instruction.
This also means that the correct emulation of a non-halting
program is also non-halting, however a halt decider / termination
analyzer must still make a decision so it must predict was the
correct emulation, i.e. that done by UTM, will do.
The correct emulation of DD, i.e. UTM(DD), halts, so HHH(DD)==0 is >>>>>> wrong.
Counter-factual.
Simulating Termination Analyzer HHH correctly simulates its input
until:
In other words, it doesn't correctly simulate.
No attempt at rebuttal, therefore you agree (again) that HHH does not
correctly simulate DD.
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
Generically HHH(DD) specifies
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)
HHH simulates DD then DD calls HHH(DD)...
Cannot possibly terminate normally
Strawman, as that isn't what what HHH does.
That is what the generic HHH defined above does.
So in other words, you're changing the input.
Changing the input is not allowed.
Not at all.
I am showing the exact behavior of one element
of the infinite set of implementations of the
above defined generic HHH.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
On 8/11/2025 12:21 PM, Richard Heathfield wrote:
On 11/08/2025 17:58, olcott wrote:
<snip>
*Forbids the complete simulation of a non-terminating input*
It's not forbidden. It's just not possible. There's a difference.
<snip>
It is ridiculously stupid to require a simulating
termination analyzer to simulate a non-terminating
input to its non-existent completion.
Everyone that says it should is is ridiculously stupid
on this one point.
On 8/11/2025 11:30 AM, Mike Terry wrote:
On 11/08/2025 02:00, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the >>>> real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
He might have a less obviously invalid argument if he stopped
claiming that his "simulator" is really a perfect simulator, or
used a different word than "simulator" to describe it.
PO and everybody else here knows that PO's simulation is only a /
partial/ simulation. When PO claims his simulation is correct, he
could be claiming one of two things:
a) his partial simulation correctly simulates each instruction it
simulates.
b) As for (a), but additionally that the subsequent halt decision by
the decider is correct.
Not sure which of these PO thinks is entailed by the phrase "correct
simulation", but its obvious he is NOT claiming his simulations are
complete.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*Forbids the complete simulation of a non-terminating input*
His halt decider may abandon its (partial) simulation activity at any
time and do something else like return its halt decision. This is
what posters here mean by the decider "aborting" the simulation.
I don't recall PO acknowledging that his deciders do NOT perform
correct simulations - that's something that some posters here may
say. They could mean:
a) some instruction is simulated but with incorrect outcome (e.g.
registers not set correctly)
b) instructions were simulated OK, but the decider stopped simulating
before the simulation
halted. (PO never has always made clear his simulations are
partial!)
Counter factual since 2022
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D *until H correctly determines that its simulated D*
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I changed the above spec to be more consistent with conventional
notions.
[When] simulating halt decider H correctly simulates its
input D until H correctly determines that [D simulated by H
cannot possibly reach its own simulated final halt state] then
c) instructions were simulated correctly, but then the decider
returned the wrong halting
status. (Is that the /simulation/ that was wrong or the /
decider/? People have
different usages for the terminology.)
Posters may say PO acknowledges his simulation is incorrect, but
really they're saying that /they/ have inferred (a) or (b) or (c)
above from something PO said.
I never in anyway acknowledged that the simulation is incorrect.
He also
makes arguments based on how C code should behave, when he's clearly
writing code that goes beyond what the C standard guarantees; these
arguments would be more nearly valid if he acknowledged that he's
not writing valid C, and defined the characteristics of the C-like
language he's using.
Fair point. In the distant past I think he has said his C code is
just for the MSVC (2017?) C compiler, but that gets forgotten. His
work is nothing really to do with C, and he might just as well have
used Fortran or something else, as long as there's a repeatable
process to turn that into a COFF file he can feed to his x86utm.exe.
(x86utm isn't C specific, although it was written to work for one
specific case: his halt7.obj file built by MSVC. His claims are not
really about C, but about the halting problem, although his demo code
is "C based".)
It is directly about C code within the context that
the x86utm operating system provides the basis for
any C function to emulate the x86 machine language
instructions of any other C function in debug step
mode.
Since the purpose of compilers is to translate the
C code into semantically equivalent x86 code when
DD is correctly emulated by HHH this is equivalent
to DD being correctly simulated by a C language
interpreter.
Imagine that you want to create an algorithm that, given a
representation of any procedure/input pair as input, correctly
determines whether the argument represents a halting algorithm
or not. This is obviously easy enough to do in limited cases:
`printf("hello\n");` halts, and `while (1){}` doesn't. But you
want to make that determination for all possible inputs. And you
think that the proofs that this is impossible are incorrect.
A correct algorithm cannot work by correctly simulating its input
algorithm to completion. A halt decider must halt and give a correct
result. Correct simulation of a non-halting procedure does not halt.
Ah, I see you are in the (b) camp above! :) PO has never claimed he
simulates too completion. His code's halting decisions are based on a
combination of simulation and (simulation trace) analysis.
Yes.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
But an algorithm that performs partial simulation of its input
might conceivably do the job. Suppose you can *start* simulating
the input. If that simulation halts in fewer than some specified
number of steps, you're done. If it doesn't, then maybe the
algorithm can perform some analysis on its input and on how the
simulation has proceeded so far, and reliably determine that the
procedure with the given input will or will not eventually halt.
(This is precisely what has been proven to be impossible.)
This is doable for a subset of inputs: those that halt after some
small number of steps, and those like `while (1){}` whose non-halting
is sufficiently obvious by inspection. One can *imagine* extending
the latter to cover all inputs.
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns >> 0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
Yes.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
Yes.
To cut a long story short, it turns out that his decider /does/ decide
the one input he needs, but it decides incorrectly, saying that it
never halts when in fact the input is easily seen to halt.
HHH(DD) does decide correctly when the basis is DD
correctly simulated by HHH.
It is impossible to understand that every other basis
is incorrect until after one first understand that this
basis is correct.
That you said that DD correctly simulated by HHH would
eventually halt with no abort simulation ever needed
proves that you still do not have a correct understanding.
Because you did such an excellent job on everything else
your lack of understanding of this seems like a master auto
mechanic that has never heard of spark plugs and on the
basis that they never heard of them does not believe that
they exist.
Not a good guy to employ for a tune-up.
[His so-called "non-termination pattern" matches, even though the
computation being simulated halts. So his decider aborts the
simulation and incorrectly returns 0 [never halts].]
Mike.
(Right.)
If you assert that the simulated procedure can have only a finite
number of states, you can run the simulation for a number of steps
equal to the number of states, and determine whether any state has
repeated (impractical if the number of states is, say, 2**524288
for a system whose current state is represented in 64 kilo-octets
of storage). But the halting problem isn't about finite systems.
Mike.
On 8/11/2025 11:30 AM, Mike Terry wrote:
On 11/08/2025 02:00, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
<lots of good stuff snipped>
fixing any bugs
won't solve the basic problem.
Agreed, because the fact that the emulation fails to emulate isn't the >>>> real issue; if anything it's a distraction. The real issue is what
happens after HHH has made its decision and returned.
Disclaimer: I do not fully understand olcott's arguments, and I
have not analyzed his code.
olcott seems to be claiming that his simulator performs correct
simulations, while simultaneously acknowledging that it does not.
He might have a less obviously invalid argument if he stopped
claiming that his "simulator" is really a perfect simulator, or
used a different word than "simulator" to describe it.
PO and everybody else here knows that PO's simulation is only a /
partial/ simulation. When PO claims his simulation is correct, he
could be claiming one of two things:
a) his partial simulation correctly simulates each instruction it
simulates.
b) As for (a), but additionally that the subsequent halt decision by
the decider is correct.
Not sure which of these PO thinks is entailed by the phrase "correct
simulation", but its obvious he is NOT claiming his simulations are
complete.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*Forbids the complete simulation of a non-terminating input*
His halt decider may abandon its (partial) simulation activity at any
time and do something else like return its halt decision. This is
what posters here mean by the decider "aborting" the simulation.
I don't recall PO acknowledging that his deciders do NOT perform
correct simulations - that's something that some posters here may
say. They could mean:
a) some instruction is simulated but with incorrect outcome (e.g.
registers not set correctly)
b) instructions were simulated OK, but the decider stopped simulating
before the simulation
halted. (PO never has always made clear his simulations are
partial!)
Counter factual since 2022
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D *until H correctly determines that its simulated D*
*would never stop running unless aborted* then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
I changed the above spec to be more consistent with conventional
notions.
[When] simulating halt decider H correctly simulates its
input D until H correctly determines that [D simulated by H
cannot possibly reach its own simulated final halt state] then
c) instructions were simulated correctly, but then the decider
returned the wrong halting
status. (Is that the /simulation/ that was wrong or the /
decider/? People have
different usages for the terminology.)
Posters may say PO acknowledges his simulation is incorrect, but
really they're saying that /they/ have inferred (a) or (b) or (c)
above from something PO said.
I never in anyway acknowledged that the simulation is incorrect.
He also
makes arguments based on how C code should behave, when he's clearly
writing code that goes beyond what the C standard guarantees; these
arguments would be more nearly valid if he acknowledged that he's
not writing valid C, and defined the characteristics of the C-like
language he's using.
Fair point. In the distant past I think he has said his C code is
just for the MSVC (2017?) C compiler, but that gets forgotten. His
work is nothing really to do with C, and he might just as well have
used Fortran or something else, as long as there's a repeatable
process to turn that into a COFF file he can feed to his x86utm.exe.
(x86utm isn't C specific, although it was written to work for one
specific case: his halt7.obj file built by MSVC. His claims are not
really about C, but about the halting problem, although his demo code
is "C based".)
It is directly about C code within the context that
the x86utm operating system provides the basis for
any C function to emulate the x86 machine language
instructions of any other C function in debug step
mode.
Since the purpose of compilers is to translate the
C code into semantically equivalent x86 code when
DD is correctly emulated by HHH this is equivalent
to DD being correctly simulated by a C language
interpreter.
Imagine that you want to create an algorithm that, given a
representation of any procedure/input pair as input, correctly
determines whether the argument represents a halting algorithm
or not. This is obviously easy enough to do in limited cases:
`printf("hello\n");` halts, and `while (1){}` doesn't. But you
want to make that determination for all possible inputs. And you
think that the proofs that this is impossible are incorrect.
A correct algorithm cannot work by correctly simulating its input
algorithm to completion. A halt decider must halt and give a correct
result. Correct simulation of a non-halting procedure does not halt.
Ah, I see you are in the (b) camp above! :) PO has never claimed he
simulates too completion. His code's halting decisions are based on a
combination of simulation and (simulation trace) analysis.
Yes.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
But an algorithm that performs partial simulation of its input
might conceivably do the job. Suppose you can *start* simulating
the input. If that simulation halts in fewer than some specified
number of steps, you're done. If it doesn't, then maybe the
algorithm can perform some analysis on its input and on how the
simulation has proceeded so far, and reliably determine that the
procedure with the given input will or will not eventually halt.
(This is precisely what has been proven to be impossible.)
This is doable for a subset of inputs: those that halt after some
small number of steps, and those like `while (1){}` whose non-halting
is sufficiently obvious by inspection. One can *imagine* extending
the latter to cover all inputs.
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns >> 0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
Yes.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
Yes.
To cut a long story short, it turns out that his decider /does/ decide
the one input he needs, but it decides incorrectly, saying that it
never halts when in fact the input is easily seen to halt.
HHH(DD) does decide correctly when the basis is DD
correctly simulated by HHH.
It is impossible to understand that every other basis
is incorrect until after one first understand that this
basis is correct.
That you said that DD correctly simulated by HHH would
eventually halt with no abort simulation ever needed
proves that you still do not have a correct understanding.
Because you did such an excellent job on everything else
your lack of understanding of this seems like a master auto
mechanic that has never heard of spark plugs and on the
basis that they never heard of them does not believe that
they exist.
Not a good guy to employ for a tune-up.
[His so-called "non-termination pattern" matches, even though the
computation being simulated halts. So his decider aborts the
simulation and incorrectly returns 0 [never halts].]
Mike.
(Right.)
If you assert that the simulated procedure can have only a finite
number of states, you can run the simulation for a number of steps
equal to the number of states, and determine whether any state has
repeated (impractical if the number of states is, say, 2**524288
for a system whose current state is represented in 64 kilo-octets
of storage). But the halting problem isn't about finite systems.
Mike.
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and
is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists in
the program DD that halts, therefore the pattern is not non-halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and
claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts.
The x86 language semantics requires the simulation of the next
instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86
language, show that the final halts state can be reached when the
semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of the
input.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
until the
*recursive simulation non-halting behavior pattern*
is matched.
All three LLM systems figured this out on their own.
I did not tell them about the
*recursive simulation non-halting behavior pattern*
or the value that HHH(DD) should return.
https://claude.ai/share/da9e56ba-f4e9-45ee-9f2c-dc5ffe10f00c
https://chatgpt.com/share/68939ee5-e2f8-8011-837d-438fe8e98b9c
https://grok.com/share/c2hhcmQtMg%3D%3D_810120bb-5ab5-4bf8-af21-
eedd0f09e141
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts
and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists
in the program DD that halts, therefore the pattern is not non-
halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and
claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts.
The x86 language semantics requires the simulation of the next
instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86
language, show that the final halts state can be reached when the
semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of
the input.
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is >>>>>>>> therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists in the >>>>>> program DD that halts, therefore the pattern is not non-halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and claim >>>> that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts.
The x86 language semantics requires the simulation of the next
instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86
language, show that the final halts state can be reached when the
semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of the input.
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state after
three recursions.
That generic HHH(DD) not any other HHH
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts
and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake.
The mistake is that the pattern HHH thinks is non-halting exists
in the program DD that halts, therefore the pattern is not non-
halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and
claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts.
The x86 language semantics requires the simulation of the next
instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86
language, show that the final halts state can be reached when the
semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of
the input.
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
On 8/11/2025 10:30 AM, dbush wrote:
On 8/11/2025 11:27 AM, olcott wrote:
On 8/11/2025 10:08 AM, dbush wrote:
On 8/11/2025 11:06 AM, olcott wrote:
On 8/11/2025 10:03 AM, dbush wrote:
Not at all. It defines exactly one element of the infinite set ofSo in other words, you're changing the input.Generically HHH(DD) specifies HHH simulates DD then DD calls
HHH(DD)
HHH simulates DD then DD calls HHH(DD)...
Cannot possibly terminate normally
Strawman, as that isn't what what HHH does.
That is what the generic HHH defined above does.
Changing the input is not allowed.
I am showing the exact behavior of one element of the infinite set of
implementations of the above defined generic HHH.
Which changes the input.
Generic HHH/DDD pairs.
On 8/13/2025 3:07 AM, Mikko wrote:
On 2025-08-12 16:53:53 +0000, olcott said:
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting exists >>>>>>>> in the program DD that halts, therefore the pattern is not non- >>>>>>>> halting.
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts >>>>>>>>>> and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. >>>>>>>>
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and
claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation
aborts. The x86 language semantics requires the simulation of the
next instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the
x86 language, show that the final halts state can be reached when
the semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of
the input.
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
Your HHH is not generic.
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
On 8/13/2025 6:54 AM, joes wrote:
Am Mon, 11 Aug 2025 10:34:57 -0500 schrieb olcott:
On 8/11/2025 10:30 AM, dbush wrote:
On 8/11/2025 11:27 AM, olcott wrote:
On 8/11/2025 10:08 AM, dbush wrote:
On 8/11/2025 11:06 AM, olcott wrote:
On 8/11/2025 10:03 AM, dbush wrote:
Not at all. It defines exactly one element of the infinite set ofSo in other words, you're changing the input.Generically HHH(DD) specifies HHH simulates DD then DD calls >>>>>>>>> HHH(DD)
HHH simulates DD then DD calls HHH(DD)...
Cannot possibly terminate normally
Strawman, as that isn't what what HHH does.
That is what the generic HHH defined above does.
Changing the input is not allowed.
I am showing the exact behavior of one element of the infinite set of >>>>> implementations of the above defined generic HHH.
Which changes the input.
Generic HHH/DDD pairs.
Right. Different DDDs.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Just like the Linz proof assumes each
Ĥ.embedded_H of the infinite set of Turing
Machines thus changing its own input ⟨Ĥ⟩ ⟨Ĥ⟩
On 8/13/2025 3:50 AM, Fred. Zwarts wrote:
Op 12.aug.2025 om 18:53 schreef olcott:
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting exists >>>>>>>> in the program DD that halts, therefore the pattern is not non- >>>>>>>> halting.
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts >>>>>>>>>> and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. >>>>>>>>
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and
claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation
aborts. The x86 language semantics requires the simulation of the
next instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the
x86 language, show that the final halts state can be reached when
the semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of
the input.
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
Irrelevant. Replace two with N and three with N+1 and it is still true.
Using induction we see that HHH fails for any N to reach the final
halt state, where a correct simulation has no problem to reach the
final halt state.
Both simulations use the world class x86emulib emulator.
It is good that you see that DD cannot possibly reach
its final halt state. It is bad that you disagree with
the x86 language and say that the emulation is incorrect.
On 8/13/2025 3:07 AM, Mikko wrote:
On 2025-08-12 16:53:53 +0000, olcott said:
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:Saying the DD is not correctly emulated by HHH at
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting exists in the
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is >>>>>>>>>> therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. >>>>>>>>
program DD that halts, therefore the pattern is not non- halting. >>>>>>>
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and claim >>>>>> that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts. >>>>>> The x86 language semantics requires the simulation of the next
instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86 >>>>>> language, show that the final halts state can be reached when the
semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of the input.
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>> (a) Detects a non-terminating behavior pattern: abort simulation and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and
incorrectly aborts the simulation assuming non-termination behaviour
and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state after >>>> three recursions.
That generic HHH(DD) not any other HHH
Your HHH is not generic.
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
On 8/13/2025 6:54 AM, joes wrote:
Am Mon, 11 Aug 2025 10:34:57 -0500 schrieb olcott:
On 8/11/2025 10:30 AM, dbush wrote:
On 8/11/2025 11:27 AM, olcott wrote:
On 8/11/2025 10:08 AM, dbush wrote:
On 8/11/2025 11:06 AM, olcott wrote:
On 8/11/2025 10:03 AM, dbush wrote:
Not at all. It defines exactly one element of the infinite set ofSo in other words, you're changing the input.Generically HHH(DD) specifies HHH simulates DD then DD calls >>>>>>>>> HHH(DD)
HHH simulates DD then DD calls HHH(DD)...
Cannot possibly terminate normally
Strawman, as that isn't what what HHH does.
That is what the generic HHH defined above does.
Changing the input is not allowed.
I am showing the exact behavior of one element of the infinite set of >>>>> implementations of the above defined generic HHH.
Which changes the input.
Generic HHH/DDD pairs.
Right. Different DDDs.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Just like the Linz proof assumes each
Ĥ.embedded_H of the infinite set of Turing
Machines thus changing its own input ⟨Ĥ⟩ ⟨Ĥ⟩
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:When N steps of DD are correctly emulated by generic HHH no DD can
On 8/13/2025 3:07 AM, Mikko wrote:
On 2025-08-12 16:53:53 +0000, olcott said:*This is the generic HHH that I told the LLM systems about*
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the *recursive simulation non-halting >>>>>>>>>>>>> behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts >>>>>>>>>>>> and is therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific
mistake.
The mistake is that the pattern HHH thinks is non-halting
exists in the program DD that halts, therefore the pattern is >>>>>>>>>> not non- halting.
Saying the DD is not correctly emulated by HHH at minimum
requires pointing to the line of DD that is emulated by HHH
incorrectly and explaining what is wrong with the emulation of >>>>>>>>> this line by HHH.
That has been done many times. But you close your eyes for it and >>>>>>>> claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp [00002163] 8bec mov
ebp,esp [00002165] 51 push ecx [00002166] >>>>>>>>> 6862210000 push 00002162 // push DD [0000216b]
e862f4ffff call 000015d2 // call HHH [00002170]
83c404 add esp,+04 [00002173] 8945fc mov
[ebp-04],eax [00002176] 837dfc00 cmp dword [ebp-04],+00 >>>>>>>>> [0000217a] 7402 jz 0000217e [0000217c] ebfe
jmp 0000217c [0000217e] 8b45fc mov eax,[ebp-04] >>>>>>>>> [00002181] 8be5 mov esp,ebp [00002183] 5d
pop ebp [00002184] c3 ret Size in bytes:(0035)
[00002184]
The call to HHH is incorrectly simulated when the simulation
aborts. The x86 language semantics requires the simulation of the >>>>>>>> next instruction.
You cannot show that DD emulated by HH according to theHHH deviates from this semantics by aborting the simulation.
definition of the x86 language can possibly reach its own
correctly emulated "ret" instruction because it cannot.
*Any other basis of correct emulation is incorrect*
Other simulators, that do not deviate from the semantics of the >>>>>>>> x86 language, show that the final halts state can be reached when >>>>>>>> the semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of >>>>>>>> the input.
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and >>>>>> incorrectly aborts the simulation assuming non-termination
behaviour and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
Your HHH is not generic.
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return
1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
possibly reach its own emulated final state state. That people deny this seems to indicate that they are dishonest or have very little technical competence.
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
On 8/13/2025 3:07 AM, Mikko wrote:
On 2025-08-12 16:53:53 +0000, olcott said:
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:Saying the DD is not correctly emulated by HHH at
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting exists in the
On 8/10/2025 10:45 PM, olcott wrote:
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that halts and is
therefore NOT a non-halting behavior pattern?
If that was true then you could point out the specific mistake. >>>>>>>>>>
program DD that halts, therefore the pattern is not non- halting. >>>>>>>>>
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it and claim
that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation aborts. >>>>>>>> The x86 language semantics requires the simulation of the next >>>>>>>> instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the x86 >>>>>>>> language, show that the final halts state can be reached when the >>>>>>>> semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not of the input.
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and >>>>>> incorrectly aborts the simulation assuming non-termination behaviour >>>>>> and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>>>
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state after >>>>>> three recursions.
That generic HHH(DD) not any other HHH
Your HHH is not generic.
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
On 8/13/2025 3:07 AM, Mikko wrote:
On 2025-08-12 16:53:53 +0000, olcott said:
On 8/12/2025 5:13 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 16:48 schreef olcott:
On 8/11/2025 3:17 AM, Fred. Zwarts wrote:
Op 11.aug.2025 om 05:20 schreef olcott:
On 8/10/2025 10:04 PM, dbush wrote:
On 8/10/2025 11:03 PM, olcott wrote:
On 8/10/2025 9:49 PM, dbush wrote:The mistake is that the pattern HHH thinks is non-halting
On 8/10/2025 10:45 PM, olcott wrote:If that was true then you could point out the specific mistake. >>>>>>>>>>
Until you understand the
*recursive simulation non-halting behavior pattern*
you will remain utterly clueless.
You mean the pattern that exists in the program DD that >>>>>>>>>>>> halts and is therefore NOT a non-halting behavior pattern? >>>>>>>>>>>
exists in the program DD that halts, therefore the pattern is >>>>>>>>>> not non- halting.
Saying the DD is not correctly emulated by HHH at
minimum requires pointing to the line of DD that
is emulated by HHH incorrectly and explaining what
is wrong with the emulation of this line by HHH.
That has been done many times. But you close your eyes for it
and claim that what you do not see does not exists.
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
The call to HHH is incorrectly simulated when the simulation
aborts. The x86 language semantics requires the simulation of
the next instruction.
You cannot show that DD emulated by HH according
to the definition of the x86 language can possibly
reach its own correctly emulated "ret" instruction
because it cannot.
*Any other basis of correct emulation is incorrect*
HHH deviates from this semantics by aborting the simulation.
Other simulators, that do not deviate from the semantics of the >>>>>>>> x86 language, show that the final halts state can be reached
when the semantics of the x86 language are followed.
That HHH must violate this semantics, is a problem of HHH, not >>>>>>>> of the input.
Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
Incorrect, that must be:
(a) Sees a finite recursion, but does not recognise it as such and >>>>>> incorrectly aborts the simulation assuming non-termination
behaviour and incorrectly returns 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
That generic HHH(DD) specifies
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
Counter factual. HHH aborts after two recursions.
That means that a correct simulation reaches the final halt state
after three recursions.
That generic HHH(DD) not any other HHH
Your HHH is not generic.
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until: >>> (a) Detects a non-terminating behavior pattern: abort simulation and
return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
That people deny this seems to indicate that they are dishonest
or have very little technical competence.
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input
until:
(a) Detects a non-terminating behavior pattern: abort simulation
and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD)==0 and DD() halts.
No Turing machine M is accountable for
the behavior of its caller.
Machine M contains simulating halt decider H
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞
M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn
*Repeats until aborted proving non-halting*
(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩
then M.H ⟨M⟩ ⟨M⟩ transitions to M.qn
causing M applied to ⟨M⟩ halt
M.H ⟨M⟩ ⟨M⟩ is not accountable for the behavior of
M applied to ⟨M⟩
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>> (a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
HHH(DD)==0 and DD() halts.
On 8/16/2025 8:05 AM, dbush wrote:
On 8/16/2025 8:00 AM, olcott wrote:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>> return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of >>>>>>>> your
generic HHH saying that it halts than there are instances that >>>>>>>> say it
doesn't halt. Both can't be right but the majority opinion is more >>>>>>>> credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
In other words, you admit that you're not working on the halting problem
I am doing the same thing that ZFC did to the
Russell's Paradox problem. Since ZFC set theory
is now called naive set theory.
After my correction the original halting problem
will be called the naive halting problem.
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>>>
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your >>>>>> generic HHH saying that it halts than there are instances that say it >>>>>> doesn't halt. Both can't be right but the majority opinion is more >>>>>> credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>> return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of >>>>>>>> your
generic HHH saying that it halts than there are instances that >>>>>>>> say it
doesn't halt. Both can't be right but the majority opinion is more >>>>>>>> credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your >>>>>>>> generic HHH saying that it halts than there are instances that say it >>>>>>>> doesn't halt. Both can't be right but the majority opinion is more >>>>>>>> credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>>>> input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>>>> return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances >>>>>>>>>> of your
generic HHH saying that it halts than there are instances that >>>>>>>>>> say it
doesn't halt. Both can't be right but the majority opinion is >>>>>>>>>> more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of
another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual
meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem".
Turing machine deciders only compute the mapping
from their inputs...
So when the halting problem definition requires
something else that proves it is wrong.
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its >>>>>>>>>>> input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>>>> return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances >>>>>>>>>> of your
generic HHH saying that it halts than there are instances that >>>>>>>>>> say it
doesn't halt. Both can't be right but the majority opinion is >>>>>>>>>> more
credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of
another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual
meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem".
Turing machine deciders only compute the mapping
from their inputs...
So when the halting problem definition requires
something else that proves it is wrong.
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more >>>>>>>>>> credible.
When N steps of DD are correctly emulated by generic HHH
no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can.
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH.
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of
another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual
meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem".
Turing machine deciders only compute the mapping
from their inputs...
So when the halting problem definition requires
something else that proves it is wrong.
The halting problem assumes that there is an
input that does the opposite of whatever the
decider decides. No such input actually exists.
On 8/19/2025 9:53 AM, Richard Heathfield wrote:
On 19/08/2025 15:46, olcott wrote:
The halting problem assumes that there is an
input that does the opposite of whatever the
decider decides. No such input actually exists.
The Halting Problem assumes (as you appear to) that a universal
decider exists.
I merely prove that the proofs do not derive their conclusion.
If that assumption is true, it becomes possible to write the
program that you appear to think is impossible to write.
Therefore, the assumption (that a universal decider exists)
must be false.
QED.
On 8/19/2025 9:53 AM, Richard Heathfield wrote:
On 19/08/2025 15:46, olcott wrote:
The halting problem assumes that there is an
input that does the opposite of whatever the
decider decides. No such input actually exists.
The Halting Problem assumes (as you appear to) that a universal decider
exists.
I merely prove that the proofs do not derive their conclusion.
On 19/08/2025 16:30, olcott wrote:
On 8/19/2025 9:53 AM, Richard Heathfield wrote:
On 19/08/2025 15:46, olcott wrote:
The halting problem assumes that there is an
input that does the opposite of whatever the
decider decides. No such input actually exists.
The Halting Problem assumes (as you appear to) that a universal
decider exists.
I merely prove that the proofs do not derive their conclusion.
But they do.
If that assumption is true, it becomes possible to write the
program that you appear to think is impossible to write.
Therefore, the assumption (that a universal decider exists)
must be false.
QED.
See?
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 9:53 AM, Richard Heathfield wrote:
On 19/08/2025 15:46, olcott wrote:I merely prove that the proofs do not derive their conclusion.
The halting problem assumes that there is an input that does the
opposite of whatever the decider decides. No such input actually
exists.
The Halting Problem assumes (as you appear to) that a universal
decider exists.
But you don't understand what that conclusion is!
From years of discussions it is apparent that you believe the
following
wrong version:
The Halting Theorem shows that there exist contrived machines which
do not have a halting status due to perpetrating a contradictory
behavior.
You believe that DD() refers to a single machine. It is always the same
DD no matter what version of HHH is integrated into it. You believe
that since HHH is called from DD, it is not a part of DD; only the code
between the curly braces of DD comprises DD. and not anything external.
You believe that the purpose of DD is to show that DD's halting status
(halts or not) is indeterminate, because it "behaves opposite" to /any/
decider that is "plugged in" to it. You believe that the substitution
of a different HHH into the DD template does not produce a different
DD.
This is wrong, and you've certainly written an apparatus that manages
to debunk one aspect of it: you've shown that, no, DD as such is not
undecidable.
You show that even though DD contradicts the result reported by the HHH
embedded into it, a /different/ HHH (using the same procedure name and
body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
that DD does not halt. Bravo! You also know that when you remove theThus the correct return value for HHH(DD) is 0.
static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside HHH
are then exactly the same (except that the inner one is emulated wheras
the outside one is native).
On 8/19/2025 12:19 PM, Kaz Kylheku wrote:And he doesn’t even know it.
Peter believes the Halting Theorem to be the assertion that there exist
programs which contradict every decider that is plugged into them,
which makes their halting status indeterminate. (And because of the
existence of these programs, universal halting is undecideable.)
*Correcting the error of the halting problem spec*
Is it possible to create a halt decider: H that consistently reports the
halt status of the behavior specified by its input finite string Turing machine description: P as measured by P correctly simulated by H?
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 9:53 AM, Richard Heathfield wrote:
On 19/08/2025 15:46, olcott wrote:
The Halting Problem assumes (as you appear to) that a universalI merely prove that the proofs do not derive their conclusion.
decider exists.
But you don't understand what that conclusion is!
From years of discussions it is apparent that you believe the
following wrong version:
The Halting Theorem shows that there exist contrived machines which
do not have a halting status due to perpetrating a contradictory
behavior.
You believe that DD() refers to a single machine. It is always the same
DD no matter what version of HHH is integrated into it. You believe
that since HHH is called from DD, it is not a part of DD; only the code
between the curly braces of DD comprises DD. and not anything external.
You believe that the purpose of DD is to show that DD's halting status
(halts or not) is indeterminate, because it "behaves opposite" to /any/
decider that is "plugged in" to it. You believe that the substitution
of a different HHH into the DD template does not produce a different
DD.
This is wrong, and you've certainly written an apparatus that manages
to debunk one aspect of it: you've shown that, no, DD as such is not
undecidable.
You show that even though DD contradicts the result reported by the HHH
embedded into it, a /different/ HHH (using the same procedure name and
body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
that DD does not halt. Bravo! You also know that when you remove theThus the correct return value for HHH(DD) is 0.
static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside HHH
are then exactly the same (except that the inner one is emulated wheras
the outside one is native).
On 8/19/2025 1:05 PM, joes wrote:<snip>
Am Tue, 19 Aug 2025 12:50:31 -0500 schrieb olcott:
Is it possible to create a halt decider: H that consistently
reports the
halt status of the behavior specified by its input finite
string Turing
machine description: P as measured by P correctly simulated by H?
Yes, behold:
return 0;
It simulates no instructions incorrectly
Now you are a Liar.
On 8/19/2025 1:21 PM, Richard Heathfield wrote:
On 19/08/2025 19:07, olcott wrote:
On 8/19/2025 1:05 PM, joes wrote:<snip>
Am Tue, 19 Aug 2025 12:50:31 -0500 schrieb olcott:
Is it possible to create a halt decider: H that consistently
reports the
halt status of the behavior specified by its input finite
string Turing
machine description: P as measured by P correctly simulated
by H?
Yes, behold:
return 0;
It simulates no instructions incorrectly
Now you are a Liar.
Are you claiming that his H simulates some instructions
incorrectly, or that his H returns non-zero?
That was my mistake for not paying close enough
attention. All the instructions that HHH emulates
are emulated correctly.
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the HHH
embedded into it, a /different/ HHH (using the same procedure name and
body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
that DD does not halt. Bravo! You also know that when you remove the
static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside HHH are
then exactly the same (except that the inner one is emulated wheras the
outside one is native).
Thus the correct return value for HHH(DD) is 0.
The /only problem/, the way I see it, is that you believe the wrong
thinking which you have correctly debunked to be the thinking of Turing,
when in fact it is your own, because you don't get the Turing version
of the Halting Problem.
If you managed to get the Turing version of it, it would be so obvious
that you're not making sense you'd slap your forehead and quit.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When the second named state of Turing machine Ĥ
reports on the behavior of its correct simulation
of its input
I really think you should try to get it. You are really wasting a lot of
time on this. You have some programming skills. You could be doing
something useful, like teaching a kids' computer camp.
On 8/19/2025 5:58 PM, André G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the HHH >>>> embedded into it, a /different/ HHH (using the same procedure name and >>>> body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
But if (**execution_trace == 0x90909090) creates the exact same problem
as using a static variable. You're creating a global state which your
HHH accesses and thus HHH is not a pure function. Except you're doing it
in a far messier and more questionable way.
André
I have known that for years.
After I got people here to quit lying about the
behavior of DD correct simulated by HHH I had
intended to fix that issue.
On 8/19/2025 3:21 PM, olcott wrote:
On 8/19/2025 5:16 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:02 PM, olcott wrote:
On 8/19/2025 1:29 PM, Richard Heathfield wrote:
On 19/08/2025 19:23, olcott wrote:
On 8/19/2025 1:21 PM, Richard Heathfield wrote:
On 19/08/2025 19:07, olcott wrote:
On 8/19/2025 1:05 PM, joes wrote:<snip>
Am Tue, 19 Aug 2025 12:50:31 -0500 schrieb olcott:
Is it possible to create a halt decider: H that consistently reports theYes, behold:
halt status of the behavior specified by its input finite string Turing
machine description: P as measured by P correctly simulated by H? >>>>>>>>>
return 0;
It simulates no instructions incorrectly
Now you are a Liar.
Are you claiming that his H simulates some instructions incorrectly, or that his H returns
non-zero?
That was my mistake for not paying close enough
attention. All the instructions that HHH emulates
are emulated correctly.
This is where you apologise to joe for falsely accusing him of lying. >>>>>
Her.
Huh?
She is not Joe S, she is Joes.
Oh. I did not know. Sorry.
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting Theorem doesn't
say that there exist test cases whose halting is indeterminate such that
they cannot be decided by /any/ decider.
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
When I show how D is correctly decided by H these proofs fail.
The Tarski Undefinability Theorem depends on the exact same
pathological self-reference faulty reasoning.
I am not just using execution_trace as a flag.
Its primary purpose is to communicate the actual
instructions of DD that are simulated by some HHH
between simulation levels.
There never has been any actual input that does
the opposite of whatever its decider decides.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 19/08/2025 15:46, olcott wrote:
The halting problem assumes that there is an
input that does the opposite of whatever the
decider decides. No such input actually exists.
The Halting Problem assumes (as you appear to) that a universal
decider exists.
If that assumption is true, it becomes possible to write the program
that you appear to think is impossible to write.
Therefore, the assumption (that a universal decider exists) must be
false.
QED.
A quibble: The Halting Problem itself doesn't assume that.
The usual proof of the undecidability of the Halting Problem makes
that assumption.
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:You should just go ahead and do it. It would show the behaviour better.
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 5:58 PM, André G. Isaak wrote:
On 2025-08-19 11:42, olcott wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
But if (**execution_trace == 0x90909090) creates the exact sameI have known that for years.
problem as using a static variable. You're creating a global state
which your HHH accesses and thus HHH is not a pure function.
After I got people here to quit lying about the behavior of DD correct
simulated by HHH I had intended to fix that issue.
I can assure you everybody will be completely honest about that.The correct simulation doesn't matter.I know that yet if I corrected that everyone here besides you would lie
The static flag (whether using a "static" variable, or de-facto static
data stored in the code segment) throws a monkey wrench into the claim
you are making based on a correct simulation.
about my having eliminated all static data as they lie about nearly everything else.
The input isn’t even doing anything, it’s just data. The simulator isThe if statement testing the value of *execution_trace, together withThe fact that the counter-example input cannot even reach its own "do
another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
The fact that HHH (top level) can correctly decide something that HH
(recursive) doesn't decide is not interesting and doesn't speak to the
Halting Theorem.
the opposite" code and remains stuck in recursive simulation does apply
to the halting problem proofs.
The proof shows that the assumption is wrong. D halts, and H does notContrary to your repeatedly stated belief, The Halting Theorem doesn'tThe halting problem proofs depend on the assumption that there is an H/D
say that there exist test cases whose halting is indeterminate such
that they cannot be decided by /any/ decider.
pair such that D is undecidable by H. When I show how D is correctly
decided by H these proofs fail.
I am not just using execution_trace as a flag.You are *also* using it as a flag.
On 8/19/2025 9:55 PM, Mike Terry wrote:
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
On 8/19/2025 5:16 PM, Chris M. Thomasson wrote:
On 8/19/2025 3:02 PM, olcott wrote:
On 8/19/2025 1:29 PM, Richard Heathfield wrote:
She did correct me once.Oh. I did not know. Sorry.She is not Joe S, she is Joes.This is where you apologise to joe for falsely accusing him of
lying.
I have never seen any evidence to suggest that Joes is female, other
than PO correcting people when they say otherwise. I put little/no
store in that.
Not that it matters one iota whether Joes is male or female. Joes
doesn't confirm either way which is fine.
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the one input he needs, but it decides incorrectly, saying that it never halts when in fact the input is easily seen to halt. [His so-called "non-termination pattern" matches, even though the computation being simulated halts. So his decider aborts the simulation and incorrectly returns 0 [never halts].]
On 8/20/2025 4:58 AM, joes wrote:
Thanks, Mike.
You can use „they” or any funny neopronouns, or just my name.
Do you prefer she to other pronouns?
On 19/08/2025 23:27, Chris M. Thomasson wrote:
On 8/19/2025 3:21 PM, olcott wrote:
She is not Joe S, she is Joes.
Oh. I did not know. Sorry.
I have never seen any evidence to suggest that Joes is female, other than PO correcting people when
they say otherwise. I put little/no store in that.
It is utterly unsurprising that it can obtain a correct answer;^^^^^^^
that doesn't contradict anything int the Halting Theorem.
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps.
He simulates until either the simulation naturally halts, or
one of his so-called "non-termination" patterns occurs in the
analysis of the simulation. If that happens, the decider returns
0 [does not halt].
If the simulation never halts and never matches one of his
so-called non-termination pattern, the simulation continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case:
the case the Linz HP proof constructs for a given decider,
which "does the opposite of what the decider decides".
[If you're not familiar with the proof you won't understand
this bit, but it would take too long to explain here.]
So it makes no difference that his decider can't decide /every/
input - he does not claim to have a Halt Decider, just a
/partial/ halt decider that correctly decides that one input.
To cut a long story short, it turns out that his decider /does/ decide the >> one input he needs, but it decides incorrectly, saying that it never halts >> when in fact the input is easily seen to halt. [His so-called
"non-termination pattern" matches, even though the computation being
simulated halts. So his decider aborts the simulation and incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing piece. PO
has been quite clear that 0 is the correct return value. When asked he
said:
"Yes that is the correct answer even though P(P) halts."
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting Theorem doesn't >>>> say that there exist test cases whose halting is indeterminate such that >>>> they cannot be decided by /any/ decider.
The halting problem proofs depend on the assumption
that there is an H/D pair such that D is undecidable by H.
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
OK that seems to make sense.
"Undecidable" is the situation of not having an algorithm (computational
function) to calculate some abstract Boolean math function.
Its a little more concrete when we add a model of computation.
H has some algorithm. D is chosen to make the algorithm come up
with the wrong answer, or else not to halt.
Turing machine deciders only compute the mapping
from their inputs...
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*From the bottom of page 319 has been adapted to this*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
I have gone over the HP many times.
Mensa scored me in the top 3%.
I was in the top 20% of my BSCS classes.
(You've repeatedly claimed that halting claims that D is undecidable, and
that that is obviously and pathologically wrong.)
The proofs claim that: D is undecidable by H.
When I show how D is correctly decided by H these proofs fail.
When you show how D is correctly decided by H, you are equivocating
between two definitions of H that are active simultaneously.
Not exactly. The x86utm operating system does
cooperative multi-tasking.
HHH executes then HHH simulates DD that calls HHH(DD)^^^^^^
then and HHH simulates this instance of itself simulating
There is no self-reference.
HHH is deciding on the behavior of:
DD simulated by HHH that calls HHH(DD)
that simulates DD that calls HHH(DD)...
HHH just needs the sequential list of every DD insruction
that is simulated at any level stored in execution_trace.
with another part of the code which mutates that storage location,
give rise to two deciders HHH (top level) and HHH (recursive).
I don't believe that's PO's intention, or even a good way of looking at things. This is just a
On 8/19/2025 8:00 PM, Kaz Kylheku wrote:
On 2025-08-19, olcott <polcott333@gmail.com> wrote:
On 8/19/2025 12:06 PM, Kaz Kylheku wrote:
You show that even though DD contradicts the result reported by the HHH >>>> embedded into it, a /different/ HHH (using the same procedure name and >>>> body, distinguished from DD's HHH by a hidden static flag) can decide
(1) The static flag is dead and not used.
if (**execution_trace == 0x90909090) is used instead.
It's the same thing. "static data" doesn't mean that "static" keyword
must be used.
Yes I know that yet I wanted you to understand
my actual code, not a misconception of it.
String literals like char *s = "abc" are understood to be static data
in C. Yet, no static keyworcd is used. Moreover, it's common for
compilers to place them into the text segment, right where the code
is---much like your *execution_trace word!
External variables without the "static" keyword are also in static
storage. At file scope "static" doesn't control the kind of storage,
but the linkage of the identifier: it give sinternal versus external
linkage.
In this debate when I say "static flag" I mean that it's something in
a persistent memory outside of the function (not allocated and
initialized on entry into the function, but externally accessed
and shared by all activations of the function).
It is not so much a flag as it is a location
to store the required execution trace.
On this topic, also ...
You should go back to the static variable because it's a much more
portable way to obtain a piece of static storage associated with
a function than modifying its code. static variables are defined
by the C language, whereas self-modifying code is undefined behavior.
It clutters your code with weird gotos around inline assembly.
I envisioned my way of doing it as analogous to a UTM
setting aside a portion of its own tape for its slave
UTMs to use as their own tape.
I envision HHH as a UTM with extra features.
Moreover, you're assuming that the EAX register is free for you
to clobber. That is false; there are calling conventions for X86
where EAX is the first parameter; if you do some LEA EAX, WHATEVER,
you will obliterate the argument. Maybe that's not happening with
your toolchain but it's a threat.
I could easily see all the generated x86 code verifying
that this is in fact not an issue in this case.
that DD does not halt. Bravo! You also know that when you remove the
static flag, of course the whole show doesn't halt: you get runaway
simulation. You know that this is because the outside and inside HHH are >>>> then exactly the same (except that the inner one is emulated wheras the >>>> outside one is native).
Thus the correct return value for HHH(DD) is 0.
Wishing for HHH(DD) to have some return value doesn't make it have
that return value.
Deducing what its return value should be on the basis
of the actual behavior of DD correctly simulated by
HHH is proven to be correctly 0.
If HHH(DD) doens't have that value, it's just wrong.
Not exactly. The static analysis of the C code does
prove that HHH(DD) returning 0 would be correct.
Linz shows such a machine that is simulating its
own machine description by his definition of his
Ĥ template. Ĥ applied to ⟨Ĥ⟩ does remain stuck in
recursive simulation unless Ĥ.embedded_H aborts
this simulation.
If Ĥ.embedded_H is smart enough to see the repeating
state then it has the basis to abort and reject.
It might be that no Ĥ.embedded_H is smart enough
to see the repeating state.
I really think you should try to get it. You are really wasting a lot of >>>> time on this. You have some programming skills. You could be doing
something useful, like teaching a kids' computer camp.
Please, re-read my post, and don't get hung up on "static", etc.
I just wanted to to understand that the only static
data needed in my current code is execution_trace.
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
So HHH is broken.
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:Ĥ.embedded_H ⟨Ĥ⟩
On 2025-08-20, olcott <polcott333@gmail.com> wrote:More concretely every sequence of steps of a Turing machine either
On 8/19/2025 9:59 PM, Kaz Kylheku wrote:
On 2025-08-20, olcott <polcott333@gmail.com> wrote:OK that seems to make sense.
On 8/19/2025 8:18 PM, Kaz Kylheku wrote:
Contrary to your repeatedly stated belief, The Halting TheoremThe halting problem proofs depend on the assumption that there is an >>>>> H/D pair such that D is undecidable by H.
doesn't say that there exist test cases whose halting is
indeterminate such that they cannot be decided by /any/ decider.
Not quite. That should be "such that D is is either /incorrectly/
decided by H, or else H does not terminate".
"Undecidable" is the situation of not having an algorithmIts a little more concrete when we add a model of computation.
(computational function) to calculate some abstract Boolean math
function.
The model is Turing computation. The domain is all Turing computations
and there is an abstract funtion which assigns absolutely all of them a
termination value.
reaches a final halt state or fails to reach a final halt state.
The question is, can some of these Turing computations calculate thatWhen we are careful to make sure to keep this in mind:
function in its entirety (the whole domain?)
Turing machine deciders only compute the mapping from their inputs...
The the mistake of believing that one TM can directly report on the
behavior of its own caller is never made.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, Ĥ.q0 ⟨Ĥ⟩ ⊢*
⟨Ĥ⟩ ⊢* Ĥ.qn
Linz incorrectly requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
to report on the behavior of its caller/itself.
All the proofs make this same mistake.
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus has
no idea if its caller is DD or main.
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is only
concerned with what is passed to it as an input which *just happens to
be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
On 8/20/2025 4:19 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 14:47:20 -0500, olcott wrote:
On 8/20/2025 1:44 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 19:32:54 +0100, Richard Heathfield wrote:
On 20/08/2025 19:20, olcott wrote:
Every C programmer knows that HHH(DD) cannot see its own caller
thus has no idea if its caller is DD or main.
So HHH is broken.
Wrong, there is no need for HHH to know what is calling it, it is
only concerned with what is passed to it as an input which *just
happens to be*
its caller (well, a description thereof).
/Flibble
That merely proves that you are not an expert programmer.
If that were true you could point out the error in what I said (hint:
you can't because I made no error, unlike yourself).
/Flibble
You corrected yourself on the next post that I replied to.
On Wed, 2025-08-20 at 21:35 -0400, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
On 8/20/2025 6:51 PM, wij wrote:
On Wed, 2025-08-20 at 18:40 -0500, olcott wrote:
On 8/20/2025 6:31 PM, wij wrote:
On Wed, 2025-08-20 at 18:24 +0100, Mike Terry wrote:
On 20/08/2025 12:10, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>>>>
On 11/08/2025 02:00, Keith Thompson wrote:...
Richard Heathfield <rjh@cpax.org.uk> writes:
On 10/08/2025 23:17, Keith Thompson wrote:
Is this what olcott is trying to do?
Pretty much. Except:
1. PO does not specify any limit for the number of steps. >>>>>>>>>>>>> He simulates until either the simulation naturally >>>>>>>>>>>>> halts, or
one of his so-called "non-termination" patterns occurs >>>>>>>>>>>>> in the
analysis of the simulation. If that happens, the >>>>>>>>>>>>> decider returns
0 [does not halt].
If the simulation never halts and never matches one of >>>>>>>>>>>>> his
so-called non-termination pattern, the simulation >>>>>>>>>>>>> continues
indefinitely.
2. PO is only interested in deciding ONE SPECIFIC input case: >>>>>>>>>>>>> the case the Linz HP proof constructs for a given >>>>>>>>>>>>> decider,
which "does the opposite of what the decider decides". >>>>>>>>>>>>> [If you're not familiar with the proof you won't >>>>>>>>>>>>> understand
this bit, but it would take too long to explain here.] >>>>>>>>>>>>> So it makes no difference that his decider can't >>>>>>>>>>>>> decide / every/
input - he does not claim to have a Halt Decider, just a >>>>>>>>>>>>> /partial/ halt decider that correctly decides that one >>>>>>>>>>>>> input.
To cut a long story short, it turns out that his decider / >>>>>>>>>>>>> does/ decide the
one input he needs, but it decides incorrectly, saying that >>>>>>>>>>>>> it never halts
when in fact the input is easily seen to halt. [His so-called >>>>>>>>>>>>> "non-termination pattern" matches, even though the
computation being
simulated halts. So his decider aborts the simulation and >>>>>>>>>>>>> incorrectly
returns 0 [never halts].]
I like these summaries of yours, but there is a final missing >>>>>>>>>>>> piece. PO
has been quite clear that 0 is the correct return value. When >>>>>>>>>>>> asked he
said:
"Yes that is the correct answer even though P(P) halts." >>>>>>>>>>>>
Right - it's been clear that PO really does believe that for >>>>>>>>>>> quite a while now! All his current
posting amounts to PO trying to justify /why/ the obviously >>>>>>>>>>> wrong answer is /really/ correct.
It's
all nonsense of course.
Mike.
Then, the next question is why people like to jump into the >>>>>>>>>> nonsense (POO simulation)?
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted. People here have been consistently lying
about this for three years. Except Ben:
Everbody? now knows that you cannot square a circle. But, now if I >>>>>>>> change the
idea, sentence to:
"..you cannot square a circle except a genine proof proves
otherwise."
This pattern of argument applies to every existing theorem.
Therefore, your idea is meaningless from the beginning.
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
; I don't think that is the shell game. PO really /has/ an H >>>>>>>>> > (it's trivial to do for this one case) that correctly determines >>>>>>>>> > that P(P) *would* never stop running *unless* aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
In other words, you're not smart enough to understand what is written
below hence why you dishonestly trimmed it.
All you're doing is proving you don't understand proof by
contradiction over 50 years after it was taught to you.
No input exists because a total halt decider does not exist. The
assumption that a total halt decider exists is what allows the
creation of a Turing machine, and therefore a finite string
description of that machine, that does the opposite.
All of your arguments boil down to "it's impossible because Turing >>>>>> was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
then it becomes
dead obvious that
No total halt decider exists.
So you're saying the proof is wrong because what it proves is right.
Error: assuming the conclusion.
So, I think the whole story is that since olcott thinks he can see the HP is undecidable, therefore he thus decides the HP is decidable,... then the long journey
began: "Talent hits a target no one else can hit; Genius hits a target no one else can see."
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted.
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
The DD that is calling HHH(DD) is not its input.
No C function or Turing machine can have its actual
self as its input.
On 8/20/2025 7:34 PM, dbush wrote:
On 8/20/2025 7:56 PM, olcott wrote:
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
No input exists because a total halt decider does not exist.
No such input exists therefore the conventional proof
that no universal decider exists FAILS.
What I just said is true that you are no bright enough
to understand that it is true is no error on my part.
On 8/20/2025 8:35 PM, dbush wrote:
On 8/20/2025 9:22 PM, olcott wrote:
On 8/20/2025 8:06 PM, dbush wrote:
On 8/20/2025 8:53 PM, olcott wrote:
On 8/20/2025 7:34 PM, dbush wrote:
All of your arguments boil down to "it's impossible because
Turing was right."
The proof that I am correct is when
anyone tries to show an *input* that
does the opposite of what its decider
decides concretely in C,
Which can only be done if a total halt decider exists.
I think that you know you have that backwards.
Dishonestly saying that HHH emulates zero
instructions of DD proves that you don't tell
the truth.
On 8/20/2025 9:48 PM, Richard Heathfield wrote:
On 21/08/2025 00:40, olcott wrote:
Its an easily verified fact that DD correctly
simulated by HHH would never stop running unless
aborted.
It's an easily verified fact that HHH is part of DD.
int DD()
{
int Halt_Status = HHH(DD);
Verified.
It's an easily verified fact that HHH(DD) stops the DD
simulation, at least according to the author of HHH:
"The execution trace is not needed to correctly determine that
DD correctly simulated by HHH is non-halting. All five LLM
systems figured that out on the basis of static analysis of the
C text
that HHH(DD)==0 is correct." P Olcott, 20/8/2025 in Usenet
message <1085e5p$idn8$1@dont-email.me>.
THEREFORE, HHH (which is a part of DD - see above) terminates
DD, and THEREFORE DD is self-terminating, which means in turn
that HHH is incorrect to claim that DD is non-halting; the
seeds for DD's halting are baked right into its fabric.
HHH must return 1, because DD must halt (as the simulation
proves when it *forces* DD to halt).
When I prove some instructions are correctly
simulated by HHH and you continue to say that
zero instructions are simulation by HHH you
prove yourself to be a liar.
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
Cite your sources.
The conventional proof does not require the existence of the
input you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
On 8/20/2025 9:52 PM, Richard Heathfield wrote:
On 21/08/2025 00:56, olcott wrote:
<snip>
It is impossible for a decider to report the
correct halt status of an input that does the
opposite of whatever the decider decides
YET NO ONE IN 89 YEARS EVER NOTICED THAT
NO SUCH INPUT HAS EVER EXISTED.
On the contrary, what everyone except you has noticed is that
it's impossible for the decider (of the halting status of any
arbitrary program with any arbitrary input) to exist, and
therefore - lacking existence - it is obviously not in a
position to report anything.
They keep saying that I am wrong entirely
on the basis of their own failure to pay attention.
They pay attention to the proof, which clearly you don't.
I sum up my view more precisely here: [The Peter Linz HP proof]
On 8/20/2025 1:42 PM, Mr Flibble wrote:
On Wed, 20 Aug 2025 13:20:28 -0500, olcott wrote:
On 8/20/2025 12:44 PM, Kaz Kylheku wrote:
When we are careful to make sure to keep this in mind:
Turing machine deciders only compute the mapping from their inputs...
For a Turing computation to do that, it has to calculate its own
halting.
Every C programmer knows that HHH(DD) cannot see its own caller thus
has no idea if its caller is DD or main.
Nobody is suggesting that HHH(DD) can see its caller however we are
passing a *description* of DD to HHH and HHH needs to return a decision
to its caller, DD.
It does do that. HHH reports that its DD DOES NOT HALT because its
simulated DD DOES CALL HHH IN RECURSIVE SIMULATION that would never stop running unless aborted.
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
On 8/20/2025 11:45 PM, Richard Heathfield wrote:
On 21/08/2025 05:01, olcott wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
<snip>
Cite your sources.
The conventional proof does not require the existence of the
input you describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
It's high time you took a closer look at Turing's proof, which
requires no such "input" to exist. Indeed, the whole point of
his proof is to show that there can be nowhere into which to
put such an "input", and therefore such an "input" *cannot* exist.
It wasn't even called the Halting problem
until after he died.
If you want to anchor
the HP in text then use please use Linz.
On 8/21/2025 12:36 PM, Richard Heathfield wrote:
On 21/08/2025 18:20, olcott wrote:Because most people get confused by the term "partial halt decider" yet understand the gist of the idea of a halt decider (determines halt
On 8/21/2025 12:04 PM, Richard Heathfield wrote:
On 21/08/2025 17:18, olcott wrote:
<snip>
I never claimed and always disavowed that I have a universal deciderWhen I apply a simulating halt decider in both cases we get the same >>>>> result.
Is it then your claim that you have a universal halt decider? Because
you don't.
and that I am rebutting the halting problem.
That's what I thought. Glad to have it confirmed.
So when you claim to have a halt decider, you mean it only works
sometimes, like this one does:
status)
I use the less precisely accurate term.
int usuallyrighthaltdecider(const char **src, size_t nlines)I prove that the proofs do not prove their point.
{
return 1;
}
At most I have a partial halt decider that refutes the conventional
proof of the halting problem
No, it doesn't. The conventional proof of the halting problem reasons
about a hypothetical /universal/ halt decider (which it proves cannot
exist).
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a
certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:DD correctly simulated by HHH cannot possibly ever stop running (not
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:None-the-less correct analysis of this text does prove that HHH(DD)==0
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:I know that. You taught me that.
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of theCite your sources.
input you describe,
I have been studying this for 22 years and never saw a proof that >>>>>>> did not require an input to do or say the opposite of what its
decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>> certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable state
with another running implementation of the decider".)
I don't currently know how to change my code so that HHH can see the >>>>> recursive simulation execution traces of DD without the use of
static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does
/not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
counting OOM error) unless aborted.
You must understand a little of my x86utm operating system architecture
to even understand that HHH can simulate an instance of itself
simulating an instance of DD when its own instance of DD calls HHH(DD).
Since HHH_embedded(DD) does not terminate and return 0, whereas
HHH_toplevel(DD) does so, they are different algorithms.
The whole contraption is confirming that HHH_embedded(DD) is not
correctly deciding the halting of DD.
HHH_toplevel is correct, but irrelevant.
Above you've admitted that you've not found a way to show that
HHH_toplevel is correct without the static data; i.e. a way to show it
in any situation in which HHH_toplevel and HHH_embedded are exactly the
same function, not changing their behavior to split into two.
Yet, until you find that way, your claim that you have disproved the
Halting Theorem has not been confirmed.
The Theorem says that what you are looking for is impossible,
and has unassailable logic.
You cannot make those two deciders the same. It is impossible for
HHH_embedded(DD) not to be wrong, and so if the same expression is
tested outside of the test case, it must yield the same wrong result.
If the same expression HHH(DD) is yielding different behaviors and
results in different contexts, your apparatus is broken.
A non-broken version of the apparatus cannot exist in such a way that
it refutes Halting.
All Five LLM systems figured out on their own that HHH(DD)==0 would be correct because DD correctly simulated by HHH cannot possibly halt.
If you don't understand that DD correctly simulated by HHH cannot
possibly halt, then you don't understand my code well enough.
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the input you >>>>>>>> describe,Cite your sources.
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>> certain decider. Which decider it contains does not vary with the
decider being applied to that input.
The embedded decider may be a clean-room implementation of the
algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have
elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km
footrace in under 37 minutes without cutting the course, so for now,
until I find better training methods, I hope you all don't mind me
getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate.
HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH cannot possibly
ever stop running (not counting OOM error) unless
aborted.
You must understand a little of my x86utm operating
system architecture to even understand that HHH
can simulate an instance of itself simulating an
instance of DD when its own instance of DD calls
HHH(DD).
Your code is bullshit, people don't want to invest too much time in understanding bullshit.
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.Counter-factual.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can
be simultaneously true that HHH(DD) stops and returns 0, yet exactly the
same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and
that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
On 2025-08-21, Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:Counter-factual.
Your code is bullshit, people don't want to invest too much time in
understanding bullshit.
But we already have a decent understanding of it. It's not rocket
science.
The code does what Peter says it does. HHH(DD) simulates DD and
finds non-termination.
Unfortunately, he claims that by doing so it is simulating
"an instance of itself" which is false; the HHH(DD) call inside
DD is a different HHH
which does not correctly simulate DD.
Peter does not say that it does; he admits that it is running
away with recursion and not terminating.
The crazy part is believing that there is only one HHH such that it can >>>> be simultaneously true that HHH(DD) stops and returns 0, yet exactly
the
same expression HHH(DD) does not stop.
That would be crazy until you understand that it has
always only been the behavior of the input that counts.
Turing machine deciders only compute the mapping
from their inputs...
DD simulated by HHH is BEFORE any DD has had its
simulation aborted.
Directly executed DD() is AFTER DD has had its
simulation aborted.
HHH(DD) maps its input to DD correctly simulated
by HHH and reports the same result regardless of
its execution context.
DD that need not be a computable function has different
behavior depending on its process context.
He knows that a mutable static variable is responsible for the
discrepancy which makes this actually happen in his implementation, and >>>> that he's failed to find a way to get rid of it.
The behavior of DD correctly simulated by HHH remains
the same non-halting behavior. Without the static data
the current HHH cannot see this behavior.
But that means you haven't accomplished what you claim to have
accomplished -- created a decider which correctly decides the Linz
counterecxample. Until you come up with an HHH that can see this
behaviour without relying on static data, then you're not
demonstrating anything.
André
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this result
without relying on static data then it doesn't achieve what you have
claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives when
given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
On 8/21/2025 6:05 PM, André G. Isaak wrote:
On 2025-08-21 16:53, olcott wrote:
On 8/21/2025 5:40 PM, André G. Isaak wrote:
On 2025-08-21 16:25, olcott wrote:
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
The above is meaningless. Learn the notation.
That you do not understand the notation does
not entail that it is meaningless.
You've got Ĥ.q0 transitioning to two distinct things (Ĥ.∞ & Ĥ.qn).
That's a contradiction. You need to specify the conditions under which
each transition occurs. You've been corrected on this many times in
the past and yet you continue to make the same error.
That is all in the Linz proof https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.∞ is the conventional HP proof halts
Ĥ.qn is the conventional HP proof does not halt
I have demonstrated that the transition
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
would be correct.
Even if it is correct, if your decider can't actually give this
result without relying on static data then it doesn't achieve what
you have claimed to achieve.
No one has ever accomplished this much.
All of the proofs previously had the return values
of yes and no both being the wrong answer.
No. The proofs all claim that there is a single correct answer but
that this is not the answer which the putative halt decider gives
when given the unsolvable input constructed from that decider.
AKA both Boolean values that it gives are the wrong answer.
Every yes/no having no correct yes/no answer (within the
full context of the question that includes who is being asked)
is an incorrect question.
It only gives one boolean value if it gives an answer at all. The only
way for it to give the opposite boolean value is for you to redesign
the TM in which case you are no longer dealing with the same H/D pair.
André
If I ask you a question and you answer yes
or you answer no you are not two distinctly
separate human beings.
On 8/21/2025 3:57 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 2:18 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 1:16 PM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/21/2025 10:44 AM, Kaz Kylheku wrote:
On 2025-08-21, olcott <polcott333@gmail.com> wrote:
On 8/20/2025 10:33 PM, Richard Heathfield wrote:
The conventional proof does not require the existence of the >>>>>>>>>> input youCite your sources.
describe,
I have been studying this for 22 years
and never saw a proof that did not require
an input to do or say the opposite of what
its decider says.
You've been studying it wrong. The input contains its own copy of a >>>>>>>> certain decider. Which decider it contains does not vary with the >>>>>>>> decider being applied to that input.
The embedded decider may be a clean-room implementation of the >>>>>>>> algorithm description developed by the author of the input,
based on a description of the decider.
(Needless to say, it is not valid for a decider algorithm to have >>>>>>>> elements like "look at your own code bytes to share mutable
state with another running implementation of the decider".)
I know that. You taught me that.
I don't currently know how to change my code so that
HHH can see the recursive simulation execution traces
of DD without the use of static data.
OK, but that's like saying, I currently don't know how to run a 10 km >>>>>> footrace in under 37 minutes without cutting the course, so for now, >>>>>> until I find better training methods, I hope you all don't mind me >>>>>> getting my age group wins that way.
None-the-less correct analysis of this text
does prove that HHH(DD)==0 is correct
Well, yes HHH_toplevel(DD) == 0 is correct, since DD doesn't terminate. >>>> HHH_toplevel(DD) == 0 is not only a description of what the correct
result should be, but but what actually /happens/. Yes, great!
Problem is that DD() calls HHH_embedded(DD). HHH_embedded(DD) does /
not/
return 0, because then DD() would terminate, which would make
HHH_toplevel wrong.
DD correctly simulated by HHH cannot possibly
ever stop running (not counting OOM error) unless
aborted.
You must understand a little of my x86utm operating
system architecture to even understand that HHH
can simulate an instance of itself simulating an
instance of DD when its own instance of DD calls
HHH(DD).
Yes it /can/. Your architecture supports it. Only problem is that when
you do it cleanly, you run into nontermination,
Hence proving that HHH(DD)==0 is correct.
and so you diddled HHH
with static data that changes. Yet you're still equivocating on it,
describing with language that reveals a belief that there is only
one HHH. That's what your "instance of itself" phrase in your
above paragraph is doing.
There is only one HHH, the rest are data manipulated
by this one HHH.
When you have the mutating static data whose value alters the
control flow in HHH, there is no "itself" any more.
*It does not alter the control flow during the simulation*
It merely recognizes that DD correctly simulated
by HHH cannot possibly stop running without being
aborted and then aborts DD preventing an OOM error.
The top level HHH is
not simulating "and instance of itself" when it simulates DDD, because
the HHH called by DDD is no longer equivalent to itself.
When we abandon the static data that fact that DD()
never halts proves that HHH(DD)==0 is correct.
Without the static variable cheating, your UTM system is just an
elaborate
monument to the Halting Theorem.
No one else ever figured out any way that HHH(DD)==0 is
correct. Now all that I need to do is find a way for HHH
to detect the repeating state of its input that everyone
else can see.
It is great talking to you about these things because
I know that you are competent and not playing Trollish
head games like most of the reviewers on this forum.
With the static variable cheating, it is inescapably such a monument;
only you're falsly claiming that it isn't.
On 8/21/2025 5:40 PM, André G. Isaak wrote:That’s still a tautology: „HHH simulates DD the way it does it”. The
On 2025-08-21 16:25, olcott wrote:
On 8/21/2025 5:16 PM, André G. Isaak wrote:
On 2025-08-21 15:26, olcott wrote:
On 8/21/2025 4:05 PM, Kaz Kylheku wrote:
HHH(DD) maps its input to DD correctly simulated by HHH and reports
the same result regardless of its execution context.
As a C function DD is most certainly computable. You should make theDD that need not be a computable function has different behavior
depending on its process context.
That is indication of a bug.He knows that a mutable static variable is responsible for theThe behavior of DD correctly simulated by HHH remains the same
discrepancy which makes this actually happen in his implementation, >>>>>> and that he's failed to find a way to get rid of it.
non-halting behavior. Without the static data the current HHH cannot >>>>> see this behavior.
That you do not understand the notation does not entail that it is meaningless.Explain it.
No, DD definitely halts, and HHH could just return that.No. The proofs all claim that there is a single correct answer but thatAKA both Boolean values that it gives are the wrong answer. Every yes/no having no correct yes/no answer (within the full context of the question
this is not the answer which the putative halt decider gives when given
the unsolvable input constructed from that decider.
that includes who is being asked) is an incorrect question.
No, DD definitely halts, and HHH could just return that.
On 8/22/2025 3:15 AM, joes wrote:
On 2025-08-21 15:26, olcott wrote:
The behavior of DD correctly simulated by HHH remains the
same
non-halting behavior. Without the static data the current
HHH cannot
see this behavior.
That is indication of a bug.
It is not a bug. It is perfectly legitimate in
and does its job in C.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // input halts state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // does not halt state
On 8/22/2025 3:35 AM, Richard Heathfield wrote:
On 22/08/2025 09:15, joes wrote:
<snip>
No, DD definitely halts, and HHH could just return that.
Because HH returns 0 DD, the C function (to distinguish it from
its pale simulated shadow), unquestioningly and indubitably
halts. HHH ought to report this by returning 1, but if it does
so, DD, the C function, no longer halts. HHH has an impossible
task; whatever it decides is wrong.
Olcott's position appears to be that whatever the simulation
does is the right answer /by definition/, and that the actual
code of DD (which it largely ignores) is neither here not there
because, being invisible to HHH, it is never simulated.
I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a position.
Turing machine deciders only compute the mapping
from their inputs...
It was always a confused mistake to assume the Dennis Bush
position that a halt decider must report on the behavior
of the non-input direct execution of M applied to ⟨M⟩.
On 8/22/2025 10:18 AM, André G. Isaak wrote:
On 2025-08-22 08:29, olcott wrote:
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // input halts state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // does not halt state
OK. Now you're at least adding something to suggest when Ĥ.q0
transitions to Ĥ.∞ and when it transitions to Ĥ.qn, but you're adding
your conditions as comments. These are not comments, they are a
required part of the notation. You always need to include the conditions.
On its own, a line like
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
When ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H
reaches its own simulated final halt state of ⟨Ĥ.qn⟩.
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
When ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H cannot
possibly reach its own simulated final halt state of ⟨Ĥ.qn⟩.
<snip>
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:The DD that is directly executed at the same time can.
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more >>>>>>>>>>>> credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>> no DD can possibly reach its own emulated final state state. >>>>>>>>>>
HHH(DD) is not accountable for the behavior of its caller
No, but the author of HHH is accountable for the behavour of HHH. >>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of
another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual
meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem".
Turing machine deciders only compute the mapping
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
There never has been any ACTUAL INPUT that
does the opposite of whatever its decider decides.
On 8/26/2025 4:38 PM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
There never has been any ACTUAL INPUT that
does the opposite of whatever its decider decides.
So what has there been that does the opposite of whatever
its decider decides?
In the case of HHH/DD
When DD() is directly executed it is the caller
of HHH(DD) thus not its input static finite string
of x86 machine code that does the opposite.
In the case of Linz it is the machine that
Ĥ.embedded_H is embedded within that does the opposite.
On 8/26/2025 4:38 PM, Kaz Kylheku wrote:A string doesn’t do anything. If a program isn’t the input, an input isn’t a program.
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
In the case of HHH/DD When DD() is directly executed it is the caller of HHH(DD) thus not its input static finite string of x86 machine code thatThere never has been any ACTUAL INPUT that does the opposite ofSo what has there been that does the opposite of whatever its decider
whatever its decider decides.
decides?
does the opposite.
In the case of Linz it is the machine that Ĥ.embedded_H is embeddedI.e. Ĥ.
within that does the opposite.
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour of HHH. >>>>>>>>>>
On 2025-08-14 17:26:59 +0000, olcott said:
On 8/14/2025 4:24 AM, Mikko wrote:The DD that is directly executed at the same time can.
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>> no DD can possibly reach its own emulated final state state. >>>>>>>>>>>>
HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of
another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual
meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem".
Turing machine deciders only compute the mapping
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
There never has been any ACTUAL INPUT that
does the opposite of whatever its decider decides.
On 2025-08-26 16:22:48 +0000, olcott said:
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle
implies a contradiction.
On 8/27/2025 12:42 AM, Kaz Kylheku wrote:
The directly executed DD() and the DD analyzed by HHH must be the same
item, behaving the same way; if they are not, something is screwed up,
and further argumentation from those screwed-up circumstances is
fallacious.
Now that I think that I can see how to make HHH(DD)
a pure function of its input I have a better basis to
disagree.
If HHH(DD) can somehow find a way to report on the
recursive simulation structural relationship between
HHH and DD this gives the outermost HHH the basis to
reject its input as non-halting.
You still have not commented on whether or not that
you can see that DD correctly simulated by HHH cannot
possibly reach its own simulated "return" instruction
final halt state.
Linz is tedious to follow compared to the simple version of halting
using functions, and their considerable notational advantage.
Yet many reviewers think that the C stuff is nonsense
because the HP is about TM's. Because of this I show
a mapping between them.
GOOD! This same relationship holds even if HHH(DD)
recognizes the repeating pattern and aborts DD on
this basis. In this case HHH(DD)==0 is correct and
DD() halts.
I postponed work on making HHH(DD) a pure function
of its inputs until after people first understood
that HHH(DD)==0 is correct.
A correct static analysis of the above proves that
HHH(DD)==0 is correct. When HHH performs this static
analysis itself it can correctly return 0.
On 8/27/2025 1:12 PM, Richard Heathfield wrote:
On 27/08/2025 18:47, olcott wrote:
<snip>
GOOD! This same relationship holds even if HHH(DD)
recognizes the repeating pattern and aborts DD on
this basis. In this case HHH(DD)==0 is correct and
DD() halts.
And therefore HHH should return 1 because DD halts.
I postponed work on making HHH(DD) a pure function
of its inputs until after people first understood
that HHH(DD)==0 is correct.
You have at last admitted that DD halts. Well done.
Because DD halts, HHH should return 1.
As you already agreed that is not the behavior that
the input to HHH(DD) specifies,
thus you are wrong and know you are wrong.
On 8/27/2025 1:43 PM, Richard Heathfield wrote:
On 27/08/2025 19:17, olcott wrote:
On 8/27/2025 1:12 PM, Richard Heathfield wrote:
On 27/08/2025 18:47, olcott wrote:
<snip>
GOOD! This same relationship holds even if HHH(DD)
recognizes the repeating pattern and aborts DD on
this basis. In this case HHH(DD)==0 is correct and
DD() halts.
And therefore HHH should return 1 because DD halts.
I postponed work on making HHH(DD) a pure function
of its inputs until after people first understood
that HHH(DD)==0 is correct.
You have at last admitted that DD halts. Well done.
Because DD halts, HHH should return 1.
As you already agreed that is not the behavior that
the input to HHH(DD) specifies,
Excuse me? I've agreed that HHH spirals down into infinite
recursion.
Yes that is it. Thus HHH seeing this rejects DD as non-halting.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 27/08/2025 08:58, Mikko wrote:[Python code snipped]
On 2025-08-26 16:22:48 +0000, olcott said:
<snip>
That is the same as the proof usingIt is similar. The assumption of the existence of a square circle
the radius of a square circle.
implies a contradiction.
Not if you define what you mean.
import numpy as np
import matplotlib.pyplot as plt
That plots a "squircle", a figure that is neither a square nor a circle. Calling it a "square circle" is, I suggest, incorrect.
On 8/27/2025 12:42 AM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
On 8/26/2025 4:38 PM, Kaz Kylheku wrote:
On 2025-08-26, olcott <polcott333@gmail.com> wrote:
There never has been any ACTUAL INPUT that
does the opposite of whatever its decider decides.
So what has there been that does the opposite of whatever
its decider decides?
In the case of HHH/DD
When DD() is directly executed it is the caller
of HHH(DD) thus not its input static finite string
of x86 machine code that does the opposite.
Sorry, I don't get it.
If DD is a pure function (as required), the expression DD() denotes
exactly the same computation, no matter where it is planted
(other than if it's planted into some lexical scope where the name DD is
shadowed, something we are no concerned with). In any scope where DD
resolves to the same function, DD() is exactly the same calculation.
Exactly the same observation holds for the expression HHH(DD), if HHH is
a pure function.
Pure functions don't know who their caller is, how hwo many levels they
are recursed, beneath what, ...
Exactly so when a halt decider is required
to report on the behavior of its caller this
requirement is incorrect.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Definition of Turing Machine Ĥ applied
to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
*if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*if Ĥ applied to ⟨Ĥ⟩ does not halt*
The highlighted lines require Ĥ.embedded_H
to report on the behavior of their caller Ĥ.q0 ⟨Ĥ⟩
Likewise the equivalent Turing Machines do not know about
the circumstnaces of what put together their tape and
set them in motion.
Those are implementation details outside of the mathematical
abstraction.
It is an error like confusing, say, the function sin(θ) with a
blackboard graph of it and saying things like this sin(θ) knows that it
is plotted closer to the edge of the blackboard, compared to
that other sin(θ).
The directly executed DD() and the DD analyzed by HHH must be the same
item, behaving the same way; if they are not, something is screwed up,
and further argumentation from those screwed-up circumstances is
fallacious.
Now that I think that I can see how to make HHH(DD)
a pure function of its input I have a better basis to
disagree.
If HHH(DD) can somehow find a way to report on the
recursive simulation structural relationship between
HHH and DD this gives the outermost HHH the basis to
reject its input as non-halting.
You still have not commented on whether or not that
you can see that DD correctly simulated by HHH cannot
possibly reach its own simulated "return" instruction
final halt state.
Until you acknowledge that you understand this we
cannot proceed to the next step.
In the case of Linz it is the machine that
Ĥ.embedded_H is embedded within that does the opposite.
I simply don't see an embedded_H in the Linz reference.
⟨M⟩ Turing machine description of machine M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.
*From the bottom of page 319* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.
*Has been adapted to this*
Template of machine M applied to ⟨M⟩
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
*Repeats until aborted*
(a) M copies its input ⟨M⟩
(b) M invokes embedded_H ⟨M⟩ ⟨M⟩
(c) embedded_H simulates ⟨M⟩ ⟨M⟩
Linz is tedious to follow compared to the simple version of halting
using functions, and their considerable notational advantage.
Yet many reviewers think that the C stuff is nonsense
because the HP is about TM's. Because of this I show
a mapping between them.
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour of HHH. >>>>>>>>>>>>
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:The DD that is directly executed at the same time can. >>>>>>>>>>>>
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more instances of your
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state state. >>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>> another term. To give the same term two different definitions
in the same scope or in overlapping scopes is an error. It is
also an error to define a term and then to use it in its usual >>>>>>>> meaning.
If you define the term "halting problem" differently from the
usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem". >>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle implies
a contradiction. Likewise, the assumption of a the existence of a halting
decider implies a contradiction.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour >>>>>>>>>>>>> of HHH.
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said:
*This is the generic HHH that I told the LLM systems >>>>>>>>>>>>>>>>>> about*
Simulating Termination Analyzer HHH correctly >>>>>>>>>>>>>>>>>> simulates its input until:
(a) Detects a non-terminating behavior pattern: abort >>>>>>>>>>>>>>>>>> simulation and return 0.
(b) Simulated input reaches its simulated "return" >>>>>>>>>>>>>>>>>> statement: return 1.
*It is the same one that I refer to here*
For each instance of your generic DD there are more >>>>>>>>>>>>>>>>> instances of your
generic HHH saying that it halts than there are >>>>>>>>>>>>>>>>> instances that say it
doesn't halt. Both can't be right but the majority >>>>>>>>>>>>>>>>> opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state >>>>>>>>>>>>>>>> state.
The DD that is directly executed at the same time can. >>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition.
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>> another term. To give the same term two different definitions >>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>> usual definition then you merely declare that you are don't
say anything about what is usually called the "halting problem". >>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle
implies
a contradiction. Likewise, the assumption of a the existence of a
halting
decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
On 8/28/25 3:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour of HHH.
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:The DD that is directly executed at the same time can. >>>>>>>>>>>>>>
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more instances of your
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state state. >>>>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition. >>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>> say anything about what is usually called the "halting problem". >>>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle implies >>>> a contradiction. Likewise, the assumption of a the existence of a halting >>>> decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
Linz doesn't HAVE an embedded_H, only a copy of H that, by definition,
does the same thing as H, and the same requirements.
On 8/28/2025 2:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour of HHH.
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:The DD that is directly executed at the same time can. >>>>>>>>>>>>>>
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more instances of your
*This is the generic HHH that I told the LLM systems about* >>>>>>>>>>>>>>>>>>>
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state state. >>>>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition. >>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>> say anything about what is usually called the "halting problem". >>>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle implies >>>> a contradiction. Likewise, the assumption of a the existence of a halting >>>> decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
*Here he is making those assumptions*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
*if M applied to WM halts, and*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
*if M applied to WM does not halt*
On 2025-08-28 10:56:41 +0000, Richard Damon said:
On 8/28/25 3:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour >>>>>>>>>>>>>>> of HHH.
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more >>>>>>>>>>>>>>>>>>> instances of your
*This is the generic HHH that I told the LLM systems >>>>>>>>>>>>>>>>>>>> about*
Simulating Termination Analyzer HHH correctly >>>>>>>>>>>>>>>>>>>> simulates its input until:
(a) Detects a non-terminating behavior pattern: >>>>>>>>>>>>>>>>>>>> abort simulation and return 0.
(b) Simulated input reaches its simulated "return" >>>>>>>>>>>>>>>>>>>> statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are >>>>>>>>>>>>>>>>>>> instances that say it
doesn't halt. Both can't be right but the majority >>>>>>>>>>>>>>>>>>> opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state >>>>>>>>>>>>>>>>>> state.
The DD that is directly executed at the same time can. >>>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition. >>>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>>> say anything about what is usually called the "halting problem". >>>>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually >>>>>>> constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle
implies
a contradiction. Likewise, the assumption of a the existence of a
halting
decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
Linz doesn't HAVE an embedded_H, only a copy of H that, by definition,
does the same thing as H, and the same requirements.
I interpreted Olcott's "embedded_H" to mean the copy of H contained in Ĥ.
It needn't be an exact copy, just functionally equivalent.
On 8/29/2025 2:11 AM, Mikko wrote:
On 2025-08-28 10:56:41 +0000, Richard Damon said:
On 8/28/25 3:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:You don't have the authority to change the definition. >>>>>>>>>>>>>>
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the >>>>>>>>>>>>>>>> behavour of HHH.
On 2025-08-14 17:26:59 +0000, olcott said: >>>>>>>>>>>>>>>>>>HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more >>>>>>>>>>>>>>>>>>>> instances of your
*This is the generic HHH that I told the LLM >>>>>>>>>>>>>>>>>>>>> systems about*
Simulating Termination Analyzer HHH correctly >>>>>>>>>>>>>>>>>>>>> simulates its input until:
(a) Detects a non-terminating behavior pattern: >>>>>>>>>>>>>>>>>>>>> abort simulation and return 0.
(b) Simulated input reaches its simulated "return" >>>>>>>>>>>>>>>>>>>>> statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are >>>>>>>>>>>>>>>>>>>> instances that say it
doesn't halt. Both can't be right but the majority >>>>>>>>>>>>>>>>>>>> opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state >>>>>>>>>>>>>>>>>>> state.
The DD that is directly executed at the same time can. >>>>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec* >>>>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>>>> say anything about what is usually called the "halting >>>>>>>>>>>> problem".
Turing machine deciders only compute the mapping
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually >>>>>>>> constructed for some decider is irrelevant. The proof uses the >>>>>>>> possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle
implies
a contradiction. Likewise, the assumption of a the existence of a
halting
decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
Linz doesn't HAVE an embedded_H, only a copy of H that, by
definition, does the same thing as H, and the same requirements.
I interpreted Olcott's "embedded_H" to mean the copy of H contained in Ĥ. >> It needn't be an exact copy, just functionally equivalent.
Its stipulated to be an exact copy.
On 8/28/2025 2:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour >>>>>>>>>>>>>> of HHH.
On 2025-08-14 17:26:59 +0000, olcott said:HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more >>>>>>>>>>>>>>>>>> instances of your
*This is the generic HHH that I told the LLM systems >>>>>>>>>>>>>>>>>>> about*
Simulating Termination Analyzer HHH correctly >>>>>>>>>>>>>>>>>>> simulates its input until:
(a) Detects a non-terminating behavior pattern: abort >>>>>>>>>>>>>>>>>>> simulation and return 0.
(b) Simulated input reaches its simulated "return" >>>>>>>>>>>>>>>>>>> statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are >>>>>>>>>>>>>>>>>> instances that say it
doesn't halt. Both can't be right but the majority >>>>>>>>>>>>>>>>>> opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state >>>>>>>>>>>>>>>>> state.
The DD that is directly executed at the same time can. >>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec*
You don't have the authority to change the definition. >>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>> say anything about what is usually called the "halting problem". >>>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually
constructed for some decider is irrelevant. The proof uses the
possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle
implies
a contradiction. Likewise, the assumption of a the existence of a
halting
decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
*Here he is making those assumptions*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
*if M applied to WM halts, and*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
*if M applied to WM does not halt*
On 8/29/2025 2:16 AM, Mikko wrote:
On 2025-08-28 14:33:48 +0000, olcott said:
On 8/28/2025 2:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf*From the bottom of page 319 has been adapted to this*
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
*Here he is making those assumptions*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
*if M applied to WM halts, and*
q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
*if M applied to WM does not halt*
Those are not assumpitons. They are a part of the definition 12.1,
which defines the halting problem.
Yes and Linz could have equally defined the radius
of a square circle to be the length of one of its
four equal length sides / π.
On 8/29/2025 2:11 AM, Mikko wrote:
On 2025-08-28 10:56:41 +0000, Richard Damon said:
On 8/28/25 3:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:Turing machine deciders only compute the mapping
On 8/17/2025 3:45 AM, Mikko wrote:
On 2025-08-16 12:00:57 +0000, olcott said:
On 8/16/2025 2:17 AM, Mikko wrote:You don't have the authority to change the definition. >>>>>>>>>>>>>>
On 2025-08-15 12:17:04 +0000, olcott said:
On 8/15/2025 3:34 AM, Mikko wrote:No, but the author of HHH is accountable for the behavour of HHH.
On 2025-08-14 17:26:59 +0000, olcott said: >>>>>>>>>>>>>>>>>>HHH(DD) is not accountable for the behavior of its caller >>>>>>>>>>>>>>>>
On 8/14/2025 4:24 AM, Mikko wrote:
On 2025-08-13 15:29:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
For each instance of your generic DD there are more instances of your
*This is the generic HHH that I told the LLM systems about*
Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.
*It is the same one that I refer to here* >>>>>>>>>>>>>>>>>>>>
generic HHH saying that it halts than there are instances that say it
doesn't halt. Both can't be right but the majority opinion is more
credible.
When N steps of DD are correctly emulated by generic HHH >>>>>>>>>>>>>>>>>>> no DD can possibly reach its own emulated final state state.
The DD that is directly executed at the same time can. >>>>>>>>>>>>>>>>
HHH(DD)==0 and DD() halts.
Which shows that HHH is not a halting decider.
*Correcting the error of the halting problem spec* >>>>>>>>>>>>>>
As soon as I point out that it is inconsistent
with other theory of computation definitions:
Turing machine deciders only compute the mapping
from their inputs,
then this inconsistency *is* the authority.
That is neither a definition nor an inconsistency.
The definition of one term cannot contradict the definition of >>>>>>>>>>>> another term. To give the same term two different definitions >>>>>>>>>>>> in the same scope or in overlapping scopes is an error. It is >>>>>>>>>>>> also an error to define a term and then to use it in its usual >>>>>>>>>>>> meaning.
If you define the term "halting problem" differently from the >>>>>>>>>>>> usual definition then you merely declare that you are don't >>>>>>>>>>>> say anything about what is usually called the "halting problem". >>>>>>>>>>>
from their inputs...
True but irrelevant.
The actual input that "does the opposite" of whatever
the decider decides has never been an actual input.
For every decider one can be constructed. Whether it is actually >>>>>>>> constructed for some decider is irrelevant. The proof uses the >>>>>>>> possibility.
That is the same as the proof using
the radius of a square circle.
It is similar. The assumption of the existence of a square circle implies
a contradiction. Likewise, the assumption of a the existence of a halting
decider implies a contradiction.
So we agree.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.∞,
if M applied to ⟨M⟩ halts, and
M.q0 ⟨M⟩ ⊢* M.embedded_H ⟨M⟩ ⟨M⟩ ⊢* M.qn
if M applied to ⟨M⟩ does not halt.
At least in the case of the HP proofs the
assumption that M.embedded_H must report
on the behavior of M applied to ⟨M⟩ is incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to
those proofs.
Linz doesn't HAVE an embedded_H, only a copy of H that, by definition,
does the same thing as H, and the same requirements.
I interpreted Olcott's "embedded_H" to mean the copy of H contained in Ĥ. >> It needn't be an exact copy, just functionally equivalent.
Its stipulated to be an exact copy.
On 8/29/2025 2:11 AM, Mikko wrote:
On 2025-08-28 10:56:41 +0000, Richard Damon said:
On 8/28/25 3:27 AM, Mikko wrote:
On 2025-08-27 15:04:36 +0000, olcott said:
On 8/27/2025 2:58 AM, Mikko wrote:
On 2025-08-26 16:22:48 +0000, olcott said:
On 8/26/2025 4:20 AM, Mikko wrote:
On 2025-08-19 14:46:06 +0000, olcott said:
On 8/19/2025 2:15 AM, Mikko wrote:
On 2025-08-18 17:39:11 +0000, olcott said:
On 8/18/2025 3:55 AM, Mikko wrote:
On 2025-08-17 15:34:28 +0000, olcott said:
It is consistent to compute the direct execution from the description.As soon as I point out that it is inconsistent with other >>>>>>>>>>>>> theory of computation definitions:
Turing machine deciders only compute the mapping from their >>>>>>>>>>>>> inputs, then this inconsistency *is* the authority.
You might want to fix that grammar.*From the bottom of page 319 has been adapted to this*
Its stipulated to be an exact copy.At least in the case of the HP proofs the assumption that
M.embedded_H must report on the behavior of M applied to ⟨M⟩ is
incorrect.
Linz does not make any such assumptions, nor do other authors who
present a similar proof. Therefore the issue is not relevant to those
proofs.
Linz doesn't HAVE an embedded_H, only a copy of H that, by definition,
does the same thing as H, and the same requirements.
I interpreted Olcott's "embedded_H" to mean the copy of H contained in
Ĥ. It needn't be an exact copy, just functionally equivalent.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 160:04:41 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,056 |
| Messages: | 6,416,492 |