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

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.

To put it in a way Olcott might understand, his simulator works like
this one:

void loop(ptr input) {
HERE: goto HERE;
} int H(ptr program, ptr input) {
begin_simulation(loop, input);
run_until_halt_or_loop_detected();
if(loop_detected)
return 0;
else
return 1;
}

It correctly simulates a looping program and detects a loop, but that
program isn't the one that was input so who cares?

> I an afraid he will never understand this and just keeps repeating
> (unless aborted).

Heh. Good one.

On 1/15/24 12:26 AM, immibis wrote:
> On 1/15/24 06:23, 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⟩.
>
> And ⟨Ĥ⟩ directly executed cannot possibly reach its own state of ⟨Ĥ.qy⟩
> or ⟨Ĥ.qn⟩

But if it fails to reach one of those states, the only possible reason
is that H failed to be a decider, which is a precondition for it being a
Halt Decider.

Seems you have proven that a machine can't be both a "Correct Simulator"
and a Decider, so a Correct Simulation based Halt Decider is merely a
contradiction of terms, like the Barber who shaves everyone who doesn't
shave themselves.

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.

--
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/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"?

Op 15.jan.2024 om 15:46 schreef olcott:
> On 1/15/2024 3:47 AM, Fred. Zwarts wrote:
>> Op 14.jan.2024 om 21:05 schreef olcott:

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

Apparently, Olcott does not understand that the function H(D,D)
*correctly simulated by H* does return and therefore the function named
D *correctly simulated by H* reaches its own line 04 and then line 06.
This is the H that is included in D and therefore part of the input. The
H that does not return is not part of the input. H must decide on its
input, not on its non-input.

On 1/15/2024 9:44 AM, Fred. Zwarts wrote:
> Op 15.jan.2024 om 15:46 schreef olcott:
>> On 1/15/2024 3:47 AM, Fred. Zwarts wrote:
>>> Op 14.jan.2024 om 21:05 schreef olcott:
>
>>>>
>>>> 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.
>>
>
> Apparently, Olcott does not understand that the function H(D,D)
> *correctly simulated by H* does return

If that was true then you could show all of the detailed steps
with lines numbers of D how it does this.

It is impossible to show how it does this correctly
therefore you are proven to be WRONG.

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)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

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)

*Simulation invariant*
D correctly simulated by H cannot possibly reach past its own line 03.

No one can possibly provide the exact sequence of the line numbers
of D correctly simulated by H that differs from the above sequence.
*This proves that 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/15/24 17:07, olcott wrote:
> [something]

What is the definition of a correct simulation?

On 1/15/2024 10:43 AM, immibis wrote:
> On 1/15/24 17:07, olcott wrote:
> > [something]
>
> What is the definition of a correct simulation?

H executes the instructions of D as they are specified in D.

When HH does this it simulates itself simulating D until
it sees that this is a repeating state.

Begin Local Halt Decider Simulation Execution Trace Stored at:113027

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[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] ; D
[00001c49][0011300b][00001c42] 50 push eax
[00001c4a][0011300b][00001c42] 8b4d08 mov ecx,[ebp+08] ; D
[00001c4d][00113007][00001c42] 51 push ecx
[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] ; D
[00001c49][0015da33][00001c42] 50 push eax
[00001c4a][0015da33][00001c42] 8b4d08 mov ecx,[ebp+08] ; D
[00001c4d][0015da2f][00001c42] 51 push ecx
[00001c4e][0015da2b][00001c53] e80ff7ffff call 00001362 ; HH
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
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/15/24 18:29, olcott wrote:
> On 1/15/2024 10:43 AM, immibis wrote:
>> On 1/15/24 17:07, olcott wrote:
>>  > [something]
>>
>> What is the definition of a correct simulation?
>
> H executes the instructions of D as they are specified in D.

No it doesn't.

