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

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.

--
Copyright 2022 Pete Olcott

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

On Mon, 25 Jul 2022 14:58:15 -0500
olcott <NoOne@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

On 7/25/2022 3:01 PM, Mr Flibble wrote:
> On Mon, 25 Jul 2022 14:58:15 -0500
> olcott <NoOne@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]

--
Copyright 2022 Pete Olcott

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

On Mon, 25 Jul 2022 15:14:21 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> > On Mon, 25 Jul 2022 14:58:15 -0500
> > olcott <NoOne@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

On 7/25/2022 3:17 PM, Mr Flibble wrote:
> On Mon, 25 Jul 2022 15:14:21 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>> olcott <NoOne@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.

--
Copyright 2022 Pete Olcott

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

On Mon, 25 Jul 2022 15:20:39 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/25/2022 3:17 PM, Mr Flibble wrote:
> > On Mon, 25 Jul 2022 15:14:21 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> >>> On Mon, 25 Jul 2022 14:58:15 -0500
> >>> olcott <NoOne@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);
}

On 7/25/2022 3:25 PM, Mr Flibble wrote:
> On Mon, 25 Jul 2022 15:20:39 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>> olcott <NoOne@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
}

--
Copyright 2022 Pete Olcott

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

On Mon, 25 Jul 2022 16:39:41 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/25/2022 3:25 PM, Mr Flibble wrote:
> > On Mon, 25 Jul 2022 15:20:39 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/25/2022 3:17 PM, Mr Flibble wrote:
> >>> On Mon, 25 Jul 2022 15:14:21 -0500
> >>> olcott <NoOne@NoWhere.com> wrote:
> >>>
> >>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
> >>>>> On Mon, 25 Jul 2022 14:58:15 -0500
> >>>>> olcott <NoOne@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

On 7/25/22 4:14 PM, olcott wrote:
> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>> On Mon, 25 Jul 2022 14:58:15 -0500
>> olcott <NoOne@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

So?

Proof by Example is a classic fallacy. The fact you bring that up just
shows you don't know the basics of logic.

H may be Infinite_Recursion right, because that isn't one of the cases
where your rule is wrong.

H gets P(P) wrong, as P(P) Halts if H(P,P) returns 0, so that CAN'T be
the right answer.

Ans, if you say H(P,P) doesn't refer to P(P) then you LIE that P is the
impossible program of the proof, as that is defined to be asking about
itself with its input, and you have shown that as the call to H(P,P).

>
> 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]
>
>

On 7/25/22 5:39 PM, olcott wrote:
> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>> On Mon, 25 Jul 2022 15:20:39 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>> olcott <NoOne@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
> }
>

Nope, just shows that H is wrong, or you have been lying about P being
the impossible program and you whole proof is just a fabrication.

Which one is it?

On 7/25/2022 4:54 PM, Mr Flibble wrote:
> On Mon, 25 Jul 2022 16:39:41 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>> olcott <NoOne@NoWhere.com> wrote:
>>>
>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>> olcott <NoOne@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.

We can see that the correctly simulated input to H(P,P) would keep
calling H(P,P) to simulate itself again and again unless H aborts this
simulation, thus the correct simulation of the input to H(P,P) cannot
possibly reach its "return" instruction and halt even if it was never
aborted.

--
Copyright 2022 Pete Olcott

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

On 7/25/22 3:58 PM, olcott 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.

Nope, not by your definition.

Halting is a function of the MACHINE, not a simulation.

Just because for all H[i](P[i],P[i]) (where P[i} calls H[i](P[i],P[i])
and does the opposite) none of these reach in their simulation a halting
state of its input, does that prove that P[i])P[i]) is non-halting.

It has been shown that for ANY P[i] where H[i](P[i],P[i]) returns 0,
that P[i](P[i]) will halt.

The only case where P[i](P[i]) doesn't halt, is the case where
H[i](P[i],P[i]) doesn't return 0, because it didn't abort its
simulation, and thus it NEVER returns an answer, so fails to be a decider.

Yes, you can replace the behavior of the machine with a UTM equivalent
simulation, but that means one that NEVER stops until it reaches a final
state. Any H that stops its simulation early doesn't show that the input
is non-halting, only the UTM equivalent simulation does, which shows
those H's to be wrong, as ANY case where H[i](P[i],P[i]) returns 0 will
cause P[i](P[i]) to reach the final state.

>
> 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.
>
>

