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.

So if H aborts its simulation, we need to look at an ACTUAL Direct
Exectution or PURE Simulation of that input.

Yes, if H IS a Direct Execution or Pure Simulation of its input, then
yes, the fact that its processing of P(P) doesn't reach that end state
shows that THAT P(P) is non-halting. Your problem is that ALL of these
machines also never return an answer, so fail to meet the requirements
of being a decider.

Note, this result ONLY applies to the P built on the H that never
aborts. Since P's behavior depends on H, changing to a different H gives
you different results.

When H does abort its simulation, then the simulation/execution by H is
NOT the required PURE SIMULATION or DIRECT EXECUTION, so its failure to
reach the end is NOT proof of non-halting, and since you have changed
the machine P by changing H you previous proof based on the actual
direct execution/pure simulation is not applicable.

You keep on trying to mix the results of one H with that of another, as
has been said before that is INVALID, it makes as much sense as proving
that your cat barks by noting that you neighbor has a cat, so you call
your pet, which happens to be a dog, a cat for this experement.

FAIL.

>
>> Thus, the only machines that meet your premise, are machines that will
>> never abort the simulation/execution of P, and it has been shown that
>> these machine will never return the, in THIS case, correct value of 0.
>>
>> ERGO, you proof fails.
>>
>> You can not show a precisely specified H that actually does CORRECTLY
>> SIMULATE its input which it claims to be non-halting, and also return
>> a value. This is because BY DEFINITION, it takes infinite time to
>> correctly simulate a non-halting computation, and you can't do both
>> return an answer in finite time and still spend an infinite time to do
>> the correct simulation.
>>
>> Your proposition is only true if H is a member of the empty set.
>>
>> FAIL.
>>
>>>
>>>
>>>> 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).
>>>>
>>>> With That:
>>>>
>>>> If your precisely specified H(P,P) is one that returns 0 from the
>>>> call to H(P,P) then it can easily be shown that P(P) for that H will
>>>> halt.
>>>>
>>>> Yes, H doesn't see that halting because it aborts its simulation
>>>> before it gets there, but the machine that the input represents does.
>>>>
>>>> Yes, P(P) is non-halting if H(P,P) doesn't return, but then H didn't
>>>> give the needed answer so this case is not a counter example either.
>>>>
>>>>
>>>> FAIL.
>>>>
>>>
>>>
>>
>
>