On 1/15/2024 1:01 PM, immibis wrote:
> On 1/15/24 18:29, olcott wrote:
>> On 1/15/2024 10:43 AM, immibis wrote:
>>> On 1/15/24 17:07, olcott wrote:
>>>  > [something]
>>>
>>> What is the definition of a correct simulation?
>>
>> H executes the instructions of D as they are specified in D.
>
> No it doesn't.

I think that you know that it does otherwise you could show what these
steps should be.

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 }

When D correctly simulated by H reaches line 03
it is not allowed to simply jump to line 06.

When the simulated D calls a simulated H(D,D) the
it cannot possibly return to the simulated D.

If you can't understand this then you lack
sufficient skill in the C programming language.

--
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/15/24 20:20, olcott wrote:
> On 1/15/2024 1:01 PM, immibis wrote:
>> On 1/15/24 18:29, olcott wrote:
>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>> On 1/15/24 17:07, olcott wrote:
>>>>  > [something]
>>>>
>>>> What is the definition of a correct simulation?
>>>
>>> H executes the instructions of D as they are specified in D.
>>
>> No it doesn't.
>
> I think that you know that it does otherwise you could show what these
> steps should be.
>

They are the same steps that are simulated by your program when H1
simulates D. You can easily create the execution trace yourself, if you
want it.

On 1/15/2024 1:26 PM, immibis wrote:
> On 1/15/24 20:20, olcott wrote:
>> On 1/15/2024 1:01 PM, immibis wrote:
>>> On 1/15/24 18:29, olcott wrote:
>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>  > [something]
>>>>>
>>>>> What is the definition of a correct simulation?
>>>>
>>>> H executes the instructions of D as they are specified in D.
>>>
>>> No it doesn't.
>>
>> I think that you know that it does otherwise you could show what these
>> steps should be.
>>
>
> They are the same steps that are simulated by your program when H1
> simulates D. You can easily create the execution trace yourself, if you
> want it.

main() invokes D(D) that invokes H(D,D) that returns to D.

main() invokes H(D,D) that simulates D(D) that calls a simulated
H(D,D) that cannot possibly return to its caller. When the invoked
H(D,D) returns to main() this is an entirely different instance
of H thus not the simulated H.

Perhaps you lack sufficient software engineering skill to see this?
Exactly which computer languages are you an expert in?

--
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/15/24 21:11, olcott wrote:
> On 1/15/2024 1:26 PM, immibis wrote:
>> On 1/15/24 20:20, olcott wrote:
>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>> On 1/15/24 18:29, olcott wrote:
>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>  > [something]
>>>>>>
>>>>>> What is the definition of a correct simulation?
>>>>>
>>>>> H executes the instructions of D as they are specified in D.
>>>>
>>>> No it doesn't.
>>>
>>> I think that you know that it does otherwise you could show what
>>> these steps should be.
>>>
>>
>> They are the same steps that are simulated by your program when H1
>> simulates D. You can easily create the execution trace yourself, if
>> you want it.
>
> main() invokes D(D) that invokes H(D,D) that returns to D.
>
> main() invokes H(D,D) that simulates D(D) that calls a simulated
> H(D,D) that cannot possibly return to its caller. When the invoked
> H(D,D) returns to main() this is an entirely different instance
> of H thus not the simulated H.

If you change it so main() invokes H1(D,D) you will get the execution
trace you are looking for.

On 1/15/2024 2:15 PM, immibis wrote:
> On 1/15/24 21:11, olcott wrote:
>> On 1/15/2024 1:26 PM, immibis wrote:
>>> On 1/15/24 20:20, olcott wrote:
>>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>>> On 1/15/24 18:29, olcott wrote:
>>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>>  > [something]
>>>>>>>
>>>>>>> What is the definition of a correct simulation?
>>>>>>
>>>>>> H executes the instructions of D as they are specified in D.
>>>>>
>>>>> No it doesn't.
>>>>
>>>> I think that you know that it does otherwise you could show what
>>>> these steps should be.
>>>>
>>>
>>> They are the same steps that are simulated by your program when H1
>>> simulates D. You can easily create the execution trace yourself, if
>>> you want it.
>>
>> main() invokes D(D) that invokes H(D,D) that returns to D.
>>
>> main() invokes H(D,D) that simulates D(D) that calls a simulated
>> H(D,D) that cannot possibly return to its caller. When the invoked
>> H(D,D) returns to main() this is an entirely different instance
>> of H thus not the simulated H.
>
> If you change it so main() invokes H1(D,D) you will get the execution
> trace you are looking for.

