On 7/25/2022 10:43 PM, Dennis Bush wrote:
> On Monday, July 25, 2022 at 11:34:23 PM UTC-4, olcott wrote:
>> On 7/25/2022 10:15 PM, Dennis Bush wrote:
>>> On Monday, July 25, 2022 at 11:13:11 PM UTC-4, olcott wrote:
>>>> On 7/25/2022 9:59 PM, Dennis Bush wrote:
>>>>> On Monday, July 25, 2022 at 10:55:14 PM UTC-4, olcott wrote:
>>>>>> On 7/25/2022 9:42 PM, Dennis Bush wrote:
>>>>>>> On Monday, July 25, 2022 at 9:56:49 PM UTC-4, olcott wrote:
>>>>>>>> On 7/25/2022 7:51 PM, Dennis Bush wrote:
>>>>>>>>> On Monday, July 25, 2022 at 8:30:15 PM UTC-4, olcott wrote:
>>>>>>>>>> On 7/25/2022 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Mon, 25 Jul 2022 16:39:41 -0500
>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>>>>>>>>>>>> olcott <No...@NoWhere.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 7/25/2022 2:22 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> How can we help Olcott understand that his "infinite
>>>>>>>>>>>>>>>>>>> recursion" is a property of his simulating halting decider
>>>>>>>>>>>>>>>>>>> and NOT a property of the input passed to his decider? His
>>>>>>>>>>>>>>>>>>> error is compounded by him incorrectly mapping his decider's
>>>>>>>>>>>>>>>>>>> recursion to the input being non-halting.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> *People that don't comprehend that this is true*
>>>>>>>>>>>>>>>>>> *don't comprehend that I am correct*
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> In every case where the simulation would never stop unless
>>>>>>>>>>>>>>>>>> aborted a non-halting behavior pattern is specified by the
>>>>>>>>>>>>>>>>>> input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If a simulating halt decider continues to correctly simulate
>>>>>>>>>>>>>>>>>> its input until it correctly matches a non-halting behavior
>>>>>>>>>>>>>>>>>> pattern then this SHD is necessarily correct when it aborts its
>>>>>>>>>>>>>>>>>> simulation and reports non-halting.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But I have designed an SHD that has no recursion at all:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://github.com/i42output/halting-problem#readme
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> So you are wrong to claim that infinite recursion is necessary
>>>>>>>>>>>>>>>>> property for SHDs.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes you are definitely clueless on these things.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> H correctly determines that Infinite_Recursion() never halts
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void Infinite_Recursion(int N)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Infinite_Recursion(N);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> int main()
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> Output("Input_Halts = ", H((u32)Infinite_Recursion, 0x777));
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> _Infinite_Recursion()
>>>>>>>>>>>>>>>> [000010f2](01) 55 push ebp
>>>>>>>>>>>>>>>> [000010f3](02) 8bec mov ebp,esp
>>>>>>>>>>>>>>>> [000010f5](03) 8b4508 mov eax,[ebp+08]
>>>>>>>>>>>>>>>> [000010f8](01) 50 push eax
>>>>>>>>>>>>>>>> [000010f9](05) e8f4ffffff call 000010f2
>>>>>>>>>>>>>>>> [000010fe](03) 83c404 add esp,+04
>>>>>>>>>>>>>>>> [00001101](01) 5d pop ebp
>>>>>>>>>>>>>>>> [00001102](01) c3 ret
>>>>>>>>>>>>>>>> Size in bytes:(0017) [00001102]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But P isn't recursive; your H is.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In every case where the simulation would never stop unless aborted
>>>>>>>>>>>>>> a non-halting behavior pattern is specified by the input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> FALSE. The following input specifies a halting "behavior pattern":
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px()
>>>>>>>>>>>>> {
>>>>>>>>>>>>> (void)H(Px, Px);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> main()
>>>>>>>>>>>> {
>>>>>>>>>>>> H(Px,Px); // simulated input is infinitely recursive.
>>>>>>>>>>>> Px(Px); // halts
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> And there's the rub: everyone except you can see a problem there.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> Everyone besides me simply assumes that the behavior must be the same
>>>>>>>>>> while not bothering to verify that it is proven fact that the behavior
>>>>>>>>>> is not the same.
>>>>>>>>>>
>>>>>>>>>> In example 05 shown in my paper
>>>>>>>>>>
>>>>>>>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>>>>>>>
>>>>>>>>>> When we look at the line-by-line execution trace of P(P) and the
>>>>>>>>>> simulation of the input to H(P,P) we see that in both cases this exactly
>>>>>>>>>> matches the line-by-line x86 source-code listing of P.
>>>>>>>>>
>>>>>>>>> FALSE. A line-by-line comparison shows that the trace of both are *identical* up to the point where the simulation by H aborts. Then the direct execution continues past that point to a final state,
>>>>>>>> Yes that much is true.
>>>>>>>>> demonstrating that H aborted too soon.
>>>>>>>> No that is counter-factual.
>>>>>>>
>>>>>>> Not according to a UTM simulation of the same input, i.e. UTM(Pa,Pa)
>>>>>>>
>>>>>>>>
>>>>>>>> I know that you are smart enough to know that it is an easily verified
>>>>>>>> fact (for every master of the x86 language) to see that if H(P,P) never
>>>>>>>> aborted the simulation of its input
>>>>>>>
>>>>>>> Is irrelevant because it DOES abort. And because it does, there is no infinite recursion.
>>>>>> In other words you are saying there is no infinite loop because the
>>>>>> simulated infinite loop is aborted.
>>>>>
>>>>> Again, there is no simulated infinite loop. Ha thinks there is but there is not. UTM(Pa,Pa) demonstrates this fact.
>>>>>
>>>> So when H0 simulates Infinite_Loop() there is no partial simulation of
>>>> any infinite loop?
>>>
>>>
>>> The difference is that UTM(Infinite_Loop) does not halt, while UTM(Pa,Pa) does halt. That means there is no infinite loop in Pa(Pa), contrary to what Ha might think.
>> I just looked up your profile again. I was born in Orange New Jersey.
>> Your profile seems to indicate that you have great technical competence:
>>
>> "I develop primarily in C and Java, with interests in network
>> programming, encryption, network security, and multicast."
>>
>> *It does not indicate any competence with the x86 language*
>>
>> Simulate(P,P) halts
>> P(P) halts
>> H1(P,P) reports 1 for halting
>>
>> The correctly simulated input to H(P,P) does not halt only because H and
>> P have the following pathological relationship to each other:
>>
>> For any program H that might determine if programs halt, a
>> "pathological" program P, called with some input, can pass its own
>> source and its input to H and then specifically do the opposite of what
>> H predicts P will do. No H can exist that handles this case.
>> https://en.wikipedia.org/wiki/Halting_problem
>>
>> The execution trace of the correct simulation of the input to H(P,P)
>> proves that it never reaches its "return" instruction and halts whether
>> or not it is aborted.
>>
>> It seems that no one understands the x86 language well enough to see
>> this, and tries to bluff through their ignorance and claim that I am
>> incorrect anyway.
>
> You are claiming that no implementation of the function H can simulate the function P to completion.
Go back and carefully read what I said and see that I already answered
this.

--
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer