On 1/19/2024 7:25 PM, Richard Damon wrote:
> On 1/19/24 8:01 PM, olcott wrote:
>> On 1/19/2024 6:48 PM, Richard Damon wrote:
>>> On 1/19/24 7:36 PM, olcott wrote:
>>>> On 1/19/2024 6:08 PM, Richard Damon wrote:
>>>>> On 1/19/24 6:55 PM, olcott wrote:
>>>>>> On 1/19/2024 5:38 PM, Richard Damon wrote:
>>>>>>> On 1/19/24 6:30 PM, olcott wrote:
>>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> [ .... ]
>>>>>>>>>
>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>> {
>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>> function will not
>>>>>>>>>> halt until they waited an infinite amount of time and saw that
>>>>>>>>>> it did
>>>>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>>>
>>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>>> simulator is
>>>>>>>>> not a sensible thing to do.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The best selling author of textbooks on the theory of
>>>>>>>> computation disagrees.
>>>>>>>>
>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>> Nope.
>>>>>>>
>>>>>>> He agrees that if H can CORRECT determine that a CORRECT
>>>>>>> SIMULATION (it doesn't really matter by who) of THIS input would
>>>>>>> be non-halting, then the decider can abort.
>>>>>>
>>>>>> You have simply been indoctrinated to believe this.
>>>>>> My counter-example may be the first case in history
>>>>>> where the correct simulation has different behavior
>>>>>> that the direct execution.
>>>>>
>>>>> Which is INPOSSIBE by the DEFINITION of "Correct Simulation"
>>>>>
>>>>
>>>> The definition of correct simulation simply presumed
>>>> that pathological self-reference does not change the
>>>> execution sequence because no one ever bothered to
>>>> carefully examined this.
>>>
>>> Nope.
>>>
>>> Just your admission of total ignorance.
>>>
>>>>
>>>> Naive set theory presumed that its definition of {set}
>>>> was correct and ZFC proved that it was not correct.
>>>
>>> Nope.
>>>
>>> Russel's paradox proved that it was incorrect.
>>>
>>
>> And what everyone else is simply not bright enough to
>> understand is that every undecidable input proves
>> the each decision problem with undecidable input
>> is itself incorrect.
>
> Nope, undecidable problems are by definition correct,

Then you were wrong when you said:
"Russel's paradox proved that it was incorrect."

It being the definition of the term: {set}.
*You just admitted that definitions can be incorrect*

--
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/19/24 7:55 PM, olcott wrote:
> On 1/19/2024 6:46 PM, Richard Damon wrote:
>> On 1/19/24 7:31 PM, olcott wrote:
>>> On 1/19/2024 6:13 PM, Richard Damon wrote:
>>>> On 1/19/24 6:33 PM, olcott wrote:
>>>>> On 1/19/2024 5:03 PM, Richard Damon wrote:
>>>>>> On 1/19/24 5:29 PM, olcott wrote:
>>>>>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>>>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>>>>>> Deciders always must compute the mapping from an
>>>>>>>>>>>>>>>>>>> input finite string to
>>>>>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Definition of the HP based on the above definition
>>>>>>>>>>>>>>>>>>> of a decider*
>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> *Definition of halt decider based on the above
>>>>>>>>>>>>>>>>>>> definitions*
>>>>>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its
>>>>>>>>>>>>>>>>>>> own simulated final
>>>>>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> a input finite string pair of program/input specifies
>>>>>>>>>>>>>>>>>> a computation that would reach a final state and
>>>>>>>>>>>>>>>>>> terminate normally
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by
>>>>>>>>>>>>>>>>>> H* cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy" of
>>>>>>>>>>>>>>>> H that it uses,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>>>>>> Non-halting behavior patterns can be matched in N steps.
>>>>>>>>>>>>>>> The simulated ⟨Ĥ⟩ halts only it when reaches its
>>>>>>>>>>>>>>> simulated final state of ⟨Ĥ.qn⟩ in a finite number of steps.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to
>>>>>>>>>>>>>>> embedded_H
>>>>>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates
>>>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat
>>>>>>>>>>>>>>> the process
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Except that pattern isn't non-halting, since if H (and
>>>>>>>>>>>>>> thus embedded_H) abort its simulation, that loop is NOT
>>>>>>>>>>>>>> non-halting,
>>>>>>>>>>>>>
>>>>>>>>>>>>> An aborted simulation does not count as the simulated input
>>>>>>>>>>>>> reaching
>>>>>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>>>>>
>>>>>>>>>>>> Right, but doesn't show that the correct simulaiton of that
>>>>>>>>>>>> input would not halt.
>>>>>>>>>>>>
>>>>>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the
>>>>>>>>>>>> question about its input (Ĥ) (Ĥ), and that H aborts its
>>>>>>>>>>>> simulation and returns to Ĥ which halts, as would a CORRECT
>>>>>>>>>>>> simulaton of the input to any H give (Ĥ) (Ĥ).
>>>>>>>>>>>
>>>>>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can possibly
>>>>>>>>>>> reach
>>>>>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, and it doesn't matter as an aborted simulation does not
>>>>>>>>>> prove non-halting. Partial simulations don't themselves prove
>>>>>>>>>> anything.
>>>>>>>>>
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>    HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> In other words no one can possibly tell that the above function
>>>>>>>>> will not
>>>>>>>>> halt until they waited an infinite amount of time and saw that
>>>>>>>>> it did
>>>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>>>
>>>>>>>>> The freaking repeated state proves non-halting the first
>>>>>>>>> freaking time
>>>>>>>>> that it is encountered.
>>>>>>>>>
>>>>>>>>
>>>>>>>> That isn't what I said. The fact that the aborted simulation
>>>>>>>> didn't reach an end, doesn't prove BY ITSELF, that the input is
>>>>>>>> non-halting.
>>>>>>>>
>>>>>>>
>>>>>>> It is the repeated state that proves non-halting you big dummy.
>>>>>>> You never did any programming did you?
>>>>>>>
>>>>>>
>>>>>> And what repeated state is that?
>>>>>>
>>>>>
>>>>> You don't even know what the term means.
>>>>>
>>>>
>>>> Sure I do, the conplete state of execution of the program is the
>>>> collection of ALL the information under the "control" of the program.
>>>>
>>>> Since the "state" you called repeated occred at a differet level of
>>>> simulation then the origianl, the state of the whole program is NOT
>>>> the same, as the data reguarding simulation levels differs.
>>>>
>>>> YOU don't seem to know what it means, since you use it incorrectly.
>>>
>>> The exact same sequence of instructions is executed
>>> with the exact same data... Dunderhead.
>>>
>>
>> That isn't the "state"
>>
>> DUNDERHEAD.
>>
>
> 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
> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>
> That you cannot tell that the above specifies
> non-halting behavior makes you a dunderhead.
>

On 1/19/2024 7:31 PM, Richard Damon wrote:
> On 1/19/24 7:55 PM, olcott wrote:
>> On 1/19/2024 6:46 PM, Richard Damon wrote:
>>> On 1/19/24 7:31 PM, olcott wrote:
>>>> On 1/19/2024 6:13 PM, Richard Damon wrote:
>>>>> On 1/19/24 6:33 PM, olcott wrote:
>>>>>> On 1/19/2024 5:03 PM, Richard Damon wrote:
>>>>>>> On 1/19/24 5:29 PM, olcott wrote:
>>>>>>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>>>>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>>>>>>> Deciders always must compute the mapping from an
>>>>>>>>>>>>>>>>>>>> input finite string to
>>>>>>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Definition of the HP based on the above definition
>>>>>>>>>>>>>>>>>>>> of a decider*
>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *Definition of halt decider based on the above
>>>>>>>>>>>>>>>>>>>> definitions*
>>>>>>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its
>>>>>>>>>>>>>>>>>>>> own simulated final
>>>>>>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> a input finite string pair of program/input specifies
>>>>>>>>>>>>>>>>>>> a computation that would reach a final state and
>>>>>>>>>>>>>>>>>>> terminate normally
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by
>>>>>>>>>>>>>>>>>>> H* cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy"
>>>>>>>>>>>>>>>>> of H that it uses,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>>>>>>> Non-halting behavior patterns can be matched in N steps.
>>>>>>>>>>>>>>>> The simulated ⟨Ĥ⟩ halts only it when reaches its
>>>>>>>>>>>>>>>> simulated final state of ⟨Ĥ.qn⟩ in a finite number of
>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to
>>>>>>>>>>>>>>>> embedded_H
>>>>>>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat
>>>>>>>>>>>>>>>> the process
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Except that pattern isn't non-halting, since if H (and
>>>>>>>>>>>>>>> thus embedded_H) abort its simulation, that loop is NOT
>>>>>>>>>>>>>>> non-halting,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> An aborted simulation does not count as the simulated
>>>>>>>>>>>>>> input reaching
>>>>>>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, but doesn't show that the correct simulaiton of that
>>>>>>>>>>>>> input would not halt.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the
>>>>>>>>>>>>> question about its input (Ĥ) (Ĥ), and that H aborts its
>>>>>>>>>>>>> simulation and returns to Ĥ which halts, as would a CORRECT
>>>>>>>>>>>>> simulaton of the input to any H give (Ĥ) (Ĥ).
>>>>>>>>>>>>
>>>>>>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can
>>>>>>>>>>>> possibly reach
>>>>>>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, and it doesn't matter as an aborted simulation does not
>>>>>>>>>>> prove non-halting. Partial simulations don't themselves prove
>>>>>>>>>>> anything.
>>>>>>>>>>
>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>> {
>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>> function will not
>>>>>>>>>> halt until they waited an infinite amount of time and saw that
>>>>>>>>>> it did
>>>>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>>>>
>>>>>>>>>> The freaking repeated state proves non-halting the first
>>>>>>>>>> freaking time
>>>>>>>>>> that it is encountered.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> That isn't what I said. The fact that the aborted simulation
>>>>>>>>> didn't reach an end, doesn't prove BY ITSELF, that the input is
>>>>>>>>> non-halting.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is the repeated state that proves non-halting you big dummy.
>>>>>>>> You never did any programming did you?
>>>>>>>>
>>>>>>>
>>>>>>> And what repeated state is that?
>>>>>>>
>>>>>>
>>>>>> You don't even know what the term means.
>>>>>>
>>>>>
>>>>> Sure I do, the conplete state of execution of the program is the
>>>>> collection of ALL the information under the "control" of the program.
>>>>>
>>>>> Since the "state" you called repeated occred at a differet level of
>>>>> simulation then the origianl, the state of the whole program is NOT
>>>>> the same, as the data reguarding simulation levels differs.
>>>>>
>>>>> YOU don't seem to know what it means, since you use it incorrectly.
>>>>
>>>> The exact same sequence of instructions is executed
>>>> with the exact same data... Dunderhead.
>>>>
>>>
>>> That isn't the "state"
>>>
>>> DUNDERHEAD.
>>>
>>
>> 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
>> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>>
>> That you cannot tell that the above specifies
>> non-halting behavior makes you a dunderhead.
>>
>
> But since DD(DD) Halts, it can't be showing non-halting behavior.

On 1/19/24 8:26 PM, olcott wrote:
> On 1/19/2024 7:20 PM, Richard Damon wrote:
>> On 1/19/24 5:29 PM, olcott wrote:
>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>>>> decider*
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>>> normally
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy" of H
>>>>>>>>>>>> that it uses,
>>>>>>>>>>>
>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>> Non-halting behavior patterns can be matched in N steps. The
>>>>>>>>>>> simulated ⟨Ĥ⟩ halts only it when reaches its simulated final
>>>>>>>>>>> state of ⟨Ĥ.qn⟩ in a finite number of steps.
>>>>>>>>>>>
>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates ⟨Ĥ⟩
>>>>>>>>>>> applied to ⟨Ĥ⟩
>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the
>>>>>>>>>>> process
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Except that pattern isn't non-halting, since if H (and thus
>>>>>>>>>> embedded_H) abort its simulation, that loop is NOT non-halting,
>>>>>>>>>
>>>>>>>>> An aborted simulation does not count as the simulated input
>>>>>>>>> reaching
>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>
>>>>>>>> Right, but doesn't show that the correct simulaiton of that
>>>>>>>> input would not halt.
>>>>>>>>
>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the question
>>>>>>>> about its input (Ĥ) (Ĥ), and that H aborts its simulation and
>>>>>>>> returns to Ĥ which halts, as would a CORRECT simulaton of the
>>>>>>>> input to any H give (Ĥ) (Ĥ).
>>>>>>>
>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can possibly reach
>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>
>>>>>>
>>>>>> Yes, and it doesn't matter as an aborted simulation does not prove
>>>>>> non-halting. Partial simulations don't themselves prove anything.
>>>>>
>>>>> void Infinite_Loop()
>>>>> {
>>>>>    HERE: goto HERE;
>>>>> }
>>>>>
>>>>> In other words no one can possibly tell that the above function
>>>>> will not
>>>>> halt until they waited an infinite amount of time and saw that it did
>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>
>>>>> The freaking repeated state proves non-halting the first freaking time
>>>>> that it is encountered.
>>>>>
>>>>
>>>> That isn't what I said. The fact that the aborted simulation didn't
>>>> reach an end, doesn't prove BY ITSELF, that the input is non-halting.
>>>>
>>>
>>> It is the repeated state that proves non-halting you big dummy.
>>> You never did any programming did you?
>>>
>>
>> But the full state wasn;t repeated, but only showed in different level
>> of conditional simulation, which doesn't count.
>>
>> You seem to have never heard of logic and rules.
>>
>>
>
> The full state of D was repeated.
> The only thing that changed was the stack address.
>

