Halting problem undecidability and infinitely nested simulation

When input P to simulating halt decider H has the pathological
self-reference error (PSRE) simulating halt decider H decides this input
P on the basis of proxy input P2 that has the pathological
self-reference error removed.

void H_Hat(u32 P)
{ u32 Input_Halts = Halts(P, P);
if (Input_Halts)
HERE: goto HERE;
}

The pathological self-reference error arises in the halting theorem from
the fact that neither return values: {0, 1} from Halts() to H_Hat()
represent the actual halting behavior of H_Hat() in the computation:
Halts((u32)H_Hat, (u32)H_Hat);

When we define H_Hat2() by replacing the call to Halts() with a call to
Simulate()

u32 Simulate(u32 P, u32 I)
{ ((void(*)(int))P)(I);
return 1;
}

H_Hat2() never halts on its own machine address as input.
This key fact is leveraged to correctly decide halting:
Halts((u32)H_Hat, (u32)H_Hat);

We hypothesize that input P having the pathological self-reference error
(PSRE) can be substituted for equivalent proxy input P2 such that the
halting status of P2 derives the halting status of P. If this
hypothesis is correct it becomes the basis for refuting the halting
theorem.

To put this in concrete terms if Halts((u32)H_Hat2, (u32)H_Hat2);
provides the correct halting value for Halts((u32)H_Hat, (u32)H_Hat);
then H_Hat becomes a decidable input. The rest of the proof will attempt
to show this.

Generic halt deciding principle for inputs having the pathological
self-reference error

Whenever input P has the pathological self-reference error such that a
simulating halt decider H must decide halting on an input that invokes
itself we define proxy input P2 copy of P such that the embedded
simulating halt decider is replaced with a simulator.

(a) Simulating halt decider H and simulator S are equivalent
computations for all inputs P that halt. This means that H correctly
decides halting on P if and only if P2 halts.

(b) Simulating halt decider H and simulator S are equivalent
computations for all inputs P that do not halt up to the point where H
stops simulating P. This means that H correctly decides not halting on P
if and only if P2 does not halt.

In other words: Halts correctly decides not halting on H_Hat because
H_Hat2 does not halt.

Peter Linz Ĥ applied to the Turing machine description of itself: [Ĥ]
Figure 12.3 Turing Machine Ĥ

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

The above is adapted from (Linz:1990:319).
It shows that Turing machine Ĥ copies its input at (q0) and begins
executing an embedded copy of the original halt decider with this input
at (qx).

The (qy) state indicates that the halt decider has determined that its
input would halt. The ((qn)) state indicates the input would not halt.
The appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
decider decides that its input would halt.

Linz, Peter 1990. An Introduction to Formal Languages and Automata.
Lexington/Toronto: D. C. Heath and Company.

The above definition specifies this execution trace:
It can be understood from the above specification that when the embedded
halt decider at Ĥ.qx bases its halting decision on simulating its input,
and it has ([Ĥ],[Ĥ]) as its input that:
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy then
Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
this copy...
unless and until the halt decider at Ĥ.qx stops simulating its input.

When we apply the Generic halt deciding principle to the embedded
simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
that the simulation of this input must be aborted.

Because the necessity to abort the simulation of an input is equated
with this input specifying an infinite computation the simulating halt
decider Ĥ.qx correctly transitions to its final Ĥ.qn state deciding not
halting on its input.

The computation Ĥ([Ĥ]) only halts because it contains an otherwise
infinitely nested simulation that has been aborted at state Ĥ.qx.
Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
evidence that it is a halting computation.

The above proof does correctly refute the halting theorem.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

olcott <NoOne@NoWhere.com> writes:

> Halting problem undecidability and infinitely nested simulation

Some recent remarks from Peter Olcott that give a good flavour of his
approach:

"What I don't know is what an instance of the halting problem is."

"Whether a computation is finite is more nuanced than it simply stops
running"

"the fact that a computation halts does not entail that it is a halting
computation"

"To limit the scope of a halt decider to only report whether or not
its input actually halts is to artificially constrain an otherwise
correct halt decider."

--
Ben.

