The x86utm operating system was created so that the halting problem
could be examined concretely in the high level language of C.
When examining the halting problem this way every detail can be
explicitly specified. UTM tape elements are 32-bit unsigned integers.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

H analyzes the (currently updated) stored execution trace of its x86
emulation of P(P) after it simulates each instruction of input (P, P).
As soon as a non-halting behavior pattern is matched H aborts the
simulation of its input and decides that its input does not halt.

Every H only acts as a pure x86 emulator until some P has demonstrated
that it will never halt unless it is aborted. Because of this the
behavior of H can always be ignored in every execution trace.

The indices to H and P indicate the degree of nested simulation. It is
easily verified that the above computation never halts unless some H(n)
aborts some P(m).

If any H(n) must abort any P(m) then this H(n) does correctly decide
that this P(m) does not halt.

In the above computation (zero based addressing) H(1) aborts P(2).

Halting problem undecidability and infinitely nested simulation

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 12:54 PM, Richard Damon wrote:
> On 7/5/21 1:17 PM, olcott wrote:
>> On 7/5/2021 12:06 PM, Richard Damon wrote:
>>> On 7/5/21 12:28 PM, olcott wrote:
>>>> The x86utm operating system was created so that the halting problem
>>>> could be examined concretely in the high level language of C.
>>>> When examining the halting problem this way every detail can be
>>>> explicitly specified. UTM tape elements are 32-bit unsigned integers.
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>>    u32 Input_Halts = H(x, x);
>>>>    if (Input_Halts)
>>>>      HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    P((u32)P);
>>>> }
>>>>
>>>> H analyzes the (currently updated) stored execution trace of its x86
>>>> emulation of P(P) after it simulates each instruction of input (P, P).
>>>> As soon as a non-halting behavior pattern is matched H aborts the
>>>> simulation of its input and decides that its input does not halt.
>>>>
>>>> Every H only acts as a pure x86 emulator until some P has demonstrated
>>>> that it will never halt unless it is aborted. Because of this the
>>>> behavior of H can always be ignored in every execution trace.
>>>>
>>>> The indices to H and P indicate the degree of nested simulation. It is
>>>> easily verified that the above computation never halts unless some H(n)
>>>> aborts some P(m).
>>>>
>>>> If any H(n) must abort any P(m) then this H(n) does correctly decide
>>>> that this P(m) does not halt.
>>>>
>>>> In the above computation (zero based addressing) H(1) aborts P(2).
>>>>
>>>> Halting problem undecidability and infinitely nested simulation
>>>>
>>>> https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation
>>>>
>>>>
>>>>
>>>
>>> So, you now do indicate somewhat via the stack address that changes on
>>> calls.
>>>
>>> But you still have the unsound claim that H can ignore its own behavior.
>>
>> That a simulating halt decider only aborts its input after its input has
>> demonstrated non-halting behavior and acts as a pure simulator until
>> then seems to be above your capacity to comprehend.
>>
>
> That you need to actually PROVE your assertions seems to be beyond yours.
>
> H does NOT see actual PROOF of non-Halting behavior, because H ignores
> that fact that the H within P can and will abort the simulation and thus
> make P a Halting Computation.

This really really seems to be beyond your capacity to understand:

H never ever gets to the point in its own execution where it aborts the
simulation of its input until AFTER its input has already proven that it
will never halt unless aborted.

I have told that twenty times now and you still don't get it.
I have told that twenty times now and you still don't get it.
I have told that twenty times now and you still don't get it.
I have told that twenty times now and you still don't get it.
I have told that twenty times now and you still don't get it.

When H simulates inputs that halt H ONLY acts as a pure simulator until
these inputs halt on their own.

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
> For anyone interested, here's the answer to the question posed in the
> subject line: How do we know that H(P,P)==0 is correct?
>
> We know that H(M,I) == 0 (false) is correct if, and only if, M(I) is not
> a halting (finite) computation.
>
> But PO rejects the very definition of a halting decider: a TM that
> accepts exactly those strings that represent finite computations, and
> rejects all others.
>
> Instead, a PO "Other-Halting" decider also rejects some strings that
> represent finite computations, specifically P(P) where P is hat(H), a
> function defined in terms of H like this:
>
> def hat(h):
> def p(x):
> if h(x, x):
> while True: pass
> return p
>
> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
> hat(H)(hat(H)) being a halting computation. No one except PO is
> interested in the POOH problem.
>
> On the other hand, everyone is interested in halting, but the
> computation D(hat(D), hat(D)) shows that no D computes the halting
> function.
>

Try and get your double-talk around this:

void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ P((u32)P);
}

Because the above computation must be aborted at some point or it never
halts the above computation is a non-halting computation.

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>> For anyone interested, here's the answer to the question posed in the
>>> subject line: How do we know that H(P,P)==0 is correct?
>>>
>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I) is not
>>> a halting (finite) computation.
>>>
>>> But PO rejects the very definition of a halting decider: a TM that
>>> accepts exactly those strings that represent finite computations, and
>>> rejects all others.
>>>
>>> Instead, a PO "Other-Halting" decider also rejects some strings that
>>> represent finite computations, specifically P(P) where P is hat(H), a
>>> function defined in terms of H like this:
>>> def hat(h):
>>> def p(x):
>>> if h(x, x):
>>> while True: pass
>>> return p
>>>
>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>> interested in the POOH problem.
>>>
>>> On the other hand, everyone is interested in halting, but the
>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>> function.
>>
>> Try and get your double-talk around this:
>>
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> Because the above computation must be aborted at some point or it
>> never halts the above computation is a non-halting computation.
>
> It is a halting computation because it halts. The fact that P(P) halts
> is not in dispute.
>
> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
> == 0 and so P(P) is a non-POOH computation. The only dispute is that
> you think someone might be interested in the POOH problem.
>
> (For obvious reasons, you resist giving the property you claim H is
> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
> you won't suggest a better alternative.)
>

In computability theory, the halting problem is the problem of
determining, from a description of an arbitrary computer program and an
input, whether the program will finish running, or continue to run
forever. https://en.wikipedia.org/wiki/Halting_problem

(1) At least one way to circumvent the pathological self-reference
(olcott 2004) of the halting problem counter-example templates is with a
simulating halt decider.

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
Output("Input_Would_Halt2 = ", Input_Would_Halt2);
}

(2) Because every input to a simulating halt decider either halts on its
own or must have its simulation terminated: all simulations that must be
terminated are correctly construed as non-halting computations.

(3) This criterion measure defines the exact same halting / not halting
sets as the halting problem. Every element P(I) that was a halting
computation remains a halting computation. Every element P(I) that was a
non-halting computation remains a non-halting computation.

The only thing that has changed is that undecidable inputs can no longer
be defined. Every TM / input pair falls into exactly one of two sets:
(a) Halting
(b) Non-halting

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 7:45 PM, Richard Damon wrote:
> On 7/5/21 8:04 PM, olcott wrote:
>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and an
>> input, whether the program will finish running, or continue to run
>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>
>> (1) At least one way to circumvent the pathological self-reference
>> (olcott 2004) of the halting problem counter-example templates is with a
>> simulating halt decider.
>>
>> void Infinite_Loop()
>> {
>>   HERE: goto HERE;
>> }
>>
>> int main()
>> {
>>   u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
>>   Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>> }
>>
>> (2) Because every input to a simulating halt decider either halts on its
>> own or must have its simulation terminated: all simulations that must be
>> terminated are correctly construed as non-halting computations.
>>
>> (3) This criterion measure defines the exact same halting / not halting
>> sets as the halting problem. Every element P(I) that was a halting
>> computation remains a halting computation. Every element P(I) that was a
>> non-halting computation remains a non-halting computation.
>>
>> The only thing that has changed is that undecidable inputs can no longer
>> be defined. Every TM / input pair falls into exactly one of two sets:
>> (a) Halting
>> (b) Non-halting
>>
>
> Problem is that this doesn't change the challenge of the ^ machine.
>
> The definition of Halting DOES NOT CHANGE.

Because every element of the set of computations that never halt unless
their simulation is aborted maps to every element of the set of
non-halting computations we know that it is an equivalent criterion
measure that defines the same set.

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 8:22 PM, Richard Damon wrote:
> On 7/5/21 9:01 PM, olcott wrote:
>> On 7/5/2021 7:45 PM, Richard Damon wrote:
>>> On 7/5/21 8:04 PM, olcott wrote:
>>>
>>>> In computability theory, the halting problem is the problem of
>>>> determining, from a description of an arbitrary computer program and an
>>>> input, whether the program will finish running, or continue to run
>>>> forever. https://en.wikipedia.org/wiki/Halting_problem
>>>>
>>>> (1) At least one way to circumvent the pathological self-reference
>>>> (olcott 2004) of the halting problem counter-example templates is with a
>>>> simulating halt decider.
>>>>
>>>> void Infinite_Loop()
>>>> {
>>>>    HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
>>>>    Output("Input_Would_Halt2 = ", Input_Would_Halt2);
>>>> }
>>>>
>>>> (2) Because every input to a simulating halt decider either halts on its
>>>> own or must have its simulation terminated: all simulations that must be
>>>> terminated are correctly construed as non-halting computations.
>>>>
>>>> (3) This criterion measure defines the exact same halting / not halting
>>>> sets as the halting problem. Every element P(I) that was a halting
>>>> computation remains a halting computation. Every element P(I) that was a
>>>> non-halting computation remains a non-halting computation.
>>>>
>>>> The only thing that has changed is that undecidable inputs can no longer
>>>> be defined. Every TM / input pair falls into exactly one of two sets:
>>>> (a) Halting
>>>> (b) Non-halting
>>>>
>>>
>>> Problem is that this doesn't change the challenge of the ^ machine.
>>>
>>> The definition of Halting DOES NOT CHANGE.
>>
>> Because every element of the set of computations that never halt unless
>> their simulation is aborted maps to every element of the set of
>> non-halting computations we know that it is an equivalent criterion
>> measure that defines the same set.
>>
>
> If it WAS an equivalnet set, then H^(H^) wouldn't be on different sides
> for the two divides.
>

The simulating halt decider has two crucial phases:
(1) It is only a simulator until its input proves that it will never
halt unless aborted.

At this point we have perfect certainty that the simulating halt decider
is correct.

(2) After its input proves that it will never halt unless its simulation
an aborted its input is aborted.

> It IS a computation that Halts, and thus NOT in the set of non-Halting
> computations. By your logic, it needs to be classified in the set of
> computations that never halt unless there simulation is aborted.
>
> Thus by your logic, they aren't equivalent sets.
>
> Ultimately the problem is you mis-define that later set, with the proper
> definition the equivalence does hold. The definition that does this is
> that it means that if the simulation would be unending unless the
> instance of the simulator that doing that simulation actually needs to
> abort the simulation, but replacing it with a pure non-aborting
> simulator would yield an infinite simulation. THAT definition works, not
> your crasy one the includes other copies of the algorithm aborting other
> copies of the machine.
>

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 9:33 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>>>> For anyone interested, here's the answer to the question posed in the
>>>>> subject line: How do we know that H(P,P)==0 is correct?
>>>>>
>>>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I) is not
>>>>> a halting (finite) computation.
>>>>>
>>>>> But PO rejects the very definition of a halting decider: a TM that
>>>>> accepts exactly those strings that represent finite computations, and
>>>>> rejects all others.
>>>>>
>>>>> Instead, a PO "Other-Halting" decider also rejects some strings that
>>>>> represent finite computations, specifically P(P) where P is hat(H), a
>>>>> function defined in terms of H like this:
>>>>>
>>>>> def hat(h):
>>>>> def p(x):
>>>>> if h(x, x):
>>>>> while True: pass
>>>>> return p
>>>>>
>>>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>>>> interested in the POOH problem.
>>>>>
>>>>> On the other hand, everyone is interested in halting, but the
>>>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>>>> function.
>>>>
>>>> Try and get your double-talk around this:
>>>>
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> Because the above computation must be aborted at some point or it
>>>> never halts the above computation is a non-halting computation.
>>>
>>> It is a halting computation because it halts. The fact that P(P) halts
>>> is not in dispute.
>>>
>>> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
>>> == 0 and so P(P) is a non-POOH computation. The only dispute is that
>>> you think someone might be interested in the POOH problem.
>
>> In computability theory, the halting problem is the problem of
>> determining, from a description of an arbitrary computer program and
>> an input, whether the program will finish running, or continue to run
>> forever. https://en.wikipedia.org/wiki/Halting_problem
>
> Yes, that's why H(P,P) == 0 is wrong (as far as halting is concerned)
> when P(P) halts.

The simulating halt decider has two crucial phases:
(1) It is only a simulator until its input proves that it will never
halt unless aborted.

At this point we have perfect certainty that the simulating halt decider
is correct.

(2) After its input proves that it will never halt unless its simulation
an aborted its input is aborted.

>
>> (1) At least one way to circumvent the pathological self-reference
>> (olcott 2004) of the halting problem counter-example templates is with
>> a simulating halt decider.
>>
>> (2) Because every input to a simulating halt decider either halts on
>> its own or must have its simulation terminated: all simulations that
>> must be terminated are correctly construed as non-halting
>> computations.
>
> The only computations that should be construed as non-halting are the
> ones that don't halt. Why does this still need to be said? Have you
> simply lost the plot?
>

A simulating halt decider is only a simulator until its input proves
that it will never halt unless aborted.

We know that when UTM(P,I) never halts that P(I) never halts.
When a simulating halt decider determines that UTM(P,I) never halts then
and only then it switches modes from simulator to halt decider.

The significance of this crucial timing difference is beyond Richard's
capacity to understand.

If H is only a simulator until it makes its halt status decision then it
is impossible for the behavior of H to have any effect what-so-ever on
this halt status decision. Richard does not seem to have the capacity to
begin to understand that.

>> (3) This criterion measure defines the exact same halting / not
>> halting sets as the halting problem.
>
> Not according to you. P(P) halts but it's non-POOH because it halts in
> the way you decided is "special".
>
>> Every element P(I) that was a
>> halting computation remains a halting computation. Every element P(I)
>> that was a non-halting computation remains a non-halting computation.
>
> Not according to you. If they were the same, you'd agree that every
> instance of the halting problem has a correct yes/no answer and that yes
> is only correct for those strings that represent halting computations.

I still have no idea of what you mean by halting problem instances,
however every TM / input pair either halts on its input or not.

A non-halting computation is every computation that never halts unless
its simulation is aborted.

This maps to every element of the conventional halting problem set of
non-halting computations and a few more.