If it doesn't stop on an incorrect pattern, then H[i](P[i],P[i]) will
never stop as there is NO finite pattern in the simulation of that input
to H[i], that if it was part of that H[i] patterns, would be a correct
halting pattern as it also makes P[i](P[i]) a halting computation.

You are making the error of assuming an answer exsits.

On 7/25/22 3:58 PM, olcott 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.

The problem is this isn't the definition of Halting. It is close and
matches for many cases, but the "impossible program" is one case where
it doesn't

If you are wrong, you are not right.

>
> 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.
>
>

The simulating halt decider has to do what it is programmed to do, and
nothing else.

Looking at what OTHER programs (the variant that doesn't halt) when
looking at that changes what is in the input, is invalid.

With Ha being the version of H that aborts, and Pa the version of P that
calls Ha, and Hn a version that doesn't abort.

Since Hn does a correct simulation, you can use Hn(Pa,Pa) to prove that
Ha(Pa,Pa) returning 0 is incorrect as Hn(Pa,Pa) will see that it halts.

On 7/25/22 8:30 PM, olcott wrote:
> On 7/25/2022 4:54 PM, Mr Flibble wrote:
>> On Mon, 25 Jul 2022 16:39:41 -0500
>> olcott <NoOne@NoWhere.com> wrote:
>>
>>> On 7/25/2022 3:25 PM, Mr Flibble wrote:
>>>> On Mon, 25 Jul 2022 15:20:39 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>> On 7/25/2022 3:17 PM, Mr Flibble wrote:
>>>>>> On Mon, 25 Jul 2022 15:14:21 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 7/25/2022 3:01 PM, Mr Flibble wrote:
>>>>>>>> On Mon, 25 Jul 2022 14:58:15 -0500
>>>>>>>> olcott <NoOne@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.
>

So, DEFINITIONS don't mean anything to you?

> 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.
>
> We can see that the correctly simulated input to H(P,P) would keep
> calling H(P,P) to simulate itself again and again unless H aborts this
> simulation, thus the correct simulation of the input to H(P,P) cannot
> possibly reach its "return" instruction and halt even if it was never
> aborted.
>

So, you "prove" your point by assuming a false condition?

Rule (3) is INVALID, you have been told this and not refuted the allegation.

Proof by example is a classical fallacy.

You are thus PROVEN to be just a pathological liar.

(And you have said what happens to liars).

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, demonstrating that H aborted too soon.

Take a look at Mike Terry's last reply in the other thread where he goes into this in much more detail.

Read his ENTIRE post, then read it again, and keep reading it until you UNDERSTAND it.

You claim that you want closure, even if you're wrong. Read that post and understand it, and you'll get your closure.

I look forward to seeing your response to his post. And if you fail to respond to it, I and everyone else here will take that as your 100% agreement with it.

>
> We can see that the correctly simulated input to H(P,P) would keep
> calling H(P,P) to simulate itself again and again unless H aborts this
> simulation, thus the correct simulation of the input to H(P,P) cannot
> possibly reach its "return" instruction and halt even if it was never
> aborted.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

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.

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 that this simulation would never
stop running.

Whether you have the capacity to understand this or not it is a verified
fact either way.

--
Copyright 2022 Pete Olcott

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

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. Pa(Pa) halts because Ha(Pa,Pa) makes an incorrect abort decision.

It's invalid to even hypothesize if the function H has a different implementation because doing so changes the input.

The input to Ha(Pa,Pa) does not represent Pn(Pn). The input to Ha(Pa,Pa) represents Pa(Pa).

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. That is not very smart on your part.
Is your SE profile fake?

void Infinite_Loop()
{ HERE: goto HERE;
}

int main()
{ Output("Input_Halts = ", H0((u32)Infinite_Loop));
}

_Infinite_Loop()
[00001102](01) 55 push ebp
[00001103](02) 8bec mov ebp,esp
[00001105](02) ebfe jmp 00001105
[00001107](01) 5d pop ebp
[00001108](01) c3 ret
Size in bytes:(0007) [00001108]

--
Copyright 2022 Pete Olcott

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

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.

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.
>

On 7/25/2022 10:13 PM, 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?
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H0((u32)Infinite_Loop));
> }
>
> _Infinite_Loop()
> [00001102](01)  55         push ebp
> [00001103](02)  8bec       mov ebp,esp
> [00001105](02)  ebfe       jmp 00001105
> [00001107](01)  5d         pop ebp
> [00001108](01)  c3         ret
> Size in bytes:(0007) [00001108]
>
>

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?

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.

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.