#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y);
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P (see below)
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

It is obvious that the direct execution of the above code never halts
because it is infinitely recursive. It is equally obvious that when H
performs a correct pure simulation of its input (instead of directly
executing it) that its input never halts.

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

Because there is nothing that H can possibly do to cause or enable P to
reach its final state at 1a72 we correctly conclude that the input to
H(P,P) never halts.

For every possible H in the universe that is invoked at machine address
00001a7e the specific byte sequence of the machine code for P as input
to H(P,P) never halts. Thus all rebuttals in the universe are
categorically denied.

Halting problem undecidability and infinitely nested simulation (V2)
https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2

--
Copyright 2021 Pete Olcott

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

On 11/12/21 3:11 PM, olcott wrote:
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P (see below)
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
> It is obvious that the direct execution of the above code never halts
> because it is infinitely recursive. It is equally obvious that when H
> performs a correct pure simulation of its input (instead of directly
> executing it) that its input never halts.
>
> _P()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b4508          mov eax,[ebp+08]
> [00001a64](01)  50              push eax        // push P
> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
> [00001a68](01)  51              push ecx        // push P
> [00001a69](05)  e810000000      call 00001a7e   // call H
> [00001a6e](03)  83c408          add esp,+08
> [00001a71](01)  5d              pop ebp
> [00001a72](01)  c3              ret
> Size in bytes:(0021) [00001a72]
>
> Because there is nothing that H can possibly do to cause or enable P to
> reach its final state at 1a72 we correctly conclude that the input to
> H(P,P) never halts.

Wrong. IF H does abort and return 0 then the ACTUAL running of P will
reach that address, and the actual running of P is what matters.

All you have shown is that it is impossible for H to PROVE that P will
be halting, not that P isn't Halting.

>
> For every possible H in the universe that is invoked at machine address
> 00001a7e the specific byte sequence of the machine code for P as input
> to H(P,P) never halts. Thus all rebuttals in the universe are
> categorically denied.
>

Except that you are proving the wrong thing. You have only proved that H
can not Prove that P is Halting, not that P itself in non-halting.

It is a fundamental fact that for EVERY H that aborts its 'simulation'
of P and returns 0, that the actual computation P(P) will halt. (And
thus the H was wrong)

It is also true that for EVERY H that does NOT abort its 'simulation' of
P, that H will never be able to return an answer, so that H fails to be
a decider.

Your attempt to deny that just shows that you are a pathological liar,
and don't have a grasp on what is actually truth,

Yes, you have shown that the simulation in H never reaches that final
state, so as has been pointed out, you HAVE proved that H can never
prove that P is halting by seeing that happening, but not able to prove
that fact, and the fact not actually being true are two very different
things.

I think that fundamentally the problem is that you are basing your whole
arguement on the LIE that you are even working on the Halting Problem,
as to make that claim, you needed to first accept the ground rules of
the problem and the logic system it is built on.

You just don't understand what the meaning of Truth actually is.

>
> Halting problem undecidability and infinitely nested simulation (V2)
> https://www.researchgate.net/publication/356105750_Halting_problem_undecidability_and_infinitely_nested_simulation_V2
>
>

On 11/12/2021 4:00 PM, Richard Damon wrote:
> On 11/12/21 3:11 PM, olcott wrote:
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y);
>>    return 1;
>> }
>>
>> // Minimal essence of Linz(1990) Ĥ
>> // and Strachey(1965) P (see below)
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>> It is obvious that the direct execution of the above code never halts
>> because it is infinitely recursive. It is equally obvious that when H
>> performs a correct pure simulation of its input (instead of directly
>> executing it) that its input never halts.
>>
>> _P()
>> [00001a5e](01)  55              push ebp
>> [00001a5f](02)  8bec            mov ebp,esp
>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>> [00001a64](01)  50              push eax        // push P
>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>> [00001a68](01)  51              push ecx        // push P
>> [00001a69](05)  e810000000      call 00001a7e   // call H
>> [00001a6e](03)  83c408          add esp,+08
>> [00001a71](01)  5d              pop ebp
>> [00001a72](01)  c3              ret
>> Size in bytes:(0021) [00001a72]
>>
>> Because there is nothing that H can possibly do to cause or enable P
>> to reach its final state at 1a72 we correctly conclude that the input
>> to H(P,P) never halts.
>
> Wrong. IF H does abort and return 0 then the ACTUAL running of P will
> reach that address, and the actual running of P is what matters.
>
> All you have shown is that it is impossible for H to PROVE that P will
> be halting, not that P isn't Halting.
>
I have shown that P always specifies infinite recursion whether or not
this infinite recursion is aborted, therefore H(P,P)==0 is always correct.

All rebuttals must take this form:
Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

If no rebuttals exist this conclusively proves that H(P,P)==0 for every
H in the unverse.

--
Copyright 2021 Pete Olcott

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

On 11/12/21 5:07 PM, olcott wrote:
> On 11/12/2021 4:00 PM, Richard Damon wrote:
>> On 11/12/21 3:11 PM, olcott wrote:
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y);
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P (see below)
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>> It is obvious that the direct execution of the above code never halts
>>> because it is infinitely recursive. It is equally obvious that when H
>>> performs a correct pure simulation of its input (instead of directly
>>> executing it) that its input never halts.
>>>
>>> _P()
>>> [00001a5e](01)  55              push ebp
>>> [00001a5f](02)  8bec            mov ebp,esp
>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>> [00001a64](01)  50              push eax        // push P
>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>> [00001a68](01)  51              push ecx        // push P
>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>> [00001a6e](03)  83c408          add esp,+08
>>> [00001a71](01)  5d              pop ebp
>>> [00001a72](01)  c3              ret
>>> Size in bytes:(0021) [00001a72]
>>>
>>> Because there is nothing that H can possibly do to cause or enable P
>>> to reach its final state at 1a72 we correctly conclude that the input
>>> to H(P,P) never halts.
>>
>> Wrong. IF H does abort and return 0 then the ACTUAL running of P will
>> reach that address, and the actual running of P is what matters.
>>
>> All you have shown is that it is impossible for H to PROVE that P will
>> be halting, not that P isn't Halting.
>>
> I have shown that P always specifies infinite recursion whether or not
> this infinite recursion is aborted, therefore H(P,P)==0 is always correct.

No, you haven't.

You logic makes the unsound step of FIRST assuming that H never aborts
its operation, and THEN has H do an abort.

If you DO have a valid proof that P(P) is non-halting when H(P,P) return
0 then you have just proved you logic system to be inconsistent as it
can also be proved the if H(P,P) returns 0, that P(P) halts.

A system that can prove a statement and its complement is inconsestent,
and logically worthless.

>
> All rebuttals must take this form:
> Find an invocation of H(P,P) at machine address 00001a7e such that the
> simulation or execution of (the exact byte sequence of) P reaches its
> final address of 00001a72.
>
> If no rebuttals exist this conclusively proves that H(P,P)==0 for every
> H in the unverse.
>

WRONG CRITERIA.

Just proves you are looking at POOP.

The REAL halting problems asks what P(P) actually does.

If H(P,P) returns 0 in finite time, then P(P) will halt in finite time.

Do you disagree with that statement?

If not, then you have to admit either that you aren't actually working
on the Halting Problem, or that you H is incorrect when it returns 0.

On 11/12/2021 4:13 PM, Richard Damon wrote:
> On 11/12/21 5:07 PM, olcott wrote:
>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>> On 11/12/21 3:11 PM, olcott wrote:
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>>    x(y);
>>>>    return 1;
>>>> }
>>>>
>>>> // Minimal essence of Linz(1990) Ĥ
>>>> // and Strachey(1965) P (see below)
>>>> void P(ptr x)
>>>> {
>>>>    H(x, x);
>>>> }
>>>>
>>>> int main(void)
>>>> {
>>>>    H(P, P);
>>>> }
>>>>
>>>> It is obvious that the direct execution of the above code never
>>>> halts because it is infinitely recursive. It is equally obvious that
>>>> when H performs a correct pure simulation of its input (instead of
>>>> directly executing it) that its input never halts.
>>>>
>>>> _P()
>>>> [00001a5e](01)  55              push ebp
>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>> [00001a64](01)  50              push eax        // push P
>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>> [00001a68](01)  51              push ecx        // push P
>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>> [00001a6e](03)  83c408          add esp,+08
>>>> [00001a71](01)  5d              pop ebp
>>>> [00001a72](01)  c3              ret
>>>> Size in bytes:(0021) [00001a72]
>>>>
>>>> Because there is nothing that H can possibly do to cause or enable P
>>>> to reach its final state at 1a72 we correctly conclude that the
>>>> input to H(P,P) never halts.
>>>
>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P will
>>> reach that address, and the actual running of P is what matters.
>>>
>>> All you have shown is that it is impossible for H to PROVE that P
>>> will be halting, not that P isn't Halting.
>>>
>> I have shown that P always specifies infinite recursion whether or not
>> this infinite recursion is aborted, therefore H(P,P)==0 is always
>> correct.
>
> No, you haven't.
>
> You logic makes the unsound step of FIRST assuming that H never aborts
> its operation, and THEN has H do an abort.
>
> If you DO have a valid proof that P(P) is non-halting when H(P,P) return
> 0 then you have just proved you logic system to be inconsistent as it
> can also be proved the if H(P,P) returns 0, that P(P) halts.
>
> A system that can prove a statement and its complement is inconsestent,
> and logically worthless.
>
>>
>> All rebuttals must take this form:
>> Find an invocation of H(P,P) at machine address 00001a7e such that the
>> simulation or execution of (the exact byte sequence of) P reaches its
>> final address of 00001a72.
>>
>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>> every H in the unverse.
>>
>
> WRONG CRITERIA.
>
> Just proves you are looking at POOP.
>
> The REAL halting problems asks what P(P) actually does.
>

I proven beyond all possible doubt that the real P is infinitely
recursive in my latest example where H directly executes its input

x(y) is new syntax to me too.
Ben provided it and it uses function pointer syntax.
When H(P,P) is called x(y) means P(P);

>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> int H(ptr x, ptr y)
>>>> {
>>>> x(y);
>>>> return 1;
>>>> }

--
Copyright 2021 Pete Olcott

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