On 5/27/2021 10:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Halting problem undecidability and infinitely nested simulation
>
> Some recent remarks from Peter Olcott that give a good flavour of his
> approach:
>
> "What I don't know is what an instance of the halting problem is."
>
> "Whether a computation is finite is more nuanced than it simply stops
> running"
>
> "the fact that a computation halts does not entail that it is a halting
> computation"
>
> "To limit the scope of a halt decider to only report whether or not
> its input actually halts is to artificially constrain an otherwise
> correct halt decider."
>

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

When we apply the Generic halt deciding principle to the embedded
simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
that the simulation of this input must be aborted.

Because the necessity to abort the simulation of an input is equated
with this input specifying an infinite computation the simulating halt
decider Ĥ.qx correctly transitions to its final Ĥ.qn state deciding not
halting on its input.

The computation Ĥ([Ĥ]) only halts because it contains an otherwise
infinitely nested simulation that has been aborted at state Ĥ.qx.
Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
evidence that it is a halting computation.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 5/27/2021 10:31 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Halting problem undecidability and infinitely nested simulation
>
> Some recent remarks from Peter Olcott that give a good flavour of his
> approach:
>
> "What I don't know is what an instance of the halting problem is."
>
> "Whether a computation is finite is more nuanced than it simply stops
> running"
>
As proven by (A) and (B)

> "the fact that a computation halts does not entail that it is a halting
> computation"
>
As proven by (A) and (B)

> "To limit the scope of a halt decider to only report whether or not
> its input actually halts is to artificially constrain an otherwise
> correct halt decider."
>

If we are very precise in the meaning of those words then this means
that we cannot report that a computation will never halt until we first
wait forever and find that "its input actually halts"

On the other hand when the behavior of the simulation of an input
matches a non-halting behavior pattern, then we need not wait forever to
see if: "its input actually halts".

void Infinite_Loop()
{ HERE: goto HERE;
}

_Infinite_Loop()
[00000aaf](01) 55 push ebp
[00000ab0](02) 8bec mov ebp,esp
[00000ab2](02) ebfe jmp 00000ab2
[00000ab4](01) 5d pop ebp
[00000ab5](01) c3 ret
Size in bytes:(0007) [00000ab5]

[infinite_loop] non-halting behavior pattern
(a) The instruction is a JMP instruction.
(b) It is jumping upward or to its own address.
(c) There are no conditional branch instructions in-between.
(d) There are no other JMP instructions in-between (André G. Isaak)

When the [infinite_loop] non-halting behavior pattern of the simulation
of _Infinite_Loop() is matched by the behavior of _Infinite_Loop() the
simulating halt decider correctly decides not-halting on this input.

Begin Local Halt Decider Simulation at Machine Address:aaf
....[00000aaf][002115e2][002115e6](01) 55 push ebp
....[00000ab0][002115e2][002115e6](02) 8bec mov ebp,esp
....[00000ab2][002115e2][002115e6](02) ebfe jmp 00000ab2
....[00000ab2][002115e2][002115e6](02) ebfe jmp 00000ab2
Local Halt Decider: Infinite Loop Detected Simulation Stopped

Ben has a very hard time with my words because he generally does not pay
very close attention to what I am actually saying. Ben focuses most of
his attention on spouting off some contrived rebuttal or another.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

When we apply the Generic halt deciding principle to the embedded
simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
that the simulation of this input must be aborted.

(A) Because the necessity to abort the simulation of an input is equated
with this input specifying an infinite computation the simulating halt
decider Ĥ.qx correctly transitions to its final Ĥ.qn state deciding not
halting on its input.

(B) The computation Ĥ([Ĥ]) only halts because it contains an otherwise
infinitely nested simulation that has been aborted at state Ĥ.qx.
Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
evidence that it is a halting computation.

http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