On 1/19/2024 7:28 PM, Richard Damon wrote:
> On 1/19/24 8:14 PM, olcott wrote:
>> On 1/19/2024 6:54 PM, Richard Damon wrote:
>>> On 1/19/24 7:38 PM, olcott wrote:
>>>> On 1/19/2024 6:10 PM, Richard Damon wrote:
>>>>> On 1/19/24 6:32 PM, olcott wrote:
>>>>>> On 1/19/2024 5:03 PM, Richard Damon wrote:
>>>>>>> On 1/19/24 5:14 PM, olcott wrote:
>>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>>> On 1/19/24 1:56 PM, olcott wrote:
>>>>>>>>>> On 1/19/2024 12:16 PM, immibis wrote:
>>>>>>>>>>> On 1/19/24 17:14, olcott wrote:
>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>>> decider*
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>
>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>> normally
>>>>>>>>>>>>>
>>>>>>>>>>>>> to
>>>>>>>>>>>>>
>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> H is not allowed to simply ignore that D would detect
>>>>>>>>>>> infinite recursion, stop simulating and reach a final state.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *This is simply over your head*
>>>>>>>>>> Unless the outermost HH aborts its simulation then none of
>>>>>>>>>> them do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And if the outermost HH aborts its simulation, then a correct
>>>>>>>>> simulation of all of them do,
>>>>>>>>
>>>>>>>> This is simply not true. What computer language are you an
>>>>>>>> expert in?
>>>>>>>>
>>>>>>>> The outermost HH sees the abort criteria first. If it does not
>>>>>>>> abort
>>>>>>>> then none of them do because it is the exact same code at the exact
>>>>>>>> same machine address.
>>>>>>>>
>>>>>>>
>>>>>>> No, YOU do not understand about programs.
>>>>>>>
>>>>>>
>>>>>> I will assume that you are not an expert in any programming
>>>>>> language until you say otherwise.
>>>>>>
>>>>>
>>>>> Well, I AM proficient in probably more programming languages than
>>>>> you actually know.
>>>>>
>>>>> So, I have said otherwise.
>>>>>
>>>>> I am still employed at a job where programming is a major part of
>>>>> my job and considered the "go to" person for handling problems.
>>>>
>>>> In other words you are a Jack of some trades and a master of none.
>>>>
>>>
>>> Nope. It seems you are a Jack of no trades and a master of lying.
>>>
>>> Who comes to YOU to solve problems.
>>
>> It is not about solving arbitrary problems it is about
>> being able to perfectly understand how execution traces
>> work and how they can be verified as correct.
>>
>> You are clearly not very good at that problem.
>>
>
> I think better than you,
> How many programs have you had to debug at the assembly level due to
> bugs in the compiler?
>
>
> You don't even understand what a simulation trace of a program should
> contain.
>
> You think changing levels of abstraction is correct when looking at the
> beahavior of the first level and asking if the simulator is correct.
>
> THe Call to H should be followed by the simulation of the subroutine H.
>

The fact that I wrote the x86utm operating system where
HH correctly simulates itself simulating DD and bases
its halt status decision on the x86 machine code trace
(My own program decodes the control flow machine code).
proves that I know these things very well.

I have been working in the 8088 assembly language since
it was new. The x86 language with flat addressing is
much better. 64k segmented architecture was a bit of
a nightmare.

--
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/19/2024 7:37 PM, Richard Damon wrote:
> On 1/19/24 8:26 PM, olcott wrote:
>> On 1/19/2024 7:20 PM, Richard Damon wrote:
>>> On 1/19/24 5:29 PM, olcott wrote:
>>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>>>>> decider*
>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>>>> normally
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy" of H
>>>>>>>>>>>>> that it uses,
>>>>>>>>>>>>
>>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>>
>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>
>>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>>> Non-halting behavior patterns can be matched in N steps. The
>>>>>>>>>>>> simulated ⟨Ĥ⟩ halts only it when reaches its simulated final
>>>>>>>>>>>> state of ⟨Ĥ.qn⟩ in a finite number of steps.
>>>>>>>>>>>>
>>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to embedded_H
>>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates
>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the
>>>>>>>>>>>> process
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Except that pattern isn't non-halting, since if H (and thus
>>>>>>>>>>> embedded_H) abort its simulation, that loop is NOT non-halting,
>>>>>>>>>>
>>>>>>>>>> An aborted simulation does not count as the simulated input
>>>>>>>>>> reaching
>>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>>
>>>>>>>>> Right, but doesn't show that the correct simulaiton of that
>>>>>>>>> input would not halt.
>>>>>>>>>
>>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the question
>>>>>>>>> about its input (Ĥ) (Ĥ), and that H aborts its simulation and
>>>>>>>>> returns to Ĥ which halts, as would a CORRECT simulaton of the
>>>>>>>>> input to any H give (Ĥ) (Ĥ).
>>>>>>>>
>>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can possibly reach
>>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>>
>>>>>>>
>>>>>>> Yes, and it doesn't matter as an aborted simulation does not
>>>>>>> prove non-halting. Partial simulations don't themselves prove
>>>>>>> anything.
>>>>>>
>>>>>> void Infinite_Loop()
>>>>>> {
>>>>>>    HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> In other words no one can possibly tell that the above function
>>>>>> will not
>>>>>> halt until they waited an infinite amount of time and saw that it did
>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>
>>>>>> The freaking repeated state proves non-halting the first freaking
>>>>>> time
>>>>>> that it is encountered.
>>>>>>
>>>>>
>>>>> That isn't what I said. The fact that the aborted simulation didn't
>>>>> reach an end, doesn't prove BY ITSELF, that the input is non-halting.
>>>>>
>>>>
>>>> It is the repeated state that proves non-halting you big dummy.
>>>> You never did any programming did you?
>>>>
>>>
>>> But the full state wasn;t repeated, but only showed in different
>>> level of conditional simulation, which doesn't count.
>>>
>>> You seem to have never heard of logic and rules.
>>>
>>>
>>
>> The full state of D was repeated.
>> The only thing that changed was the stack address.
>>
>
> No, the second set of "State" wasn't a state of the program,
> but a state
> of the simulated simulated program inside the first simulation..

On 1/19/24 8:29 PM, olcott wrote:
> On 1/19/2024 7:25 PM, Richard Damon wrote:
>> On 1/19/24 8:01 PM, olcott wrote:
>>> On 1/19/2024 6:48 PM, Richard Damon wrote:
>>>> On 1/19/24 7:36 PM, olcott wrote:
>>>>> On 1/19/2024 6:08 PM, Richard Damon wrote:
>>>>>> On 1/19/24 6:55 PM, olcott wrote:
>>>>>>> On 1/19/2024 5:38 PM, Richard Damon wrote:
>>>>>>>> On 1/19/24 6:30 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>>>>>>>>>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> [ .... ]
>>>>>>>>>>
>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>> {
>>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>>> function will not
>>>>>>>>>>> halt until they waited an infinite amount of time and saw
>>>>>>>>>>> that it did
>>>>>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>>>>
>>>>>>>>>> That is why attempting to solve the halting problem with a
>>>>>>>>>> simulator is
>>>>>>>>>> not a sensible thing to do.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The best selling author of textbooks on the theory of
>>>>>>>>> computation disagrees.
>>>>>>>>>
>>>>>>>>> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope.
>>>>>>>>
>>>>>>>> He agrees that if H can CORRECT determine that a CORRECT
>>>>>>>> SIMULATION (it doesn't really matter by who) of THIS input would
>>>>>>>> be non-halting, then the decider can abort.
>>>>>>>
>>>>>>> You have simply been indoctrinated to believe this.
>>>>>>> My counter-example may be the first case in history
>>>>>>> where the correct simulation has different behavior
>>>>>>> that the direct execution.
>>>>>>
>>>>>> Which is INPOSSIBE by the DEFINITION of "Correct Simulation"
>>>>>>
>>>>>
>>>>> The definition of correct simulation simply presumed
>>>>> that pathological self-reference does not change the
>>>>> execution sequence because no one ever bothered to
>>>>> carefully examined this.
>>>>
>>>> Nope.
>>>>
>>>> Just your admission of total ignorance.
>>>>
>>>>>
>>>>> Naive set theory presumed that its definition of {set}
>>>>> was correct and ZFC proved that it was not correct.
>>>>
>>>> Nope.
>>>>
>>>> Russel's paradox proved that it was incorrect.
>>>>
>>>
>>> And what everyone else is simply not bright enough to
>>> understand is that every undecidable input proves
>>> the each decision problem with undecidable input
>>> is itself incorrect.
>>
>> Nope, undecidable problems are by definition correct,
>
> Then you were wrong when you said:
> "Russel's paradox proved that it was incorrect."

Russels paradox proved that the rule of naive set theory were incorrect
in the sense that they created in logic system that fixed the problem.

>
> It being the definition of the term: {set}.
> *You just admitted that definitions can be incorrect*
>
>

definition can create incorrect logic system.

That means you need to abandon the system they defined.

You don't get to change the definition and still be working in the same
theory.

Note, Naive set theory was proven to be "incorrect" and replaced by ZFC
set theory.

Most people accepted, once Russel's paradox was understood, that Naive
set theory was broken and needed a replacement.

If you want to do something similar for Computation Theory (or Logic
Theory) first you must demonstrate to the bulk of its users that it is
fundamentally broken.

Then you need to show your revised definitions and what you can actually
show comes out of them.

Note, ZFC produce a LOT of background work showing the results of their
new set theory. Which helped peopl accept it.

You have yet to convince anyone that the failure to build Halt Deciders
actually hurts Computation Theory and just totally breaks it.

You also haven't clearly laid out our new rules, or show how to derive a
full system out of them.

So, you have NOTHING but egg on your face.

On 1/19/24 8:34 PM, olcott wrote:
> On 1/19/2024 7:31 PM, Richard Damon wrote:
>> On 1/19/24 7:55 PM, olcott wrote:
>>> On 1/19/2024 6:46 PM, Richard Damon wrote:
>>>> On 1/19/24 7:31 PM, olcott wrote:
>>>>> On 1/19/2024 6:13 PM, Richard Damon wrote:
>>>>>> On 1/19/24 6:33 PM, olcott wrote:
>>>>>>> On 1/19/2024 5:03 PM, Richard Damon wrote:
>>>>>>>> On 1/19/24 5:29 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>>>>>>>> Deciders always must compute the mapping from an
>>>>>>>>>>>>>>>>>>>>> input finite string to
>>>>>>>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Definition of the HP based on the above definition
>>>>>>>>>>>>>>>>>>>>> of a decider*
>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> *Definition of halt decider based on the above
>>>>>>>>>>>>>>>>>>>>> definitions*
>>>>>>>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its
>>>>>>>>>>>>>>>>>>>>> own simulated final
>>>>>>>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> a input finite string pair of program/input
>>>>>>>>>>>>>>>>>>>> specifies a computation that would reach a final
>>>>>>>>>>>>>>>>>>>> state and terminate normally
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> H correctly determines that D correctly simulated
>>>>>>>>>>>>>>>>>>>> *by H* cannot possiby reach its own simulated final
>>>>>>>>>>>>>>>>>>>> state.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy"
>>>>>>>>>>>>>>>>>> of H that it uses,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>>>>>>>> Non-halting behavior patterns can be matched in N
>>>>>>>>>>>>>>>>> steps. The simulated ⟨Ĥ⟩ halts only it when reaches its
>>>>>>>>>>>>>>>>> simulated final state of ⟨Ĥ.qn⟩ in a finite number of
>>>>>>>>>>>>>>>>> steps.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to
>>>>>>>>>>>>>>>>> embedded_H
>>>>>>>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy)
>>>>>>>>>>>>>>>>> simulates ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat
>>>>>>>>>>>>>>>>> the process
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Except that pattern isn't non-halting, since if H (and
>>>>>>>>>>>>>>>> thus embedded_H) abort its simulation, that loop is NOT
>>>>>>>>>>>>>>>> non-halting,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> An aborted simulation does not count as the simulated
>>>>>>>>>>>>>>> input reaching
>>>>>>>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Right, but doesn't show that the correct simulaiton of
>>>>>>>>>>>>>> that input would not halt.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the
>>>>>>>>>>>>>> question about its input (Ĥ) (Ĥ), and that H aborts its
>>>>>>>>>>>>>> simulation and returns to Ĥ which halts, as would a
>>>>>>>>>>>>>> CORRECT simulaton of the input to any H give (Ĥ) (Ĥ).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can
>>>>>>>>>>>>> possibly reach
>>>>>>>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, and it doesn't matter as an aborted simulation does not
>>>>>>>>>>>> prove non-halting. Partial simulations don't themselves
>>>>>>>>>>>> prove anything.
>>>>>>>>>>>
>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>> {
>>>>>>>>>>>    HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> In other words no one can possibly tell that the above
>>>>>>>>>>> function will not
>>>>>>>>>>> halt until they waited an infinite amount of time and saw
>>>>>>>>>>> that it did
>>>>>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>>>>>
>>>>>>>>>>> The freaking repeated state proves non-halting the first
>>>>>>>>>>> freaking time
>>>>>>>>>>> that it is encountered.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That isn't what I said. The fact that the aborted simulation
>>>>>>>>>> didn't reach an end, doesn't prove BY ITSELF, that the input
>>>>>>>>>> is non-halting.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is the repeated state that proves non-halting you big dummy.
>>>>>>>>> You never did any programming did you?
>>>>>>>>>
>>>>>>>>
>>>>>>>> And what repeated state is that?
>>>>>>>>
>>>>>>>
>>>>>>> You don't even know what the term means.
>>>>>>>
>>>>>>
>>>>>> Sure I do, the conplete state of execution of the program is the
>>>>>> collection of ALL the information under the "control" of the program.
>>>>>>
>>>>>> Since the "state" you called repeated occred at a differet level
>>>>>> of simulation then the origianl, the state of the whole program is
>>>>>> NOT the same, as the data reguarding simulation levels differs.
>>>>>>
>>>>>> YOU don't seem to know what it means, since you use it incorrectly.
>>>>>
>>>>> The exact same sequence of instructions is executed
>>>>> with the exact same data... Dunderhead.
>>>>>
>>>>
>>>> That isn't the "state"
>>>>
>>>> DUNDERHEAD.
>>>>
>>>
>>> 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
>>> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>>>
>>> That you cannot tell that the above specifies
>>> non-halting behavior makes you a dunderhead.
>>>
>>
>> But since DD(DD) Halts, it can't be showing non-halting behavior.
>
> Because of your ADHD I may need to say this hundreds of times
> before you actually pay attention to the words.
>
> DD(DD) relies on its HH(DD,DD) to terminate the recursive
> simulation that it specifies.
>

On 1/19/24 8:43 PM, olcott wrote:
> On 1/19/2024 7:37 PM, Richard Damon wrote:
>> On 1/19/24 8:26 PM, olcott wrote:
>>> On 1/19/2024 7:20 PM, Richard Damon wrote:
>>>> On 1/19/24 5:29 PM, olcott wrote:
>>>>> On 1/19/2024 3:57 PM, Richard Damon wrote:
>>>>>> On 1/19/24 4:47 PM, olcott wrote:
>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>> On 1/19/24 1:36 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 11:56 AM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 12:17 PM, olcott wrote:
>>>>>>>>>>> On 1/19/2024 11:05 AM, Richard Damon wrote:
>>>>>>>>>>>> On 1/19/24 11:55 AM, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 10:44 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 11:14 AM, olcott wrote:
>>>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Definition of the HP based on the above definition of
>>>>>>>>>>>>>>>>> a decider*
>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> *Definition of halt decider based on the above
>>>>>>>>>>>>>>>>> definitions*
>>>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>>>>> normally
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, D, if it is an actual program, has its OWN "copy" of H
>>>>>>>>>>>>>> that it uses,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have proven that does not make any difference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>>>
>>>>>>>>>>>>> Simulating Partial Halt Decider Applied to Linz Proof
>>>>>>>>>>>>> Non-halting behavior patterns can be matched in N steps.
>>>>>>>>>>>>> The simulated ⟨Ĥ⟩ halts only it when reaches its simulated
>>>>>>>>>>>>> final state of ⟨Ĥ.qn⟩ in a finite number of steps.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (a) Ĥ.q0 The input ⟨Ĥ⟩ is copied then transitions to
>>>>>>>>>>>>> embedded_H
>>>>>>>>>>>>> (b) embedded_H applied ⟨Ĥ⟩ ⟨Ĥ⟩ (input and copy) simulates
>>>>>>>>>>>>> ⟨Ĥ⟩ applied to ⟨Ĥ⟩
>>>>>>>>>>>>> (c) which begins at its own simulated ⟨Ĥ.q0⟩ to repeat the
>>>>>>>>>>>>> process
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Except that pattern isn't non-halting, since if H (and thus
>>>>>>>>>>>> embedded_H) abort its simulation, that loop is NOT non-halting,
>>>>>>>>>>>
>>>>>>>>>>> An aborted simulation does not count as the simulated input
>>>>>>>>>>> reaching
>>>>>>>>>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>>>>>>>>
>>>>>>>>>> Right, but doesn't show that the correct simulaiton of that
>>>>>>>>>> input would not halt.
>>>>>>>>>>
>>>>>>>>>> Ĥ uses its copy of H to answer (by its simulation) the
>>>>>>>>>> question about its input (Ĥ) (Ĥ), and that H aborts its
>>>>>>>>>> simulation and returns to Ĥ which halts, as would a CORRECT
>>>>>>>>>> simulaton of the input to any H give (Ĥ) (Ĥ).
>>>>>>>>>
>>>>>>>>> Do you understand that none of the simulated ⟨Ĥ⟩ can possibly
>>>>>>>>> reach
>>>>>>>>> their simulated final state of ⟨Ĥ.qn⟩ ???
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, and it doesn't matter as an aborted simulation does not
>>>>>>>> prove non-halting. Partial simulations don't themselves prove
>>>>>>>> anything.
>>>>>>>
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>    HERE: goto HERE;
>>>>>>> }
>>>>>>>
>>>>>>> In other words no one can possibly tell that the above function
>>>>>>> will not
>>>>>>> halt until they waited an infinite amount of time and saw that it
>>>>>>> did
>>>>>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>>>>>>
>>>>>>> The freaking repeated state proves non-halting the first freaking
>>>>>>> time
>>>>>>> that it is encountered.
>>>>>>>
>>>>>>
>>>>>> That isn't what I said. The fact that the aborted simulation
>>>>>> didn't reach an end, doesn't prove BY ITSELF, that the input is
>>>>>> non-halting.
>>>>>>
>>>>>
>>>>> It is the repeated state that proves non-halting you big dummy.
>>>>> You never did any programming did you?
>>>>>
>>>>
>>>> But the full state wasn;t repeated, but only showed in different
>>>> level of conditional simulation, which doesn't count.
>>>>
>>>> You seem to have never heard of logic and rules.
>>>>
>>>>
>>>
>>> The full state of D was repeated.
>>> The only thing that changed was the stack address.
>>>
>>
>> No, the second set of "State" wasn't a state of the program, but a
>> state of the simulated simulated program inside the first simulation..
>
> Only the x86utm operating system simulates the program
> HH simulates the C function named HH. A C function <is>
> a microcosm of a program.
>
>