> But despite endlessly quoting Wikipedia and Linz you reject this
> definition in favour of POOH.
>
>> The only thing that has changed is that undecidable inputs can no
>> longer be defined. Every TM / input pair falls into exactly one of two
>> sets:
>> (a) Halting
>> (b) Non-halting
>
> Actually you can't do this even for the POOH problem, but since you
> don't engage with difficult topics, there's no way I can explain to you
> why.
>

--
Copyright 2021 Pete Olcott

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

On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>> For anyone interested, here's the answer to the question posed in the
>>> subject line: How do we know that H(P,P)==0 is correct?
>>>
>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I) is not
>>> a halting (finite) computation.
>>>
>>> But PO rejects the very definition of a halting decider: a TM that
>>> accepts exactly those strings that represent finite computations, and
>>> rejects all others.
>>>
>>> Instead, a PO "Other-Halting" decider also rejects some strings that
>>> represent finite computations, specifically P(P) where P is hat(H), a
>>> function defined in terms of H like this:
>>> def hat(h):
>>> def p(x):
>>> if h(x, x):
>>> while True: pass
>>> return p
>>>
>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>> interested in the POOH problem.
>>>
>>> On the other hand, everyone is interested in halting, but the
>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>> function.
>>
>> Try and get your double-talk around this:
>>
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> P((u32)P);
>> }
>>
>> Because the above computation must be aborted at some point or it
>> never halts the above computation is a non-halting computation.
>
> It is a halting computation because it halts. The fact that P(P) halts
> is not in dispute.
>
> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
> == 0 and so P(P) is a non-POOH computation. The only dispute is that
> you think someone might be interested in the POOH problem.
>
> (For obvious reasons, you resist giving the property you claim H is
> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
> you won't suggest a better alternative.)
>

On the basis that we know that every UTM(P,I) never halts defines the
exact same set of computations that must be aborted by a simulating halt
decider which defines the exact same set of computations P(I) that never
halt we can know that any input to a simulating halt decider that never
halts unless its simulation is aborted is a non-halting computation.

Because we know that a simulating halt decider only simulates its input
until after it has made its halt status decision we can know that H can
ignore its own address range in its execution traces.

Because the x86 execution trace of P on input P provides no possible
escape from infinitely nested simulation and we can ignore the execution
trace of H then we can know that H must abort its simulation of P on the
basis of the sixteen lines of P:

_P()
[00000b25](01) 55 push ebp
[00000b26](02) 8bec mov ebp,esp
[00000b28](01) 51 push ecx
[00000b29](03) 8b4508 mov eax,[ebp+08]
[00000b2c](01) 50 push eax
[00000b2d](03) 8b4d08 mov ecx,[ebp+08]
[00000b30](01) 51 push ecx
[00000b31](05) e81ffeffff call 00000955 // call H

Begin Local Halt Decider Simulation at Machine Address:b25
....[00000b25][002116fe][00211702](01) 55 push ebp // P1
....[00000b26][002116fe][00211702](02) 8bec mov ebp,esp
....[00000b28][002116fa][002016ce](01) 51 push ecx
....[00000b29][002116fa][002016ce](03) 8b4508 mov eax,[ebp+08]
....[00000b2c][002116f6][00000b25](01) 50 push eax
....[00000b2d][002116f6][00000b25](03) 8b4d08 mov ecx,[ebp+08]
....[00000b30][002116f2][00000b25](01) 51 push ecx
....[00000b31][002116ee][00000b36](05) e81ffeffff call 00000955 // H1
....[00000b25][0025c126][0025c12a](01) 55 push ebp // P2
....[00000b26][0025c126][0025c12a](02) 8bec mov ebp,esp
....[00000b28][0025c122][0024c0f6](01) 51 push ecx
....[00000b29][0025c122][0024c0f6](03) 8b4508 mov eax,[ebp+08]
....[00000b2c][0025c11e][00000b25](01) 50 push eax
....[00000b2d][0025c11e][00000b25](03) 8b4d08 mov ecx,[ebp+08]
....[00000b30][0025c11a][00000b25](01) 51 push ecx
....[00000b31][0025c116][00000b36](05) e81ffeffff call 00000955 // H2
Local Halt Decider: Infinite Recursion Detected Simulation Stopped

--
Copyright 2021 Pete Olcott

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

On 7/6/2021 9:42 AM, wij wrote:
> On Tuesday, 6 July 2021 at 21:27:20 UTC+8, olcott wrote:
>> On 7/6/2021 7:07 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>
>>>>>> Try and get your double-talk around this:
>>>>>>
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> P((u32)P);
>>>>>> }
>>>>>>
>>>>>> Because the above computation must be aborted at some point or it
>>>>>> never halts the above computation is a non-halting computation.
>>>>>
>>>>> It is a halting computation because it halts. The fact that P(P) halts
>>>>> is not in dispute.
>>>>>
>>>>> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
>>>>> == 0 and so P(P) is a non-POOH computation. The only dispute is that
>>>>> you think someone might be interested in the POOH problem.
>>>>> (For obvious reasons, you resist giving the property you claim H is
>>>>> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
>>>>> you won't suggest a better alternative.)
>>>>
>>>> On the basis that we know that every UTM(P,I) never halts defines the
>>>> exact same set of computations that must be aborted by a simulating
>>>> halt decider which defines the exact same set of computations P(I)
>>>> that never halt we can know that any input to a simulating halt
>>>> decider that never halts unless its simulation is aborted is a
>>>> non-halting computation.
>>>
>>> That's a lot of waffle. The computations for which a halt decider
>>> should return 0 are those that don't halt. P(P) halts, so H(P,P) == 0
>>> is wrong.
>>>
>> The is a lot of double-talk. I provided a sequence of correct deductions
>> and you only provided your opinion that you don't like it.
>
> That is simply all it is, not an opinion (IMO), very simple.
> You made a simple thing very complicated for yourself, by redefining the HP,
> and build an 'x86utm' OS because you like it? or what?
>
>>> Any decision problem for which 0 is the correct answer for P(P) is
>>> something other than the halting problem. I'm calling it the PO
>>> "Other-Halting" problem until a better name is suggested.
>>>
>>>> Because the x86 execution trace of P on input P...
>>>
>>> ... shows that P(P) halts, we know that H(P,P) == 0 is wrong.
>>>
>> The criteria for non-halting is impossibly incorrect. If we have the DNA
>> of a black cat and this black cat barks we still have a black cat.
>
> Simple fact is that H can not pass a real test.
> There is no need for any real software engineer to talk about your reasoning
> and implement.

The criterion measure of every Turing Machine Description ⟨P⟩ of Turing
machine P that would never halt on its input I <is> the exact same set
as the set of simulations (P,I) that must be aborted to prevent their
infinite simulation <is> the exact same set as Turing machines that do
not halt on their input P(I) cannot be circumvented or bypassed.

There is no case where a black cat is not a cat that is black.

>
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein
+

--
Copyright 2021 Pete Olcott

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

On 7/6/2021 7:39 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I still have no idea of what you mean by halting problem instances,
>
> Yet you are prepared to pontificate about it.
>
>> however every TM / input pair either halts on its input or not.
>>
>> A non-halting computation is every computation that never halts unless
>> its simulation is aborted.
>
> A non-halting computation is simply a computation that never halts.
> Those that halt (for whatever reason) are halting computations. Here
> you appear to be defining (rather vaguely) non-POOH computations without
> the honesty of giving the property a clear name.
>

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ u32 Input_Would_Halt2 = H((u32)Infinite_Loop, (u32)Infinite_Loop);
Output("Input_Would_Halt2 = ", Input_Would_Halt2);
}

You keep dodging this.
When Infinite_Loop() is forced to halt its stops running.

void Infinite_Recursion(u32 N)
{ Infinite_Recursion(N);
}

int main()
{ u32 Input_Halts = H((u32)Infinite_Recursion, 3);
Output("Input_Halts = ", Input_Halts);
}

When Infinite_Recursion() is forced to halt its stops running.

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

When P() is forced to halt its stops running.

This proves that forced to halt does not count as halting.

All computations that must be forced to halt to prevent their infinite
simulation is the same set of simulations that never halt is the same
set as computation that never halt.

That a simulating halt decider later forced them to halt so that it
could report that they never halt does not ever count as halting.

>> This maps to every element of the conventional halting problem set of
>> non-halting computations and a few more.
>
> Yes. The halting problem and the POOH problem have different "yes" and
> "no" sets. You can choose to be potentially right talking about the
> POOH problem, or you can be certainly wrong by pretending that you are
> talking about the halting problem.
>

--
Copyright 2021 Pete Olcott

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

On 7/6/2021 7:39 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> I still have no idea of what you mean by halting problem instances,
>
> Yet you are prepared to pontificate about it.
>
>> however every TM / input pair either halts on its input or not.
>>
>> A non-halting computation is every computation that never halts unless
>> its simulation is aborted.
>
> A non-halting computation is simply a computation that never halts.
> Those that halt (for whatever reason) are halting computations. Here
> you appear to be defining (rather vaguely) non-POOH computations without
> the honesty of giving the property a clear name.
>
>> This maps to every element of the conventional halting problem set of
>> non-halting computations and a few more.
>
> Yes. The halting problem and the POOH problem have different "yes" and
> "no" sets. You can choose to be potentially right talking about the
> POOH problem, or you can be certainly wrong by pretending that you are
> talking about the halting problem.
>

When the simulation of a computation halts without ever being aborted
this is exactly the same as the set of halting problem computations that
halt.

Every element of the set of halting problem computations that never halt
map to an element of the set of simulations that must be aborted.

The set of halting problem TM / confounding inputs are no longer
confounding. They are no longer confounding because their erroneous
criterion measure that suffered from the pathological
self-reference(Olcott 2004) error has been transformed into a criterion
measure that does not have this error.

--
Copyright 2021 Pete Olcott

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

On Mon, 5 Jul 2021 23:15:06 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> > olcott <NoOne@NoWhere.com> writes:
> >
> >> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
> >>> For anyone interested, here's the answer to the question posed in
> >>> the subject line: How do we know that H(P,P)==0 is correct?
> >>>
> >>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I)
> >>> is not a halting (finite) computation.
> >>>
> >>> But PO rejects the very definition of a halting decider: a TM that
> >>> accepts exactly those strings that represent finite computations,
> >>> and rejects all others.
> >>>
> >>> Instead, a PO "Other-Halting" decider also rejects some strings
> >>> that represent finite computations, specifically P(P) where P is
> >>> hat(H), a function defined in terms of H like this:
> >>> def hat(h):
> >>> def p(x):
> >>> if h(x, x):
> >>> while True: pass
> >>> return p
> >>>
> >>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
> >>> hat(H)(hat(H)) being a halting computation. No one except PO is
> >>> interested in the POOH problem.
> >>>
> >>> On the other hand, everyone is interested in halting, but the
> >>> computation D(hat(D), hat(D)) shows that no D computes the halting
> >>> function.
> >>
> >> Try and get your double-talk around this:
> >>
> >> void P(u32 x)
> >> {
> >> u32 Input_Halts = H(x, x);
> >> if (Input_Halts)
> >> HERE: goto HERE;
> >> }
> >>
> >> int main()
> >> {
> >> P((u32)P);
> >> }
> >>
> >> Because the above computation must be aborted at some point or it
> >> never halts the above computation is a non-halting computation.
> >
> > It is a halting computation because it halts. The fact that P(P)
> > halts is not in dispute.
> >
> > Nor is it a matter of dispute that your POOH decider, H, returns
> > H(P,P) == 0 and so P(P) is a non-POOH computation. The only
> > dispute is that you think someone might be interested in the POOH
> > problem.
> >
> > (For obvious reasons, you resist giving the property you claim H is
> > deciding a proper name. I'm not entirely sold on "PO Other
> > Halting" but you won't suggest a better alternative.)
> >
>
> On the basis that we know that every UTM(P,I) never halts defines the
> exact same set of computations that must be aborted by a simulating
> halt decider which defines the exact same set of computations P(I)
> that never halt we can know that any input to a simulating halt
> decider that never halts unless its simulation is aborted is a
> non-halting computation.
>
> Because we know that a simulating halt decider only simulates its
> input until after it has made its halt status decision we can know
> that H can ignore its own address range in its execution traces.
>
> Because the x86 execution trace of P on input P provides no possible
> escape from infinitely nested simulation and we can ignore the
> execution trace of H then we can know that H must abort its
> simulation of P on the basis of the sixteen lines of P:
>
> _P()
> [00000b25](01) 55 push ebp
> [00000b26](02) 8bec mov ebp,esp
> [00000b28](01) 51 push ecx
> [00000b29](03) 8b4508 mov eax,[ebp+08]
> [00000b2c](01) 50 push eax
> [00000b2d](03) 8b4d08 mov ecx,[ebp+08]
> [00000b30](01) 51 push ecx
> [00000b31](05) e81ffeffff call 00000955 // call H
>
> Begin Local Halt Decider Simulation at Machine Address:b25
> ...[00000b25][002116fe][00211702](01) 55 push ebp
> // P1 ...[00000b26][002116fe][00211702](02) 8bec mov
> ebp,esp ...[00000b28][002116fa][002016ce](01) 51 push
> ecx ...[00000b29][002116fa][002016ce](03) 8b4508 mov
> eax,[ebp+08] ...[00000b2c][002116f6][00000b25](01) 50
> push eax ...[00000b2d][002116f6][00000b25](03) 8b4d08 mov
> ecx,[ebp+08] ...[00000b30][002116f2][00000b25](01) 51
> push ecx ...[00000b31][002116ee][00000b36](05) e81ffeffff call
> 00000955 // H1 ...[00000b25][0025c126][0025c12a](01) 55
> push ebp // P2 ...[00000b26][0025c126][0025c12a](02) 8bec
> mov ebp,esp ...[00000b28][0025c122][0024c0f6](01) 51
> push ecx ...[00000b29][0025c122][0024c0f6](03) 8b4508
> mov eax,[ebp+08] ...[00000b2c][0025c11e][00000b25](01) 50
> push eax ...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov
> ecx,[ebp+08] ...[00000b30][0025c11a][00000b25](01) 51
> push ecx ...[00000b31][0025c116][00000b36](05) e81ffeffff call
> 00000955 // H2 Local Halt Decider: Infinite Recursion Detected
> Simulation Stopped
But this case is trivial and uninteresting: your decider needs to
analyse branching logic predicated on arbitrary input to be
non-trivial and interesting. You've still got nothing of value to show.

/Flibble

On 7/6/2021 3:18 PM, Mr Flibble wrote:
> On Mon, 5 Jul 2021 23:15:06 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
>>>>> For anyone interested, here's the answer to the question posed in
>>>>> the subject line: How do we know that H(P,P)==0 is correct?
>>>>>
>>>>> We know that H(M,I) == 0 (false) is correct if, and only if, M(I)
>>>>> is not a halting (finite) computation.
>>>>>
>>>>> But PO rejects the very definition of a halting decider: a TM that
>>>>> accepts exactly those strings that represent finite computations,
>>>>> and rejects all others.
>>>>>
>>>>> Instead, a PO "Other-Halting" decider also rejects some strings
>>>>> that represent finite computations, specifically P(P) where P is
>>>>> hat(H), a function defined in terms of H like this:
>>>>> def hat(h):
>>>>> def p(x):
>>>>> if h(x, x):
>>>>> while True: pass
>>>>> return p
>>>>>
>>>>> For a POOH decider, H(hat(H), hat(H)) = False is correct, despite
>>>>> hat(H)(hat(H)) being a halting computation. No one except PO is
>>>>> interested in the POOH problem.
>>>>>
>>>>> On the other hand, everyone is interested in halting, but the
>>>>> computation D(hat(D), hat(D)) shows that no D computes the halting
>>>>> function.
>>>>
>>>> Try and get your double-talk around this:
>>>>
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> P((u32)P);
>>>> }
>>>>
>>>> Because the above computation must be aborted at some point or it
>>>> never halts the above computation is a non-halting computation.
>>>
>>> It is a halting computation because it halts. The fact that P(P)
>>> halts is not in dispute.
>>>
>>> Nor is it a matter of dispute that your POOH decider, H, returns
>>> H(P,P) == 0 and so P(P) is a non-POOH computation. The only
>>> dispute is that you think someone might be interested in the POOH
>>> problem.
>>>
>>> (For obvious reasons, you resist giving the property you claim H is
>>> deciding a proper name. I'm not entirely sold on "PO Other
>>> Halting" but you won't suggest a better alternative.)
>>>
>>
>> On the basis that we know that every UTM(P,I) never halts defines the
>> exact same set of computations that must be aborted by a simulating
>> halt decider which defines the exact same set of computations P(I)
>> that never halt we can know that any input to a simulating halt
>> decider that never halts unless its simulation is aborted is a
>> non-halting computation.
>>
>> Because we know that a simulating halt decider only simulates its
>> input until after it has made its halt status decision we can know
>> that H can ignore its own address range in its execution traces.
>>
>> Because the x86 execution trace of P on input P provides no possible
>> escape from infinitely nested simulation and we can ignore the
>> execution trace of H then we can know that H must abort its
>> simulation of P on the basis of the sixteen lines of P:
>>
>> _P()
>> [00000b25](01) 55 push ebp
>> [00000b26](02) 8bec mov ebp,esp
>> [00000b28](01) 51 push ecx
>> [00000b29](03) 8b4508 mov eax,[ebp+08]
>> [00000b2c](01) 50 push eax
>> [00000b2d](03) 8b4d08 mov ecx,[ebp+08]
>> [00000b30](01) 51 push ecx
>> [00000b31](05) e81ffeffff call 00000955 // call H
>>
>> Begin Local Halt Decider Simulation at Machine Address:b25
>> ...[00000b25][002116fe][00211702](01) 55 push ebp
>> // P1 ...[00000b26][002116fe][00211702](02) 8bec mov
>> ebp,esp ...[00000b28][002116fa][002016ce](01) 51 push
>> ecx ...[00000b29][002116fa][002016ce](03) 8b4508 mov
>> eax,[ebp+08] ...[00000b2c][002116f6][00000b25](01) 50
>> push eax ...[00000b2d][002116f6][00000b25](03) 8b4d08 mov
>> ecx,[ebp+08] ...[00000b30][002116f2][00000b25](01) 51
>> push ecx ...[00000b31][002116ee][00000b36](05) e81ffeffff call
>> 00000955 // H1 ...[00000b25][0025c126][0025c12a](01) 55
>> push ebp // P2 ...[00000b26][0025c126][0025c12a](02) 8bec
>> mov ebp,esp ...[00000b28][0025c122][0024c0f6](01) 51
>> push ecx ...[00000b29][0025c122][0024c0f6](03) 8b4508
>> mov eax,[ebp+08] ...[00000b2c][0025c11e][00000b25](01) 50
>> push eax ...[00000b2d][0025c11e][00000b25](03) 8b4d08 mov
>> ecx,[ebp+08] ...[00000b30][0025c11a][00000b25](01) 51
>> push ecx ...[00000b31][0025c116][00000b36](05) e81ffeffff call
>> 00000955 // H2 Local Halt Decider: Infinite Recursion Detected
>> Simulation Stopped
>
> But this case is trivial and uninteresting: your decider needs to
> analyse branching logic predicated on arbitrary input to be
> non-trivial and interesting. You've still got nothing of value to show.
>
> /Flibble
>
>

Once people comprehend that my halting criteria eliminates the
pathological self-reference(Olcott 2004) of the halting problem proof
counter-examples they will understand that the halting problem is not
undecidable. Then teams of hundreds of software developers can handle
details such as branching logic.

The reason that my C code analyzes x86 code is that x86 code provides a
complete directed graph of all control flow.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

On Tue, 6 Jul 2021 15:41:09 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/6/2021 3:18 PM, Mr Flibble wrote:
> > On Mon, 5 Jul 2021 23:15:06 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/5/2021 6:15 PM, Ben Bacarisse wrote:
> >>> olcott <NoOne@NoWhere.com> writes:
> >>>
> >>>> On 7/5/2021 4:34 PM, Ben Bacarisse wrote:
> >>>>> For anyone interested, here's the answer to the question posed
> >>>>> in the subject line: How do we know that H(P,P)==0 is correct?
> >>>>>
> >>>>> We know that H(M,I) == 0 (false) is correct if, and only if,
> >>>>> M(I) is not a halting (finite) computation.
> >>>>>
> >>>>> But PO rejects the very definition of a halting decider: a TM
> >>>>> that accepts exactly those strings that represent finite
> >>>>> computations, and rejects all others.
> >>>>>
> >>>>> Instead, a PO "Other-Halting" decider also rejects some strings
> >>>>> that represent finite computations, specifically P(P) where P is
> >>>>> hat(H), a function defined in terms of H like this:
> >>>>> def hat(h):
> >>>>> def p(x):
> >>>>> if h(x, x):
> >>>>> while True: pass
> >>>>> return p
> >>>>>
> >>>>> For a POOH decider, H(hat(H), hat(H)) = False is correct,
> >>>>> despite hat(H)(hat(H)) being a halting computation. No one
> >>>>> except PO is interested in the POOH problem.
> >>>>>
> >>>>> On the other hand, everyone is interested in halting, but the
> >>>>> computation D(hat(D), hat(D)) shows that no D computes the
> >>>>> halting function.
> >>>>
> >>>> Try and get your double-talk around this:
> >>>>
> >>>> void P(u32 x)
> >>>> {
> >>>> u32 Input_Halts = H(x, x);
> >>>> if (Input_Halts)
> >>>> HERE: goto HERE;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> P((u32)P);
> >>>> }
> >>>>
> >>>> Because the above computation must be aborted at some point or it
> >>>> never halts the above computation is a non-halting computation.
> >>>
> >>> It is a halting computation because it halts. The fact that P(P)
> >>> halts is not in dispute.
> >>>
> >>> Nor is it a matter of dispute that your POOH decider, H, returns
> >>> H(P,P) == 0 and so P(P) is a non-POOH computation. The only
> >>> dispute is that you think someone might be interested in the POOH
> >>> problem.
> >>>
> >>> (For obvious reasons, you resist giving the property you claim H
> >>> is deciding a proper name. I'm not entirely sold on "PO Other
> >>> Halting" but you won't suggest a better alternative.)
> >>>
> >>
> >> On the basis that we know that every UTM(P,I) never halts defines
> >> the exact same set of computations that must be aborted by a
> >> simulating halt decider which defines the exact same set of
> >> computations P(I) that never halt we can know that any input to a
> >> simulating halt decider that never halts unless its simulation is
> >> aborted is a non-halting computation.
> >>
> >> Because we know that a simulating halt decider only simulates its
> >> input until after it has made its halt status decision we can know
> >> that H can ignore its own address range in its execution traces.
> >>
> >> Because the x86 execution trace of P on input P provides no
> >> possible escape from infinitely nested simulation and we can
> >> ignore the execution trace of H then we can know that H must abort
> >> its simulation of P on the basis of the sixteen lines of P:
> >>
> >> _P()
> >> [00000b25](01) 55 push ebp
> >> [00000b26](02) 8bec mov ebp,esp
> >> [00000b28](01) 51 push ecx
> >> [00000b29](03) 8b4508 mov eax,[ebp+08]
> >> [00000b2c](01) 50 push eax
> >> [00000b2d](03) 8b4d08 mov ecx,[ebp+08]
> >> [00000b30](01) 51 push ecx
> >> [00000b31](05) e81ffeffff call 00000955 // call H
> >>
> >> Begin Local Halt Decider Simulation at Machine Address:b25
> >> ...[00000b25][002116fe][00211702](01) 55 push ebp
> >> // P1 ...[00000b26][002116fe][00211702](02) 8bec mov
> >> ebp,esp ...[00000b28][002116fa][002016ce](01) 51 push
> >> ecx ...[00000b29][002116fa][002016ce](03) 8b4508 mov
> >> eax,[ebp+08] ...[00000b2c][002116f6][00000b25](01) 50
> >> push eax ...[00000b2d][002116f6][00000b25](03) 8b4d08 mov
> >> ecx,[ebp+08] ...[00000b30][002116f2][00000b25](01) 51
> >> push ecx ...[00000b31][002116ee][00000b36](05) e81ffeffff
> >> call 00000955 // H1 ...[00000b25][0025c126][0025c12a](01) 55
> >> push ebp // P2 ...[00000b26][0025c126][0025c12a](02) 8bec
> >> mov ebp,esp ...[00000b28][0025c122][0024c0f6](01) 51
> >> push ecx ...[00000b29][0025c122][0024c0f6](03) 8b4508
> >> mov eax,[ebp+08] ...[00000b2c][0025c11e][00000b25](01) 50
> >> push eax ...[00000b2d][0025c11e][00000b25](03) 8b4d08
> >> mov ecx,[ebp+08] ...[00000b30][0025c11a][00000b25](01) 51
> >> push ecx ...[00000b31][0025c116][00000b36](05) e81ffeffff
> >> call 00000955 // H2 Local Halt Decider: Infinite Recursion
> >> Detected Simulation Stopped
> >
> > But this case is trivial and uninteresting: your decider needs to
> > analyse branching logic predicated on arbitrary input to be
> > non-trivial and interesting. You've still got nothing of value to
> > show.
> >
> > /Flibble
> >
> >
>
> Once people comprehend that my halting criteria eliminates the
> pathological self-reference(Olcott 2004) of the halting problem proof
> counter-examples they will understand that the halting problem is not
> undecidable. Then teams of hundreds of software developers can handle
> details such as branching logic.
>
> The reason that my C code analyzes x86 code is that x86 code provides
> a complete directed graph of all control flow.

Nonsense:

mov eax,[ebp+08]

the memory at the address [ebp+08] might be
mapped to an I/O device so you don't know a priori what value it will
have.

More nonsense is of course that you have yet to show an example which
does involve control flow (with branching logic) and even if you did you
haven't responded to people posting non-trivial control flow examples.

/Flibble

On 7/6/2021 8:56 PM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
> No one is interested in the POOH problem. For the halting problem,
> H(P,P) is correct only when
>
> H(P,P) != 0 and P(P) halts, or
> H(P,P) == 0 and P(P) does not halt.
>
> Neither is the case. That H might be correct for some other decision
> problem is not relevant.
>

// Simplified Linz Ĥ (Linz:1990:319)
void P(u32 x)
{ u32 Input_Halts = H(x, x);
if (Input_Halts)
HERE: goto HERE;
}

int main()
{ u32 Input_Halts = H((u32)P, (u32)P);
Output("Input_Halts = ", Input_Halts);
}

When the simulation of the Turing machine description ⟨P⟩ of a Turing
machine P on input I never halts we know that P(I) never halts.

Simulating halt deciders must abort their simulation of all inputs where
the pure simulation of this input would never halt.

Simulating halt deciders act as a pure simulators of their input until
this input demonstrates non-halting behavior.

This allows simulating halt deciders to totally ignore their own
behavior in making their halt status decision.

It is this feature of the adapted halt deciding criteria that eliminates
the pathological self-reference (polcott 2004) from the halting problem
counter-example templates.

Simulating halt deciders never have behavior that effects their halt
status decision because they only act as pure simulators until after
they have made this decision.

Using the above reasoning we can know that when the x86 execution trace
of P on input P shows that there is no code in P that escapes the
infinitely nested simulation of P on input P, then we know that P on
input P meets the definition of a computation that never halts: (a pure
simulation that never halts).

--
Copyright 2021 Pete Olcott

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

According to your posting-frequency you're manic.
But post only to comp.arch; this is the only appropriate NG.
You don't have any C/C++-specific issues and your thoguhts
aren't related to AI either.

On 7/7/2021 5:46 AM, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 7/5/21 7:15 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>>
>>>>
>>>> Because the above computation must be aborted at some point or it
>>>> never halts the above computation is a non-halting computation.
>>>
>>> It is a halting computation because it halts. The fact that P(P) halts
>>> is not in dispute.
>>>
>>> Nor is it a matter of dispute that your POOH decider, H, returns H(P,P)
>>> == 0 and so P(P) is a non-POOH computation. The only dispute is that
>>> you think someone might be interested in the POOH problem.
>>>
>>> (For obvious reasons, you resist giving the property you claim H is
>>> deciding a proper name. I'm not entirely sold on "PO Other Halting" but
>>> you won't suggest a better alternative.)
>>>
>>
>> I think the name is wrong, his machines don't REALLY deal with Halting,
>> so it isn't other Halting, it really should be called Peter Olcott's
>> Other Problem.
>
> Good point. It's because, in the original description, the halting of
> one computation was reported as the halting of another that I went with
> that name, but it does, as you say, suggest the wrong meaning for
> other. Your name is better, but I don't want to confuse anyone by
> changing. Maybe PO can choose which he prefers?
>

H acts as a pure x86 simulator until its input demonstrates non-halting
behavior. It is common knowledge that when-so-ever the pure simulation
of the machine description of a machine never halts on its input that
this logically entails that this machine never halts on its input. This
proves that H uses the same halting criteria as the halting problem.

Because H acts as a pure simulator of its input until after it makes its
halt status decision we know that the behavior of H cannot possibly have
any effect on the behavior of P thus the behavior of H can be totally
ignored in any halt status decision.

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 10:32 AM, Ben Bacarisse wrote:
> olcott <NoOne@NoWhere.com> writes:
>
>> On 7/6/2021 8:56 PM, Ben Bacarisse wrote:
>>> olcott <NoOne@NoWhere.com> writes:
>>> No one is interested in the POOH problem. For the halting problem,
>>> H(P,P) is correct only when
>>> H(P,P) != 0 and P(P) halts, or
>>> H(P,P) == 0 and P(P) does not halt.
>>> Neither is the case. That H might be correct for some other decision
>>> problem is not relevant.
>>>
>>
>> // Simplified Linz Ĥ (Linz:1990:319)
>> void P(u32 x)
>> {
>> u32 Input_Halts = H(x, x);
>> if (Input_Halts)
>> HERE: goto HERE;
>> }
>>
>> int main()
>> {
>> u32 Input_Halts = H((u32)P, (u32)P);
>> Output("Input_Halts = ", Input_Halts);
>> }
>>
>> When the simulation of the Turing machine description ⟨P⟩ of a Turing
>> machine P on input I never halts we know that P(I) never halts.
>
> P(P) halts. Any simulation of P(P) halts. H(P,P) == 0 is wrong about
> the halting of P(P).
>
>> Simulating halt deciders must abort their simulation of all inputs
>> where the pure simulation of this input would never halt.
>
> That is, indeed, one way in which they can be wrong. Every TM is wrong
> about some instances.

H acts as a pure x86 simulator until its input demonstrates non-halting
behavior. It is common knowledge that when-so-ever the pure simulation
of the machine description of a machine never halts on its input that
this logically entails that this machine never halts on its input. This
proves that H uses the same halting criteria as the halting problem.

Because H acts as a pure simulator of its input until after it makes its
halt status decision we know that the behavior of H cannot possibly have
any effect on the behavior of P thus the behavior of H can be totally
ignored in any halt status decision.

Every H in the entire nested simulation chain always only acts as a pure
c86 emulator until some H detects that some P will never halt.

We know that a black cat is a cat that is black even if the black cat
barks. We know that H(P,P)==0 even if P(P) halts. In both cases we know
this by logical necessity.

When the pure simulation of an input never halts then this is a
non-halting computation by logical necessity. You know that there are no
exceptions to this rule.

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 12:53 PM, wij wrote:
> On Thursday, 8 July 2021 at 00:24:32 UTC+8, olcott wrote:
>> On 7/7/2021 10:32 AM, Ben Bacarisse wrote:
>>> olcott <No...@NoWhere.com> writes:
>>>
>>>> On 7/6/2021 8:56 PM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>> No one is interested in the POOH problem. For the halting problem,
>>>>> H(P,P) is correct only when
>>>>> H(P,P) != 0 and P(P) halts, or
>>>>> H(P,P) == 0 and P(P) does not halt.
>>>>> Neither is the case. That H might be correct for some other decision
>>>>> problem is not relevant.
>>>>>
>>>>
>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>> void P(u32 x)
>>>> {
>>>> u32 Input_Halts = H(x, x);
>>>> if (Input_Halts)
>>>> HERE: goto HERE;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>> Output("Input_Halts = ", Input_Halts);
>>>> }
>>>>
>>>> When the simulation of the Turing machine description ⟨P⟩ of a Turing
>>>> machine P on input I never halts we know that P(I) never halts.
>>>
>>> P(P) halts. Any simulation of P(P) halts. H(P,P) == 0 is wrong about
>>> the halting of P(P).
>>>
>>>> Simulating halt deciders must abort their simulation of all inputs
>>>> where the pure simulation of this input would never halt.
>>>
>>> That is, indeed, one way in which they can be wrong. Every TM is wrong
>>> about some instances.
>> H acts as a pure x86 simulator until its input demonstrates non-halting
>> behavior. It is common knowledge that when-so-ever the pure simulation
>> of the machine description of a machine never halts on its input that
>> this logically entails that this machine never halts on its input. This
>> proves that H uses the same halting criteria as the halting problem.
>>
>> Because H acts as a pure simulator of its input until after it makes its
>> halt status decision we know that the behavior of H cannot possibly have
>> any effect on the behavior of P thus the behavior of H can be totally
>> ignored in any halt status decision.
>> Every H in the entire nested simulation chain always only acts as a pure
>> c86 emulator until some H detects that some P will never halt.
>>
>> We know that a black cat is a cat that is black even if the black cat
>> barks. We know that H(P,P)==0 even if P(P) halts. In both cases we know
>> this by logical necessity.
>>
>
> I do not want to go into theoretical details too much.
> If you admit H(P,P)==0 and P(P) halts, then H is no longer a halting decider
> by definition.
>

P(P) does specify infinitely nested simulation that a global halt
decider immediately catches and aborts, thus not allowing P(P) to halt.

When the local halt decider is used then H aborts its simulation (P,P)
as soon as (P,P) is an input to H.

> If H re-assign the T/F value of 'pathological input', H will still create another
> another set of undecidable input, H is doomed not a decisive function.
> [Hints]: H is function f:2^(2^|N|)->{0,1}, way beyond the capability of TM.
> Even if such a f is possible, the convention HP still true. H will still be an
> undecidable function.
>

Because H acts as a pure simulator of its input until after it makes its
halt status decision we know that the behavior of H cannot possibly have
any effect on the behavior of P thus the behavior of H can be totally
ignored in any halt status decision. This eliminates the pathological
self-reference of the halting problem proof counter-example templates
making them decidable.

>> When the pure simulation of an input never halts then this is a
>> non-halting computation by logical necessity. You know that there are no
>> exceptions to this rule.
>> --
>> Copyright 2021 Pete Olcott
>>
>> "Great spirits have always encountered violent opposition from mediocre
>> minds." Einstein

--
Copyright 2021 Pete Olcott

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

On 07/07/2021 13:18, Bonita Montero wrote:
> According to your posting-frequency you're manic.
> But post only to comp.arch; this is the only appropriate NG.
> You don't have any C/C++-specific issues and your thoguhts
> aren't related to AI either.

He wants to win a Nobel price in computing! He believes you can
recommend him to the Nobel committee for his incessant trolling.

On 7/7/2021 12:25 PM, Real Troll wrote:
> On 07/07/2021 13:18, Bonita Montero wrote:
>> According to your posting-frequency you're manic.
>> But post only to comp.arch; this is the only appropriate NG.
>> You don't have any C/C++-specific issues and your thoguhts
>> aren't related to AI either.
>
> He wants to win a Nobel price in computing! He believes you can
> recommend him to the Nobel committee for his incessant trolling.

There is no Nobel prize in computing. It turns out that it would have
been impossible for me to make my views clear enough to be understood
without the feedback that I have received on comp.theory of USENET.

They are finally on the verge of being clear enough to be understood to
be correct...

H acts as a pure x86 simulator until its input demonstrates non-halting
behavior. It is common knowledge that when-so-ever the pure simulation
of the machine description of a machine never halts on its input that
this logically entails that this machine never halts on its input. This
proves that H uses the same halting criteria as the halting problem.

Because H acts as a pure simulator of its input until after it makes its
halt status decision we know that the behavior of H cannot possibly have
any effect on the behavior of P thus the behavior of H can be totally
ignored in any halt status decision. This eliminates the pathological
self-reference of the halting problem proof counter-example templates
making them decidable.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

--
Copyright 2021 Pete Olcott

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

olcott <NoOne@NoWhere.com> writes:
>On 7/7/2021 12:25 PM, Real Troll wrote:
>> On 07/07/2021 13:18, Bonita Montero wrote:
>>> According to your posting-frequency you're manic.
>>> But post only to comp.arch; this is the only appropriate NG.
>>> You don't have any C/C++-specific issues and your thoguhts
>>> aren't related to AI either.
>>
>> He wants to win a Nobel price in computing! He believes you can
>> recommend him to the Nobel committee for his incessant trolling.
>
>There is no Nobel prize in computing.

There is, of course, the Turing award.

But crossposting trolls aren't eligable.

On 7/7/2021 2:01 PM, Scott Lurndal wrote:
> olcott <NoOne@NoWhere.com> writes:
>> On 7/7/2021 12:25 PM, Real Troll wrote:
>>> On 07/07/2021 13:18, Bonita Montero wrote:
>>>> According to your posting-frequency you're manic.
>>>> But post only to comp.arch; this is the only appropriate NG.
>>>> You don't have any C/C++-specific issues and your thoguhts
>>>> aren't related to AI either.
>>>
>>> He wants to win a Nobel price in computing! He believes you can
>>> recommend him to the Nobel committee for his incessant trolling.
>>
>> There is no Nobel prize in computing.
>
> There is, of course, the Turing award.
>
> But crossposting trolls aren't eligable.
>

I knew that and and also knew that Edsger Dijkstra won it four years
after he posted a mere letter to the editor to the CACM.

https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf

https://en.wikipedia.org/wiki/Edsger_W._Dijkstra

--
Copyright 2021 Pete Olcott

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

On 7/7/2021 1:59 PM, wij wrote:
> On Thursday, 8 July 2021 at 02:10:59 UTC+8, olcott wrote:
>> On 7/7/2021 12:53 PM, wij wrote:
>>> On Thursday, 8 July 2021 at 00:24:32 UTC+8, olcott wrote:
>>>> On 7/7/2021 10:32 AM, Ben Bacarisse wrote:
>>>>> olcott <No...@NoWhere.com> writes:
>>>>>
>>>>>> On 7/6/2021 8:56 PM, Ben Bacarisse wrote:
>>>>>>> olcott <No...@NoWhere.com> writes:
>>>>>>> No one is interested in the POOH problem. For the halting problem,
>>>>>>> H(P,P) is correct only when
>>>>>>> H(P,P) != 0 and P(P) halts, or
>>>>>>> H(P,P) == 0 and P(P) does not halt.
>>>>>>> Neither is the case. That H might be correct for some other decision
>>>>>>> problem is not relevant.
>>>>>>>
>>>>>>
>>>>>> // Simplified Linz Ĥ (Linz:1990:319)
>>>>>> void P(u32 x)
>>>>>> {
>>>>>> u32 Input_Halts = H(x, x);
>>>>>> if (Input_Halts)
>>>>>> HERE: goto HERE;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> u32 Input_Halts = H((u32)P, (u32)P);
>>>>>> Output("Input_Halts = ", Input_Halts);
>>>>>> }
>>>>>>
>>>>>> When the simulation of the Turing machine description ⟨P⟩ of a Turing
>>>>>> machine P on input I never halts we know that P(I) never halts.
>>>>>
>>>>> P(P) halts. Any simulation of P(P) halts. H(P,P) == 0 is wrong about
>>>>> the halting of P(P).
>>>>>
>>>>>> Simulating halt deciders must abort their simulation of all inputs
>>>>>> where the pure simulation of this input would never halt.
>>>>>
>>>>> That is, indeed, one way in which they can be wrong. Every TM is wrong
>>>>> about some instances.
>>>> H acts as a pure x86 simulator until its input demonstrates non-halting
>>>> behavior. It is common knowledge that when-so-ever the pure simulation
>>>> of the machine description of a machine never halts on its input that
>>>> this logically entails that this machine never halts on its input. This
>>>> proves that H uses the same halting criteria as the halting problem.
>>>>
>>>> Because H acts as a pure simulator of its input until after it makes its
>>>> halt status decision we know that the behavior of H cannot possibly have
>>>> any effect on the behavior of P thus the behavior of H can be totally
>>>> ignored in any halt status decision.
>>>> Every H in the entire nested simulation chain always only acts as a pure
>>>> c86 emulator until some H detects that some P will never halt.
>>>>
>>>> We know that a black cat is a cat that is black even if the black cat
>>>> barks. We know that H(P,P)==0 even if P(P) halts. In both cases we know
>>>> this by logical necessity.
>>>>
>>>
>>> I do not want to go into theoretical details too much.
>>> If you admit H(P,P)==0 and P(P) halts, then H is no longer a halting decider
>>> by definition.
>>>
>> P(P) does specify infinitely nested simulation that a global halt
>> decider immediately catches and aborts, thus not allowing P(P) to halt.
>>
>> When the local halt decider is used then H aborts its simulation (P,P)
>> as soon as (P,P) is an input to H.
>
> I looked to me, you used two H's, one is local H, another is global H.
> If Local_H(P,P)!=Global_H(P,P), no need to discuss further.
>

No non-halting input can avoid being analyzed by the global (partial)
halt decider. Only programs that are input parameters to the local
(partial) halt decider H are analyzed by H.

>>> If H re-assign the T/F value of 'pathological input', H will still create another
>>> another set of undecidable input, H is doomed not a decisive function.
>>> [Hints]: H is function f:2^(2^|N|)->{0,1}, way beyond the capability of TM.
>>> Even if such a f is possible, the convention HP still true. H will still be an
>>> undecidable function.
>>>
>> Because H acts as a pure simulator of its input until after it makes its
>> halt status decision we know that the behavior of H cannot possibly have
>> any effect on the behavior of P thus the behavior of H can be totally
>> ignored in any halt status decision. This eliminates the pathological
>> self-reference of the halting problem proof counter-example templates
>> making them decidable.
>
> We know 'pure simulation' is not possible, H has to decide P is in an infinite
> loop or not and return an answer. Then, the question is how does H detect an infinite loop?

H acts are a pure simulator until the infinite loop behavior pattern is
detected in the simulation of its input. All of the details of this case
are shown in my paper.

https://www.researchgate.net/publication/351947980_Halting_problem_undecidability_and_infinitely_nested_simulation

> Now, H(P,P)==0 is modified to include the meaning that "P is undecidable in
> the sense of the conventional HP".

When the pure simulation of a machine description on its input never
halts we know that the machine never halts on its input.

> By the convention HP proof, the same code example of P, this version of H will
> again fall in infinite loop, not able to return a correct answer.
>

H remains a pure simulator only until its input demonstrate non-halting
behavior. If its input never demonstrate non-halting behavior then H
remains a pure simulator.

--
Copyright 2021 Pete Olcott

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

On 07/07/2021 13:18, Bonita Montero wrote:
> According to your posting-frequency you're manic.
> But post only to comp.arch; this is the only appropriate NG.
> You don't have any C/C++-specific issues and your thoguhts

Try a message filter so that you don't see olcott's posts.

The posts won't stop, not helped by people engaging with the subject.

> aren't related to AI either.

Why would AI be any more on-topic?