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?

>
> The outer HH aborts the simulation as soon as the abort
> criteria has been met. Since it sees this abort criteria
> first unless it aborts then none of them do.
>
>> And what is HH? You changed H to HH - why?
>
> HH is the original H and can simulate itself simulating
> DD. H can not do this, it uses a different abort criteria
> so that it can abort sooner.
>

On 1/19/24 22:13, olcott wrote:
> On 1/19/2024 2:46 PM, immibis wrote:
>> On 1/19/24 18:17, olcott wrote:
>>>
>>> An aborted simulation does not count as the simulated input reaching
>>> its simulated final state of ⟨Ĥ.qn⟩ and terminated normally.
>>>
>>
>> An abortING simulation does count as the simulatOR reaching its final
>> state and terminating normally.
>>
>>
>
> Yes it does. It does not count as the simulated input DD halting.
>

Talk about each level with different name.

DD0 will reach its final state and terminate normally, if not aborted.
DD1 will reach its final state and terminate normally, if not aborted.
DD2 will reach its final state and terminate normally, if not aborted.
DD3 will reach its final state and terminate normally, if not aborted.
DD4 will reach its final state and terminate normally, if not aborted.
And so on.

DD0 aborts the simulation of DD1.
DD1 aborts the simulation of DD2, if DD1 isn't aborted before that happens.
DD2 aborts the simulation of DD3, if DD2 isn't aborted before that happens.
DD3 aborts the simulation of DD4, if DD3 isn't aborted before that happens.
DD4 aborts the simulation of DD5, if DD4 isn't aborted before that happens.
And so on.

The only reason that DD1 doesn't reach its final state and terminate
normally is that DD1 is aborted by DD0.
The only reason that DD2 doesn't reach its final state and terminate
normally is that DD2 is aborted by DD1.
The only reason that DD3 doesn't reach its final state and terminate
normally is that DD3 is aborted by DD2.
The only reason that DD4 doesn't reach its final state and terminate
normally is that DD4 is aborted by DD3.
And so on.

If the ONLY reason a simulation doesn't reach its final state and
terminate normally is that the simulation is aborted, then the correct
return value from the halting decider is 1.

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.

--
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 3:34 PM, Richard Damon wrote:
> On 1/19/24 2:08 PM, olcott wrote:
>> On 1/19/2024 12:27 PM, Richard Damon wrote:
>>> On 1/19/24 1: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.
>>>>
>>>
>>> Except that D doesn't create infinite recursion BECAUSE H (the H used
>>> by D) aborts its simulation and stops it.
>>>
>>
>> HH correctly simulates DD until it correctly determines
>> that HH correctly simulated by HH cannot possibly reach
>> its own simulated final state and halt, then HH returns
>> to its caller.
>
> The HH actually NEVER stops its simulation
>
>>
>> When DD(DD) is its caller then this entirely different
>> execution sequence benefits from the fact that HH
>> has aborted the simulation of the different execution
>> sequence specified by DD.
>
> But it isn't a different exection sequence.

When DD(DD) calls HH(DD,DD) this *DOES NOT SPECIFY* recursive
simulation.

When DD is simulated by HH(DD,DD) calls HH(DD,DD) this *DOES SPECIFY*
recursive simulation.

You must be very terrible at coding.

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

For some case, like above, it is possible to reason about the future
behavior of the simulation, and actually PROVE that it will never reach
a finite state.

It just turns out, that for the D/H case, there is no proof, becuase it
just isn't true, as ANY H that returns 0, will cause the D that is built
on it, to be Halting, and thus a correct simulation of it will end.

The fact that you have shown that you don't actually understand how to
build an actual proof, puts you at a major disadvantage to show what you
need to do.

On 1/19/24 4:52 PM, olcott wrote:
> On 1/19/2024 3:34 PM, Richard Damon wrote:
>> On 1/19/24 2:08 PM, olcott wrote:
>>> On 1/19/2024 12:27 PM, Richard Damon wrote:
>>>> On 1/19/24 1: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.
>>>>>
>>>>
>>>> Except that D doesn't create infinite recursion BECAUSE H (the H
>>>> used by D) aborts its simulation and stops it.
>>>>
>>>
>>> HH correctly simulates DD until it correctly determines
>>> that HH correctly simulated by HH cannot possibly reach
>>> its own simulated final state and halt, then HH returns
>>> to its caller.
>>
>> The HH actually NEVER stops its simulation
>>
>>>
>>> When DD(DD) is its caller then this entirely different
>>> execution sequence benefits from the fact that HH
>>> has aborted the simulation of the different execution
>>> sequence specified by DD.
>>
>> But it isn't a different exection sequence.
>
> When DD(DD) calls HH(DD,DD) this *DOES NOT SPECIFY* recursive
> simulation.
>
> When DD is simulated by HH(DD,DD) calls HH(DD,DD) this *DOES SPECIFY*
> recursive simulation.