On 2021-05-27 12:38, olcott wrote:
> On 5/27/2021 10:31 AM, Ben Bacarisse wrote:
>> olcott <NoOne@NoWhere.com> writes:
>>
>>> Halting problem undecidability and infinitely nested simulation
>>
>> Some recent remarks from Peter Olcott that give a good flavour of his
>> approach:
>>
>>    "What I don't know is what an instance of the halting problem is."
>>
>>    "Whether a computation is finite is more nuanced than it simply stops
>>    running"
>>
> As proven by (A) and (B)
>
>
>>    "the fact that a computation halts does not entail that it is a
>> halting
>>    computation"
>>
> As proven by (A) and (B)
>
>
>>    "To limit the scope of a halt decider to only report whether or not
>>    its input actually halts is to artificially constrain an otherwise
>>    correct halt decider."
>>
>
> If we are very precise in the meaning of those words then this means
> that we cannot report that a computation will never halt until we first
> wait forever and find that "its input actually halts"

There's nothing in the definition of a halt decider that requires one to
run (or simulate) the computation. It was your decision to do things
this way. If that decision creates problems, you can't blame those
problems on the way the halting problem is formulated.

We can easily determine that many computations don't halt without
waiting forever. You only have to wait forever if you're stupid enough
to try to establish that they don't halt by running/simulating them.

> On the other hand when the behavior of the simulation of an input
> matches a non-halting behavior pattern, then we need not wait forever to
> see if: "its input actually halts".
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> _Infinite_Loop()
> [00000aaf](01)  55                      push ebp
> [00000ab0](02)  8bec                    mov ebp,esp
> [00000ab2](02)  ebfe                    jmp 00000ab2
> [00000ab4](01)  5d                      pop ebp
> [00000ab5](01)  c3                      ret
> Size in bytes:(0007) [00000ab5]
>
> [infinite_loop] non-halting behavior pattern
> (a) The instruction is a JMP instruction.
> (b) It is jumping upward or to its own address.
> (c) There are no conditional branch instructions in-between.
> (d) There are no other JMP instructions in-between (André G. Isaak)
>
> When the [infinite_loop] non-halting behavior pattern of the simulation
> of _Infinite_Loop() is matched by the behavior of _Infinite_Loop() the
> simulating halt decider correctly decides not-halting on this input.
>
> Begin Local Halt Decider Simulation at Machine Address:aaf
> ...[00000aaf][002115e2][002115e6](01)  55                      push ebp
> ...[00000ab0][002115e2][002115e6](02)  8bec                    mov ebp,esp
> ...[00000ab2][002115e2][002115e6](02)  ebfe                    jmp 00000ab2
> ...[00000ab2][002115e2][002115e6](02)  ebfe                    jmp 00000ab2
> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>
> Ben has a very hard time with my words because he generally does not pay
> very close attention to what I am actually saying. Ben focuses most of
> his attention on spouting off some contrived rebuttal or another.
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> When we apply the Generic halt deciding principle to the embedded
> simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
> that the simulation of this input must be aborted.
>
> (A) Because the necessity to abort the simulation of an input is equated
> with this input specifying an infinite computation the simulating halt
> decider Ĥ.qx correctly transitions to its final Ĥ.qn state deciding not
> halting on its input.
>
> (B) The computation Ĥ([Ĥ]) only halts because it contains an otherwise
> infinitely nested simulation that has been aborted at state Ĥ.qx.
> Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
> the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
> evidence that it is a halting computation.

If something 'only halts because of X' it still halts.

It's no different from claiming that an airplane only flies because its
wings generate lift. Would you argue that an airplane doesn't *actually*
fly based on that 'only...because' clause?

André

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

On 5/27/2021 3:24 PM, André G. Isaak wrote:
> On 2021-05-27 12:38, olcott wrote:
>> On 5/27/2021 10:31 AM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>
>>> Some recent remarks from Peter Olcott that give a good flavour of his
>>> approach:
>>>
>>>    "What I don't know is what an instance of the halting problem is."
>>>
>>>    "Whether a computation is finite is more nuanced than it simply stops
>>>    running"
>>>
>> As proven by (A) and (B)
>>
>>
>>>    "the fact that a computation halts does not entail that it is a
>>> halting
>>>    computation"
>>>
>> As proven by (A) and (B)
>>
>>
>>>    "To limit the scope of a halt decider to only report whether or not
>>>    its input actually halts is to artificially constrain an otherwise
>>>    correct halt decider."
>>>
>>
>> If we are very precise in the meaning of those words then this means
>> that we cannot report that a computation will never halt until we
>> first wait forever and find that "its input actually halts"
>
> There's nothing in the definition of a halt decider that requires one to
> run (or simulate) the computation.

Thanks for responding.

Of course there isn't and it is quite silly that this point keeps
getting repeated. The proof categorically claims that no type of halt
decider correctly decides all inputs on the basis of inputs that do the
opposite of whatever its paired decider decides.

If there exists any type of decider that does correctly decide paired
inputs that do the opposite of whatever this decider decides then the
categorical claim of the proof is proven to be incorrect.

It turns out that a halt decider based on simulating its input is such a
decider that refutes the categorical claim of the proofs.

> It was your decision to do things
> this way. If that decision creates problems, you can't blame those
> problems on the way the halting problem is formulated.
>
> We can easily determine that many computations don't halt without
> waiting forever. You only have to wait forever if you're stupid enough
> to try to establish that they don't halt by running/simulating them.
>
>> On the other hand when the behavior of the simulation of an input
>> matches a non-halting behavior pattern, then we need not wait forever
>> to see if: "its input actually halts".
>>
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>>
>> _Infinite_Loop()
>> [00000aaf](01)  55                      push ebp
>> [00000ab0](02)  8bec                    mov ebp,esp
>> [00000ab2](02)  ebfe                    jmp 00000ab2
>> [00000ab4](01)  5d                      pop ebp
>> [00000ab5](01)  c3                      ret
>> Size in bytes:(0007) [00000ab5]
>>
>> [infinite_loop] non-halting behavior pattern
>> (a) The instruction is a JMP instruction.
>> (b) It is jumping upward or to its own address.
>> (c) There are no conditional branch instructions in-between.
>> (d) There are no other JMP instructions in-between (André G. Isaak)
>>
>> When the [infinite_loop] non-halting behavior pattern of the
>> simulation of _Infinite_Loop() is matched by the behavior of
>> _Infinite_Loop() the simulating halt decider correctly decides
>> not-halting on this input.
>>
>> Begin Local Halt Decider Simulation at Machine Address:aaf
>> ...[00000aaf][002115e2][002115e6](01)  55                      push ebp
>> ...[00000ab0][002115e2][002115e6](02)  8bec                    mov
>> ebp,esp
>> ...[00000ab2][002115e2][002115e6](02)  ebfe                    jmp
>> 00000ab2
>> ...[00000ab2][002115e2][002115e6](02)  ebfe                    jmp
>> 00000ab2
>> Local Halt Decider: Infinite Loop Detected Simulation Stopped
>>
>> Ben has a very hard time with my words because he generally does not
>> pay very close attention to what I am actually saying. Ben focuses
>> most of his attention on spouting off some contrived rebuttal or another.
>>
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
>> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>>
>> When we apply the Generic halt deciding principle to the embedded
>> simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
>> that the simulation of this input must be aborted.
>>
>> (A) Because the necessity to abort the simulation of an input is
>> equated with this input specifying an infinite computation the
>> simulating halt decider Ĥ.qx correctly transitions to its final Ĥ.qn
>> state deciding not halting on its input.
>>
>> (B) The computation Ĥ([Ĥ]) only halts because it contains an otherwise
>> infinitely nested simulation that has been aborted at state Ĥ.qx.
>> Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
>> the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
>> evidence that it is a halting computation.
>
> If something 'only halts because of X' it still halts.
>

Not the way that I am defining my terms:

Everyone knows that infinite loops are finite strings that specify
infinite computations.

This same reasoning equally applies to infinite recursion and infinitely
nested simulation.

On 5/11/2021 11:10 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> Truism:
>> Every simulation that would never stop unless Halts() stops
>> it at some point specifies infinite execution.
>
> Any algorithm that implements this truism is, of course, a halting
> decider.

Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qy ∞
Ĥ.q0 wM ⊢* Ĥ.qx wM wM ⊢* Ĥ.qn

The input to the computation Ĥ.qx(<Ĥ><Ĥ>) exactly matches the above
criteria.

> It's no different from claiming that an airplane only flies because its
> wings generate lift. Would you argue that an airplane doesn't *actually*
> fly based on that 'only...because' clause?
>
> André
>