On 11/12/21 5:24 PM, olcott wrote:
> On 11/12/2021 4:13 PM, Richard Damon wrote:
>> On 11/12/21 5:07 PM, olcott wrote:
>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> int H(ptr x, ptr y)
>>>>> {
>>>>>    x(y);
>>>>>    return 1;
>>>>> }
>>>>>
>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>> // and Strachey(1965) P (see below)
>>>>> void P(ptr x)
>>>>> {
>>>>>    H(x, x);
>>>>> }
>>>>>
>>>>> int main(void)
>>>>> {
>>>>>    H(P, P);
>>>>> }
>>>>>
>>>>> It is obvious that the direct execution of the above code never
>>>>> halts because it is infinitely recursive. It is equally obvious
>>>>> that when H performs a correct pure simulation of its input
>>>>> (instead of directly executing it) that its input never halts.
>>>>>
>>>>> _P()
>>>>> [00001a5e](01)  55              push ebp
>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>> [00001a64](01)  50              push eax        // push P
>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>> [00001a68](01)  51              push ecx        // push P
>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>> [00001a71](01)  5d              pop ebp
>>>>> [00001a72](01)  c3              ret
>>>>> Size in bytes:(0021) [00001a72]
>>>>>
>>>>> Because there is nothing that H can possibly do to cause or enable
>>>>> P to reach its final state at 1a72 we correctly conclude that the
>>>>> input to H(P,P) never halts.
>>>>
>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P
>>>> will reach that address, and the actual running of P is what matters.
>>>>
>>>> All you have shown is that it is impossible for H to PROVE that P
>>>> will be halting, not that P isn't Halting.
>>>>
>>> I have shown that P always specifies infinite recursion whether or
>>> not this infinite recursion is aborted, therefore H(P,P)==0 is always
>>> correct.
>>
>> No, you haven't.
>>
>> You logic makes the unsound step of FIRST assuming that H never aborts
>> its operation, and THEN has H do an abort.
>>
>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>> return 0 then you have just proved you logic system to be inconsistent
>> as it can also be proved the if H(P,P) returns 0, that P(P) halts.
>>
>> A system that can prove a statement and its complement is
>> inconsestent, and logically worthless.
>>
>>>
>>> All rebuttals must take this form:
>>> Find an invocation of H(P,P) at machine address 00001a7e such that
>>> the simulation or execution of (the exact byte sequence of) P reaches
>>> its final address of 00001a72.
>>>
>>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>>> every H in the unverse.
>>>
>>
>> WRONG CRITERIA.
>>
>> Just proves you are looking at POOP.
>>
>> The REAL halting problems asks what P(P) actually does.
>>
>
> I proven beyond all possible doubt that the real P is infinitely
> recursive in my latest example where H directly executes its input

Yes, *IF* H just directly executes its input, then P(P) will be
non-Halting, but H(P,P) never returns 0, so it is not a counter example.

This statement ONLY applies to H's that behave that way. Any H that does
return 0 for H(P,P) has a P that P(P) will be Halting.

You can't have H be one thing in one part of the proof, and something
else in another.

If we call the H that doesn't abort to be Hn, and the P based on it to
be Pn to make things clear, then yes, a DIFFERENT H that does abort its
simulation, call it Ha, can correct decide by Ha(Pn,Pn) returning 0 that
Pn(Pn) is non-halting, but that doesn't meet the requirements to be a
counter example, to be a counter example, you need to find some H, Hx
that gets right the P based on in Px correctly.

We Know that Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns.
We Know that Pa(Pa) is Halitng, but Ha(Pa,Pa) returns 0 (Non-Halting)

You do get the following cases right, but they aren't the needed cases:

Hn(Pa,Pa) will return 1, which is right since Pa(Pa) is Halting.
Ha(Pn,Pn) will return 0, which is right since Pn(Pn) is Non-Halting.

FAIL.

>
> x(y) is new syntax to me too.
> Ben provided it and it uses function pointer syntax.
> When H(P,P) is called x(y) means P(P);
>
> >>>> #include <stdint.h>
> >>>> typedef void (*ptr)();
> >>>>
> >>>> int H(ptr x, ptr y)
> >>>> {
> >>>>    x(y);
> >>>>    return 1;
> >>>> }
>
>

On 11/12/2021 4:36 PM, Richard Damon wrote:
> On 11/12/21 5:24 PM, olcott wrote:
>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>> On 11/12/21 5:07 PM, olcott wrote:
>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>> #include <stdint.h>
>>>>>> typedef void (*ptr)();
>>>>>>
>>>>>> int H(ptr x, ptr y)
>>>>>> {
>>>>>>    x(y);
>>>>>>    return 1;
>>>>>> }
>>>>>>
>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>> // and Strachey(1965) P (see below)
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    H(x, x);
>>>>>> }
>>>>>>
>>>>>> int main(void)
>>>>>> {
>>>>>>    H(P, P);
>>>>>> }
>>>>>>
>>>>>> It is obvious that the direct execution of the above code never
>>>>>> halts because it is infinitely recursive. It is equally obvious
>>>>>> that when H performs a correct pure simulation of its input
>>>>>> (instead of directly executing it) that its input never halts.
>>>>>>
>>>>>> _P()
>>>>>> [00001a5e](01)  55              push ebp
>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>> [00001a71](01)  5d              pop ebp
>>>>>> [00001a72](01)  c3              ret
>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>
>>>>>> Because there is nothing that H can possibly do to cause or enable
>>>>>> P to reach its final state at 1a72 we correctly conclude that the
>>>>>> input to H(P,P) never halts.
>>>>>
>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P
>>>>> will reach that address, and the actual running of P is what matters.
>>>>>
>>>>> All you have shown is that it is impossible for H to PROVE that P
>>>>> will be halting, not that P isn't Halting.
>>>>>
>>>> I have shown that P always specifies infinite recursion whether or
>>>> not this infinite recursion is aborted, therefore H(P,P)==0 is
>>>> always correct.
>>>
>>> No, you haven't.
>>>
>>> You logic makes the unsound step of FIRST assuming that H never
>>> aborts its operation, and THEN has H do an abort.
>>>
>>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>>> return 0 then you have just proved you logic system to be
>>> inconsistent as it can also be proved the if H(P,P) returns 0, that
>>> P(P) halts.
>>>
>>> A system that can prove a statement and its complement is
>>> inconsestent, and logically worthless.
>>>
>>>>
>>>> All rebuttals must take this form:
>>>> Find an invocation of H(P,P) at machine address 00001a7e such that
>>>> the simulation or execution of (the exact byte sequence of) P
>>>> reaches its final address of 00001a72.
>>>>
>>>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>>>> every H in the unverse.
>>>>
>>>
>>> WRONG CRITERIA.
>>>
>>> Just proves you are looking at POOP.
>>>
>>> The REAL halting problems asks what P(P) actually does.
>>>
>>
>> I proven beyond all possible doubt that the real P is infinitely
>> recursive in my latest example where H directly executes its input
>
>
> Yes, *IF* H just directly executes its input, then P(P) will be
> non-Halting,

The ultimate measure of the halt status of an input is its behavior when
directly executed.

> but H(P,P) never returns 0, so it is not a counter example.
>

The fact that for every possible H that can possibly exist at at machine
address 00001a7e the simulation or execution of (the exact byte sequence
of) P never reaches its final address of 00001a72 conclusively proves
that the input to H(P,P) never halts.

The input to H(P,P) never halts therefore when H returns 0 it is always
correct.

> This statement ONLY applies to H's that behave that way. Any H that does
> return 0 for H(P,P) has a P that P(P) will be Halting.
>
> You can't have H be one thing in one part of the proof, and something
> else in another.
>
> If we call the H that doesn't abort to be Hn, and the P based on it to
> be Pn to make things clear, then yes, a DIFFERENT H that does abort its
> simulation, call it Ha, can correct decide by Ha(Pn,Pn) returning 0 that
> Pn(Pn) is non-halting, but that doesn't meet the requirements to be a
> counter example, to be a counter example, you need to find some H, Hx
> that gets right the P based on in Px correctly.
>
> We Know that Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns.
> We Know that Pa(Pa) is Halitng, but Ha(Pa,Pa) returns 0 (Non-Halting)
>
> You do get the following cases right, but they aren't the needed cases:
>
> Hn(Pa,Pa) will return 1, which is right since Pa(Pa) is Halting.
> Ha(Pn,Pn) will return 0, which is right since Pn(Pn) is Non-Halting.
>
>
> FAIL.
>
>>
>> x(y) is new syntax to me too.
>> Ben provided it and it uses function pointer syntax.
>> When H(P,P) is called x(y) means P(P);
>>
>>  >>>> #include <stdint.h>
>>  >>>> typedef void (*ptr)();
>>  >>>>
>>  >>>> int H(ptr x, ptr y)
>>  >>>> {
>>  >>>>    x(y);
>>  >>>>    return 1;
>>  >>>> }
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 11/12/21 5:53 PM, olcott wrote:
> On 11/12/2021 4:36 PM, Richard Damon wrote:
>> On 11/12/21 5:24 PM, olcott wrote:
>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>> #include <stdint.h>
>>>>>>> typedef void (*ptr)();
>>>>>>>
>>>>>>> int H(ptr x, ptr y)
>>>>>>> {
>>>>>>>    x(y);
>>>>>>>    return 1;
>>>>>>> }
>>>>>>>
>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>> // and Strachey(1965) P (see below)
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> int main(void)
>>>>>>> {
>>>>>>>    H(P, P);
>>>>>>> }
>>>>>>>
>>>>>>> It is obvious that the direct execution of the above code never
>>>>>>> halts because it is infinitely recursive. It is equally obvious
>>>>>>> that when H performs a correct pure simulation of its input
>>>>>>> (instead of directly executing it) that its input never halts.
>>>>>>>
>>>>>>> _P()
>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>> [00001a72](01)  c3              ret
>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>
>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>> enable P to reach its final state at 1a72 we correctly conclude
>>>>>>> that the input to H(P,P) never halts.
>>>>>>
>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P
>>>>>> will reach that address, and the actual running of P is what matters.
>>>>>>
>>>>>> All you have shown is that it is impossible for H to PROVE that P
>>>>>> will be halting, not that P isn't Halting.
>>>>>>
>>>>> I have shown that P always specifies infinite recursion whether or
>>>>> not this infinite recursion is aborted, therefore H(P,P)==0 is
>>>>> always correct.
>>>>
>>>> No, you haven't.
>>>>
>>>> You logic makes the unsound step of FIRST assuming that H never
>>>> aborts its operation, and THEN has H do an abort.
>>>>
>>>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>>>> return 0 then you have just proved you logic system to be
>>>> inconsistent as it can also be proved the if H(P,P) returns 0, that
>>>> P(P) halts.
>>>>
>>>> A system that can prove a statement and its complement is
>>>> inconsestent, and logically worthless.
>>>>
>>>>>
>>>>> All rebuttals must take this form:
>>>>> Find an invocation of H(P,P) at machine address 00001a7e such that
>>>>> the simulation or execution of (the exact byte sequence of) P
>>>>> reaches its final address of 00001a72.
>>>>>
>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>>>>> every H in the unverse.
>>>>>
>>>>
>>>> WRONG CRITERIA.
>>>>
>>>> Just proves you are looking at POOP.
>>>>
>>>> The REAL halting problems asks what P(P) actually does.
>>>>
>>>
>>> I proven beyond all possible doubt that the real P is infinitely
>>> recursive in my latest example where H directly executes its input
>>
>>
>> Yes, *IF* H just directly executes its input, then P(P) will be
>> non-Halting,
>
> The ultimate measure of the halt status of an input is its behavior when
> directly executed.
>
>> but H(P,P) never returns 0, so it is not a counter example.
>>
>
> The fact that for every possible H that can possibly exist at at machine
> address 00001a7e the simulation or execution of (the exact byte sequence
> of) P never reaches its final address of 00001a72 conclusively proves
> that the input to H(P,P) never halts.
>
> The input to H(P,P) never halts therefore when H returns 0 it is always
> correct.