On 2024-01-19 18:26, olcott wrote:

> The full state of D was repeated.
> The only thing that changed was the stack address.

The contents of the stack and the stack address are *part* of the state
of the machine. If they change, you are not repeating the same state.

André

--
To email remove 'invalid' & replace 'gm' with well known Google mail
service.

On 1/19/24 8:40 PM, olcott wrote:
> On 1/19/2024 7:28 PM, Richard Damon wrote:
>> On 1/19/24 8:14 PM, olcott wrote:
>>> On 1/19/2024 6:54 PM, Richard Damon wrote:
>>>> On 1/19/24 7:38 PM, olcott wrote:
>>>>> On 1/19/2024 6:10 PM, Richard Damon wrote:
>>>>>> On 1/19/24 6:32 PM, olcott wrote:
>>>>>>> On 1/19/2024 5:03 PM, Richard Damon wrote:
>>>>>>>> On 1/19/24 5:14 PM, olcott wrote:
>>>>>>>>> On 1/19/2024 3:34 PM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 1:56 PM, olcott wrote:
>>>>>>>>>>> On 1/19/2024 12:16 PM, immibis wrote:
>>>>>>>>>>>> On 1/19/24 17:14, olcott wrote:
>>>>>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>>>>>> Deciders always must compute the mapping from an input
>>>>>>>>>>>>>>> finite string to
>>>>>>>>>>>>>>> their own accept or reject state on the basis of a
>>>>>>>>>>>>>>> syntactic or semantic
>>>>>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>>>>>> decider*
>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>>>>>> (a) If simulating termination analyzer H correctly
>>>>>>>>>>>>>>> determines that D
>>>>>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>>>>>> simulated final
>>>>>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>>>>>> computation that would reach a final state and terminate
>>>>>>>>>>>>>> normally
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>>>>>> is calling itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> H is not allowed to simply ignore that D would detect
>>>>>>>>>>>> infinite recursion, stop simulating and reach a final state.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *This is simply over your head*
>>>>>>>>>>> Unless the outermost HH aborts its simulation then none of
>>>>>>>>>>> them do.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And if the outermost HH aborts its simulation, then a correct
>>>>>>>>>> simulation of all of them do,
>>>>>>>>>
>>>>>>>>> This is simply not true. What computer language are you an
>>>>>>>>> expert in?
>>>>>>>>>
>>>>>>>>> The outermost HH sees the abort criteria first. If it does not
>>>>>>>>> abort
>>>>>>>>> then none of them do because it is the exact same code at the
>>>>>>>>> exact
>>>>>>>>> same machine address.
>>>>>>>>>
>>>>>>>>
>>>>>>>> No, YOU do not understand about programs.
>>>>>>>>
>>>>>>>
>>>>>>> I will assume that you are not an expert in any programming
>>>>>>> language until you say otherwise.
>>>>>>>
>>>>>>
>>>>>> Well, I AM proficient in probably more programming languages than
>>>>>> you actually know.
>>>>>>
>>>>>> So, I have said otherwise.
>>>>>>
>>>>>> I am still employed at a job where programming is a major part of
>>>>>> my job and considered the "go to" person for handling problems.
>>>>>
>>>>> In other words you are a Jack of some trades and a master of none.
>>>>>
>>>>
>>>> Nope. It seems you are a Jack of no trades and a master of lying.
>>>>
>>>> Who comes to YOU to solve problems.
>>>
>>> It is not about solving arbitrary problems it is about
>>> being able to perfectly understand how execution traces
>>> work and how they can be verified as correct.
>>>
>>> You are clearly not very good at that problem.
>>>
>>
>> I think better than you,
>> How many programs have you had to debug at the assembly level due to
>> bugs in the compiler?
>>
>>
>> You don't even understand what a simulation trace of a program should
>> contain.
>>
>> You think changing levels of abstraction is correct when looking at
>> the beahavior of the first level and asking if the simulator is correct.
>>
>> THe Call to H should be followed by the simulation of the subroutine H.
>>
>
> The fact that I wrote the x86utm operating system where
> HH correctly simulates itself simulating DD and bases
> its halt status decision on the x86 machine code trace
> (My own program decodes the control flow machine code).
> proves that I know these things very well.
>
> I have been working in the 8088 assembly language since
> it was new. The x86 language with flat addressing is
> much better. 64k segmented architecture was a bit of
> a nightmare.
>

