On 1/15/24 9:46 AM, olcott wrote:
> On 1/15/2024 3:47 AM, Fred. Zwarts wrote:
>> Op 14.jan.2024 om 21:05 schreef olcott:
>>> On 1/14/2024 1:10 PM, Richard Damon wrote:
>>>> On 1/14/24 1:51 PM, olcott wrote:
>>>>> On 1/14/2024 12:31 PM, immibis wrote:
>>>>>> On 1/14/24 16:31, olcott wrote:
>>>>>>> On 1/14/2024 4:42 AM, Mikko wrote:
>>>>>>>> On 2024-01-14 00:22:10 +0000, olcott said:
>>>>>>>>
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, whether an input finite string pair of program/input
>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>> terminate
>>>>>>>>> normally.
>>>>>>>>
>>>>>>>> The definition of the halting problem does not specify "normally".
>>>>>>>> Termination just means a situation where continuation is not
>>>>>>>> possible.
>>>>>>>> Non-termination means that such situation does ever occur even when
>>>>>>>> the program runs forever.
>>>>>>>>
>>>>>>>
>>>>>>> computation that halts… “the Turing machine will halt whenever it
>>>>>>> enters a final state” (Linz:1990:234)  In other words Line 06 of
>>>>>>> D shown below.
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>> Automata. Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>
>>>>>>> Most people here are making the mistake of believing that when
>>>>>>> the simulation of D is aborted then this simulated D halts.
>>>>>>
>>>>>> Nobody is making this mistake. You are making the mistake of
>>>>>> believing that if the simulation is aborted then the directly
>>>>>> executed D does not halt OR you are making the mistake of
>>>>>> believing that a simulation which differs from a direct execution
>>>>>> can possibly be correct.
>>>>>
>>>>> Mike Terry agrees that every step of the older H that simulates
>>>>> itself simulating D is correct. He examined the x86 machine code
>>>>> to verify this.
>>>>>
>>>>
>>>> Which makes it a correct PARTIAL simulation, not a correct simulation.
>>>>
>>>> Thus, your logic is still invalid.
>>>>
>>>> H has NOT correctly determined that a correct simulation of the
>>>> input would not halt.
>>>
>>> Anyone that is an expert at the C programming language
>>> can verify that this execution trace proves that D
>>> correctly simulated by H never reaches its own simulated
>>> line 06.
>>>
>>> 01 int D(ptr x)  // ptr is pointer to int function
>>> 02 {
>>> 03   int Halt_Status = H(x, x);
>>> 04   if (Halt_Status)
>>> 05     HERE: goto HERE;
>>> 06   return Halt_Status;
>>> 07 }
>>> 08
>>> 09 void main()
>>> 10 {
>>> 11   H(D,D);
>>> 12 }
>>>
>>> *Execution Trace*
>>> Line 11: main() invokes H(D,D);
>>>
>>> *keeps repeating* (unless aborted) > Line 03: simulated D(D) invokes
>>> simulated H(D,D) that simulates D(D)
>>
>> Apparently, Olcott does not realize that H does abort. Because of that
>> "*keeps repeating* (unless aborted)" can be replaced with "Does not
>> repeat".
>>
>>>
>>> *Simulation invariant*
>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>
>> And apparently he does not realize that that H, which is part of D and
>> therefore part of the input, does return, so that D continues with
>> line 04.
>>
>> I an afraid he will never understand this and just keeps repeating
>> (unless aborted).
>
> The function named D *correctly simulated by H* cannot possibly
> reach its own line 06 (final state) and halt. If a function
> does not reach its own final state then IT DOES NOT HALT.
>

And an H that correctly simulats the input can't answer.

Since the H that D calls is the H that giv the H that claimes to give
the right answer (and not just the one that correctly simulates it)

Thus the D given to the H that answers is a different D then the one
that you claim correctly simulates its input.

Thus you are revealing either your insanity at thinking two different
things are the same, or that you are just a liar and claim that two
things you know are different are the same.

You are just proven to be a FAILURE.

On 1/15/24 7:05 PM, olcott wrote:
> On 1/15/2024 5:19 AM, immibis wrote:
>> On 1/15/24 10:47, Fred. Zwarts wrote:
>>> Op 14.jan.2024 om 21:05 schreef olcott:
>>>>
>>>> *keeps repeating* (unless aborted) > Line 03: simulated D(D) invokes
>>>> simulated H(D,D) that simulates D(D)
>>>
>>> Apparently, Olcott does not realize that H does abort. Because of
>>> that "*keeps repeating* (unless aborted)" can be replaced with "Does
>>> not repeat".
>>
>> Olcott's "aborted" means the outermost simulation layer chooses to
>> abort the simulation. Because of his design, the outermost simulation
>> can choose to abort, but the inner simulations know they are inner
>> simulations and will never abort. Of course, this leads to an
>> incorrect halting decision.
>>
>> The outer H can be said to correctly decide the inner D doesn't abort,
>> but that means nothing since the inner D is a different program than
>> the one which it was asked to evaluate.
>
> The inner simulations never have enough information to abort.
> The outer simulation is always one recursive simulation
> ahead of the next inner one.

But the machine they are a simulation of DOES.

We don't care about the "simulation" that are being done, we care about
the actual machine.