No, you have a fundamental error in your logic,

FIRST, as has been explained before, but you just ignorantly ignore,
'inputs' do not have behavior, and as such do not halt or be
non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
your statement is proved conclusively FALSE because it makes an error in
category (Maybe you don't understand these terms, but repeatedly
ignoring them doesn't help your cause).

The closest possible statement to the one you make is that the machine
represented by the input never Halts, but this has been proved
conclusive false for any H where H(P,P) returns 0.

Yes, if H(P,P) only does an uncoditional execution/simulation, then P(P)
is non-halting, but then H(P,P) never returns 0 so your statement isn't
satisfied.

If H(P,P) actually DOES return 0, then you statement is false as P(P)
will halt. It is then shown that the logic you used to show that it
would never halt was unsound as it was built on the premise that H(P,P)
would do an unconditional execution of its input, when in fact it doesn't.

You are just PROVING your lack of knowledge about the problem by
repeating this same error time after time.

You seem to have this mistaken belief that the partial simulation in H
somehow matters to the problem. You have shown some ramblings about why
you THINK it should, but that ignores that fact that the actual
definitions says it doesn't. Do you have ANY actual references to
someone with standing indicating that the simulation within H has ANY
bearing on what the actual correct answer should be. (Not just
references about how in SOME cases you can deduce the correct answer
from the simulation, but something saying that if an ABORTED simulation
didn't reach a halting state, that shows that the machine is non-halting).

FAIL.

>
>> This statement ONLY applies to H's that behave that way. Any H that
>> does return 0 for H(P,P) has a P that P(P) will be Halting.
>>
>> You can't have H be one thing in one part of the proof, and something
>> else in another.
>>
>> If we call the H that doesn't abort to be Hn, and the P based on it to
>> be Pn to make things clear, then yes, a DIFFERENT H that does abort
>> its simulation, call it Ha, can correct decide by Ha(Pn,Pn) returning
>> 0 that Pn(Pn) is non-halting, but that doesn't meet the requirements
>> to be a counter example, to be a counter example, you need to find
>> some H, Hx that gets right the P based on in Px correctly.
>>
>> We Know that Pn(Pn) is non-halting, but Hn(Pn,Pn) never returns.
>> We Know that Pa(Pa) is Halitng, but Ha(Pa,Pa) returns 0 (Non-Halting)
>>
>> You do get the following cases right, but they aren't the needed cases:
>>
>> Hn(Pa,Pa) will return 1, which is right since Pa(Pa) is Halting.
>> Ha(Pn,Pn) will return 0, which is right since Pn(Pn) is Non-Halting.
>>
>>
>> FAIL.
>>
>>>
>>> x(y) is new syntax to me too.
>>> Ben provided it and it uses function pointer syntax.
>>> When H(P,P) is called x(y) means P(P);
>>>
>>>  >>>> #include <stdint.h>
>>>  >>>> typedef void (*ptr)();
>>>  >>>>
>>>  >>>> int H(ptr x, ptr y)
>>>  >>>> {
>>>  >>>>    x(y);
>>>  >>>>    return 1;
>>>  >>>> }
>>>
>>>
>>
>
>

On 11/12/2021 5:13 PM, Richard Damon wrote:
> On 11/12/21 5:53 PM, olcott wrote:
>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>> On 11/12/21 5:24 PM, olcott wrote:
>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>> #include <stdint.h>
>>>>>>>> typedef void (*ptr)();
>>>>>>>>
>>>>>>>> int H(ptr x, ptr y)
>>>>>>>> {
>>>>>>>>    x(y);
>>>>>>>>    return 1;
>>>>>>>> }
>>>>>>>>
>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>>    H(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main(void)
>>>>>>>> {
>>>>>>>>    H(P, P);
>>>>>>>> }
>>>>>>>>
>>>>>>>> It is obvious that the direct execution of the above code never
>>>>>>>> halts because it is infinitely recursive. It is equally obvious
>>>>>>>> that when H performs a correct pure simulation of its input
>>>>>>>> (instead of directly executing it) that its input never halts.
>>>>>>>>
>>>>>>>> _P()
>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>
>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>> enable P to reach its final state at 1a72 we correctly conclude
>>>>>>>> that the input to H(P,P) never halts.
>>>>>>>
>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P
>>>>>>> will reach that address, and the actual running of P is what
>>>>>>> matters.
>>>>>>>
>>>>>>> All you have shown is that it is impossible for H to PROVE that P
>>>>>>> will be halting, not that P isn't Halting.
>>>>>>>
>>>>>> I have shown that P always specifies infinite recursion whether or
>>>>>> not this infinite recursion is aborted, therefore H(P,P)==0 is
>>>>>> always correct.
>>>>>
>>>>> No, you haven't.
>>>>>
>>>>> You logic makes the unsound step of FIRST assuming that H never
>>>>> aborts its operation, and THEN has H do an abort.
>>>>>
>>>>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>>>>> return 0 then you have just proved you logic system to be
>>>>> inconsistent as it can also be proved the if H(P,P) returns 0, that
>>>>> P(P) halts.
>>>>>
>>>>> A system that can prove a statement and its complement is
>>>>> inconsestent, and logically worthless.
>>>>>
>>>>>>
>>>>>> All rebuttals must take this form:
>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such that
>>>>>> the simulation or execution of (the exact byte sequence of) P
>>>>>> reaches its final address of 00001a72.
>>>>>>
>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>>>>>> every H in the unverse.
>>>>>>
>>>>>
>>>>> WRONG CRITERIA.
>>>>>
>>>>> Just proves you are looking at POOP.
>>>>>
>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>
>>>>
>>>> I proven beyond all possible doubt that the real P is infinitely
>>>> recursive in my latest example where H directly executes its input
>>>
>>>
>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>> non-Halting,
>>
>> The ultimate measure of the halt status of an input is its behavior
>> when directly executed.
>>
>>> but H(P,P) never returns 0, so it is not a counter example.
>>>
>>
>> The fact that for every possible H that can possibly exist at at
>> machine address 00001a7e the simulation or execution of (the exact
>> byte sequence of) P never reaches its final address of 00001a72
>> conclusively proves that the input to H(P,P) never halts.
>>
>> The input to H(P,P) never halts therefore when H returns 0 it is
>> always correct.
>
> No, you have a fundamental error in your logic,
>
> FIRST, as has been explained before, but you just ignorantly ignore,
> 'inputs' do not have behavior, and as such do not halt or be
> non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
> your statement is proved conclusively FALSE because it makes an error in
> category (Maybe you don't understand these terms, but repeatedly
> ignoring them doesn't help your cause).

Because the simulated or executed input to every H(P,P) invoked at
machine address 00001a7e with the byte sequence of the machine code of P
as its input never reaches the final address of P at 00001a72 it is
always correct for this H(P,P) to return 0.

All rebuttals must take this form:
Find an invocation of H(P,P) at machine address 00001a7e such that the
simulation or execution of (the exact byte sequence of) P reaches its
final address of 00001a72.

Now that I have finally made my claim 100% perfectly precise when any
fake "rebuttal" side steps this claim with the strawman error (dishonest
dodge) it is very easy to tell.

--
Copyright 2021 Pete Olcott

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

On 11/12/21 6:43 PM, olcott wrote:
> On 11/12/2021 5:13 PM, Richard Damon wrote:
>> On 11/12/21 5:53 PM, olcott wrote:
>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>> #include <stdint.h>
>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>
>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>> {
>>>>>>>>>    x(y);
>>>>>>>>>    return 1;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>    H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main(void)
>>>>>>>>> {
>>>>>>>>>    H(P, P);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> It is obvious that the direct execution of the above code never
>>>>>>>>> halts because it is infinitely recursive. It is equally obvious
>>>>>>>>> that when H performs a correct pure simulation of its input
>>>>>>>>> (instead of directly executing it) that its input never halts.
>>>>>>>>>
>>>>>>>>> _P()
>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>
>>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>>> enable P to reach its final state at 1a72 we correctly conclude
>>>>>>>>> that the input to H(P,P) never halts.
>>>>>>>>
>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of P
>>>>>>>> will reach that address, and the actual running of P is what
>>>>>>>> matters.
>>>>>>>>
>>>>>>>> All you have shown is that it is impossible for H to PROVE that
>>>>>>>> P will be halting, not that P isn't Halting.
>>>>>>>>
>>>>>>> I have shown that P always specifies infinite recursion whether
>>>>>>> or not this infinite recursion is aborted, therefore H(P,P)==0 is
>>>>>>> always correct.
>>>>>>
>>>>>> No, you haven't.
>>>>>>
>>>>>> You logic makes the unsound step of FIRST assuming that H never
>>>>>> aborts its operation, and THEN has H do an abort.
>>>>>>
>>>>>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>>>>>> return 0 then you have just proved you logic system to be
>>>>>> inconsistent as it can also be proved the if H(P,P) returns 0,
>>>>>> that P(P) halts.
>>>>>>
>>>>>> A system that can prove a statement and its complement is
>>>>>> inconsestent, and logically worthless.
>>>>>>
>>>>>>>
>>>>>>> All rebuttals must take this form:
>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such
>>>>>>> that the simulation or execution of (the exact byte sequence of)
>>>>>>> P reaches its final address of 00001a72.
>>>>>>>
>>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0 for
>>>>>>> every H in the unverse.
>>>>>>>
>>>>>>
>>>>>> WRONG CRITERIA.
>>>>>>
>>>>>> Just proves you are looking at POOP.
>>>>>>
>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>
>>>>>
>>>>> I proven beyond all possible doubt that the real P is infinitely
>>>>> recursive in my latest example where H directly executes its input
>>>>
>>>>
>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>> non-Halting,
>>>
>>> The ultimate measure of the halt status of an input is its behavior
>>> when directly executed.
>>>
>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>
>>>
>>> The fact that for every possible H that can possibly exist at at
>>> machine address 00001a7e the simulation or execution of (the exact
>>> byte sequence of) P never reaches its final address of 00001a72
>>> conclusively proves that the input to H(P,P) never halts.
>>>
>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>> always correct.
>>
>> No, you have a fundamental error in your logic,
>>
>> FIRST, as has been explained before, but you just ignorantly ignore,
>> 'inputs' do not have behavior, and as such do not halt or be
>> non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
>> your statement is proved conclusively FALSE because it makes an error
>> in category (Maybe you don't understand these terms, but repeatedly
>> ignoring them doesn't help your cause).
>
> Because the simulated or executed input to every H(P,P) invoked at
> machine address 00001a7e with the byte sequence of the machine code of P
> as its input never reaches the final address of P at 00001a72 it is
> always correct for this H(P,P) to return 0.

Whch just proves that H can not prove Halting. It does NOT prove
non-halting, except for the case when H NEVER aborts, and it that case
it never gives the answer.

FAIL.

>
> All rebuttals must take this form:
> Find an invocation of H(P,P) at machine address 00001a7e such that the
> simulation or execution of (the exact byte sequence of) P reaches its
> final address of 00001a72.

No, they don't because that isn't the critera that Halting is based on.

You have basically just proved that you don't have the basic
understanding of the logical principles to engage in meaningful
discusion on this topic.

>
> Now that I have finally made my claim 100% perfectly precise when any
> fake "rebuttal" side steps this claim with the strawman error (dishonest
> dodge) it is very easy to tell.
>

FALSE. You just proved that you like to LIE about what you are doing.

FAIL.

On 11/12/2021 6:39 PM, Richard Damon wrote:
>
> On 11/12/21 6:43 PM, olcott wrote:
>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>> On 11/12/21 5:53 PM, olcott wrote:
>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>> #include <stdint.h>
>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>
>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>> {
>>>>>>>>>>    x(y);
>>>>>>>>>>    return 1;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>    H(x, x);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main(void)
>>>>>>>>>> {
>>>>>>>>>>    H(P, P);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>> never halts because it is infinitely recursive. It is equally
>>>>>>>>>> obvious that when H performs a correct pure simulation of its
>>>>>>>>>> input (instead of directly executing it) that its input never
>>>>>>>>>> halts.
>>>>>>>>>>
>>>>>>>>>> _P()
>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>
>>>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>>>> enable P to reach its final state at 1a72 we correctly
>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>
>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of
>>>>>>>>> P will reach that address, and the actual running of P is what
>>>>>>>>> matters.
>>>>>>>>>
>>>>>>>>> All you have shown is that it is impossible for H to PROVE that
>>>>>>>>> P will be halting, not that P isn't Halting.
>>>>>>>>>
>>>>>>>> I have shown that P always specifies infinite recursion whether
>>>>>>>> or not this infinite recursion is aborted, therefore H(P,P)==0
>>>>>>>> is always correct.
>>>>>>>
>>>>>>> No, you haven't.
>>>>>>>
>>>>>>> You logic makes the unsound step of FIRST assuming that H never
>>>>>>> aborts its operation, and THEN has H do an abort.
>>>>>>>
>>>>>>> If you DO have a valid proof that P(P) is non-halting when H(P,P)
>>>>>>> return 0 then you have just proved you logic system to be
>>>>>>> inconsistent as it can also be proved the if H(P,P) returns 0,
>>>>>>> that P(P) halts.
>>>>>>>
>>>>>>> A system that can prove a statement and its complement is
>>>>>>> inconsestent, and logically worthless.
>>>>>>>
>>>>>>>>
>>>>>>>> All rebuttals must take this form:
>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such
>>>>>>>> that the simulation or execution of (the exact byte sequence of)
>>>>>>>> P reaches its final address of 00001a72.
>>>>>>>>
>>>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0
>>>>>>>> for every H in the unverse.
>>>>>>>>
>>>>>>>
>>>>>>> WRONG CRITERIA.
>>>>>>>
>>>>>>> Just proves you are looking at POOP.
>>>>>>>
>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>
>>>>>>
>>>>>> I proven beyond all possible doubt that the real P is infinitely
>>>>>> recursive in my latest example where H directly executes its input
>>>>>
>>>>>
>>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>>> non-Halting,
>>>>
>>>> The ultimate measure of the halt status of an input is its behavior
>>>> when directly executed.
>>>>
>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>
>>>>
>>>> The fact that for every possible H that can possibly exist at at
>>>> machine address 00001a7e the simulation or execution of (the exact
>>>> byte sequence of) P never reaches its final address of 00001a72
>>>> conclusively proves that the input to H(P,P) never halts.
>>>>
>>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>>> always correct.
>>>
>>> No, you have a fundamental error in your logic,
>>>
>>> FIRST, as has been explained before, but you just ignorantly ignore,
>>> 'inputs' do not have behavior, and as such do not halt or be
>>> non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
>>> your statement is proved conclusively FALSE because it makes an error
>>> in category (Maybe you don't understand these terms, but repeatedly
>>> ignoring them doesn't help your cause).
>>
>> Because the simulated or executed input to every H(P,P) invoked at
>> machine address 00001a7e with the byte sequence of the machine code of
>> P as its input never reaches the final address of P at 00001a72 it is
>> always correct for this H(P,P) to return 0.
>
> Whch just proves that H can not prove Halting. It does NOT prove
> non-halting, except for the case when H NEVER aborts, and it that case
> it never gives the answer.
>

It proves no such thing.

If the input to (the precisely specified) H(P,P) never halts then it
always correct for H to report that the input to this H(P,P) never halts.

--
Copyright 2021 Pete Olcott

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

On 11/12/21 7:52 PM, olcott wrote:
> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>
>> On 11/12/21 6:43 PM, olcott wrote:
>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>
>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>> {
>>>>>>>>>>>    x(y);
>>>>>>>>>>>    return 1;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>    H(x, x);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main(void)
>>>>>>>>>>> {
>>>>>>>>>>>    H(P, P);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>>> never halts because it is infinitely recursive. It is equally
>>>>>>>>>>> obvious that when H performs a correct pure simulation of its
>>>>>>>>>>> input (instead of directly executing it) that its input never
>>>>>>>>>>> halts.
>>>>>>>>>>>
>>>>>>>>>>> _P()
>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>
>>>>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>>>>> enable P to reach its final state at 1a72 we correctly
>>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>>
>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running of
>>>>>>>>>> P will reach that address, and the actual running of P is what
>>>>>>>>>> matters.
>>>>>>>>>>
>>>>>>>>>> All you have shown is that it is impossible for H to PROVE
>>>>>>>>>> that P will be halting, not that P isn't Halting.
>>>>>>>>>>
>>>>>>>>> I have shown that P always specifies infinite recursion whether
>>>>>>>>> or not this infinite recursion is aborted, therefore H(P,P)==0
>>>>>>>>> is always correct.
>>>>>>>>
>>>>>>>> No, you haven't.
>>>>>>>>
>>>>>>>> You logic makes the unsound step of FIRST assuming that H never
>>>>>>>> aborts its operation, and THEN has H do an abort.
>>>>>>>>
>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>> H(P,P) return 0 then you have just proved you logic system to be
>>>>>>>> inconsistent as it can also be proved the if H(P,P) returns 0,
>>>>>>>> that P(P) halts.
>>>>>>>>
>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> All rebuttals must take this form:
>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such
>>>>>>>>> that the simulation or execution of (the exact byte sequence
>>>>>>>>> of) P reaches its final address of 00001a72.
>>>>>>>>>
>>>>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0
>>>>>>>>> for every H in the unverse.
>>>>>>>>>
>>>>>>>>
>>>>>>>> WRONG CRITERIA.
>>>>>>>>
>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>
>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>
>>>>>>>
>>>>>>> I proven beyond all possible doubt that the real P is infinitely
>>>>>>> recursive in my latest example where H directly executes its input
>>>>>>
>>>>>>
>>>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>>>> non-Halting,
>>>>>
>>>>> The ultimate measure of the halt status of an input is its behavior
>>>>> when directly executed.
>>>>>
>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>
>>>>>
>>>>> The fact that for every possible H that can possibly exist at at
>>>>> machine address 00001a7e the simulation or execution of (the exact
>>>>> byte sequence of) P never reaches its final address of 00001a72
>>>>> conclusively proves that the input to H(P,P) never halts.
>>>>>
>>>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>>>> always correct.
>>>>
>>>> No, you have a fundamental error in your logic,
>>>>
>>>> FIRST, as has been explained before, but you just ignorantly ignore,
>>>> 'inputs' do not have behavior, and as such do not halt or be
>>>> non-halting. Halting is a property of COMPUTATIONS, not inputs. Thus
>>>> your statement is proved conclusively FALSE because it makes an
>>>> error in category (Maybe you don't understand these terms, but
>>>> repeatedly ignoring them doesn't help your cause).
>>>
>>> Because the simulated or executed input to every H(P,P) invoked at
>>> machine address 00001a7e with the byte sequence of the machine code
>>> of P as its input never reaches the final address of P at 00001a72 it
>>> is always correct for this H(P,P) to return 0.
>>
>> Whch just proves that H can not prove Halting. It does NOT prove
>> non-halting, except for the case when H NEVER aborts, and it that case
>> it never gives the answer.
>>
>
> It proves no such thing.
>
> If the input to (the precisely specified) H(P,P) never halts then it
> always correct for H to report that the input to this H(P,P) never halts.
>

WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING PROPERTY,
only machines do.

Only reasonable interpretations of this statement is either:
1) The behavior of Computation (Machine + Input) that this input
represents,
2) The behavior of a UTM/pure simulation of this input (NOT a simulation
that aborts its simulation).

On 11/12/2021 7:13 PM, Richard Damon wrote:
> On 11/12/21 7:52 PM, olcott wrote:
>> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>>
>>> On 11/12/21 6:43 PM, olcott wrote:
>>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>
>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>> {
>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>    return 1;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>>    H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main(void)
>>>>>>>>>>>> {
>>>>>>>>>>>>    H(P, P);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>>>> never halts because it is infinitely recursive. It is
>>>>>>>>>>>> equally obvious that when H performs a correct pure
>>>>>>>>>>>> simulation of its input (instead of directly executing it)
>>>>>>>>>>>> that its input never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> _P()
>>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>>
>>>>>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>>>>>> enable P to reach its final state at 1a72 we correctly
>>>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>>>
>>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running
>>>>>>>>>>> of P will reach that address, and the actual running of P is
>>>>>>>>>>> what matters.
>>>>>>>>>>>
>>>>>>>>>>> All you have shown is that it is impossible for H to PROVE
>>>>>>>>>>> that P will be halting, not that P isn't Halting.
>>>>>>>>>>>
>>>>>>>>>> I have shown that P always specifies infinite recursion
>>>>>>>>>> whether or not this infinite recursion is aborted, therefore
>>>>>>>>>> H(P,P)==0 is always correct.
>>>>>>>>>
>>>>>>>>> No, you haven't.
>>>>>>>>>
>>>>>>>>> You logic makes the unsound step of FIRST assuming that H never
>>>>>>>>> aborts its operation, and THEN has H do an abort.
>>>>>>>>>
>>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>>> H(P,P) return 0 then you have just proved you logic system to
>>>>>>>>> be inconsistent as it can also be proved the if H(P,P) returns
>>>>>>>>> 0, that P(P) halts.
>>>>>>>>>
>>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All rebuttals must take this form:
>>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such
>>>>>>>>>> that the simulation or execution of (the exact byte sequence
>>>>>>>>>> of) P reaches its final address of 00001a72.
>>>>>>>>>>
>>>>>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0
>>>>>>>>>> for every H in the unverse.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> WRONG CRITERIA.
>>>>>>>>>
>>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>>
>>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I proven beyond all possible doubt that the real P is infinitely
>>>>>>>> recursive in my latest example where H directly executes its input
>>>>>>>
>>>>>>>
>>>>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>>>>> non-Halting,
>>>>>>
>>>>>> The ultimate measure of the halt status of an input is its
>>>>>> behavior when directly executed.
>>>>>>
>>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>>
>>>>>>
>>>>>> The fact that for every possible H that can possibly exist at at
>>>>>> machine address 00001a7e the simulation or execution of (the exact
>>>>>> byte sequence of) P never reaches its final address of 00001a72
>>>>>> conclusively proves that the input to H(P,P) never halts.
>>>>>>
>>>>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>>>>> always correct.
>>>>>
>>>>> No, you have a fundamental error in your logic,
>>>>>
>>>>> FIRST, as has been explained before, but you just ignorantly
>>>>> ignore, 'inputs' do not have behavior, and as such do not halt or
>>>>> be non-halting. Halting is a property of COMPUTATIONS, not inputs.
>>>>> Thus your statement is proved conclusively FALSE because it makes
>>>>> an error in category (Maybe you don't understand these terms, but
>>>>> repeatedly ignoring them doesn't help your cause).
>>>>
>>>> Because the simulated or executed input to every H(P,P) invoked at
>>>> machine address 00001a7e with the byte sequence of the machine code
>>>> of P as its input never reaches the final address of P at 00001a72
>>>> it is always correct for this H(P,P) to return 0.
>>>
>>> Whch just proves that H can not prove Halting. It does NOT prove
>>> non-halting, except for the case when H NEVER aborts, and it that
>>> case it never gives the answer.
>>>
>>
>> It proves no such thing.
>>
>> If the input to (the precisely specified) H(P,P) never halts then it
>> always correct for H to report that the input to this H(P,P) never halts.
>>
>
> WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING PROPERTY,
> only machines do.
>

On 2021-11-12 15:53, olcott wrote:

> The ultimate measure of the halt status of an input is its behavior when
> directly executed.

The input itself doesn't have a halt status. The machine it represents
does. And the ultimate measure of the halt status of that machine is
whether that machine halts when directly executed.

P(P) halts when directly exectuted.

Therefore H(P, P) == 0 is the wrong answer.

André

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

On 11/12/2021 7:47 PM, André G. Isaak wrote:
> On 2021-11-12 15:53, olcott wrote:
>
>> The ultimate measure of the halt status of an input is its behavior
>> when directly executed.
>
> The input itself doesn't have a halt status.

In this case it does. Ben simplified my syntax.

#include <stdint.h>
typedef void (*ptr)();

int H(ptr x, ptr y)
{ x(y); // direct execution of P(P)
return 1;
}

// Minimal essence of Linz(1990) Ĥ
// and Strachey(1965) P
void P(ptr x)
{ H(x, x);
}

int main(void)
{ H(P, P);
}

> The machine it represents
> does. And the ultimate measure of the halt status of that machine is
> whether that machine halts when directly executed.
>
> P(P) halts when directly exectuted.
>
> Therefore H(P, P) == 0 is the wrong answer.
>
> André
>

--
Copyright 2021 Pete Olcott

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

On 11/12/21 8:42 PM, olcott wrote:
> On 11/12/2021 7:13 PM, Richard Damon wrote:
>> On 11/12/21 7:52 PM, olcott wrote:
>>> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>>>
>>>> On 11/12/21 6:43 PM, olcott wrote:
>>>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>
>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>    return 1;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    H(x, x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main(void)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>    H(P, P);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>>>>> never halts because it is infinitely recursive. It is
>>>>>>>>>>>>> equally obvious that when H performs a correct pure
>>>>>>>>>>>>> simulation of its input (instead of directly executing it)
>>>>>>>>>>>>> that its input never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> _P()
>>>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Because there is nothing that H can possibly do to cause or
>>>>>>>>>>>>> enable P to reach its final state at 1a72 we correctly
>>>>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>>>>
>>>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running
>>>>>>>>>>>> of P will reach that address, and the actual running of P is
>>>>>>>>>>>> what matters.
>>>>>>>>>>>>
>>>>>>>>>>>> All you have shown is that it is impossible for H to PROVE
>>>>>>>>>>>> that P will be halting, not that P isn't Halting.
>>>>>>>>>>>>
>>>>>>>>>>> I have shown that P always specifies infinite recursion
>>>>>>>>>>> whether or not this infinite recursion is aborted, therefore
>>>>>>>>>>> H(P,P)==0 is always correct.
>>>>>>>>>>
>>>>>>>>>> No, you haven't.
>>>>>>>>>>
>>>>>>>>>> You logic makes the unsound step of FIRST assuming that H
>>>>>>>>>> never aborts its operation, and THEN has H do an abort.
>>>>>>>>>>
>>>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>>>> H(P,P) return 0 then you have just proved you logic system to
>>>>>>>>>> be inconsistent as it can also be proved the if H(P,P) returns
>>>>>>>>>> 0, that P(P) halts.
>>>>>>>>>>
>>>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> All rebuttals must take this form:
>>>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e such
>>>>>>>>>>> that the simulation or execution of (the exact byte sequence
>>>>>>>>>>> of) P reaches its final address of 00001a72.
>>>>>>>>>>>
>>>>>>>>>>> If no rebuttals exist this conclusively proves that H(P,P)==0
>>>>>>>>>>> for every H in the unverse.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> WRONG CRITERIA.
>>>>>>>>>>
>>>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>>>
>>>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I proven beyond all possible doubt that the real P is
>>>>>>>>> infinitely recursive in my latest example where H directly
>>>>>>>>> executes its input
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>>>>>> non-Halting,
>>>>>>>
>>>>>>> The ultimate measure of the halt status of an input is its
>>>>>>> behavior when directly executed.
>>>>>>>
>>>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>>>
>>>>>>>
>>>>>>> The fact that for every possible H that can possibly exist at at
>>>>>>> machine address 00001a7e the simulation or execution of (the
>>>>>>> exact byte sequence of) P never reaches its final address of
>>>>>>> 00001a72 conclusively proves that the input to H(P,P) never halts.
>>>>>>>
>>>>>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>>>>>> always correct.
>>>>>>
>>>>>> No, you have a fundamental error in your logic,
>>>>>>
>>>>>> FIRST, as has been explained before, but you just ignorantly
>>>>>> ignore, 'inputs' do not have behavior, and as such do not halt or
>>>>>> be non-halting. Halting is a property of COMPUTATIONS, not inputs.
>>>>>> Thus your statement is proved conclusively FALSE because it makes
>>>>>> an error in category (Maybe you don't understand these terms, but
>>>>>> repeatedly ignoring them doesn't help your cause).
>>>>>
>>>>> Because the simulated or executed input to every H(P,P) invoked at
>>>>> machine address 00001a7e with the byte sequence of the machine code
>>>>> of P as its input never reaches the final address of P at 00001a72
>>>>> it is always correct for this H(P,P) to return 0.
>>>>
>>>> Whch just proves that H can not prove Halting. It does NOT prove
>>>> non-halting, except for the case when H NEVER aborts, and it that
>>>> case it never gives the answer.
>>>>
>>>
>>> It proves no such thing.
>>>
>>> If the input to (the precisely specified) H(P,P) never halts then it
>>> always correct for H to report that the input to this H(P,P) never
>>> halts.
>>>
>>
>> WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING PROPERTY,
>> only machines do.
>>
>
> If the correctly simulated or directly executed input to (the precisely
> specified) H(P,P) never halts then it always correct for H to report
> that the input to this H(P,P) never halts.
>
> If X is a Y then it is always correct to say X is a Y.

On 11/12/21 8:59 PM, olcott wrote:
> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>> On 2021-11-12 15:53, olcott wrote:
>>
>>> The ultimate measure of the halt status of an input is its behavior
>>> when directly executed.
>>
>> The input itself doesn't have a halt status.
>
> In this case it does. Ben simplified my syntax.

Nope.

This just shows that you don't have a valid Turing Model in place.

A sting of bytes does not in of itself have a Halting Status.

Interpreting that string as a set of instructions by executing it, makes
it have one.

Basically, your x(y) to be implemented in a Turing Machine would likely
be putting in the code for a UTM there, and the tape would need to be
loaded with a representation of the function P and all the code of H
that it calls, including that UTM.

That input tape, still, doesn't have behavior on its own. but ONLY as
viewed as either the representation of an actual Turing Machine, or as
the input to a UTM (which is what you do here).

FAIL.

>
> #include <stdint.h>
> typedef void (*ptr)();
>
> int H(ptr x, ptr y)
> {
>   x(y);  // direct execution of P(P)
>   return 1;
> }
>
> // Minimal essence of Linz(1990) Ĥ
> // and Strachey(1965) P
> void P(ptr x)
> {
>   H(x, x);
> }
>
> int main(void)
> {
>   H(P, P);
> }
>
>
>
>> The machine it represents does. And the ultimate measure of the halt
>> status of that machine is whether that machine halts when directly
>> executed.
>>
>> P(P) halts when directly exectuted.
>>
>> Therefore H(P, P) == 0 is the wrong answer.
>>
>> André
>>
>
>

On 11/12/2021 8:11 PM, Richard Damon wrote:
> On 11/12/21 8:42 PM, olcott wrote:
>> On 11/12/2021 7:13 PM, Richard Damon wrote:
>>> On 11/12/21 7:52 PM, olcott wrote:
>>>> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>>>>
>>>>> On 11/12/21 6:43 PM, olcott wrote:
>>>>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>    return 1;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    H(x, x);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> int main(void)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>    H(P, P);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>>>>>> never halts because it is infinitely recursive. It is
>>>>>>>>>>>>>> equally obvious that when H performs a correct pure
>>>>>>>>>>>>>> simulation of its input (instead of directly executing it)
>>>>>>>>>>>>>> that its input never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Because there is nothing that H can possibly do to cause
>>>>>>>>>>>>>> or enable P to reach its final state at 1a72 we correctly
>>>>>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL running
>>>>>>>>>>>>> of P will reach that address, and the actual running of P
>>>>>>>>>>>>> is what matters.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All you have shown is that it is impossible for H to PROVE
>>>>>>>>>>>>> that P will be halting, not that P isn't Halting.
>>>>>>>>>>>>>
>>>>>>>>>>>> I have shown that P always specifies infinite recursion
>>>>>>>>>>>> whether or not this infinite recursion is aborted, therefore
>>>>>>>>>>>> H(P,P)==0 is always correct.
>>>>>>>>>>>
>>>>>>>>>>> No, you haven't.
>>>>>>>>>>>
>>>>>>>>>>> You logic makes the unsound step of FIRST assuming that H
>>>>>>>>>>> never aborts its operation, and THEN has H do an abort.
>>>>>>>>>>>
>>>>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>>>>> H(P,P) return 0 then you have just proved you logic system to
>>>>>>>>>>> be inconsistent as it can also be proved the if H(P,P)
>>>>>>>>>>> returns 0, that P(P) halts.
>>>>>>>>>>>
>>>>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> All rebuttals must take this form:
>>>>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e
>>>>>>>>>>>> such that the simulation or execution of (the exact byte
>>>>>>>>>>>> sequence of) P reaches its final address of 00001a72.
>>>>>>>>>>>>
>>>>>>>>>>>> If no rebuttals exist this conclusively proves that
>>>>>>>>>>>> H(P,P)==0 for every H in the unverse.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> WRONG CRITERIA.
>>>>>>>>>>>
>>>>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>>>>
>>>>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I proven beyond all possible doubt that the real P is
>>>>>>>>>> infinitely recursive in my latest example where H directly
>>>>>>>>>> executes its input
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes, *IF* H just directly executes its input, then P(P) will be
>>>>>>>>> non-Halting,
>>>>>>>>
>>>>>>>> The ultimate measure of the halt status of an input is its
>>>>>>>> behavior when directly executed.
>>>>>>>>
>>>>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>>>>
>>>>>>>>
>>>>>>>> The fact that for every possible H that can possibly exist at at
>>>>>>>> machine address 00001a7e the simulation or execution of (the
>>>>>>>> exact byte sequence of) P never reaches its final address of
>>>>>>>> 00001a72 conclusively proves that the input to H(P,P) never halts.
>>>>>>>>
>>>>>>>> The input to H(P,P) never halts therefore when H returns 0 it is
>>>>>>>> always correct.
>>>>>>>
>>>>>>> No, you have a fundamental error in your logic,
>>>>>>>
>>>>>>> FIRST, as has been explained before, but you just ignorantly
>>>>>>> ignore, 'inputs' do not have behavior, and as such do not halt or
>>>>>>> be non-halting. Halting is a property of COMPUTATIONS, not
>>>>>>> inputs. Thus your statement is proved conclusively FALSE because
>>>>>>> it makes an error in category (Maybe you don't understand these
>>>>>>> terms, but repeatedly ignoring them doesn't help your cause).
>>>>>>
>>>>>> Because the simulated or executed input to every H(P,P) invoked at
>>>>>> machine address 00001a7e with the byte sequence of the machine
>>>>>> code of P as its input never reaches the final address of P at
>>>>>> 00001a72 it is always correct for this H(P,P) to return 0.
>>>>>
>>>>> Whch just proves that H can not prove Halting. It does NOT prove
>>>>> non-halting, except for the case when H NEVER aborts, and it that
>>>>> case it never gives the answer.
>>>>>
>>>>
>>>> It proves no such thing.
>>>>
>>>> If the input to (the precisely specified) H(P,P) never halts then it
>>>> always correct for H to report that the input to this H(P,P) never
>>>> halts.
>>>>
>>>
>>> WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING
>>> PROPERTY, only machines do.
>>>
>>
>> If the correctly simulated or directly executed input to (the
>> precisely specified) H(P,P) never halts then it always correct for H
>> to report that the input to this H(P,P) never halts.
>>
>> If X is a Y then it is always correct to say X is a Y.
>
> Except that, BY DEFINITION, if H has aborted its simulation/direct
> execution of its input, then it has NOT correctly simulated it.
>

On 11/12/2021 8:19 PM, Richard Damon wrote:
> On 11/12/21 8:59 PM, olcott wrote:
>> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>>> On 2021-11-12 15:53, olcott wrote:
>>>
>>>> The ultimate measure of the halt status of an input is its behavior
>>>> when directly executed.
>>>
>>> The input itself doesn't have a halt status.
>>
>> In this case it does. Ben simplified my syntax.
>
> Nope.
>
> This just shows that you don't have a valid Turing Model in place.
>
> A sting of bytes does not in of itself have a Halting Status.
>
> Interpreting that string as a set of instructions by executing it, makes
> it have one.
>
> Basically, your x(y) to be implemented in a Turing Machine would likely
> be putting in the code for a UTM there, and the tape would need to be
> loaded with a representation of the function P and all the code of H
> that it calls, including that UTM.
>
> That input tape, still, doesn't have behavior on its own. but ONLY as
> viewed as either the representation of an actual Turing Machine, or as
> the input to a UTM (which is what you do here).
>
> FAIL.
>

computation that halts
a computation is said to halt whenever it enters a final state.
(Linz:1990:234)

computer science decider
a decider is a machine that accepts or rejects inputs.
https://cs.stackexchange.com/questions/84433/what-is-decider

halt decider
A halt decider accept or rejects an input on the basis of whether or not
the direct execution or pure simulation of this input would ever reach a
final state of this input.

_P()
[00001a5e](01) 55 push ebp
[00001a5f](02) 8bec mov ebp,esp
[00001a61](03) 8b4508 mov eax,[ebp+08]
[00001a64](01) 50 push eax // push P
[00001a65](03) 8b4d08 mov ecx,[ebp+08]
[00001a68](01) 51 push ecx // push P
[00001a69](05) e810000000 call 00001a7e // call H
[00001a6e](03) 83c408 add esp,+08
[00001a71](01) 5d pop ebp
[00001a72](01) c3 ret
Size in bytes:(0021) [00001a72]

H(P,P)==0 is correct for every H at machine address 00001a7e with the
above string of machine language bytes as its input.

>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> int H(ptr x, ptr y)
>> {
>>    x(y);  // direct execution of P(P)
>>    return 1;
>> }
>>
>> // Minimal essence of Linz(1990) Ĥ
>> // and Strachey(1965) P
>> void P(ptr x)
>> {
>>    H(x, x);
>> }
>>
>> int main(void)
>> {
>>    H(P, P);
>> }
>>
>>
>>
>>> The machine it represents does. And the ultimate measure of the halt
>>> status of that machine is whether that machine halts when directly
>>> executed.
>>>
>>> P(P) halts when directly exectuted.
>>>
>>> Therefore H(P, P) == 0 is the wrong answer.
>>>
>>> André
>>>
>>
>>
>

--
Copyright 2021 Pete Olcott

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

On 11/12/21 10:25 PM, olcott wrote:
> On 11/12/2021 8:19 PM, Richard Damon wrote:
>> On 11/12/21 8:59 PM, olcott wrote:
>>> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>>>> On 2021-11-12 15:53, olcott wrote:
>>>>
>>>>> The ultimate measure of the halt status of an input is its behavior
>>>>> when directly executed.
>>>>
>>>> The input itself doesn't have a halt status.
>>>
>>> In this case it does. Ben simplified my syntax.
>>
>> Nope.
>>
>> This just shows that you don't have a valid Turing Model in place.
>>
>> A sting of bytes does not in of itself have a Halting Status.
>>
>> Interpreting that string as a set of instructions by executing it,
>> makes it have one.
>>
>> Basically, your x(y) to be implemented in a Turing Machine would
>> likely be putting in the code for a UTM there, and the tape would need
>> to be loaded with a representation of the function P and all the code
>> of H that it calls, including that UTM.
>>
>> That input tape, still, doesn't have behavior on its own. but ONLY as
>> viewed as either the representation of an actual Turing Machine, or as
>> the input to a UTM (which is what you do here).
>>
>> FAIL.
>>
>
>
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>

Right, THE COMPUTATION, not a partial simulation of one.
Note Non-Halting is defined as NEVER halting after unlimited number of
steps.

Not failing to reach the halt state after executing only a limited fixed
number of steps.

FAIL

> computer science decider
> a decider is a machine that accepts or rejects inputs.
> https://cs.stackexchange.com/questions/84433/what-is-decider
>
> halt decider
> A halt decider accept or rejects an input on the basis of whether or not
> the direct execution or pure simulation of this input would ever reach a
> final state of this input.
>

RIGHT, only FULL DIRECT EXECTUTION or PURE SIMULATION.

> _P()
> [00001a5e](01)  55              push ebp
> [00001a5f](02)  8bec            mov ebp,esp
> [00001a61](03)  8b4508          mov eax,[ebp+08]
> [00001a64](01)  50              push eax        // push P
> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
> [00001a68](01)  51              push ecx        // push P
> [00001a69](05)  e810000000      call 00001a7e   // call H
> [00001a6e](03)  83c408          add esp,+08
> [00001a71](01)  5d              pop ebp
> [00001a72](01)  c3              ret
> Size in bytes:(0021) [00001a72]
>
>
> H(P,P)==0 is correct for every H at machine address 00001a7e with the
> above string of machine language bytes as its input.
>

Nope.

If H is defined in a way that aborts its simulation and returns a value
in finite time then the DIRECT EXECTUTION of P will reach that terminal
state.

Yes, H in its PARTIAL simulation won't see that, but a partial
simulation proves nothing.

Yes, if H actual does an unconditional execution of the machine
represented by its input, then P(P) will become non-halting, but H(P,P)
never returns the 0 value to be right about it.

Also, if that is all the input it is given, then you haven't meet the
requriements.

That input is NOT a full description of the machine P, as it doesn't
fully define the behavior of the machine it is supposed to represent.

Make that the SOLE input to a direct exectuition and the call to H at
1a7e becomes undefined. For this to represent an equivalent to the
TURING MACHINE H^ (aka P) then it needs a FULL COPY of the code of H.

FAIL.

If you object, tell me what is the halting behavior of the following
program:

void X(ptr x)
{ if(foo(x,x)) {
while(1);
}
return;
}

It is just as complete a program description as what you gave for P
above with its call of H.

Go ahead, tell me what H(X,X) should return.

>>>
>>> #include <stdint.h>
>>> typedef void (*ptr)();
>>>
>>> int H(ptr x, ptr y)
>>> {
>>>    x(y);  // direct execution of P(P)
>>>    return 1;
>>> }
>>>
>>> // Minimal essence of Linz(1990) Ĥ
>>> // and Strachey(1965) P
>>> void P(ptr x)
>>> {
>>>    H(x, x);
>>> }
>>>
>>> int main(void)
>>> {
>>>    H(P, P);
>>> }
>>>
>>>
>>>
>>>> The machine it represents does. And the ultimate measure of the halt
>>>> status of that machine is whether that machine halts when directly
>>>> executed.
>>>>
>>>> P(P) halts when directly exectuted.
>>>>
>>>> Therefore H(P, P) == 0 is the wrong answer.
>>>>
>>>> André
>>>>
>>>
>>>
>>
>
>

On 11/12/21 10:17 PM, olcott wrote:
> On 11/12/2021 8:11 PM, Richard Damon wrote:
>> On 11/12/21 8:42 PM, olcott wrote:
>>> On 11/12/2021 7:13 PM, Richard Damon wrote:
>>>> On 11/12/21 7:52 PM, olcott wrote:
>>>>> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 11/12/21 6:43 PM, olcott wrote:
>>>>>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>>>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>    return 1;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    H(x, x);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> int main(void)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>    H(P, P);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> It is obvious that the direct execution of the above code
>>>>>>>>>>>>>>> never halts because it is infinitely recursive. It is
>>>>>>>>>>>>>>> equally obvious that when H performs a correct pure
>>>>>>>>>>>>>>> simulation of its input (instead of directly executing
>>>>>>>>>>>>>>> it) that its input never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Because there is nothing that H can possibly do to cause
>>>>>>>>>>>>>>> or enable P to reach its final state at 1a72 we correctly
>>>>>>>>>>>>>>> conclude that the input to H(P,P) never halts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL
>>>>>>>>>>>>>> running of P will reach that address, and the actual
>>>>>>>>>>>>>> running of P is what matters.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All you have shown is that it is impossible for H to PROVE
>>>>>>>>>>>>>> that P will be halting, not that P isn't Halting.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> I have shown that P always specifies infinite recursion
>>>>>>>>>>>>> whether or not this infinite recursion is aborted,
>>>>>>>>>>>>> therefore H(P,P)==0 is always correct.
>>>>>>>>>>>>
>>>>>>>>>>>> No, you haven't.
>>>>>>>>>>>>
>>>>>>>>>>>> You logic makes the unsound step of FIRST assuming that H
>>>>>>>>>>>> never aborts its operation, and THEN has H do an abort.
>>>>>>>>>>>>
>>>>>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>>>>>> H(P,P) return 0 then you have just proved you logic system
>>>>>>>>>>>> to be inconsistent as it can also be proved the if H(P,P)
>>>>>>>>>>>> returns 0, that P(P) halts.
>>>>>>>>>>>>
>>>>>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> All rebuttals must take this form:
>>>>>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e
>>>>>>>>>>>>> such that the simulation or execution of (the exact byte
>>>>>>>>>>>>> sequence of) P reaches its final address of 00001a72.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If no rebuttals exist this conclusively proves that
>>>>>>>>>>>>> H(P,P)==0 for every H in the unverse.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> WRONG CRITERIA.
>>>>>>>>>>>>
>>>>>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>>>>>
>>>>>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I proven beyond all possible doubt that the real P is
>>>>>>>>>>> infinitely recursive in my latest example where H directly
>>>>>>>>>>> executes its input
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes, *IF* H just directly executes its input, then P(P) will
>>>>>>>>>> be non-Halting,
>>>>>>>>>
>>>>>>>>> The ultimate measure of the halt status of an input is its
>>>>>>>>> behavior when directly executed.
>>>>>>>>>
>>>>>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The fact that for every possible H that can possibly exist at
>>>>>>>>> at machine address 00001a7e the simulation or execution of (the
>>>>>>>>> exact byte sequence of) P never reaches its final address of
>>>>>>>>> 00001a72 conclusively proves that the input to H(P,P) never halts.
>>>>>>>>>
>>>>>>>>> The input to H(P,P) never halts therefore when H returns 0 it
>>>>>>>>> is always correct.
>>>>>>>>
>>>>>>>> No, you have a fundamental error in your logic,
>>>>>>>>
>>>>>>>> FIRST, as has been explained before, but you just ignorantly
>>>>>>>> ignore, 'inputs' do not have behavior, and as such do not halt
>>>>>>>> or be non-halting. Halting is a property of COMPUTATIONS, not
>>>>>>>> inputs. Thus your statement is proved conclusively FALSE because
>>>>>>>> it makes an error in category (Maybe you don't understand these
>>>>>>>> terms, but repeatedly ignoring them doesn't help your cause).
>>>>>>>
>>>>>>> Because the simulated or executed input to every H(P,P) invoked
>>>>>>> at machine address 00001a7e with the byte sequence of the machine
>>>>>>> code of P as its input never reaches the final address of P at
>>>>>>> 00001a72 it is always correct for this H(P,P) to return 0.
>>>>>>
>>>>>> Whch just proves that H can not prove Halting. It does NOT prove
>>>>>> non-halting, except for the case when H NEVER aborts, and it that
>>>>>> case it never gives the answer.
>>>>>>
>>>>>
>>>>> It proves no such thing.
>>>>>
>>>>> If the input to (the precisely specified) H(P,P) never halts then
>>>>> it always correct for H to report that the input to this H(P,P)
>>>>> never halts.
>>>>>
>>>>
>>>> WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING
>>>> PROPERTY, only machines do.
>>>>
>>>
>>> If the correctly simulated or directly executed input to (the
>>> precisely specified) H(P,P) never halts then it always correct for H
>>> to report that the input to this H(P,P) never halts.
>>>
>>> If X is a Y then it is always correct to say X is a Y.
>>
>> Except that, BY DEFINITION, if H has aborted its simulation/direct
>> execution of its input, then it has NOT correctly simulated it.
>>
>
> computation that halts
> a computation is said to halt whenever it enters a final state.
> (Linz:1990:234)
>
> computer science decider
> a decider is a machine that accepts or rejects inputs.
> https://cs.stackexchange.com/questions/84433/what-is-decider
>
> halt decider
> A halt decider correctly determines whether or not the direct execution
> or pure simulation of its input will ever reach a final state of this
> input.

On 11/12/2021 9:41 PM, Richard Damon wrote:
> On 11/12/21 10:25 PM, olcott wrote:
>> On 11/12/2021 8:19 PM, Richard Damon wrote:
>>> On 11/12/21 8:59 PM, olcott wrote:
>>>> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>>>>> On 2021-11-12 15:53, olcott wrote:
>>>>>
>>>>>> The ultimate measure of the halt status of an input is its
>>>>>> behavior when directly executed.
>>>>>
>>>>> The input itself doesn't have a halt status.
>>>>
>>>> In this case it does. Ben simplified my syntax.
>>>
>>> Nope.
>>>
>>> This just shows that you don't have a valid Turing Model in place.
>>>
>>> A sting of bytes does not in of itself have a Halting Status.
>>>
>>> Interpreting that string as a set of instructions by executing it,
>>> makes it have one.
>>>
>>> Basically, your x(y) to be implemented in a Turing Machine would
>>> likely be putting in the code for a UTM there, and the tape would
>>> need to be loaded with a representation of the function P and all the
>>> code of H that it calls, including that UTM.
>>>
>>> That input tape, still, doesn't have behavior on its own. but ONLY as
>>> viewed as either the representation of an actual Turing Machine, or
>>> as the input to a UTM (which is what you do here).
>>>
>>> FAIL.
>>>
>>
>>
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>
> Right, THE COMPUTATION, not a partial simulation of one.
> Note Non-Halting is defined as NEVER halting after unlimited number of
> steps.
>
> Not failing to reach the halt state after executing only a limited fixed
> number of steps.
>
> FAIL
>
>
>> computer science decider
>> a decider is a machine that accepts or rejects inputs.
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>> halt decider
>> A halt decider accept or rejects an input on the basis of whether or
>> not the direct execution or pure simulation of this input would ever
>> reach a final state of this input.
>>
>
> RIGHT, only FULL DIRECT EXECTUTION or PURE SIMULATION.
>
>
>
>
>> _P()
>> [00001a5e](01)  55              push ebp
>> [00001a5f](02)  8bec            mov ebp,esp
>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>> [00001a64](01)  50              push eax        // push P
>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>> [00001a68](01)  51              push ecx        // push P
>> [00001a69](05)  e810000000      call 00001a7e   // call H
>> [00001a6e](03)  83c408          add esp,+08
>> [00001a71](01)  5d              pop ebp
>> [00001a72](01)  c3              ret
>> Size in bytes:(0021) [00001a72]
>>
>>
>> H(P,P)==0 is correct for every H at machine address 00001a7e with the
>> above string of machine language bytes as its input.
>>
>
> Nope.
>
> If H is defined in a way that aborts its simulation and returns a value
> in finite time then the DIRECT EXECTUTION of P will reach that terminal
> state.
No this is not true. For the precisely defined computation of H(P,P) the
input P never gets past 00001a69.

--
Copyright 2021 Pete Olcott

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

On 11/12/2021 9:43 PM, Richard Damon wrote:
> On 11/12/21 10:17 PM, olcott wrote:
>> On 11/12/2021 8:11 PM, Richard Damon wrote:
>>> On 11/12/21 8:42 PM, olcott wrote:
>>>> On 11/12/2021 7:13 PM, Richard Damon wrote:
>>>>> On 11/12/21 7:52 PM, olcott wrote:
>>>>>> On 11/12/2021 6:39 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 11/12/21 6:43 PM, olcott wrote:
>>>>>>>> On 11/12/2021 5:13 PM, Richard Damon wrote:
>>>>>>>>> On 11/12/21 5:53 PM, olcott wrote:
>>>>>>>>>> On 11/12/2021 4:36 PM, Richard Damon wrote:
>>>>>>>>>>> On 11/12/21 5:24 PM, olcott wrote:
>>>>>>>>>>>> On 11/12/2021 4:13 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 11/12/21 5:07 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/12/2021 4:00 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/12/21 3:11 PM, olcott wrote:
>>>>>>>>>>>>>>>> #include <stdint.h>
>>>>>>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int H(ptr x, ptr y)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    x(y);
>>>>>>>>>>>>>>>>    return 1;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // Minimal essence of Linz(1990) Ĥ
>>>>>>>>>>>>>>>> // and Strachey(1965) P (see below)
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    H(x, x);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main(void)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>    H(P, P);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is obvious that the direct execution of the above
>>>>>>>>>>>>>>>> code never halts because it is infinitely recursive. It
>>>>>>>>>>>>>>>> is equally obvious that when H performs a correct pure
>>>>>>>>>>>>>>>> simulation of its input (instead of directly executing
>>>>>>>>>>>>>>>> it) that its input never halts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _P()
>>>>>>>>>>>>>>>> [00001a5e](01)  55              push ebp
>>>>>>>>>>>>>>>> [00001a5f](02)  8bec            mov ebp,esp
>>>>>>>>>>>>>>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [00001a64](01)  50              push eax        // push P
>>>>>>>>>>>>>>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>>>>>>>>>>>>>>> [00001a68](01)  51              push ecx        // push P
>>>>>>>>>>>>>>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>>>>>>>>>>>>>>> [00001a6e](03)  83c408          add esp,+08
>>>>>>>>>>>>>>>> [00001a71](01)  5d              pop ebp
>>>>>>>>>>>>>>>> [00001a72](01)  c3              ret
>>>>>>>>>>>>>>>> Size in bytes:(0021) [00001a72]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Because there is nothing that H can possibly do to cause
>>>>>>>>>>>>>>>> or enable P to reach its final state at 1a72 we
>>>>>>>>>>>>>>>> correctly conclude that the input to H(P,P) never halts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Wrong. IF H does abort and return 0 then the ACTUAL
>>>>>>>>>>>>>>> running of P will reach that address, and the actual
>>>>>>>>>>>>>>> running of P is what matters.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> All you have shown is that it is impossible for H to
>>>>>>>>>>>>>>> PROVE that P will be halting, not that P isn't Halting.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have shown that P always specifies infinite recursion
>>>>>>>>>>>>>> whether or not this infinite recursion is aborted,
>>>>>>>>>>>>>> therefore H(P,P)==0 is always correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No, you haven't.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You logic makes the unsound step of FIRST assuming that H
>>>>>>>>>>>>> never aborts its operation, and THEN has H do an abort.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you DO have a valid proof that P(P) is non-halting when
>>>>>>>>>>>>> H(P,P) return 0 then you have just proved you logic system
>>>>>>>>>>>>> to be inconsistent as it can also be proved the if H(P,P)
>>>>>>>>>>>>> returns 0, that P(P) halts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A system that can prove a statement and its complement is
>>>>>>>>>>>>> inconsestent, and logically worthless.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All rebuttals must take this form:
>>>>>>>>>>>>>> Find an invocation of H(P,P) at machine address 00001a7e
>>>>>>>>>>>>>> such that the simulation or execution of (the exact byte
>>>>>>>>>>>>>> sequence of) P reaches its final address of 00001a72.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If no rebuttals exist this conclusively proves that
>>>>>>>>>>>>>> H(P,P)==0 for every H in the unverse.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WRONG CRITERIA.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Just proves you are looking at POOP.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The REAL halting problems asks what P(P) actually does.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I proven beyond all possible doubt that the real P is
>>>>>>>>>>>> infinitely recursive in my latest example where H directly
>>>>>>>>>>>> executes its input
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, *IF* H just directly executes its input, then P(P) will
>>>>>>>>>>> be non-Halting,
>>>>>>>>>>
>>>>>>>>>> The ultimate measure of the halt status of an input is its
>>>>>>>>>> behavior when directly executed.
>>>>>>>>>>
>>>>>>>>>>> but H(P,P) never returns 0, so it is not a counter example.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The fact that for every possible H that can possibly exist at
>>>>>>>>>> at machine address 00001a7e the simulation or execution of
>>>>>>>>>> (the exact byte sequence of) P never reaches its final address
>>>>>>>>>> of 00001a72 conclusively proves that the input to H(P,P) never
>>>>>>>>>> halts.
>>>>>>>>>>
>>>>>>>>>> The input to H(P,P) never halts therefore when H returns 0 it
>>>>>>>>>> is always correct.
>>>>>>>>>
>>>>>>>>> No, you have a fundamental error in your logic,
>>>>>>>>>
>>>>>>>>> FIRST, as has been explained before, but you just ignorantly
>>>>>>>>> ignore, 'inputs' do not have behavior, and as such do not halt
>>>>>>>>> or be non-halting. Halting is a property of COMPUTATIONS, not
>>>>>>>>> inputs. Thus your statement is proved conclusively FALSE
>>>>>>>>> because it makes an error in category (Maybe you don't
>>>>>>>>> understand these terms, but repeatedly ignoring them doesn't
>>>>>>>>> help your cause).
>>>>>>>>
>>>>>>>> Because the simulated or executed input to every H(P,P) invoked
>>>>>>>> at machine address 00001a7e with the byte sequence of the
>>>>>>>> machine code of P as its input never reaches the final address
>>>>>>>> of P at 00001a72 it is always correct for this H(P,P) to return 0.
>>>>>>>
>>>>>>> Whch just proves that H can not prove Halting. It does NOT prove
>>>>>>> non-halting, except for the case when H NEVER aborts, and it that
>>>>>>> case it never gives the answer.
>>>>>>>
>>>>>>
>>>>>> It proves no such thing.
>>>>>>
>>>>>> If the input to (the precisely specified) H(P,P) never halts then
>>>>>> it always correct for H to report that the input to this H(P,P)
>>>>>> never halts.
>>>>>>
>>>>>
>>>>> WRONG. FIRST: ERROR OF CATEGORY. INPUTS DON'T HAVE A HALTING
>>>>> PROPERTY, only machines do.
>>>>>
>>>>
>>>> If the correctly simulated or directly executed input to (the
>>>> precisely specified) H(P,P) never halts then it always correct for H
>>>> to report that the input to this H(P,P) never halts.
>>>>
>>>> If X is a Y then it is always correct to say X is a Y.
>>>
>>> Except that, BY DEFINITION, if H has aborted its simulation/direct
>>> execution of its input, then it has NOT correctly simulated it.
>>>
>>
>> computation that halts
>> a computation is said to halt whenever it enters a final state.
>> (Linz:1990:234)
>>
>> computer science decider
>> a decider is a machine that accepts or rejects inputs.
>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>
>> halt decider
>> A halt decider correctly determines whether or not the direct
>> execution or pure simulation of its input will ever reach a final
>> state of this input.
>
>
>
> Right, note you said DIRECT EXECUTION OR PURE SIMULATION determine the
> behavior,
>
> That means an UNCONDITIONAL DIRECT EXECTUTION or SIMULATION.
>
> If H 'aborts' its simulation, it is NOT a DIRECT EXECTUTION OR PURE
> SIMULATION.
>

On 11/12/21 11:08 PM, olcott wrote:

> If H somehow determines the correct halt status for its input by jumping
> up and down yelling and screaming then H is a correct halt decider for
> this input.

Except that it didn't get the right answer, since it says that a
Computation that is easily shown to Halt is non-halting.

Your only arguiement that it is right is based on some incorrect
description of what it does.

If it doesn't matter how it got the answer, then way does it matter what
its internal simulation did, since it didn't even matter that it did a
simulation.

This is part of your whole problem, you absolutely need to be consistant
to make your argument, but you keep on going off with inconsistent
arguments, which makes sense since it really appears that you logic
system is inconsistent.

H claiming that P(P) is non-halting can only be supported by a VALID
arguemnt showing a valid chain of reasoning to get to that conclusion.

You never give that, and one common root is that if H might abort its
simulation then you can not presume that H's simulation will be an
accurate depiction of the behavior of the machine, but the only way that
H can get the evidence to decide to abort its simulation is to presume
that it is such a simulation.

Yes, all you have done is jump up and down and yelled and screemed that
your H is a correct Halt Decider, but you havn't actually done anything
to acutally prove this.

BY DEFINITION, since when H(P,P) returns 0, the structure of P makes P
halt, then H(P,P) can never return 0 and be correct.

There is a case when returning zero WOULD have been correct, this
happens when H actually DOES a pure simulation of its input, but inthis
case H never actually does return that 0, so it remains not a proper
decider so isn't a counter example for Linz.

You are basically just a two faced liar, as you keep on switching your
definitions in the middle of a statement. That is just plain lying.

Linz proof shows that by the structure of the machine H^, that it is
actually IMPOSSIBLE of ANY H to return the right answer for the halting
status of the computation H^(<H^>) that was built on that H.

IMPOSSIBLE.

The key fact is that, by the nature of the way Turing Machines are
defined, it is possible for H^ to force H to give an answer in finite
time of how it will answer, and then it can act in the opposite.

The only way imaginable for H to win is to prevent H^ from using it, but
that just isn't possible with Turing Machines. Since every Turing
Machine performs a Computation and every Computation can be computed
with a Turing Machine, there is no space of H to hide and not let H^ use it.

On 11/12/21 11:07 PM, olcott wrote:
> On 11/12/2021 9:41 PM, Richard Damon wrote:
>> On 11/12/21 10:25 PM, olcott wrote:
>>> On 11/12/2021 8:19 PM, Richard Damon wrote:
>>>> On 11/12/21 8:59 PM, olcott wrote:
>>>>> On 11/12/2021 7:47 PM, André G. Isaak wrote:
>>>>>> On 2021-11-12 15:53, olcott wrote:
>>>>>>
>>>>>>> The ultimate measure of the halt status of an input is its
>>>>>>> behavior when directly executed.
>>>>>>
>>>>>> The input itself doesn't have a halt status.
>>>>>
>>>>> In this case it does. Ben simplified my syntax.
>>>>
>>>> Nope.
>>>>
>>>> This just shows that you don't have a valid Turing Model in place.
>>>>
>>>> A sting of bytes does not in of itself have a Halting Status.
>>>>
>>>> Interpreting that string as a set of instructions by executing it,
>>>> makes it have one.
>>>>
>>>> Basically, your x(y) to be implemented in a Turing Machine would
>>>> likely be putting in the code for a UTM there, and the tape would
>>>> need to be loaded with a representation of the function P and all
>>>> the code of H that it calls, including that UTM.
>>>>
>>>> That input tape, still, doesn't have behavior on its own. but ONLY
>>>> as viewed as either the representation of an actual Turing Machine,
>>>> or as the input to a UTM (which is what you do here).
>>>>
>>>> FAIL.
>>>>
>>>
>>>
>>> computation that halts
>>> a computation is said to halt whenever it enters a final state.
>>> (Linz:1990:234)
>>>
>>
>> Right, THE COMPUTATION, not a partial simulation of one.
>> Note Non-Halting is defined as NEVER halting after unlimited number of
>> steps.
>>
>> Not failing to reach the halt state after executing only a limited
>> fixed number of steps.
>>
>> FAIL
>>
>>
>>> computer science decider
>>> a decider is a machine that accepts or rejects inputs.
>>> https://cs.stackexchange.com/questions/84433/what-is-decider
>>>
>>> halt decider
>>> A halt decider accept or rejects an input on the basis of whether or
>>> not the direct execution or pure simulation of this input would ever
>>> reach a final state of this input.
>>>
>>
>> RIGHT, only FULL DIRECT EXECTUTION or PURE SIMULATION.
>>
>>
>>
>>
>>> _P()
>>> [00001a5e](01)  55              push ebp
>>> [00001a5f](02)  8bec            mov ebp,esp
>>> [00001a61](03)  8b4508          mov eax,[ebp+08]
>>> [00001a64](01)  50              push eax        // push P
>>> [00001a65](03)  8b4d08          mov ecx,[ebp+08]
>>> [00001a68](01)  51              push ecx        // push P
>>> [00001a69](05)  e810000000      call 00001a7e   // call H
>>> [00001a6e](03)  83c408          add esp,+08
>>> [00001a71](01)  5d              pop ebp
>>> [00001a72](01)  c3              ret
>>> Size in bytes:(0021) [00001a72]
>>>
>>>
>>> H(P,P)==0 is correct for every H at machine address 00001a7e with the
>>> above string of machine language bytes as its input.
>>>
>>
>> Nope.
>>
>> If H is defined in a way that aborts its simulation and returns a
>> value in finite time then the DIRECT EXECTUTION of P will reach that
>> terminal state.
> No this is not true. For the precisely defined computation of H(P,P) the
> input P never gets past 00001a69.
>

NOPE. You can not provide an H that has H(P,P) returning 0 and also the
direct execution of P(P) doesn't halt.

Yes, there are H's that never abort their operation and results in a
P(P) that is non-halting, but those H's never return the value 0 for H(P,P).

If you are making the assertion that such an H exists, the challenge is
to provide it.

Failure means you admit to lying.