I have decades as a professional C++ software engineer, it seems
that your skills are insufficient to understand what I am saying.

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

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

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.

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

HH(D,D) goes ahead and simulates itself simulating D
until D tries to invoke another simulated HH(D,D).

--
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/15/2024 1:26 PM, immibis wrote:
> On 1/15/24 20:20, olcott wrote:
>> On 1/15/2024 1:01 PM, immibis wrote:
>>> On 1/15/24 18:29, olcott wrote:
>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>  > [something]
>>>>>
>>>>> What is the definition of a correct simulation?
>>>>
>>>> H executes the instructions of D as they are specified in D.
>>>
>>> No it doesn't.
>>
>> I think that you know that it does otherwise you could show what these
>> steps should be.
>>
>
> They are the same steps that are simulated by your program when H1
> simulates D. You can easily create the execution trace yourself, if you
> want it.

When you try and show every single line number of D correctly
simulated by H then you find out that you are wrong.

--
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/15/2024 2:15 PM, immibis wrote:
> On 1/15/24 21:11, olcott wrote:
>> On 1/15/2024 1:26 PM, immibis wrote:
>>> On 1/15/24 20:20, olcott wrote:
>>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>>> On 1/15/24 18:29, olcott wrote:
>>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>>  > [something]
>>>>>>>
>>>>>>> What is the definition of a correct simulation?
>>>>>>
>>>>>> H executes the instructions of D as they are specified in D.
>>>>>
>>>>> No it doesn't.
>>>>
>>>> I think that you know that it does otherwise you could show what
>>>> these steps should be.
>>>>
>>>
>>> They are the same steps that are simulated by your program when H1
>>> simulates D. You can easily create the execution trace yourself, if
>>> you want it.
>>
>> main() invokes D(D) that invokes H(D,D) that returns to D.
>>
>> main() invokes H(D,D) that simulates D(D) that calls a simulated
>> H(D,D) that cannot possibly return to its caller. When the invoked
>> H(D,D) returns to main() this is an entirely different instance
>> of H thus not the simulated H.
>
> If you change it so main() invokes H1(D,D) you will get the execution
> trace you are looking for.

You must show every single line number of D correctly simulated by
H. Then you can see that it cannot possibly be the same as D
correctly simulated by H1, BECAUSE D DOES DOES NOT CALL H1.

--
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/15/24 7:10 PM, olcott wrote:
> On 1/15/2024 1:26 PM, immibis wrote:
>> On 1/15/24 20:20, olcott wrote:
>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>> On 1/15/24 18:29, olcott wrote:
>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>  > [something]
>>>>>>
>>>>>> What is the definition of a correct simulation?
>>>>>
>>>>> H executes the instructions of D as they are specified in D.
>>>>
>>>> No it doesn't.
>>>
>>> I think that you know that it does otherwise you could show what
>>> these steps should be.
>>>
>>
>> They are the same steps that are simulated by your program when H1
>> simulates D. You can easily create the execution trace yourself, if
>> you want it.
>
> When you try and show every single line number of D correctly
> simulated by H then you find out that you are wrong.
>
>
>

Dishonest DODGE of a strawman.

D(D) Halts.

Therefore H(D,D) returning 0 is wrong

To deny that is to admit to being a LIAR as those are the definitions.

