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