>
> Introduction to the Theory of Computation 3rd Edition
> by Michael Sipser (Author)
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>
> If I was wrong then the best author of the best selling
> book on the theory of computation would not have agreed
> with this.
>
> On 10/13/2022 11:46 AM, olcott wrote:
> > MIT Professor Michael Sipser has agreed that the following
> > verbatim paragraph is correct (he has not agreed to anything
> > else in this paper):
> >
> > 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.
> >
> > When one accepts this definition of a simulating halt decider
> > then my code shows that H correctly determines the halt status
> > of D.
>
>

Right, and if H DOES correctly determine that a correct simulation of
the actual input would not halt, H can do that. Since H doesn't do an
actual correct simulation, you can't use its simulation, so you have no
grounds to actually abort.

IF you won the nobel peace prize, you would be famous.

You haven't, so you can claim to be famous based on that statement.

On 1/15/24 7:00 PM, olcott wrote:
> On 1/14/2024 11:23 PM, immibis wrote:
>> On 1/15/24 06:17, olcott wrote:
>>> On 1/14/2024 11:00 PM, immibis wrote:
>>>> On 1/14/24 19:53, olcott wrote:
>>>>> On 1/14/2024 12:37 PM, immibis wrote:
>>>>>> On 1/14/24 16:45, olcott wrote:
>>>>>>> On 1/14/2024 1:31 AM, immibis wrote:
>>>>>>>> On 1/14/24 01:22, olcott wrote:
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, whether an input finite string pair of program/input
>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>> terminate
>>>>>>>>> normally.
>>>>>>>>>
>>>>>>>>> 01 int D(ptr x)  // ptr is pointer to int function
>>>>>>>>> 02 {
>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>> 06   return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>>
>>>>>>>>> The input to H(D,D) specifies that D calls its own termination
>>>>>>>>> analyzer as a part of this computation. The prior definition
>>>>>>>>> of the halting problem allowed people to incorrectly ignore this.
>>>>>>>>>
>>>>>>>>> A decider computes the mapping from its input...
>>>>>>>>> *The prior definition of the halting problem ignored this*
>>>>>>>>>
>>>>>>>>
>>>>>>>> your definition still ignores it
>>>>>>>
>>>>>>>  >>>whether an input finite string pair of program/input
>>>>>>> specifies a computation that would reach a final state<<<
>>>>>>>
>>>>>>> All deciders are required to compute the mapping from their inputs
>>>>>>> in this case on the basis of the behavior SPECIFIED by this input.
>>>>>>
>>>>>> do you understand waht these words mean?
>>>>>>
>>>>>>>
>>>>>>> *This input specifies that it calls H in recursive simulation*
>>>>>>
>>>>>> your input in x86utm does. Linz's input which is a Turing machine
>>>>>> does not. His one is actually a modified copy of H.
>>>>>>
>>>>>
>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>> own simulated final state of ⟨Ĥ.qn⟩.
>>>>
>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>> own simulated final state of ⟨Ĥ.qy⟩.
>>>>
>>>
>>> This state has an infinite loop appended, thus it is not a final state.
>>>
>> My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
>> its own simulated state of ⟨Ĥ.qy⟩.
>
> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.
>

And an embeeded_H that correctly simulates its input can not answer, so
isn't a Halt Decider.

You are just admitting your failure.

On 1/16/24 01:00, olcott wrote:
> On 1/14/2024 11:23 PM, immibis wrote:
>> On 1/15/24 06:17, olcott wrote:
>>> On 1/14/2024 11:00 PM, immibis wrote:
>>>> On 1/14/24 19:53, olcott wrote:
>>>>> On 1/14/2024 12:37 PM, immibis wrote:
>>>>>> On 1/14/24 16:45, olcott wrote:
>>>>>>> On 1/14/2024 1:31 AM, immibis wrote:
>>>>>>>> On 1/14/24 01:22, olcott wrote:
>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>> determining, whether an input finite string pair of program/input
>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>> terminate
>>>>>>>>> normally.
>>>>>>>>>
>>>>>>>>> 01 int D(ptr x)  // ptr is pointer to int function
>>>>>>>>> 02 {
>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>> 06   return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>>
>>>>>>>>> The input to H(D,D) specifies that D calls its own termination
>>>>>>>>> analyzer as a part of this computation. The prior definition
>>>>>>>>> of the halting problem allowed people to incorrectly ignore this.
>>>>>>>>>
>>>>>>>>> A decider computes the mapping from its input...
>>>>>>>>> *The prior definition of the halting problem ignored this*
>>>>>>>>>
>>>>>>>>
>>>>>>>> your definition still ignores it
>>>>>>>
>>>>>>>  >>>whether an input finite string pair of program/input
>>>>>>> specifies a computation that would reach a final state<<<
>>>>>>>
>>>>>>> All deciders are required to compute the mapping from their inputs
>>>>>>> in this case on the basis of the behavior SPECIFIED by this input.
>>>>>>
>>>>>> do you understand waht these words mean?
>>>>>>
>>>>>>>
>>>>>>> *This input specifies that it calls H in recursive simulation*
>>>>>>
>>>>>> your input in x86utm does. Linz's input which is a Turing machine
>>>>>> does not. His one is actually a modified copy of H.
>>>>>>
>>>>>
>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>> own simulated final state of ⟨Ĥ.qn⟩.
>>>>
>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>> own simulated final state of ⟨Ĥ.qy⟩.
>>>>
>>>
>>> This state has an infinite loop appended, thus it is not a final state.
>>>
>> My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
>> its own simulated state of ⟨Ĥ.qy⟩.
>
> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.
>

What does "correctly simulated" mean?

On 1/16/24 01:05, olcott wrote:
>
> The inner simulations never have enough information to abort.

They would if you didn't abort them. If you didn't abort the simulation
of them, they would abort, and then halt. Detecting them as non-halting
is incorrect.

On 1/16/2024 1:51 AM, immibis wrote:
> On 1/16/24 01:00, olcott wrote:
>> On 1/14/2024 11:23 PM, immibis wrote:
>>> On 1/15/24 06:17, olcott wrote:
>>>> On 1/14/2024 11:00 PM, immibis wrote:
>>>>> On 1/14/24 19:53, olcott wrote:
>>>>>> On 1/14/2024 12:37 PM, immibis wrote:
>>>>>>> On 1/14/24 16:45, olcott wrote:
>>>>>>>> On 1/14/2024 1:31 AM, immibis wrote:
>>>>>>>>> On 1/14/24 01:22, olcott wrote:
>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>> determining, whether an input finite string pair of program/input
>>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>>> terminate
>>>>>>>>>> normally.
>>>>>>>>>>
>>>>>>>>>> 01 int D(ptr x)  // ptr is pointer to int function
>>>>>>>>>> 02 {
>>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>>> 06   return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>>
>>>>>>>>>> The input to H(D,D) specifies that D calls its own termination
>>>>>>>>>> analyzer as a part of this computation. The prior definition
>>>>>>>>>> of the halting problem allowed people to incorrectly ignore this.
>>>>>>>>>>
>>>>>>>>>> A decider computes the mapping from its input...
>>>>>>>>>> *The prior definition of the halting problem ignored this*
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> your definition still ignores it
>>>>>>>>
>>>>>>>>  >>>whether an input finite string pair of program/input
>>>>>>>> specifies a computation that would reach a final state<<<
>>>>>>>>
>>>>>>>> All deciders are required to compute the mapping from their inputs
>>>>>>>> in this case on the basis of the behavior SPECIFIED by this input.
>>>>>>>
>>>>>>> do you understand waht these words mean?
>>>>>>>
>>>>>>>>
>>>>>>>> *This input specifies that it calls H in recursive simulation*
>>>>>>>
>>>>>>> your input in x86utm does. Linz's input which is a Turing machine
>>>>>>> does not. His one is actually a modified copy of H.
>>>>>>>
>>>>>>
>>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>>> own simulated final state of ⟨Ĥ.qn⟩.
>>>>>
>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>> own simulated final state of ⟨Ĥ.qy⟩.
>>>>>
>>>>
>>>> This state has an infinite loop appended, thus it is not a final state.
>>>>
>>> My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
>>> its own simulated state of ⟨Ĥ.qy⟩.
>>
>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.
>>
>
> What does "correctly simulated" mean?

Correctly simulated means that H correctly executes ear

_DD()
[00001c42] 55 push ebp
[00001c43] 8bec mov ebp,esp
[00001c45] 51 push ecx
[00001c46] 8b4508 mov eax,[ebp+08] ; DD
[00001c49] 50 push eax ; DD
[00001c4a] 8b4d08 mov ecx,[ebp+08] ; DD
[00001c4d] 51 push ecx ; DD
[00001c4e] e80ff7ffff call 00001362 ; HH
[00001c53] 83c408 add esp,+08
[00001c56] 8945fc mov [ebp-04],eax
[00001c59] 837dfc00 cmp dword [ebp-04],+00
[00001c5d] 7402 jz 00001c61
[00001c5f] ebfe jmp 00001c5f
[00001c61] 8b45fc mov eax,[ebp-04]
[00001c64] 8be5 mov esp,ebp
[00001c66] 5d pop ebp
[00001c67] c3 ret
Size in bytes:(0038) [00001c67]

01 int DD(void (*x)())
02 {
03 int Halt_Status = HH(x, x);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
07 }
08
09 int main()
10 {
11 Output("Input_Halts = ", HH(DD,DD));
12 }

Correct simulation means that the build-in third party x86
emulator emulates the above x86 instructions of DD as they
are specified in DD.

For HH this means that HH simulates itself simulating DD.
The detailed x86 execution trace proves that HH does
simulate itself simulating DD.

Begin Local Halt Decider Simulation Execution Trace Stored at:113027
[00001c42][00113013][00113017] 55 push ebp
[00001c43][00113013][00113017] 8bec mov ebp,esp
[00001c45][0011300f][00102fe3] 51 push ecx
[00001c46][0011300f][00102fe3] 8b4508 mov eax,[ebp+08] ; DD
[00001c49][0011300b][00001c42] 50 push eax ; DD
[00001c4a][0011300b][00001c42] 8b4d08 mov ecx,[ebp+08] ; DD
[00001c4d][00113007][00001c42] 51 push ecx ; DD
[00001c4e][00113003][00001c53] e80ff7ffff call 00001362 ; HH
New slave_stack at:14da47
[00001c42][0015da3b][0015da3f] 55 push ebp
[00001c43][0015da3b][0015da3f] 8bec mov ebp,esp
[00001c45][0015da37][0014da0b] 51 push ecx
[00001c46][0015da37][0014da0b] 8b4508 mov eax,[ebp+08] ; DD
[00001c49][0015da33][00001c42] 50 push eax ; DD
[00001c4a][0015da33][00001c42] 8b4d08 mov ecx,[ebp+08] ; DD
[00001c4d][0015da2f][00001c42] 51 push ecx ; DD
[00001c4e][0015da2b][00001c53] e80ff7ffff call 00001362 ; HH

main() invokes HH(DD,DD)
that simulates DD(DD)
that calls a simulated HH(DD,DD)
that simulates DD(DD)
that cannot possibly return to its caller.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/16/2024 1:54 AM, immibis wrote:
> On 1/16/24 01:05, olcott wrote:
>>
>> The inner simulations never have enough information to abort.
>
> They would if you didn't abort them.

The inner simulations are one recursive simulation away from
the next outer simulation.

This means that the outermost simulation always has one
recursive simulation more execution trace data than any
inner simulation.

The outermost simulation reaches its abort criteria one
recursive simulation sooner than the next inner one.

Since all of these simulations have identical code this
means that unless the outermost simulation aborts its
simulation then none of them do.

> If you didn't abort the simulation
> of them, they would abort, and then halt. Detecting them as non-halting
> is incorrect.

*Not possible as shown above*
You might not have enough technical skill to understand this.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/16/24 16:54, olcott wrote:
> On 1/16/2024 1:54 AM, immibis wrote:
>> On 1/16/24 01:05, olcott wrote:
>>>
>>> The inner simulations never have enough information to abort.
>>
>> They would if you didn't abort them.
>
> The inner simulations are one recursive simulation away from
> the next outer simulation.
>
> This means that the outermost simulation always has one
> recursive simulation more execution trace data than any
> inner simulation.
>
> The outermost simulation reaches its abort criteria one
> recursive simulation sooner than the next inner one.
>

The ONLY reason the inner simulation doesn't abort is that the outer
simulation aborts first.

If the outer simulation didn't abort the inner simulation would abort.

On 1/16/2024 6:11 PM, immibis wrote:
> On 1/16/24 16:54, olcott wrote:
>> On 1/16/2024 1:54 AM, immibis wrote:
>>> On 1/16/24 01:05, olcott wrote:
>>>>
>>>> The inner simulations never have enough information to abort.
>>>
>>> They would if you didn't abort them.
>>
>> The inner simulations are one recursive simulation away from
>> the next outer simulation.
>>
>> This means that the outermost simulation always has one
>> recursive simulation more execution trace data than any
>> inner simulation.
>>
>> The outermost simulation reaches its abort criteria one
>> recursive simulation sooner than the next inner one.
>>
>
> The ONLY reason the inner simulation doesn't abort is that the outer
> simulation aborts first.
>
> If the outer simulation didn't abort the inner simulation would abort.

You simply don't understand these things well enough.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/16/24 10:33 AM, olcott wrote:
> On 1/16/2024 1:51 AM, immibis wrote:
>> On 1/16/24 01:00, olcott wrote:
>>> On 1/14/2024 11:23 PM, immibis wrote:
>>>> On 1/15/24 06:17, olcott wrote:
>>>>> On 1/14/2024 11:00 PM, immibis wrote:
>>>>>> On 1/14/24 19:53, olcott wrote:
>>>>>>> On 1/14/2024 12:37 PM, immibis wrote:
>>>>>>>> On 1/14/24 16:45, olcott wrote:
>>>>>>>>> On 1/14/2024 1:31 AM, immibis wrote:
>>>>>>>>>> On 1/14/24 01:22, olcott wrote:
>>>>>>>>>>> In computability theory, the halting problem is the problem of
>>>>>>>>>>> determining, whether an input finite string pair of
>>>>>>>>>>> program/input
>>>>>>>>>>> specifies a computation that would reach a final state and
>>>>>>>>>>> terminate
>>>>>>>>>>> normally.
>>>>>>>>>>>
>>>>>>>>>>> 01 int D(ptr x)  // ptr is pointer to int function
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03   int Halt_Status = H(x, x);
>>>>>>>>>>> 04   if (Halt_Status)
>>>>>>>>>>> 05     HERE: goto HERE;
>>>>>>>>>>> 06   return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>>
>>>>>>>>>>> The input to H(D,D) specifies that D calls its own termination
>>>>>>>>>>> analyzer as a part of this computation. The prior definition
>>>>>>>>>>> of the halting problem allowed people to incorrectly ignore
>>>>>>>>>>> this.
>>>>>>>>>>>
>>>>>>>>>>> A decider computes the mapping from its input...
>>>>>>>>>>> *The prior definition of the halting problem ignored this*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> your definition still ignores it
>>>>>>>>>
>>>>>>>>>  >>>whether an input finite string pair of program/input
>>>>>>>>> specifies a computation that would reach a final state<<<
>>>>>>>>>
>>>>>>>>> All deciders are required to compute the mapping from their inputs
>>>>>>>>> in this case on the basis of the behavior SPECIFIED by this input.
>>>>>>>>
>>>>>>>> do you understand waht these words mean?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> *This input specifies that it calls H in recursive simulation*
>>>>>>>>
>>>>>>>> your input in x86utm does. Linz's input which is a Turing
>>>>>>>> machine does not. His one is actually a modified copy of H.
>>>>>>>>
>>>>>>>
>>>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>>>> own simulated final state of ⟨Ĥ.qn⟩.
>>>>>>
>>>>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
>>>>>> own simulated final state of ⟨Ĥ.qy⟩.
>>>>>>
>>>>>
>>>>> This state has an infinite loop appended, thus it is not a final
>>>>> state.
>>>>>
>>>> My bad. ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach
>>>> its own simulated state of ⟨Ĥ.qy⟩.
>>>
>>> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.
>>>
>>
>> What does "correctly simulated" mean?
>
> Correctly simulated means that H correctly executes ear
>
> _DD()
> [00001c42] 55         push ebp
> [00001c43] 8bec       mov ebp,esp
> [00001c45] 51         push ecx
> [00001c46] 8b4508     mov eax,[ebp+08] ; DD
> [00001c49] 50         push eax         ; DD
> [00001c4a] 8b4d08     mov ecx,[ebp+08] ; DD
> [00001c4d] 51         push ecx         ; DD
> [00001c4e] e80ff7ffff call 00001362    ; HH
> [00001c53] 83c408     add esp,+08
> [00001c56] 8945fc     mov [ebp-04],eax
> [00001c59] 837dfc00   cmp dword [ebp-04],+00
> [00001c5d] 7402       jz 00001c61
> [00001c5f] ebfe       jmp 00001c5f
> [00001c61] 8b45fc     mov eax,[ebp-04]
> [00001c64] 8be5       mov esp,ebp
> [00001c66] 5d         pop ebp
> [00001c67] c3         ret
> Size in bytes:(0038) [00001c67]
>
> 01 int DD(void (*x)())
> 02 {
> 03   int Halt_Status = HH(x, x);
> 04   if (Halt_Status)
> 05     HERE: goto HERE;
> 06   return Halt_Status;
> 07 }
> 08
> 09 int main()
> 10 {
> 11   Output("Input_Halts = ", HH(DD,DD));
> 12 }
>
> Correct simulation means that the build-in third party x86
> emulator emulates the above x86 instructions of DD as they
> are specified in DD.
>
> For HH this means that HH simulates itself simulating DD.
> The detailed x86 execution trace proves that HH does
> simulate itself simulating DD.
>
> Begin Local Halt Decider Simulation        Execution Trace Stored at:113027
> [00001c42][00113013][00113017] 55          push ebp
> [00001c43][00113013][00113017] 8bec        mov ebp,esp
> [00001c45][0011300f][00102fe3] 51          push ecx
> [00001c46][0011300f][00102fe3] 8b4508      mov eax,[ebp+08] ; DD
> [00001c49][0011300b][00001c42] 50          push eax         ; DD
> [00001c4a][0011300b][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
> [00001c4d][00113007][00001c42] 51          push ecx         ; DD
> [00001c4e][00113003][00001c53] e80ff7ffff  call 00001362    ; HH
> New slave_stack at:14da47
> [00001c42][0015da3b][0015da3f] 55          push ebp
> [00001c43][0015da3b][0015da3f] 8bec        mov ebp,esp
> [00001c45][0015da37][0014da0b] 51          push ecx
> [00001c46][0015da37][0014da0b] 8b4508      mov eax,[ebp+08] ; DD
> [00001c49][0015da33][00001c42] 50          push eax         ; DD
> [00001c4a][0015da33][00001c42] 8b4d08      mov ecx,[ebp+08] ; DD
> [00001c4d][0015da2f][00001c42] 51          push ecx         ; DD
> [00001c4e][0015da2b][00001c53] e80ff7ffff  call 00001362    ; HH
>
> main() invokes HH(DD,DD)
> that simulates DD(DD)
> that calls a simulated HH(DD,DD)
> that simulates DD(DD)
> that cannot possibly return to its caller.
>

And HH(DD,DD) can't ever give an answer, so fails to be a deccider.

The D built on the H that aborts its simulation is a different input
than the DD that was built on the HH that doesn't, so you can't use the
mapping calculated from DD for D (unless you think that 1 == 2)

On 1/16/24 10:54 AM, olcott wrote:
> On 1/16/2024 1:54 AM, immibis wrote:
>> On 1/16/24 01:05, olcott wrote:
>>>
>>> The inner simulations never have enough information to abort.
>>
>> They would if you didn't abort them.
>
> The inner simulations are one recursive simulation away from
> the next outer simulation.
>
> This means that the outermost simulation always has one
> recursive simulation more execution trace data than any
> inner simulation.
>
> The outermost simulation reaches its abort criteria one
> recursive simulation sooner than the next inner one.
>
> Since all of these simulations have identical code this
> means that unless the outermost simulation aborts its
> simulation then none of them do.
>
>> If you didn't abort the simulation of them, they would abort, and then
>> halt. Detecting them as non-halting is incorrect.
>
> *Not possible as shown above*
> You might not have enough technical skill to understand this.
>

Because you keep on changing programs.

If H doesn't abort, it doesn't answer

If H does abort, you can't use the "correct simulation" arguement, since
it doesn't do one.

So, you are just caught in your LIE.

On 1/16/24 8:22 PM, olcott wrote:
> On 1/16/2024 6:11 PM, immibis wrote:
>> On 1/16/24 16:54, olcott wrote:
>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>> On 1/16/24 01:05, olcott wrote:
>>>>>
>>>>> The inner simulations never have enough information to abort.
>>>>
>>>> They would if you didn't abort them.
>>>
>>> The inner simulations are one recursive simulation away from
>>> the next outer simulation.
>>>
>>> This means that the outermost simulation always has one
>>> recursive simulation more execution trace data than any
>>> inner simulation.
>>>
>>> The outermost simulation reaches its abort criteria one
>>> recursive simulation sooner than the next inner one.
>>>
>>
>> The ONLY reason the inner simulation doesn't abort is that the outer
>> simulation aborts first.
>>
>> If the outer simulation didn't abort the inner simulation would abort.
>
> You simply don't understand these things well enough.
>

No, YOU don't understand that the problem is about the ACTUAL MACHINE,
and not a fantasy version that only exists in simulation.

The machine that is being simulated, has a D that calls an H(D,D) that
aborts its simulation and returns to D.

The H sees its input call H(D,D) and gives up at that point with bad
logic, and thus gets the wrong answer.

It doesn't matter that the simulation never got to that point, what
matters is what the real machine does, and since it reaches the final
state, that is what matters.

You are just stuck in your fantasy world.

On 1/17/24 03:36, Richard Damon wrote:
>
> No, YOU don't understand that the problem is about the ACTUAL MACHINE,
> and not a fantasy version that only exists in simulation.
>
> The machine that is being simulated, has a D that calls an H(D,D) that
> aborts its simulation and returns to D.
>
> The H sees its input call H(D,D) and gives up at that point with bad
> logic, and thus gets the wrong answer.
>
> It doesn't matter that the simulation never got to that point, what
> matters is what the real machine does, and since it reaches the final
> state, that is what matters.
>
> You are just stuck in your fantasy world.

Very good way to put it. The halting problem is about whether or not the
direct execution halts. Anything else is dishonest.

On 1/17/24 02:22, olcott wrote:
> On 1/16/2024 6:11 PM, immibis wrote:
>> On 1/16/24 16:54, olcott wrote:
>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>> On 1/16/24 01:05, olcott wrote:
>>>>>
>>>>> The inner simulations never have enough information to abort.
>>>>
>>>> They would if you didn't abort them.
>>>
>>> The inner simulations are one recursive simulation away from
>>> the next outer simulation.
>>>
>>> This means that the outermost simulation always has one
>>> recursive simulation more execution trace data than any
>>> inner simulation.
>>>
>>> The outermost simulation reaches its abort criteria one
>>> recursive simulation sooner than the next inner one.
>>>
>>
>> The ONLY reason the inner simulation doesn't abort is that the outer
>> simulation aborts first.
>>
>> If the outer simulation didn't abort the inner simulation would abort.
>
> You simply don't understand these things well enough.
>
I understand perfectly, and you understand nothing.

If the only reason a simulation doesn't reach a final state is that the
simulation is aborted, the correct return value from the halting decider
is 1.

On 1/16/24 01:08, olcott wrote:
> On 1/15/2024 8:59 AM, immibis wrote:
>> On 1/15/24 15:46, olcott wrote:
>>>
>>> The function named D *correctly simulated by H* cannot possibly
>>> reach its own line 06 (final state) and halt. If a function
>>> does not reach its own final state then IT DOES NOT HALT.
>>>
>> What is the definition of "correctly simulated by H"?
>
> H correctly simulates the exact sequence of instructions
> that D specifies until it correctly matches a non-halting
> behavior pattern.

H doesn't do that so it isn't a correct simulator.

On 1/16/24 01:00, olcott wrote:
> ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly halt.

⟨Ĥ⟩ cannot possibly be correctly simulated by embedded_H.

On 1/17/2024 5:40 AM, immibis wrote:
> On 1/17/24 03:36, Richard Damon wrote:
>>
>> No, YOU don't understand that the problem is about the ACTUAL MACHINE,
>> and not a fantasy version that only exists in simulation.
>>
>> The machine that is being simulated, has a D that calls an H(D,D) that
>> aborts its simulation and returns to D.
>>
>> The H sees its input call H(D,D) and gives up at that point with bad
>> logic, and thus gets the wrong answer.
>>
>> It doesn't matter that the simulation never got to that point, what
>> matters is what the real machine does, and since it reaches the final
>> state, that is what matters.
>>
>> You are just stuck in your fantasy world.
>
> Very good way to put it. The halting problem is about whether or not the
> direct execution halts. Anything else is dishonest.

If that was true then the halting problem is about D incorrectly
simulated by H such that H simulates instructions that are not in D
or H does not simulate instruction that are in D.

D correctly simulated by H cannot possibly halt.
The directly executed D(D) depends on D correctly
simulated by H aborting its simulation otherwise
D(D) remains stuck in recursive simulation.

In other words D(D) only halts because H recognizes
the D correctly simulated by H DOES NOT HALT.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/17/2024 5:40 AM, immibis wrote:
> On 1/17/24 02:22, olcott wrote:
>> On 1/16/2024 6:11 PM, immibis wrote:
>>> On 1/16/24 16:54, olcott wrote:
>>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>>> On 1/16/24 01:05, olcott wrote:
>>>>>>
>>>>>> The inner simulations never have enough information to abort.
>>>>>
>>>>> They would if you didn't abort them.
>>>>
>>>> The inner simulations are one recursive simulation away from
>>>> the next outer simulation.
>>>>
>>>> This means that the outermost simulation always has one
>>>> recursive simulation more execution trace data than any
>>>> inner simulation.
>>>>
>>>> The outermost simulation reaches its abort criteria one
>>>> recursive simulation sooner than the next inner one.
>>>>
>>>
>>> The ONLY reason the inner simulation doesn't abort is that the outer
>>> simulation aborts first.
>>>
>>> If the outer simulation didn't abort the inner simulation would abort.
>>
>> You simply don't understand these things well enough.
>>
> I understand perfectly, and you understand nothing.
>
> If the only reason a simulation doesn't reach a final state is that the
> simulation is aborted,

*THAT IS NOT THE ONLY REASON, THUS PROVING YOU ARE CLUELESS*

> the correct return value from the halting decider
> is 1.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/17/24 16:05, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 02:22, olcott wrote:
>>> On 1/16/2024 6:11 PM, immibis wrote:
>>>> On 1/16/24 16:54, olcott wrote:
>>>>> On 1/16/2024 1:54 AM, immibis wrote:
>>>>>> On 1/16/24 01:05, olcott wrote:
>>>>>>>
>>>>>>> The inner simulations never have enough information to abort.
>>>>>>
>>>>>> They would if you didn't abort them.
>>>>>
>>>>> The inner simulations are one recursive simulation away from
>>>>> the next outer simulation.
>>>>>
>>>>> This means that the outermost simulation always has one
>>>>> recursive simulation more execution trace data than any
>>>>> inner simulation.
>>>>>
>>>>> The outermost simulation reaches its abort criteria one
>>>>> recursive simulation sooner than the next inner one.
>>>>>
>>>>
>>>> The ONLY reason the inner simulation doesn't abort is that the outer
>>>> simulation aborts first.
>>>>
>>>> If the outer simulation didn't abort the inner simulation would abort.
>>>
>>> You simply don't understand these things well enough.
>>>
>> I understand perfectly, and you understand nothing.
>>
>> If the only reason a simulation doesn't reach a final state is that
>> the simulation is aborted,
>
> *THAT IS NOT THE ONLY REASON, THUS PROVING YOU ARE CLUELESS*

It is the only reason, thus proving you are clueless.

>
>> the correct return value from the halting decider is 1.
>

On 1/17/24 16:02, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 03:36, Richard Damon wrote:
>>>
>>> No, YOU don't understand that the problem is about the ACTUAL
>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>
>>> The machine that is being simulated, has a D that calls an H(D,D)
>>> that aborts its simulation and returns to D.
>>>
>>> The H sees its input call H(D,D) and gives up at that point with bad
>>> logic, and thus gets the wrong answer.
>>>
>>> It doesn't matter that the simulation never got to that point, what
>>> matters is what the real machine does, and since it reaches the final
>>> state, that is what matters.
>>>
>>> You are just stuck in your fantasy world.
>>
>> Very good way to put it. The halting problem is about whether or not
>> the direct execution halts. Anything else is dishonest.
>
> If that was true then the halting problem is about D incorrectly
> simulated by H such that H simulates instructions that are not in D
> or H does not simulate instruction that are in D.

The halting problem is about whether or not the direct execution halts.
Anything else is dishonest.

On 1/17/2024 9:46 AM, immibis wrote:
> On 1/17/24 16:02, olcott wrote:
>> On 1/17/2024 5:40 AM, immibis wrote:
>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>
>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>
>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>> that aborts its simulation and returns to D.
>>>>
>>>> The H sees its input call H(D,D) and gives up at that point with bad
>>>> logic, and thus gets the wrong answer.
>>>>
>>>> It doesn't matter that the simulation never got to that point, what
>>>> matters is what the real machine does, and since it reaches the
>>>> final state, that is what matters.
>>>>
>>>> You are just stuck in your fantasy world.
>>>
>>> Very good way to put it. The halting problem is about whether or not
>>> the direct execution halts. Anything else is dishonest.
>>
>> If that was true then the halting problem is about D incorrectly
>> simulated by H such that H simulates instructions that are not in D
>> or H does not simulate instruction that are in D.
>
> The halting problem is about whether or not the direct execution halts.
> Anything else is dishonest.

Just like ZFC corrected the faulty definition of {set}
to eliminate the undecidability of Russell's Paradox
this correction to the definition of the halting problem:

In computability theory, the halting problem is the problem of
determining, whether an input finite string pair of program/input
specifies a computation that would reach a final state and terminate
normally.

*Eliminates the undecidability of the halting problem*

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

On 1/17/24 17:16, olcott wrote:
> On 1/17/2024 9:46 AM, immibis wrote:
>> On 1/17/24 16:02, olcott wrote:
>>> On 1/17/2024 5:40 AM, immibis wrote:
>>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>>
>>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>>
>>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>>> that aborts its simulation and returns to D.
>>>>>
>>>>> The H sees its input call H(D,D) and gives up at that point with
>>>>> bad logic, and thus gets the wrong answer.
>>>>>
>>>>> It doesn't matter that the simulation never got to that point, what
>>>>> matters is what the real machine does, and since it reaches the
>>>>> final state, that is what matters.
>>>>>
>>>>> You are just stuck in your fantasy world.
>>>>
>>>> Very good way to put it. The halting problem is about whether or not
>>>> the direct execution halts. Anything else is dishonest.
>>>
>>> If that was true then the halting problem is about D incorrectly
>>> simulated by H such that H simulates instructions that are not in D
>>> or H does not simulate instruction that are in D.
>>
>> The halting problem is about whether or not the direct execution
>> halts. Anything else is dishonest.
>
> Just like ZFC corrected the faulty definition of {set}
> to eliminate the undecidability of Russell's Paradox
> this correction to the definition of the halting problem:
>
> In computability theory, the halting problem is the problem of
> determining, whether an input finite string pair of program/input
> specifies a computation that would reach a final state and terminate
> normally.

Yes, the halting problem is about whether or not the direct execution
reaches a final state and terminates normally.

>
> *Eliminates the undecidability of the halting problem*
>

On 1/17/24 11:16 AM, olcott wrote:
> On 1/17/2024 9:46 AM, immibis wrote:
>> On 1/17/24 16:02, olcott wrote:
>>> On 1/17/2024 5:40 AM, immibis wrote:
>>>> On 1/17/24 03:36, Richard Damon wrote:
>>>>>
>>>>> No, YOU don't understand that the problem is about the ACTUAL
>>>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>>>
>>>>> The machine that is being simulated, has a D that calls an H(D,D)
>>>>> that aborts its simulation and returns to D.
>>>>>
>>>>> The H sees its input call H(D,D) and gives up at that point with
>>>>> bad logic, and thus gets the wrong answer.
>>>>>
>>>>> It doesn't matter that the simulation never got to that point, what
>>>>> matters is what the real machine does, and since it reaches the
>>>>> final state, that is what matters.
>>>>>
>>>>> You are just stuck in your fantasy world.
>>>>
>>>> Very good way to put it. The halting problem is about whether or not
>>>> the direct execution halts. Anything else is dishonest.
>>>
>>> If that was true then the halting problem is about D incorrectly
>>> simulated by H such that H simulates instructions that are not in D
>>> or H does not simulate instruction that are in D.
>>
>> The halting problem is about whether or not the direct execution
>> halts. Anything else is dishonest.
>
> Just like ZFC corrected the faulty definition of {set}
> to eliminate the undecidability of Russell's Paradox
> this correction to the definition of the halting problem:
>
> In computability theory, the halting problem is the problem of
> determining, whether an input finite string pair of program/input
> specifies a computation that would reach a final state and terminate
> normally.
>
> *Eliminates the undecidability of the halting problem*
>

Nope. Just an admittion that you are a liar.

Note, it has been shown that the actual input D based on the decider H
that you claim is correct when given that D converted to a finite string
that fully represents it in saying it is non-halting, is given to ans
actual correct simulator (which by definition doesn't abort its
simulation) or directly run, will halt.

Your dishonest dodge of looking at a different finite string that uses a
different H is just proven to be what it is, a dishonest dodge that
prove you to be a stupid liar.

On 1/17/24 10:02 AM, olcott wrote:
> On 1/17/2024 5:40 AM, immibis wrote:
>> On 1/17/24 03:36, Richard Damon wrote:
>>>
>>> No, YOU don't understand that the problem is about the ACTUAL
>>> MACHINE, and not a fantasy version that only exists in simulation.
>>>
>>> The machine that is being simulated, has a D that calls an H(D,D)
>>> that aborts its simulation and returns to D.
>>>
>>> The H sees its input call H(D,D) and gives up at that point with bad
>>> logic, and thus gets the wrong answer.
>>>
>>> It doesn't matter that the simulation never got to that point, what
>>> matters is what the real machine does, and since it reaches the final
>>> state, that is what matters.
>>>
>>> You are just stuck in your fantasy world.
>>
>> Very good way to put it. The halting problem is about whether or not
>> the direct execution halts. Anything else is dishonest.
>
> If that was true then the halting problem is about D incorrectly
> simulated by H such that H simulates instructions that are not in D
> or H does not simulate instruction that are in D.

No, the Halting Problem is about H trying to figure out what D actual
does, or what an actual correct simulation of the input would do, even
if it can't do that itself.

>
> D correctly simulated by H cannot possibly halt.
> The directly executed D(D) depends on D correctly
> simulated by H aborting its simulation otherwise
> D(D) remains stuck in recursive simulation.

Which is only applicable if H does correctly simulate its input, which
means it can't abort

>
> In other words D(D) only halts because H recognizes
> the D correctly simulated by H DOES NOT HALT.
>

Except you just had two different H's and D's in that sentence, since H
is talking about a DIFFERENT D based on a DIFFERENT H than itself, as
the H that correctly simulates doesn't abort, so can't be this.

You are just admitting that you are just a pathological liar that would
know a true statement if it tried to bite your nose.