If the above didn't, then this doesn't. If HH(DD,DD) is correctly
simulting its input, then it simulating DD calling HH(DD,DD) has exactly
the same meaning to the simulaiton and the call did to the actual execution.

Yes, HH seeing that it is simulating an input that it "knows" about,
might allow it to determine some things about the simulation before they
happen, but it can only be correct about future behavior that actually
happens.

If DD(DD) calling HH(DD,DD) doesn't actually cause an infinite recursion
loop, HH(DD,DD) simulating the call in DD(DD) to HH(DD,DD) can't presume
such an infinite recursion loop, that is just using false premises.

The simulator needs to use CORRECT knowledge of what the ACTUAL input
does, since we know that eventually the actual decider that you are
claiming to be correct will abort and return 0, the input built on that
calls a decider that does that, and the simulator part of the decider
needs to use logic that is compatible with that behavior. It can't
presume the decider called behaves differently then it actually behaves.

>
> You must be very terrible at coding.
>

So, what was different.

Show the point of first difference.

You are showing you don't understand the meaning of correct simulation,

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.

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

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

--
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 22:47, 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.
>

You can prove it.

You can't prove it with by simulating a bunch of steps and then saying
it still hasn't halted so it won't ever halt.

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?

On 1/19/2024 4:39 PM, immibis wrote:
> On 1/19/24 22:47, 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.
>>
>
> You can prove it.
>
> You can't prove it with by simulating a bunch of steps and then saying
> it still hasn't halted so it won't ever halt.

Repeated State [00001c42] to [00001c4e]!
Repeated State [00001c42] to [00001c4e]!
Repeated State [00001c42] to [00001c4e]!

New Jersey, New Jersey, New Jersey is also a repeated state

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

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

In comp.theory Richard Damon <richard@damon-family.org> wrote:

[ .... ]

> Only a simulation that shows that you can not reach a final state even
> after an unbounded number of steps shows non-halting, but doing such a
> simulation make the machine fail to be a decider, as deciders must
> answer in bounded time, and until you invent a time machine, you can't
> do unbounded work in bounded time.

Is that right? Deciders must answer in finite time, but is there
actually a bound on how long this time can be? If so, what is it?

--
Alan Mackenzie (Nuremberg, Germany).

On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
> In comp.theory Richard Damon <richard@damon-family.org> wrote:
>
> [ .... ]
>
>> Only a simulation that shows that you can not reach a final state even
>> after an unbounded number of steps shows non-halting, but doing such a
>> simulation make the machine fail to be a decider, as deciders must
>> answer in bounded time, and until you invent a time machine, you can't
>> do unbounded work in bounded time.
>
> Is that right? Deciders must answer in finite time, but is there
> actually a bound on how long this time can be? If so, what is it?
>

Once a simulating halt decider sees a repeating state it knows that
its input DOES NOT HALT.

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

On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
> In comp.theory Richard Damon <richard@damon-family.org> wrote:
>
> [ .... ]
>
>> Only a simulation that shows that you can not reach a final state even
>> after an unbounded number of steps shows non-halting, but doing such a
>> simulation make the machine fail to be a decider, as deciders must
>> answer in bounded time, and until you invent a time machine, you can't
>> do unbounded work in bounded time.
>
> Is that right? Deciders must answer in finite time, but is there
> actually a bound on how long this time can be? If so, what is it?
>

The actual technical bound is anything less than infinite time.

--
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 4:54 PM, olcott wrote:
> On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
>> In comp.theory Richard Damon <richard@damon-family.org> wrote:
>>
>> [ .... ]
>>
>>> Only a simulation that shows that you can not reach a final state even
>>> after an unbounded number of steps shows non-halting, but doing such a
>>> simulation make the machine fail to be a decider, as deciders must
>>> answer in bounded time, and until you invent a time machine, you can't
>>> do unbounded work in bounded time.
>>
>> Is that right?  Deciders must answer in finite time, but is there
>> actually a bound on how long this time can be?  If so, what is it?
>>
>
> The actual technical bound is anything less than infinite time.

I stated that incorrectly actual technical bound is a finite number of
steps.

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

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 freaking repeated state proves non-halting the first freaking time
> that it is encountered.