I started on 8088 assembly code in 1975, and most of the variaions ov
x86 through the years, so you don't have more experiance than me.

As A High School Sophomore, I had teachers come to me for help with
assemble language programming as I had learned if for our school
computer. I don't think you can claim to have better experiance tham me.

Your problem isn't in the instruction by instruction simulation (but
then that isn't, as you admit, your code) but on your interpreation of it.

You don't seem to understand the fundamentals of the problem, as I
pointed out years ago.

Your Halt Decider needs to take in a full independent program to decide
on, not a function in its own address space, and especially not a
program that reuses code that is part of your decider.

On 1/19/2024 7:58 PM, André G. Isaak wrote:
> On 2024-01-19 18:26, olcott wrote:
>
>> The full state of D was repeated.
>> The only thing that changed was the stack address.
>
> The contents of the stack and the stack address are *part* of the state
> of the machine. If they change, you are not repeating the same state.
>
> André
>

Everything is identical across recursive simulations besides
the stack address. The stack address is irrelevant to whether
or not DD halts.

The easily verified fact that DD simulated by HH cannot possibly
reach its own simulated final state conclusively proves that DD
does not halt.

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
Local Halt Decider: Recursion Simulation 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/19/24 9:08 PM, olcott wrote:
> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>> On 2024-01-19 18:26, olcott wrote:
>>
>>> The full state of D was repeated.
>>> The only thing that changed was the stack address.
>>
>> The contents of the stack and the stack address are *part* of the
>> state of the machine. If they change, you are not repeating the same
>> state.
>>
>> André
>>
>
> Everything is identical across recursive simulations besides
> the stack address. The stack address is irrelevant to whether
> or not DD halts.
>

Nope, and part of the problem is you stopped looking at the actual
simulaiton of the input. The simulator being simulated at the first
call will be in a different state at the second call to H then it was
when it started, just like the outer HH doing the simulation has built
up the history shown.

That means that, if we continued an actual correct simulation of this
exact input (and thus didn't change HH, but gave the input to a proper
UTM simulator) we would see that the first simulated HH would run one
more level of simulation, and then abort its simulation, and then return
to DD and it would halt.

Thus, your simulation just isn't showing the actual "state" of the
program (in fact, you arn't even showing the state of the program, since
the key state for this program is what is happening in the HH that DD is
calling)

The "recursive" layer SHOULD be showing up as the instruction sequence
of the simulator simulating those instructions, and thus showing that
state being generated.

That second layer never actually shows as a direct simulation in the
proper simulation of the input, except maybe as interspresed comment of
the simulated HH just simulated this instruction.

If you are going to try to abstract out that simulation, you need to do
it properly, and that means that the simulation level IS part of state.

> The easily verified fact that DD simulated by HH cannot possibly
> reach its own simulated final state conclusively proves that DD
> does not halt.

No, that only hold *IF* HH correctly simulates the input, which means
that HH can NEVER abort its simulation.

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

Note. error in simulation here. Call to HH should be showing the states
of operation of HH

> [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
> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>
>

On 1/19/2024 8:39 PM, Richard Damon wrote:
> On 1/19/24 9:08 PM, olcott wrote:
>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>> On 2024-01-19 18:26, olcott wrote:
>>>
>>>> The full state of D was repeated.
>>>> The only thing that changed was the stack address.
>>>
>>> The contents of the stack and the stack address are *part* of the
>>> state of the machine. If they change, you are not repeating the same
>>> state.
>>>
>>> André
>>>
>>
>> Everything is identical across recursive simulations besides
>> the stack address. The stack address is irrelevant to whether
>> or not DD halts.
>>
>
> Nope, and part of the problem is you stopped looking at the actual
> simulaiton of the input.  The simulator being simulated at the first
> call will be in a different state at the second call to H then it was
> when it started, just like the outer HH doing the simulation has built
> up the history shown.
>
> That means that, if we continued an actual correct simulation of this
> exact input (and thus didn't change HH, but gave the input to a proper
> UTM simulator) we would see that the first simulated HH would run one
> more level of simulation, and then abort its simulation, and then return
> to DD and it would halt.
>
> Thus, your simulation just isn't showing the actual "state" of the
> program (in fact, you arn't even showing the state of the program, since
> the key state for this program is what is happening in the HH that DD is
> calling)
>
> The "recursive" layer SHOULD be showing up as the instruction sequence
> of the simulator simulating those instructions, and thus showing that
> state being generated.
>
> That second layer never actually shows as a direct simulation in the
> proper simulation of the input, except maybe as interspresed comment of
> the simulated HH just simulated this instruction.
>
> If you are going to try to abstract out that simulation, you need to do
> it properly, and that means that the simulation level IS part of state.
>
>> The easily verified fact that DD simulated by HH cannot possibly
>> reach its own simulated final state conclusively proves that DD
>> does not halt.
>
> No, that only hold *IF* HH correctly simulates the input, which means
> that HH can NEVER abort its simulation.
>
>>
>> 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
>
> Note. error in simulation here. Call to HH should be showing the states
> of operation of HH
>

Tell me how the behavior of HH can possibly show that
DD reaches its final state and I will provide a link
with the 151 pages of the execution trace of HH.

>> [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
>> Local Halt Decider: Recursion Simulation 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/19/24 9:55 PM, olcott wrote:
> On 1/19/2024 8:39 PM, Richard Damon wrote:
>> On 1/19/24 9:08 PM, olcott wrote:
>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>> On 2024-01-19 18:26, olcott wrote:
>>>>
>>>>> The full state of D was repeated.
>>>>> The only thing that changed was the stack address.
>>>>
>>>> The contents of the stack and the stack address are *part* of the
>>>> state of the machine. If they change, you are not repeating the same
>>>> state.
>>>>
>>>> André
>>>>
>>>
>>> Everything is identical across recursive simulations besides
>>> the stack address. The stack address is irrelevant to whether
>>> or not DD halts.
>>>
>>
>> Nope, and part of the problem is you stopped looking at the actual
>> simulaiton of the input.  The simulator being simulated at the first
>> call will be in a different state at the second call to H then it was
>> when it started, just like the outer HH doing the simulation has built
>> up the history shown.
>>
>> That means that, if we continued an actual correct simulation of this
>> exact input (and thus didn't change HH, but gave the input to a proper
>> UTM simulator) we would see that the first simulated HH would run one
>> more level of simulation, and then abort its simulation, and then
>> return to DD and it would halt.
>>
>> Thus, your simulation just isn't showing the actual "state" of the
>> program (in fact, you arn't even showing the state of the program,
>> since the key state for this program is what is happening in the HH
>> that DD is calling)
>>
>> The "recursive" layer SHOULD be showing up as the instruction sequence
>> of the simulator simulating those instructions, and thus showing that
>> state being generated.
>>
>> That second layer never actually shows as a direct simulation in the
>> proper simulation of the input, except maybe as interspresed comment
>> of the simulated HH just simulated this instruction.
>>
>> If you are going to try to abstract out that simulation, you need to
>> do it properly, and that means that the simulation level IS part of
>> state.
>>
>>> The easily verified fact that DD simulated by HH cannot possibly
>>> reach its own simulated final state conclusively proves that DD
>>> does not halt.
>>
>> No, that only hold *IF* HH correctly simulates the input, which means
>> that HH can NEVER abort its simulation.
>>
>>>
>>> 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
>>
>> Note. error in simulation here. Call to HH should be showing the
>> states of operation of HH
>>
>
> Tell me how the behavior of HH can possibly show that
> DD reaches its final state and I will provide a link
> with the 151 pages of the execution trace of HH.

It can't in its simulation, but an actually correct simulation of the
input, which HH doesn't do, can.

You start with the INCORRECT assumption that HH will do a correct
simulation. That assumption can only hold if HH never aborts its
simulation, and then it can never answer.

Your presumption of an HH that correctly simulates its input until it
correctly determines that the actual behavior of the program given as an
input is non-halting is an impossible presumption, just like the barber
that shaves everyone that does not shave themselves, or the set that
contains all sets that do not contain themselves.

Now, since we KNOW that HH(DD,DD) returns 0, from THAT known behavior,
we can just look at the code for DD and see that it will halt, or just
correctly simulate the input with a UTM.

Remember, programs are what there code defines them to be, and once it
is a program, its behavior for a given input can not change without
changing the code of the program (or a hidden input, which isn't allowed
for a computation).

>
>>> [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
>>> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>>>
>>>
>>
>

On 1/19/2024 9:13 PM, Richard Damon wrote:
> On 1/19/24 9:55 PM, olcott wrote:
>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>> On 1/19/24 9:08 PM, olcott wrote:
>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>
>>>>>> The full state of D was repeated.
>>>>>> The only thing that changed was the stack address.
>>>>>
>>>>> The contents of the stack and the stack address are *part* of the
>>>>> state of the machine. If they change, you are not repeating the
>>>>> same state.
>>>>>
>>>>> André
>>>>>
>>>>
>>>> Everything is identical across recursive simulations besides
>>>> the stack address. The stack address is irrelevant to whether
>>>> or not DD halts.
>>>>
>>>
>>> Nope, and part of the problem is you stopped looking at the actual
>>> simulaiton of the input.  The simulator being simulated at the first
>>> call will be in a different state at the second call to H then it was
>>> when it started, just like the outer HH doing the simulation has
>>> built up the history shown.
>>>
>>> That means that, if we continued an actual correct simulation of this
>>> exact input (and thus didn't change HH, but gave the input to a
>>> proper UTM simulator) we would see that the first simulated HH would
>>> run one more level of simulation, and then abort its simulation, and
>>> then return to DD and it would halt.
>>>
>>> Thus, your simulation just isn't showing the actual "state" of the
>>> program (in fact, you arn't even showing the state of the program,
>>> since the key state for this program is what is happening in the HH
>>> that DD is calling)
>>>
>>> The "recursive" layer SHOULD be showing up as the instruction
>>> sequence of the simulator simulating those instructions, and thus
>>> showing that state being generated.
>>>
>>> That second layer never actually shows as a direct simulation in the
>>> proper simulation of the input, except maybe as interspresed comment
>>> of the simulated HH just simulated this instruction.
>>>
>>> If you are going to try to abstract out that simulation, you need to
>>> do it properly, and that means that the simulation level IS part of
>>> state.
>>>
>>>> The easily verified fact that DD simulated by HH cannot possibly
>>>> reach its own simulated final state conclusively proves that DD
>>>> does not halt.
>>>
>>> No, that only hold *IF* HH correctly simulates the input, which means
>>> that HH can NEVER abort its simulation.
>>>
>>>>
>>>> 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
>>>
>>> Note. error in simulation here. Call to HH should be showing the
>>> states of operation of HH
>>>
>>
>> Tell me how the behavior of HH can possibly show that
>> DD reaches its final state and I will provide a link
>> with the 151 pages of the execution trace of HH.
>
> It can't in its simulation, but an actually correct simulation of the
> input, which HH doesn't do, can.

*When I challenge you to show what the correct detailed*
*line-by-line machine address by machine address steps*
*SHOULD BE you consistently utterly fail because you really*
*don't know Jack about these things and are just bluffing*

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
Local Halt Decider: Recursion Simulation Detected Simulation Stopped

_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]

--
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/19/24 10:28 PM, olcott wrote:
> On 1/19/2024 9:13 PM, Richard Damon wrote:
>> On 1/19/24 9:55 PM, olcott wrote:
>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>
>>>>>>> The full state of D was repeated.
>>>>>>> The only thing that changed was the stack address.
>>>>>>
>>>>>> The contents of the stack and the stack address are *part* of the
>>>>>> state of the machine. If they change, you are not repeating the
>>>>>> same state.
>>>>>>
>>>>>> André
>>>>>>
>>>>>
>>>>> Everything is identical across recursive simulations besides
>>>>> the stack address. The stack address is irrelevant to whether
>>>>> or not DD halts.
>>>>>
>>>>
>>>> Nope, and part of the problem is you stopped looking at the actual
>>>> simulaiton of the input.  The simulator being simulated at the first
>>>> call will be in a different state at the second call to H then it
>>>> was when it started, just like the outer HH doing the simulation has
>>>> built up the history shown.
>>>>
>>>> That means that, if we continued an actual correct simulation of
>>>> this exact input (and thus didn't change HH, but gave the input to a
>>>> proper UTM simulator) we would see that the first simulated HH would
>>>> run one more level of simulation, and then abort its simulation, and
>>>> then return to DD and it would halt.
>>>>
>>>> Thus, your simulation just isn't showing the actual "state" of the
>>>> program (in fact, you arn't even showing the state of the program,
>>>> since the key state for this program is what is happening in the HH
>>>> that DD is calling)
>>>>
>>>> The "recursive" layer SHOULD be showing up as the instruction
>>>> sequence of the simulator simulating those instructions, and thus
>>>> showing that state being generated.
>>>>
>>>> That second layer never actually shows as a direct simulation in the
>>>> proper simulation of the input, except maybe as interspresed comment
>>>> of the simulated HH just simulated this instruction.
>>>>
>>>> If you are going to try to abstract out that simulation, you need to
>>>> do it properly, and that means that the simulation level IS part of
>>>> state.
>>>>
>>>>> The easily verified fact that DD simulated by HH cannot possibly
>>>>> reach its own simulated final state conclusively proves that DD
>>>>> does not halt.
>>>>
>>>> No, that only hold *IF* HH correctly simulates the input, which
>>>> means that HH can NEVER abort its simulation.
>>>>
>>>>>
>>>>> 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
>>>>
>>>> Note. error in simulation here. Call to HH should be showing the
>>>> states of operation of HH
>>>>
>>>
>>> Tell me how the behavior of HH can possibly show that
>>> DD reaches its final state and I will provide a link
>>> with the 151 pages of the execution trace of HH.
>>
>> It can't in its simulation, but an actually correct simulation of the
>> input, which HH doesn't do, can.
>
> *When I challenge you to show what the correct detailed*
> *line-by-line machine address by machine address steps*
> *SHOULD BE you consistently utterly fail because you really*
> *don't know Jack about these things and are just bluffing*

i.e. I'm not falling for your strawman and are panicing as badly as your
buddy Trump.

Since you ADMIT that DD(DD) halts, and it does that because DD is built
on the only version of HH that matters, the one that answers, and that
version does abort its simulation at the point you show, it is thus
clear that a CORRECT simulation of this input by a real simulator that
didn't abort when your INCOMPLETE (and thus incorrect) simulation in HH
did, would show that the simulator call in the first simulation of the
input DD, would when this HH printed

New slave_stack,

would have outputed

Begin Local Halt Decider Simulation.

Then when you top level HH outputed

Local Hat Decider: Recursive Simulation Detected,

(but the HHH doesn't abort its simulation, so it wouldn't print that
message, the simulated HH would output

New Slave_stack

Then it would put out a third copy of the instructions (remember, this
is the trace of a real UTM or an HHH that was changed not to abort, but
DD still calls HH) followd by the simulated HH saying

Local Halt Decider: Recursion Simulation Detected, Simulation Stoppeed

And then the trace of the end of DD to the final return.

If you try to say you can't change the simulator looking at the input to
HHH or a UTM without changing DD to use it, then your system is just
broken and you are just admitting that. BY DEFINITION, the "pathological
program" uses the ONE decider that is claimed to be the one to get the
correct answer, and the definition of a "Correct Simulation" is not a
function of the simulator used, but of the program being simulated ALONE.

Any complaints just proves you to be a LIAR.

>
> 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
> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>
> _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]
>
>
>

On 1/19/2024 10:07 PM, Richard Damon wrote:
> On 1/19/24 10:28 PM, olcott wrote:
>> On 1/19/2024 9:13 PM, Richard Damon wrote:
>>> On 1/19/24 9:55 PM, olcott wrote:
>>>> On 1/19/2024 8:39 PM, Richard Damon wrote:
>>>>> On 1/19/24 9:08 PM, olcott wrote:
>>>>>> On 1/19/2024 7:58 PM, André G. Isaak wrote:
>>>>>>> On 2024-01-19 18:26, olcott wrote:
>>>>>>>
>>>>>>>> The full state of D was repeated.
>>>>>>>> The only thing that changed was the stack address.
>>>>>>>
>>>>>>> The contents of the stack and the stack address are *part* of the
>>>>>>> state of the machine. If they change, you are not repeating the
>>>>>>> same state.
>>>>>>>
>>>>>>> André
>>>>>>>
>>>>>>
>>>>>> Everything is identical across recursive simulations besides
>>>>>> the stack address. The stack address is irrelevant to whether
>>>>>> or not DD halts.
>>>>>>
>>>>>
>>>>> Nope, and part of the problem is you stopped looking at the actual
>>>>> simulaiton of the input.  The simulator being simulated at the
>>>>> first call will be in a different state at the second call to H
>>>>> then it was when it started, just like the outer HH doing the
>>>>> simulation has built up the history shown.
>>>>>
>>>>> That means that, if we continued an actual correct simulation of
>>>>> this exact input (and thus didn't change HH, but gave the input to
>>>>> a proper UTM simulator) we would see that the first simulated HH
>>>>> would run one more level of simulation, and then abort its
>>>>> simulation, and then return to DD and it would halt.
>>>>>
>>>>> Thus, your simulation just isn't showing the actual "state" of the
>>>>> program (in fact, you arn't even showing the state of the program,
>>>>> since the key state for this program is what is happening in the HH
>>>>> that DD is calling)
>>>>>
>>>>> The "recursive" layer SHOULD be showing up as the instruction
>>>>> sequence of the simulator simulating those instructions, and thus
>>>>> showing that state being generated.
>>>>>
>>>>> That second layer never actually shows as a direct simulation in
>>>>> the proper simulation of the input, except maybe as interspresed
>>>>> comment of the simulated HH just simulated this instruction.
>>>>>
>>>>> If you are going to try to abstract out that simulation, you need
>>>>> to do it properly, and that means that the simulation level IS part
>>>>> of state.
>>>>>
>>>>>> The easily verified fact that DD simulated by HH cannot possibly
>>>>>> reach its own simulated final state conclusively proves that DD
>>>>>> does not halt.
>>>>>
>>>>> No, that only hold *IF* HH correctly simulates the input, which
>>>>> means that HH can NEVER abort its simulation.
>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>> Note. error in simulation here. Call to HH should be showing the
>>>>> states of operation of HH
>>>>>
>>>>
>>>> Tell me how the behavior of HH can possibly show that
>>>> DD reaches its final state and I will provide a link
>>>> with the 151 pages of the execution trace of HH.
>>>
>>> It can't in its simulation, but an actually correct simulation of the
>>> input, which HH doesn't do, can.
>>
>> *When I challenge you to show what the correct detailed*
>> *line-by-line machine address by machine address steps*
>> *SHOULD BE you consistently utterly fail because you really*
>> *don't know Jack about these things and are just bluffing*
>
> i.e. I'm not falling for your strawman and are panicing as
> badly as your buddy Trump.
Trump is a Hitler wanna bee.

*You failed try again*
I show 16 lines of machine code
*you must show ever detail of your corrected machine code*
*This must include the machine address and the assembly language*

*OR YOU FAIL*
*OR YOU FAIL*
*OR YOU FAIL*
*OR YOU FAIL*

*When I challenge you to show what the correct detailed*
*line-by-line machine address by machine address steps*
*SHOULD BE you consistently utterly fail because you really*
*don't know Jack about these things and are just bluffing*

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] ; 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
Local Halt Decider: Recursion Simulation Detected Simulation Stopped

_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]

--
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/19/24 23:46, olcott wrote:
> On 1/19/2024 4:40 PM, immibis wrote:
>> On 1/19/24 23:22, olcott wrote:
>>> On 1/19/2024 3:41 PM, immibis wrote:
>>>> On 1/19/24 22:12, olcott wrote:
>>>>> On 1/19/2024 2:44 PM, immibis wrote:
>>>>>> On 1/19/24 19:56, olcott wrote:
>>>>>>> On 1/19/2024 12:16 PM, immibis wrote:
>>>>>>>> On 1/19/24 17:14, olcott wrote:
>>>>>>>>> On 1/19/2024 9:34 AM, Richard Damon wrote:
>>>>>>>>>> On 1/19/24 8:54 AM, olcott wrote:
>>>>>>>>>>> *This is the correct definition of a decider*
>>>>>>>>>>> Deciders always must compute the mapping from an input finite
>>>>>>>>>>> string to
>>>>>>>>>>> their own accept or reject state on the basis of a syntactic
>>>>>>>>>>> or semantic
>>>>>>>>>>> property of this finite string.
>>>>>>>>>>>
>>>>>>>>>>> *Definition of the HP based on the above definition of a
>>>>>>>>>>> decider*
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>> *Definition of halt decider based on the above definitions*
>>>>>>>>>>> (a) If simulating termination analyzer H correctly determines
>>>>>>>>>>> that D
>>>>>>>>>>> correctly simulated by H cannot possibly reach its own
>>>>>>>>>>> simulated final
>>>>>>>>>>> state and terminate normally then
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Nope.
>>>>>>>>>>
>>>>>>>>>> Where did you get the transition from
>>>>>>>>>>
>>>>>>>>>> a input finite string pair of program/input specifies a
>>>>>>>>>> computation that would reach a final state and terminate normally
>>>>>>>>>>
>>>>>>>>>> to
>>>>>>>>>>
>>>>>>>>>> H correctly determines that D correctly simulated *by H*
>>>>>>>>>> cannot possiby reach its own simulated final state.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The computation that D specifies to H <is> recursive
>>>>>>>>> simulation. H is not allowed to simply ignore that D
>>>>>>>>> is calling itself.
>>>>>>>>>
>>>>>>>>
>>>>>>>> H is not allowed to simply ignore that D would detect infinite
>>>>>>>> recursion, stop simulating and reach a final state.
>>>>>>>>
>>>>>>>
>>>>>>> *This is simply over your head*
>>>>>>> Unless the outermost HH aborts its simulation then none of them do.
>>>>>>>
>>>>>>
>>>>>> Why?
>>>>>>
>>>>>
>>>>> Each simulated HH has the exact same instructions as the
>>>>> others because it <is> the same code at the same machine
>>>>> address.
>>>>
>>>> Does the direct executed HH have the exact same instructions as each
>>>> simulated HH?
>>>>
>>>
>>> There is only one HH at machine address [00001032].
>>>
>>
>> Does the direct executed HH have the exact same instructions as each
>> simulated HH?
>
> There is only one HH at machine address [00001032].
> There is only one HH at machine address [00001032].
> There is only one HH at machine address [00001032].
> There is only one HH at machine address [00001032].
> There is only one HH at machine address [00001032].
>
> You must have ADD like Richard. I have to repeat
> things to Richard hundreds of times before he ever
> notices that I said them once.
>