--
Copyright 2021 Pete Olcott

"Great spirits have always encountered violent opposition from mediocre
minds." Einstein

First flaw, the title.

People have NOT stopped rebutting your statement, but you don't seem to
be able to understand what they are saying, so maybe you are missing that.

The mere fact that you make such a claim shows how out of touch you are
with actual reality.

On 5/27/21 11:01 AM, olcott wrote:
> Halting problem undecidability and infinitely nested simulation
>
> When input P to simulating halt decider H has the pathological
> self-reference error (PSRE) simulating halt decider H decides this input
> P on the basis of proxy input P2 that has the pathological
> self-reference error removed.

The Halting problem question, and the confounding machine H^ do NOT have
pathological self-reference. The key to seeing this is that FIRST, you
must decide on the algorithm that your proposed halt decider is going to
use. One you establish that, and only after that, can you then write the
H^ based on it (which make a COPY of the algorithm, not a reference to
it) and then we make a description of that machine, which again is a copy.

THE IS NO REFERENCE, so there can be no self-reference.

The point that you confuse is that in the DESIGN phase, knowing the
question that is going to be posed to you, you need to ask the question
that you talk of as the actual question of the halting problem (which is
isn't). THAT question, what does H need to return to answer H^
correctly, does have a self-reference, and the pathology that you find
is the actual proof that such a machine can not be made (and there is
actually no requirement that it can).

>
> void H_Hat(u32 P)
> {
>   u32 Input_Halts = Halts(P, P);
>   if (Input_Halts)
>     HERE: goto HERE;
> }
>
> The pathological self-reference error arises in the halting theorem from
> the fact that neither return values: {0, 1} from Halts() to H_Hat()
> represent the actual halting behavior of H_Hat() in the computation:
> Halts((u32)H_Hat, (u32)H_Hat);
>

And there is no requirement that there is. Given that to ask the
question of what does H_Hat(H_Hat) do, we FIRST need to have defined
what the computation in Halts iw, and thus that 'right' answer to what
Halts should produce is what that computation defines its output to be.
That answer will always turn out to be the WRONG answer to the actual
Halting Problem Question, that being does the machine that the input to
Halts represents actually halt or run forever.

> When we define H_Hat2() by replacing the call to Halts() with a call to
> Simulate()

And this is studing a white dog to answer a question about black cats.
In does NOT give the right answer.

>
> u32 Simulate(u32 P, u32 I)
> {
>   ((void(*)(int))P)(I);
>   return 1;
> }
>
> H_Hat2() never halts on its own machine address as input.
> This key fact is leveraged to correctly decide halting:
> Halts((u32)H_Hat, (u32)H_Hat);
>
> We hypothesize that input P having the pathological self-reference error
> (PSRE) can be substituted for equivalent proxy input P2 such that the
> halting status of P2 derives the halting status of P.  If this
> hypothesis  is correct it becomes the basis for refuting the halting
> theorem.

You might Hypothesize this, but you haven't actually proved that this is
a valid operation.

IF wishes were horses, then beggars would ride.

>
> To put this in concrete terms if Halts((u32)H_Hat2, (u32)H_Hat2);
> provides the correct halting value for Halts((u32)H_Hat, (u32)H_Hat);
> then H_Hat becomes a decidable input. The rest of the proof will attempt
> to show this.
>
> Generic halt deciding principle for inputs having the pathological
> self-reference error

No they don't.

>
> Whenever input P has the pathological self-reference error such that a
> simulating halt decider H must decide halting on an input that invokes
> itself we define proxy input P2 copy of P such that the embedded
> simulating halt decider is replaced with a simulator.

No it doesn't. You have ZERO grounds to say this operation is valid.

It is also computationally impossible to perform this substitution with
real Turing Machines. It is impossible for a given Turing machine to
100% accurately detect it presence withing the description of a Turing
Machine provided as its input. IMPOSSIBLE.

This is like beginning a proof with let us assume that 1 is equal to 2.

>
> (a) Simulating halt decider H and simulator S are equivalent
> computations for all inputs P that halt. This means that H correctly
> decides halting on P if and only if P2 halts.

WRONG.

Counter example: Linz H^

Using your logic, H will answer non-halting.

WHen H^ runs its copy of H, it will get that non-halting answer and halt.

This shows you logic is wrong.

Second counter example. Let P be a program that includes in it a request
to use H to halt decide an infinite loop, and return that answer.

Since H is a Halt Decider, it should be a finite computation, so this P
should also be a finite computation, and Halts. By substituting H in P
to be a pure simulator, that simulator will get stuck in an infinite
loop simulating, and thus P doesn't get decided as a halting computation.

Also. as mentioned above, it is impossible to actually do this.

>
> (b) Simulating halt decider H and simulator S are equivalent
> computations for all inputs P that do not halt up to the point where H
> stops simulating P. This means that H correctly decides not halting on P
> if and only if P2 does not halt.

See above second couter example.

>
> In other words: Halts correctly decides not halting on H_Hat because
> H_Hat2 does not halt.

WRONG. See proofs above.

>
> Peter Linz Ĥ applied to the Turing machine description of itself: [Ĥ]
>            Figure 12.3 Turing Machine Ĥ
>
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qy  ∞
> Ĥ.q0  wM  ⊢*  Ĥ.qx  wM  wM  ⊢*  Ĥ.qn
>
> The above is adapted from (Linz:1990:319).
> It shows that Turing machine Ĥ copies its input at (q0) and begins
> executing an embedded copy of the original halt decider with this input
> at (qx).
>
> The (qy) state indicates that the halt decider has determined that its
> input would halt. The ((qn)) state indicates the input would not halt.
> The appended (qa) and (qb) states cause Ĥ to infinitely loop if the halt
> decider decides that its input would halt.
>
> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company.
>
> The above definition specifies this execution trace:
> It can be understood from the above specification that when the embedded
> halt decider at Ĥ.qx bases its halting decision on simulating its input,
> and it has ([Ĥ],[Ĥ]) as its input that:
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy then
> Ĥ.q0 would copy its input and then Ĥ.qx would simulate its input with
> this copy...
> unless and until the halt decider at Ĥ.qx stops simulating its input.
>
> When we apply the Generic halt deciding principle to the embedded
> simulating halt decider at state Ĥ.qx to its input ([Ĥ],[Ĥ]) we find
> that the simulation of this input must be aborted.

Yes, The H that doesn't know how to halt the loop will fail to be a Halt
decider as it can't an
>
> Because the necessity to abort the simulation of an input is equated
> with this input specifying an infinite computation the simulating halt
> decider Ĥ.qx correctly transitions to its final Ĥ.qn state deciding not
> halting on its input.

>
> The computation Ĥ([Ĥ]) only halts because it contains an otherwise
> infinitely nested simulation that has been aborted at state Ĥ.qx.
> Because an aspect of the Ĥ([Ĥ]) computation has been aborted to force
> the computation to halt we cannot count that fact that Ĥ([Ĥ]) halts
> evidence that it is a halting computation.

WRONG. Because H does abort its simulation and return this answer to the
H^ that was using it, that H^ will Halt, and thus shows that H^ is a
halting computation. That decision is TOTAL based on logic with H^, thus
it gets credit for that halting.

The definition of Halting is based ONLY on the actual behavior of the
actual running of that computation. Since H^ does halt, and you even
agree to that, it is a Halting Computation

Otherwise, you are calling this an infinite loop:

for(int i=0; isLessThan(i, 5); i++) continue;

>
> The above proof does correctly refute the halting theorem.
>
> http://www.liarparadox.org/Halting_problem_undecidability_and_infinitely_nested_simulation.pdf
>
>

No it doesn't You have failed.

IF you want to redefine the problem to Olcott-Halting, then maybe you
can show that H does correctly answer the H^ is Olcott Non-Halting.

On Thu, 27 May 2021 10:01:13 -0500
olcott <NoOne@NoWhere.com> wrote:

[snip]

> The above proof does correctly refute the halting theorem.

Which halting theorem? You haven't refuted Turing until you address the
issue of branching logic predicated on arbitrary program input.

/Flibble