If the purported halt decider actually analyses its input, rather than
attempting to simulate it. But there are inputs which are beyond
analysis, and it is neither practical nor possible to say whether the
machines they represent halt or not.

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

--
Alan Mackenzie (Nuremberg, Germany).

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.

ALL programs have a defined code. HH must Either HAVE or NOT HAVE the
instruction that cause it to abort its simulation.

If HH HAS those instructions, the the correct simulation of its input
WILL see DD(DD) calling HH(DD,DD) and it eventually (after the point
that any HH simulating it has already aborted its simulation) decide to
abort its simulation and return to DD and DD will then Halt.

If you talk about changing HH to something else, then you can not also
change the HH that DD calls, or you are now talking about a different input.

So since the HH that answers has the abort (or it doesn't answer as you
have shown) DD must call the HH that aborts, and if you make a different
decider that doesn't abort that you try to call HH, you need to make
sure that DD calls the ORIGICAL HH) and then this new HH will see that
DD(DD) calls HH(DD,DD) and that eventually that HH (remember the input
DD calls the HH that you claim give the right answer, NOT the HH that is
deciding on it at the moment) will abort and return to DD and DD Halts.
So, the HH that DOES a correct simulation shows that the only DD (the DD
that calls the original HH) halts, so no HH can use correct simulation
being non-halting as a correct basis to make an action.

SAME machine address means nothing, except that your model is incorrect
and you aren't actually allowed to talk about a different HH at that
address as it changes the input.

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 reach the same point but in a different context, and that context
matters.

You are forgetting that each layer of simulation is conditional, and
thus the fact that there is a repeat at an inner layer can affect the
outer layer and cause it to abort the simulation, thus there is not
infinite loop.

Either you need to make the simulation unconditional, at which point you
do get the infinite behavior, but no answer, or you let the simulation
be conditional but then it isn't necessarily infinite. Since every level
is the same, if any level returns 0, ALL layers when correctly simulated
return 0.

On 1/19/24 5:43 PM, olcott wrote:
> On 1/19/2024 4:39 PM, immibis wrote:
>> On 1/19/24 22:47, 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.
>>>
>>
>> You can prove it.
>>
>> You can't prove it with by simulating a bunch of steps and then saying
>> it still hasn't halted so it won't ever halt.
>
> Repeated State [00001c42] to [00001c4e]!
> Repeated State [00001c42] to [00001c4e]!
> Repeated State [00001c42] to [00001c4e]!

Different context, so NOT "Repeated State"

>
> New Jersey, New Jersey, New Jersey is also a repeated state
>
> 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
>
>

On 1/19/24 5:46 PM, 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.
>

Which means you are not allowed to change it without changing the input,
so you can't talk about "any HH" since for a given DD, there is only
one, the one that it was built on.

Since this one either doesn't abort, and thus never returns an answer,
or does abort, and thus there isn't a correct simulation by HH to make a
correct decision on, has no valid grounds to do its abort, and thus acts
in error.

On 1/19/24 5:50 PM, Alan Mackenzie wrote:
> In comp.theory Richard Damon <richard@damon-family.org> wrote:
>
> [ .... ]
>
>> Only a simulation that shows that you can not reach a final state even
>> after an unbounded number of steps shows non-halting, but doing such a
>> simulation make the machine fail to be a decider, as deciders must
>> answer in bounded time, and until you invent a time machine, you can't
>> do unbounded work in bounded time.
>
> Is that right? Deciders must answer in finite time, but is there
> actually a bound on how long this time can be? If so, what is it?
>

It is not stated, but it it DOES answer in a finite time, then that time
can be given as the bound.

On 1/19/24 5:53 PM, olcott wrote:
> On 1/19/2024 4:50 PM, Alan Mackenzie wrote:
>> In comp.theory Richard Damon <richard@damon-family.org> wrote:
>>
>> [ .... ]
>>
>>> Only a simulation that shows that you can not reach a final state even
>>> after an unbounded number of steps shows non-halting, but doing such a
>>> simulation make the machine fail to be a decider, as deciders must
>>> answer in bounded time, and until you invent a time machine, you can't
>>> do unbounded work in bounded time.
>>
>> Is that right?  Deciders must answer in finite time, but is there
>> actually a bound on how long this time can be?  If so, what is it?
>>
>
> Once a simulating halt decider sees a repeating state it knows that
> its input DOES NOT HALT.
>
>

Yes, if it is FULL repeated state of the FULL thing simulated.

Seeing a repeat in the nested simulation of the outer simulation, when
the outer simulation is conditional is NOT sufficient.

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.

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