Why can't you answer the question?

On 1/20/24 00:33, olcott wrote:
> On 1/19/2024 5:03 PM, Richard Damon wrote:
>> On 1/19/24 5:29 PM, olcott wrote:
>>>
>>> It is the repeated state that proves non-halting you big dummy.
>>> You never did any programming did you?
>>>
>>
>> And what repeated state is that?
>>
>
> You don't even know what the term means.
>

You don't know what it means. The execution trace is part of the state,
but is dishonestly ignored by the code that checks for repeated states.

On 1/20/24 02:14, olcott wrote:
>
> It is not about solving arbitrary problems it is about
> being able to perfectly understand how execution traces
> work and how they can be verified as correct.
>
> You are clearly not very good at that problem.
>

And how they can be verified as incorrect.

H has some instructions which tell it when to halt, but the simulator
dishonestly ignores these instructions.

On 1/20/24 02:26, olcott wrote:
>
> The full state of D was repeated.
> The only thing that changed was the stack address.
>
You think the stack address doesn't matter?

On 1/20/24 00:30, olcott wrote:
> On 1/19/2024 4:58 PM, Alan Mackenzie wrote:
>> In comp.theory olcott <polcott2@gmail.com> wrote:
>>
>> [ .... ]
>>
>>> void Infinite_Loop()
>>> {
>>>    HERE: goto HERE;
>>> }
>>
>>> In other words no one can possibly tell that the above function will not
>>> halt until they waited an infinite amount of time and saw that it did
>>> not halt. DUMB, DUMB, DUMB, DUMB.
>>
>> That is why attempting to solve the halting problem with a simulator is
>> not a sensible thing to do.
>>
>
> The best selling author of textbooks on the theory of computation
> disagrees.
>
> https://www.amazon.com/Introduction-Theory-Computation-Michael-Sipser/dp/113318779X
>
> 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.
>

The quote is correct, and your simulator is incorrect.

On 1/20/24 01:36, olcott wrote:
>
> The definition of correct simulation simply presumed
> that pathological self-reference does not change the
> execution sequence because no one ever bothered to
> carefully examined this.
>
> Naive set theory presumed that its definition of {set}
> was correct and ZFC proved that it was not correct.
>
> Since it is a verified fact that D correctly simulated by
> H1 depends on H aborting its simulation and H cannot
> depend on this it is proved that they are not the same.
>
>

A Turing machine/initial tape pair has only one execution sequence.

On 1/20/24 01:55, olcott wrote:
>
> 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
> Local Halt Decider: Recursion Simulation Detected Simulation Stopped
>
> That you cannot tell that the above specifies
> non-halting behavior makes you a dunderhead.
>

This trace dishonestly ignores the instructions that tell HH to check
for non-halting repeated patterns.