On 7/31/22 10:00 PM, olcott wrote:
> On 7/31/2022 8:36 PM, Richard Damon wrote:
>>
>> On 7/31/22 9:26 PM, olcott wrote:
>>> On 7/31/2022 8:07 PM, Richard Damon wrote:
>>>> On 7/31/22 8:53 PM, olcott wrote:
>>>>> On 7/31/2022 1:43 PM, Dennis Bush wrote:
>>>>>> On Sunday, July 31, 2022 at 2:40:02 PM UTC-4, olcott wrote:
>>>>>>> On 7/31/2022 1:30 PM, Richard Damon wrote:
>>>>>>>> On 7/31/22 2:11 PM, olcott wrote:
>>>>>>>>> On 7/31/2022 12:44 PM, Richard Damon wrote:
>>>>>>>>>> On 7/31/22 1:15 PM, olcott wrote:
>>>>>>>>>>> typedef void (*ptr)();
>>>>>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>     int Halt_Status = H(x, x);
>>>>>>>>>>>     if (Halt_Status)
>>>>>>>>>>>       HERE: goto HERE;
>>>>>>>>>>>     return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>     Output("Input_Halts = ", H(P, P));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Key Fact (1) When H is a simulating halt decider that correctly
>>>>>>>>>>> simulates its input with an x86 emulator, the simulation will
>>>>>>>>>>> never
>>>>>>>>>>> stop running until H(P,P) aborts its emulation of its input:
>>>>>>>>>>>
>>>>>>>>>>> (1) Executed H(P,P)  simulates its   input with an x86 emulator.
>>>>>>>>>>> (2) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>> (3) Emulated H(P,P)  simulates its   input with an x86 emulator.
>>>>>>>>>>> (4) Emulated P calls emulated H(P,P) to do this again.
>>>>>>>>>>> (5) Emulated H(P,P)  simulates its   input with an x86
>>>>>>>>>>> emulator...
>>>>>>>>>>
>>>>>>>>>> This is what happens if H doesn't abort its simulation. If H ever
>>>>>>>>>> does abort its simulation, this is NOT what happens.
>>>>>>>>>
>>>>>>>>> Good, I agree.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Note, an H that simulates until it can CORRECTLY determine
>>>>>>>>>> that its
>>>>>>>>>> input is non-halting, will match this pattern, because it will
>>>>>>>>>> NEVER
>>>>>>>>>> in finite time be able to actually correctly prove the input is
>>>>>>>>>> non-halting, as ANY pattern that is defined (incorrectly) as
>>>>>>>>>> non-halting, if it is seen by H in the simulation, and H stops
>>>>>>>>>> its
>>>>>>>>>> simulation and returns 0, causes the actual program P(P) to Halt.
>>>>>>>>>>
>>>>>>>>>> Since that is the actual meaning of the question H(P,P) if H is
>>>>>>>>>> actually a Halt Decider, that proves that H is incorrect to
>>>>>>>>>> return 0
>>>>>>>>>> from H(P,P) to say that P(P) is non-halting, since it is Halting.
>>>>>>>>>>
>>>>>>>>>> If you want to repeat you LIE that the input to H(P,P) generate a
>>>>>>>>>> different sequence of configurations that P(P), please provide
>>>>>>>>>> the
>>>>>>>>>> FIRST configuration in the sequence that is different, and is
>>>>>>>>>> actually the result of a CORRECT simulation of the input.
>>>>>>>>>>
>>>>>>>>>> Note, the implication that H(P,P) seeing a call to H(P,P) is
>>>>>>>>>> "proof"
>>>>>>>>>> that its input is non-halting is proved incorrect and invalid,
>>>>>>>>>> and
>>>>>>>>>> your "proof" of this is based on assuming it, and thus falls
>>>>>>>>>> into the
>>>>>>>>>> fallacy of the assumption of the conclusion.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Key Fact (2) Furthermore the input to H(P,P) that is correctly
>>>>>>>>>>> simulated by H cannot possibly reach its own "ret" instruction
>>>>>>>>>>> whether or not H aborts its simulation.
>>>>>>>>>>
>>>>>>>>>> No, that is only true if H doesn't abort its simuation.
>>>>>>>>>
>>>>>>>>> So you believe that when H aborts its simulation this causes the
>>>>>>>>> simulated P to reach its "ret" instruction even after it has been
>>>>>>>>> aborted before reaching this instruction?
>>>>>>>>>
>>>>>>>>> Unless you reverse your position technically competent
>>>>>>>>> reviewers will
>>>>>>>>> understand that you are not a sufficiently technically competent
>>>>>>>>> reviewer.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If H aborts its simulation, then a correct and complete
>>>>>>>>>> simulation of
>>>>>>>>>> the input will reach the return instruction.
>>>>>>>>>
>>>>>>>>> If H aborts its simulation of P then the simulated P that is no
>>>>>>>>> longer
>>>>>>>>> running will continue several more execution steps and reach
>>>>>>>>> its "ret"
>>>>>>>>> instruction even though it has been forced to stop running
>>>>>>>>> before ever
>>>>>>>>> reaching the "ret" instruction.
>>>>>>>>
>>>>>>>> No, it causes the ACTUAL P, and the correct and COMPLETE
>>>>>>>> simulation of
>>>>>>>> the input to H(P,P) to reach the return instruction.
>>>>>>> There is only a simulated P in the following:
>>>>>>> typedef void (*ptr)();
>>>>>>> int H(ptr p, ptr i); // simulating halt decider
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>> int Halt_Status = H(x, x);
>>>>>>> if (Halt_Status)
>>>>>>> HERE: goto HERE;
>>>>>>> return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(P, P));
>>>>>>> }
>>>>>>> So you agree that the input to H(P,P) that is correctly simulated
>>>>>>> by H
>>>>>>> cannot possibly reach the "ret" instruction of this simulated P
>>>>>>> whether
>>>>>>> or not H aborts its simulation or not?
>>>>>>
>>>>>> Yes, I agree that there is no implementation of the function H
>>>>>> that can simulate the function call P(P) to a final state.  Which
>>>>>> has nothing to do with the requirements of a halt decider.
>>>>>>
>>>>>> Ha(Pa,Pa)==0 is wrong by definition because Pa(Pa) halts.
>>>>>
>>>>> In other words you are saying that this is incorrect:
>>>>> A halt decider must compute the mapping from its inputs to an
>>>>> accept or reject state on the basis of the actual behavior that is
>>>>> actually specified by these inputs.
>>>>>
>>>>>
>>>>
>>>> No, just that the "Actual Behvior" is determined by the actual
>>>> behavior of the program the input represents,
>>> In other words you do not believe that the correct simulation of an
>>> input necessarily has the exact same sequence of instructions that
>>> are specified by this input, thus you reject the concept of UTM
>>> simulation.
>>>
>>
>> No. a COMPLETE and correct simulation will recreate the behavior of
>> the input. The COMPLETE part is important.
>>
>
> Not at all, as long as the partial simulation correctly matches any
> correct infinite behavior pattern then there is no need to wait until
> the end of time to see that an infinite loop never halts.
>

But the pattern is only a CORRECT infinite behavior pattern if the
PROGRAM, this is P(P), gets into infinite recursion, which it doesn't if
H(P,P) aborts its simulation.

This is the ERROR you have in your logic.

Try to PROVE that your "rule (3)" is actually correct.

We KNOW it is incorrect, as even you have admitted that P(P) Halts if
H(P,P) returns 0, so H(P,P) returning 0 must be incorrect.

Since the behavior of the input to H(P,P) MUST be the behavior of P(P)
or your P is definie incorrectly, you haven't shown what pattern you
want to match that is actually correct!

Your claimed case of if the simulaton of the input to H(P,P) sees a call
to H(P,P) with no conditionals is an incorrect rule as the simple test
that P(P) Halts if H(P,P) returns 0, so P(P) CAN'T be caught in infinite
recursion.

You claim that they behave differently is disproved by the DEFINITION
specified abort, it is what YOU had P do to ask about P(P).

You also have been unable to point to the FIRST instruction that was
correctly simulated that shows the difference.

The difference happens at the call to H, where the direct exection goes
into H (even if you trace doesn't show it, that it just a bug in your
trace code) and eventually that H returns 0, but the simulation routine
does actually simulate that code but INCORRECTLY assumes a behavior
different than what actually happens. You can decide if that is it doing
an incorrect simulation or just unsound logic on the results of the
simulation.

In either case, your H is proved to be INCORRECT, and the claim that the
input behaves differently than the machine it is a description of proven
incorrect, at least if H is supposed to be a Halt Decider.

Thus, you claim is just WRONG. H(P,P) returning 0 is INCORRECT because
P(P) Halts if H(P,P) returns 0.

Your UNSOUND argument, matching your UNSOUND mind, just doesn't
establish anything.

The right answer that a halt decider deciding on P(P) where H(P,P)
returns 0 IS accept(1), as P(P) Halts, as does a complete and correct
simulation of the input to H(P,P) (even if H doesn't do that since it
aborted it simulation too soon to return the value 0)

It doesn't matter that with a DIFFERENT decider, that you also call H,
but other call things like Hn (since it never aborts) and the P built on
that (which others call Pn because it is based on Hn) will be
non-halting because Pn(Pn) will call Hn(Pn,Pn) which will simulate
Pn(Pn) which will call Hn(Pn,Pn) ... to infinity.

The problem is that the P you are looking at (which others call Pa since
it is based oh the Ha version of your H that does abort) is Pa, and
Pa(Pa) will halt since Ha(Pa,Pa) return 0 (incorrectly) because it
confused Pa with Pn.

The confusion comes because the code for the "C Function" of Pa and Pn
are the same, the difference between the PROGRAM Pa and Pn are which
version of H they are linked with (which should have been given
different names so the code for Pa and Pn would be different).

Note, by the basic software principle of C programming, there CAN'T be
two functions by the same name in a given program, so the Ha variant of
H can NEVER just assume it is seeing a call to Hn, and thus your
"infinite simulation" rule is invalid, as that only works for Hn.