On 1/15/24 3:55 PM, olcott wrote:
> On 1/15/2024 2:15 PM, immibis wrote:
>> On 1/15/24 21:11, olcott wrote:
>>> On 1/15/2024 1:26 PM, immibis wrote:
>>>> On 1/15/24 20:20, olcott wrote:
>>>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>>>> On 1/15/24 18:29, olcott wrote:
>>>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>>>  > [something]
>>>>>>>>
>>>>>>>> What is the definition of a correct simulation?
>>>>>>>
>>>>>>> H executes the instructions of D as they are specified in D.
>>>>>>
>>>>>> No it doesn't.
>>>>>
>>>>> I think that you know that it does otherwise you could show what
>>>>> these steps should be.
>>>>>
>>>>
>>>> They are the same steps that are simulated by your program when H1
>>>> simulates D. You can easily create the execution trace yourself, if
>>>> you want it.
>>>
>>> main() invokes D(D) that invokes H(D,D) that returns to D.
>>>
>>> main() invokes H(D,D) that simulates D(D) that calls a simulated
>>> H(D,D) that cannot possibly return to its caller. When the invoked
>>> H(D,D) returns to main() this is an entirely different instance
>>> of H thus not the simulated H.
>>
>> If you change it so main() invokes H1(D,D) you will get the execution
>> trace you are looking for.
>
> I have decades as a professional C++ software engineer, it seems
> that your skills are insufficient to understand what I am saying.
>

You have proven that any claim you have made to be a software engineer
was likely done as fraud.

You are proving yourself to be an absolute idiot, claiming that things
that are different must be the same.

This just proves you are insane.

On 1/15/24 3:11 PM, olcott wrote:
> On 1/15/2024 1:26 PM, immibis wrote:
>> On 1/15/24 20:20, olcott wrote:
>>> On 1/15/2024 1:01 PM, immibis wrote:
>>>> On 1/15/24 18:29, olcott wrote:
>>>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>>>> On 1/15/24 17:07, olcott wrote:
>>>>>>  > [something]
>>>>>>
>>>>>> What is the definition of a correct simulation?
>>>>>
>>>>> H executes the instructions of D as they are specified in D.
>>>>
>>>> No it doesn't.
>>>
>>> I think that you know that it does otherwise you could show what
>>> these steps should be.
>>>
>>
>> They are the same steps that are simulated by your program when H1
>> simulates D. You can easily create the execution trace yourself, if
>> you want it.
>
> main() invokes D(D) that invokes H(D,D) that returns to D.
>
> main() invokes H(D,D) that simulates D(D) that calls a simulated
> H(D,D) that cannot possibly return to its caller. When the invoked
> H(D,D) returns to main() this is an entirely different instance
> of H thus not the simulated H.

So, you are admitting that H's simulation doesn't match reality!

>
> Perhaps you lack sufficient software engineering skill to see this?
> Exactly which computer languages are you an expert in?
>
>

You seem to lack sufficient understanding of the basics of computing.

On 1/15/24 2:20 PM, olcott wrote:
> On 1/15/2024 1:01 PM, immibis wrote:
>> On 1/15/24 18:29, olcott wrote:
>>> On 1/15/2024 10:43 AM, immibis wrote:
>>>> On 1/15/24 17:07, olcott wrote:
>>>>  > [something]
>>>>
>>>> What is the definition of a correct simulation?
>>>
>>> H executes the instructions of D as they are specified in D.
>>
>> No it doesn't.
>
> I think that you know that it does otherwise you could show what these
> steps should be.
>
> 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 }
>
> When D correctly simulated by H reaches line 03
> it is not allowed to simply jump to line 06.

No, it jumps to the first line of H, so your trace is just incorrect.

>
> When the simulated D calls a simulated H(D,D) the
> it cannot possibly return to the simulated D.

But since when ACTUAL D calls H(D,D) it does, that shows that H's
simulation is just incorrect.

>
> If you can't understand this then you lack
> sufficient skill in the C programming language.
>

Your failure to undestand shows that you just don't understand how
computers work.

On 1/15/24 7:08 PM, 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.
>
> HH(D,D) goes ahead and simulates itself simulating D
> until D tries to invoke another simulated HH(D,D).
>

And the "Correct Patterns" you claim are incorrect as they match correct
simulations that halt.

This has been pointed out to you, so you are caught in your lie.