On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> On 7/27/2022 12:14 PM, Dennis Bush wrote:
> > On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> >> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>
> >>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> >>>>>
> >>>> The input passed to the decider includes a near copy of the decider
> >>>> itself. So if the decider works on the simulating principle, then
> >>>> infinitely nested simulation is a property of the system, and that's
> >>>> the way that a reasonably functional simulating decider will fail.
> >>>
> >>> This sentence is not unlike stating that if the moon is made of cheese
> >>> then halting is decidable. Or that a halt decider fails to be a halt
> >>> decider it can fail by infinitely nested simulation.
> >>>
> >>> There are no halt deciders, simulating or otherwise. Nothing about them
> >>> can be recursive or non-recursive.
> >>>
> >>>> (PO is aware of this and tries to code round it, but in fact this
> >>>> cannot be done).
> >>>
> >>> He is not aware that there are no halt deciders, and I don't think
> >>> anyone should be encouraging that misunderstanding.
> >>>
> >>>> However Linz's H_Hat doesn't require H to be a simulating halt
> >>>> decider.
> >>>
> >>> He required H to an arbitrary denote a member of an empty set.
> >>>
> >> H(P,P) does correctly determine that its correct x86 emulation of its
> >> input would never reach the C:"return" or x86:"ret" instruction of this
> >> input because this input specifies infinitely recursive simulation to H.
> >
> > The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
> >
> > The halting problem cares if Pa(Pa) halts, which it does.
> >
> > If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >
> 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
> H(P,P) does correctly determine the halt status of the above
> "pathological" input template.

No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.

If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.

On 7/27/2022 12:51 PM, Dennis Bush wrote:
> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>
>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>
>>>>>> The input passed to the decider includes a near copy of the decider
>>>>>> itself. So if the decider works on the simulating principle, then
>>>>>> infinitely nested simulation is a property of the system, and that's
>>>>>> the way that a reasonably functional simulating decider will fail.
>>>>>
>>>>> This sentence is not unlike stating that if the moon is made of cheese
>>>>> then halting is decidable. Or that a halt decider fails to be a halt
>>>>> decider it can fail by infinitely nested simulation.
>>>>>
>>>>> There are no halt deciders, simulating or otherwise. Nothing about them
>>>>> can be recursive or non-recursive.
>>>>>
>>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>>> cannot be done).
>>>>>
>>>>> He is not aware that there are no halt deciders, and I don't think
>>>>> anyone should be encouraging that misunderstanding.
>>>>>
>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>> decider.
>>>>>
>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>
>>>> H(P,P) does correctly determine that its correct x86 emulation of its
>>>> input would never reach the C:"return" or x86:"ret" instruction of this
>>>> input because this input specifies infinitely recursive simulation to H.
>>>
>>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
>>>
>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>
>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>>>
>> 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
>> H(P,P) does correctly determine the halt status of the above
>> "pathological" input template.
>
> No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
>

Because the correctly simulated input to H(P,P) specifies infinite
recursion H cannot simulate its input to the final state of this input.

> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.

If we change the subject to some entirely different sequence of
instructions like you just did then you commit the strawman deception.

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

The verified fact is that H(P,P) does correctly determine that the
correct correct correct correct
correct correct correct correct
correct correct correct correct
simulation of its input would never reach the C:"return" or x86:"ret"
instruction of this input because this input species infinite recursion
to H.

--
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 Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
> On 7/27/2022 12:51 PM, Dennis Bush wrote:
> > On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> >> On 7/27/2022 12:14 PM, Dennis Bush wrote:
> >>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> >>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> >>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>
> >>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> >>>>>>>
> >>>>>> The input passed to the decider includes a near copy of the decider
> >>>>>> itself. So if the decider works on the simulating principle, then
> >>>>>> infinitely nested simulation is a property of the system, and that's
> >>>>>> the way that a reasonably functional simulating decider will fail.
> >>>>>
> >>>>> This sentence is not unlike stating that if the moon is made of cheese
> >>>>> then halting is decidable. Or that a halt decider fails to be a halt
> >>>>> decider it can fail by infinitely nested simulation.
> >>>>>
> >>>>> There are no halt deciders, simulating or otherwise. Nothing about them
> >>>>> can be recursive or non-recursive.
> >>>>>
> >>>>>> (PO is aware of this and tries to code round it, but in fact this
> >>>>>> cannot be done).
> >>>>>
> >>>>> He is not aware that there are no halt deciders, and I don't think
> >>>>> anyone should be encouraging that misunderstanding.
> >>>>>
> >>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
> >>>>>> decider.
> >>>>>
> >>>>> He required H to an arbitrary denote a member of an empty set.
> >>>>>
> >>>> H(P,P) does correctly determine that its correct x86 emulation of its
> >>>> input would never reach the C:"return" or x86:"ret" instruction of this
> >>>> input because this input specifies infinitely recursive simulation to H.
> >>>
> >>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
> >>>
> >>> The halting problem cares if Pa(Pa) halts, which it does.
> >>>
> >>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >>>
> >> 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
> >> H(P,P) does correctly determine the halt status of the above
> >> "pathological" input template.
> >
> > No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
> >
> Because the correctly simulated input to H(P,P) specifies infinite
> recursion H cannot simulate its input to the final state of this input.

There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.

A *complete* and correct simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too soon.

> > If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> If we change the subject to some entirely different sequence of
> instructions like you just did then you commit the strawman deception.

H has a fixed algorithm. That algorithm is Ha. P has a fixed algorithm. That algorithm is Pa. It's the same set of instructions.

>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
>
> The verified fact is that H(P,P) does correctly determine that the
> correct correct correct correct
> correct correct correct correct
> correct correct correct correct
> simulation of its input would never reach the C:"return" or x86:"ret"
> instruction of this input because this input species infinite recursion
> to H.

There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.

So H / Ha is not a halt decider because it is answering the wrong question.

On Wed, 27 Jul 2022 10:51:48 -0700 (PDT)
Dennis Bush <dbush.mobile@gmail.com> wrote:

> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> > On 7/27/2022 12:14 PM, Dennis Bush wrote:
> > > On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> > >> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> > >>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > >>>
> > >>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> > >>>>>
> > >>>> The input passed to the decider includes a near copy of the
> > >>>> decider itself. So if the decider works on the simulating
> > >>>> principle, then infinitely nested simulation is a property of
> > >>>> the system, and that's the way that a reasonably functional
> > >>>> simulating decider will fail.
> > >>>
> > >>> This sentence is not unlike stating that if the moon is made of
> > >>> cheese then halting is decidable. Or that a halt decider fails
> > >>> to be a halt decider it can fail by infinitely nested
> > >>> simulation.
> > >>>
> > >>> There are no halt deciders, simulating or otherwise. Nothing
> > >>> about them can be recursive or non-recursive.
> > >>>
> > >>>> (PO is aware of this and tries to code round it, but in fact
> > >>>> this cannot be done).
> > >>>
> > >>> He is not aware that there are no halt deciders, and I don't
> > >>> think anyone should be encouraging that misunderstanding.
> > >>>
> > >>>> However Linz's H_Hat doesn't require H to be a simulating halt
> > >>>> decider.
> > >>>
> > >>> He required H to an arbitrary denote a member of an empty set.
> > >>>
> > >> H(P,P) does correctly determine that its correct x86 emulation
> > >> of its input would never reach the C:"return" or x86:"ret"
> > >> instruction of this input because this input specifies
> > >> infinitely recursive simulation to H.
> > >
> > > The halting problem doesn't care that there is no implementation
> > > of the function H that can simulate the function P to a final
> > > state.
> > >
> > > The halting problem cares if Pa(Pa) halts, which it does.
> > >
> > > If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
> > > returns 0, therefore Ha is not a halt decider.
> > 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
> > H(P,P) does correctly determine the halt status of the above
> > "pathological" input template.
>
> No, it determines that no implementation of the function H can
> simulate the function call P(P) to a final state.

Not true, my SHD can as I have solved the problem of designing a
simulating halt decider that does not rely on recursion:

https://github.com/i42output/halting-problem#readme

/Flibble

On 7/27/2022 1:19 PM, Dennis Bush wrote:
> On Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
>> On 7/27/2022 12:51 PM, Dennis Bush wrote:
>>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>
>>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>>>
>>>>>>>> The input passed to the decider includes a near copy of the decider
>>>>>>>> itself. So if the decider works on the simulating principle, then
>>>>>>>> infinitely nested simulation is a property of the system, and that's
>>>>>>>> the way that a reasonably functional simulating decider will fail.
>>>>>>>
>>>>>>> This sentence is not unlike stating that if the moon is made of cheese
>>>>>>> then halting is decidable. Or that a halt decider fails to be a halt
>>>>>>> decider it can fail by infinitely nested simulation.
>>>>>>>
>>>>>>> There are no halt deciders, simulating or otherwise. Nothing about them
>>>>>>> can be recursive or non-recursive.
>>>>>>>
>>>>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>>>>> cannot be done).
>>>>>>>
>>>>>>> He is not aware that there are no halt deciders, and I don't think
>>>>>>> anyone should be encouraging that misunderstanding.
>>>>>>>
>>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>>>> decider.
>>>>>>>
>>>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>>>
>>>>>> H(P,P) does correctly determine that its correct x86 emulation of its
>>>>>> input would never reach the C:"return" or x86:"ret" instruction of this
>>>>>> input because this input specifies infinitely recursive simulation to H.
>>>>>
>>>>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
>>>>>
>>>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>>>
>>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>>>>>
>>>> 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
>>>> H(P,P) does correctly determine the halt status of the above
>>>> "pathological" input template.
>>>
>>> No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
>>>
>> Because the correctly simulated input to H(P,P) specifies infinite
>> recursion H cannot simulate its input to the final state of this input.
>
> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
>
> A *complete* and correct simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too soon.
>
>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>> If we change the subject to some entirely different sequence of
>> instructions like you just did then you commit the strawman deception.
>
> H has a fixed algorithm. That algorithm is Ha. P has a fixed algorithm. That algorithm is Pa. It's the same set of instructions.
>
>>
>> *straw man*
>> An intentionally misrepresented proposition that is set up because it is
>> easier to defeat than an opponent's real argument.
>> https://www.lexico.com/en/definition/straw_man
>>
>> The verified fact is that H(P,P) does correctly determine that the
>> correct correct correct correct
>> correct correct correct correct
>> correct correct correct correct
>> simulation of its input would never reach the C:"return" or x86:"ret"
>> instruction of this input because this input species infinite recursion
>> to H.
>
> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
>
> So H / Ha is not a halt decider because it is answering the wrong question.

Below I show that pattern that any expert of the x86 language can spot
as specifying infinitely recursive simulation right below.

The correct x86 emulation of the input to H(P,P) by H would always cycle
through its first seven instructions of P again and again until H aborts
its simulation of P.

*You must be clueless about the x86 language to not see this*
*You must be clueless about the x86 language to not see this*
*You must be clueless about the x86 language to not see this*
*You must be clueless about the x86 language to not see this*
*You must be clueless about the x86 language to not see this*

Example 06:
H correctly determines that P() never halts (prior version of halt decider)

#include <stdint.h>
#define u32 uint32_t

#include <stdint.h>
typedef void (*ptr)();

void P(ptr x)
{ if (H(x, x))
HERE: goto HERE;
return;
}

int main()
{ Output("Input_Halts = ", H(P, P));
}

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

_main()
[00001372](01) 55 push ebp
[00001373](02) 8bec mov ebp,esp
[00001375](05) 6852130000 push 00001352 // push P
[0000137a](05) 6852130000 push 00001352 // push P
[0000137f](05) e81efeffff call 000011a2 // call H
[00001384](03) 83c408 add esp,+08
[00001387](01) 50 push eax
[00001388](05) 6823040000 push 00000423 // "Input_Halts = "
[0000138d](05) e8e0f0ffff call 00000472 // call Output
[00001392](03) 83c408 add esp,+08
[00001395](02) 33c0 xor eax,eax
[00001397](01) 5d pop ebp
[00001398](01) c3 ret
Size in bytes:(0039) [00001398]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
....[00001372][0010229e][00000000] 55 push ebp
....[00001373][0010229e][00000000] 8bec mov ebp,esp
....[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
....[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
....[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

Begin Local Halt Decider Simulation Execution Trace Stored at:212352
// H emulates the first seven instructions of P
....[00001352][0021233e][00212342] 55 push ebp // enter P
....[00001353][0021233e][00212342] 8bec mov ebp,esp
....[00001355][0021233e][00212342] 8b4508 mov eax,[ebp+08]
....[00001358][0021233a][00001352] 50 push eax // push P
....[00001359][0021233a][00001352] 8b4d08 mov ecx,[ebp+08]
....[0000135c][00212336][00001352] 51 push ecx // push P
....[0000135d][00212332][00001362] e840feffff call 000011a2 // call H

On 7/27/2022 1:40 PM, Mr Flibble wrote:
> On Wed, 27 Jul 2022 10:51:48 -0700 (PDT)
> Dennis Bush <dbush.mobile@gmail.com> wrote:
>
>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>>
>>>>>>> The input passed to the decider includes a near copy of the
>>>>>>> decider itself. So if the decider works on the simulating
>>>>>>> principle, then infinitely nested simulation is a property of
>>>>>>> the system, and that's the way that a reasonably functional
>>>>>>> simulating decider will fail.
>>>>>>
>>>>>> This sentence is not unlike stating that if the moon is made of
>>>>>> cheese then halting is decidable. Or that a halt decider fails
>>>>>> to be a halt decider it can fail by infinitely nested
>>>>>> simulation.
>>>>>>
>>>>>> There are no halt deciders, simulating or otherwise. Nothing
>>>>>> about them can be recursive or non-recursive.
>>>>>>
>>>>>>> (PO is aware of this and tries to code round it, but in fact
>>>>>>> this cannot be done).
>>>>>>
>>>>>> He is not aware that there are no halt deciders, and I don't
>>>>>> think anyone should be encouraging that misunderstanding.
>>>>>>
>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>>> decider.
>>>>>>
>>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>>
>>>>> H(P,P) does correctly determine that its correct x86 emulation
>>>>> of its input would never reach the C:"return" or x86:"ret"
>>>>> instruction of this input because this input specifies
>>>>> infinitely recursive simulation to H.
>>>>
>>>> The halting problem doesn't care that there is no implementation
>>>> of the function H that can simulate the function P to a final
>>>> state.
>>>>
>>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>>
>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
>>>> returns 0, therefore Ha is not a halt decider.
>>> 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
>>> H(P,P) does correctly determine the halt status of the above
>>> "pathological" input template.
>>
>> No, it determines that no implementation of the function H can
>> simulate the function call P(P) to a final state.
>
> Not true, my SHD can as I have solved the problem of designing a
> simulating halt decider that does not rely on recursion:
>
> https://github.com/i42output/halting-problem#readme
>
> /Flibble
>

You have a function that is called in infinite recursion return to its
caller. This is like an actual infinite loop that halts on its own after
three iterations.

--
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 Wednesday, July 27, 2022 at 2:46:26 PM UTC-4, olcott wrote:
> On 7/27/2022 1:19 PM, Dennis Bush wrote:
> > On Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
> >> On 7/27/2022 12:51 PM, Dennis Bush wrote:
> >>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> >>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
> >>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> >>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> >>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>
> >>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> >>>>>>>>>
> >>>>>>>> The input passed to the decider includes a near copy of the decider
> >>>>>>>> itself. So if the decider works on the simulating principle, then
> >>>>>>>> infinitely nested simulation is a property of the system, and that's
> >>>>>>>> the way that a reasonably functional simulating decider will fail.
> >>>>>>>
> >>>>>>> This sentence is not unlike stating that if the moon is made of cheese
> >>>>>>> then halting is decidable. Or that a halt decider fails to be a halt
> >>>>>>> decider it can fail by infinitely nested simulation.
> >>>>>>>
> >>>>>>> There are no halt deciders, simulating or otherwise. Nothing about them
> >>>>>>> can be recursive or non-recursive.
> >>>>>>>
> >>>>>>>> (PO is aware of this and tries to code round it, but in fact this
> >>>>>>>> cannot be done).
> >>>>>>>
> >>>>>>> He is not aware that there are no halt deciders, and I don't think
> >>>>>>> anyone should be encouraging that misunderstanding.
> >>>>>>>
> >>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
> >>>>>>>> decider.
> >>>>>>>
> >>>>>>> He required H to an arbitrary denote a member of an empty set.
> >>>>>>>
> >>>>>> H(P,P) does correctly determine that its correct x86 emulation of its
> >>>>>> input would never reach the C:"return" or x86:"ret" instruction of this
> >>>>>> input because this input specifies infinitely recursive simulation to H.
> >>>>>
> >>>>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
> >>>>>
> >>>>> The halting problem cares if Pa(Pa) halts, which it does.
> >>>>>
> >>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >>>>>
> >>>> 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
> >>>> H(P,P) does correctly determine the halt status of the above
> >>>> "pathological" input template.
> >>>
> >>> No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
> >>>
> >> Because the correctly simulated input to H(P,P) specifies infinite
> >> recursion H cannot simulate its input to the final state of this input..
> >
> > There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
> >
> > A *complete* and correct simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too soon.
> >
> >>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >> If we change the subject to some entirely different sequence of
> >> instructions like you just did then you commit the strawman deception.
> >
> > H has a fixed algorithm. That algorithm is Ha. P has a fixed algorithm. That algorithm is Pa. It's the same set of instructions.
> >
> >>
> >> *straw man*
> >> An intentionally misrepresented proposition that is set up because it is
> >> easier to defeat than an opponent's real argument.
> >> https://www.lexico.com/en/definition/straw_man
> >>
> >> The verified fact is that H(P,P) does correctly determine that the
> >> correct correct correct correct
> >> correct correct correct correct
> >> correct correct correct correct
> >> simulation of its input would never reach the C:"return" or x86:"ret"
> >> instruction of this input because this input species infinite recursion
> >> to H.
> >
> > There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
> >
> > So H / Ha is not a halt decider because it is answering the wrong question.
> Below I show that pattern that any expert of the x86 language can spot
> as specifying infinitely recursive simulation right below.

And your pattern is incorrect as proved by UTM(Pa,Pa) halting, and as several people have explained to you.

It's not enough that there are no instructions in the function P prior to the call to the function H that branch. There have to be no instructions *between successive calls to H* that branch, and there are *several* functions in the function H as well as other functions that it calls.

So this explains why your criteria 3 is wrong. Failure to explain why the above is wrong will be taken as admission that your criteria 3 is invalid.

>
> The correct x86 emulation of the input to H(P,P) by H would always cycle
> through its first seven instructions of P again and again until H aborts
> its simulation of P.

The correct *but not complete* emulation performed by Ha aborts too soon.

We already know that the direct execution of Pa(Pa) and the simulation performed by Ha are identical up the the point where Ha aborts. We as humans can then manually simulate the input to Ha past the point where it aborted. In doing so, we see that the instructions are identical to the continued direct execution of Pa(Pa) all the way up to where it halts. Specifically, we can see Pa call Ha, then we see the simulated Ha abort and return 0, then we see Pa halt.

You think that because no implementation of the function H can simulate the function call P(P) to a final state (which is what you mean when you say "would") that non halting is the right answer. But you're answering the wrong question.

For Ha to be a halt decider, it MUST answer whether any arbitrary algorithm will halt when given a particular input. Specifically, Ha(Pa,Pa) MUST answer whether *the machine* Pa(Pa) halts. It does not answer this correctly, so it is wrong.

On 7/27/2022 2:09 PM, Dennis Bush wrote:
> On Wednesday, July 27, 2022 at 2:46:26 PM UTC-4, olcott wrote:
>> On 7/27/2022 1:19 PM, Dennis Bush wrote:
>>> On Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
>>>> On 7/27/2022 12:51 PM, Dennis Bush wrote:
>>>>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>>>>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>>>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>>
>>>>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>>>>>
>>>>>>>>>> The input passed to the decider includes a near copy of the decider
>>>>>>>>>> itself. So if the decider works on the simulating principle, then
>>>>>>>>>> infinitely nested simulation is a property of the system, and that's
>>>>>>>>>> the way that a reasonably functional simulating decider will fail.
>>>>>>>>>
>>>>>>>>> This sentence is not unlike stating that if the moon is made of cheese
>>>>>>>>> then halting is decidable. Or that a halt decider fails to be a halt
>>>>>>>>> decider it can fail by infinitely nested simulation.
>>>>>>>>>
>>>>>>>>> There are no halt deciders, simulating or otherwise. Nothing about them
>>>>>>>>> can be recursive or non-recursive.
>>>>>>>>>
>>>>>>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>>>>>>> cannot be done).
>>>>>>>>>
>>>>>>>>> He is not aware that there are no halt deciders, and I don't think
>>>>>>>>> anyone should be encouraging that misunderstanding.
>>>>>>>>>
>>>>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>>>>>> decider.
>>>>>>>>>
>>>>>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>>>>>
>>>>>>>> H(P,P) does correctly determine that its correct x86 emulation of its
>>>>>>>> input would never reach the C:"return" or x86:"ret" instruction of this
>>>>>>>> input because this input specifies infinitely recursive simulation to H.
>>>>>>>
>>>>>>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
>>>>>>>
>>>>>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>>>>>
>>>>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>>>>>>>
>>>>>> 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
>>>>>> H(P,P) does correctly determine the halt status of the above
>>>>>> "pathological" input template.
>>>>>
>>>>> No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
>>>>>
>>>> Because the correctly simulated input to H(P,P) specifies infinite
>>>> recursion H cannot simulate its input to the final state of this input.
>>>
>>> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
>>>
>>> A *complete* and correct simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too soon.
>>>
>>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
>>>> If we change the subject to some entirely different sequence of
>>>> instructions like you just did then you commit the strawman deception.
>>>
>>> H has a fixed algorithm. That algorithm is Ha. P has a fixed algorithm. That algorithm is Pa. It's the same set of instructions.
>>>
>>>>
>>>> *straw man*
>>>> An intentionally misrepresented proposition that is set up because it is
>>>> easier to defeat than an opponent's real argument.
>>>> https://www.lexico.com/en/definition/straw_man
>>>>
>>>> The verified fact is that H(P,P) does correctly determine that the
>>>> correct correct correct correct
>>>> correct correct correct correct
>>>> correct correct correct correct
>>>> simulation of its input would never reach the C:"return" or x86:"ret"
>>>> instruction of this input because this input species infinite recursion
>>>> to H.
>>>
>>> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
>>>
>>> So H / Ha is not a halt decider because it is answering the wrong question.
>> Below I show that pattern that any expert of the x86 language can spot
>> as specifying infinitely recursive simulation right below.
>
> And your pattern is incorrect as proved by UTM(Pa,Pa) halting, and as several people have explained to you.

You know that my argument is irrefutable so you dishonestly change the
subject as your fake rebuttal.

*straw man*
An intentionally misrepresented proposition that is set up because it is
easier to defeat than an opponent's real argument.
https://www.lexico.com/en/definition/straw_man

I am referring to the sequence of instructions specified the correct x86
emulation of the input to H(P,P) by H and you incorrectly refer to an
entirely different sequence that would be correctly specified as
Simulate(P,P).

This is the last time that I respond to your dishonestly. I will
continue to glance at your replies and not respond to any of them until
you switch to the actual behavior specified the correct x86 emulation of
the input to H(P,P) by H.

--
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 Wednesday, July 27, 2022 at 3:26:04 PM UTC-4, olcott wrote:
> On 7/27/2022 2:09 PM, Dennis Bush wrote:
> > On Wednesday, July 27, 2022 at 2:46:26 PM UTC-4, olcott wrote:
> >> On 7/27/2022 1:19 PM, Dennis Bush wrote:
> >>> On Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
> >>>> On 7/27/2022 12:51 PM, Dennis Bush wrote:
> >>>>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> >>>>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
> >>>>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> >>>>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> >>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>>>>
> >>>>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> >>>>>>>>>>>
> >>>>>>>>>> The input passed to the decider includes a near copy of the decider
> >>>>>>>>>> itself. So if the decider works on the simulating principle, then
> >>>>>>>>>> infinitely nested simulation is a property of the system, and that's
> >>>>>>>>>> the way that a reasonably functional simulating decider will fail.
> >>>>>>>>>
> >>>>>>>>> This sentence is not unlike stating that if the moon is made of cheese
> >>>>>>>>> then halting is decidable. Or that a halt decider fails to be a halt
> >>>>>>>>> decider it can fail by infinitely nested simulation.
> >>>>>>>>>
> >>>>>>>>> There are no halt deciders, simulating or otherwise. Nothing about them
> >>>>>>>>> can be recursive or non-recursive.
> >>>>>>>>>
> >>>>>>>>>> (PO is aware of this and tries to code round it, but in fact this
> >>>>>>>>>> cannot be done).
> >>>>>>>>>
> >>>>>>>>> He is not aware that there are no halt deciders, and I don't think
> >>>>>>>>> anyone should be encouraging that misunderstanding.
> >>>>>>>>>
> >>>>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
> >>>>>>>>>> decider.
> >>>>>>>>>
> >>>>>>>>> He required H to an arbitrary denote a member of an empty set.
> >>>>>>>>>
> >>>>>>>> H(P,P) does correctly determine that its correct x86 emulation of its
> >>>>>>>> input would never reach the C:"return" or x86:"ret" instruction of this
> >>>>>>>> input because this input specifies infinitely recursive simulation to H.
> >>>>>>>
> >>>>>>> The halting problem doesn't care that there is no implementation of the function H that can simulate the function P to a final state.
> >>>>>>>
> >>>>>>> The halting problem cares if Pa(Pa) halts, which it does.
> >>>>>>>
> >>>>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >>>>>>>
> >>>>>> 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
> >>>>>> H(P,P) does correctly determine the halt status of the above
> >>>>>> "pathological" input template.
> >>>>>
> >>>>> No, it determines that no implementation of the function H can simulate the function call P(P) to a final state.
> >>>>>
> >>>> Because the correctly simulated input to H(P,P) specifies infinite
> >>>> recursion H cannot simulate its input to the final state of this input.
> >>>
> >>> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
> >>>
> >>> A *complete* and correct simulation of the input to Ha(Pa,Pa) is performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too soon.
> >>>
> >>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns 0, therefore Ha is not a halt decider.
> >>>> If we change the subject to some entirely different sequence of
> >>>> instructions like you just did then you commit the strawman deception.
> >>>
> >>> H has a fixed algorithm. That algorithm is Ha. P has a fixed algorithm. That algorithm is Pa. It's the same set of instructions.
> >>>
> >>>>
> >>>> *straw man*
> >>>> An intentionally misrepresented proposition that is set up because it is
> >>>> easier to defeat than an opponent's real argument.
> >>>> https://www.lexico.com/en/definition/straw_man
> >>>>
> >>>> The verified fact is that H(P,P) does correctly determine that the
> >>>> correct correct correct correct
> >>>> correct correct correct correct
> >>>> correct correct correct correct
> >>>> simulation of its input would never reach the C:"return" or x86:"ret"
> >>>> instruction of this input because this input species infinite recursion
> >>>> to H.
> >>>
> >>> There is no infinite recursion. You only think there is because no implementation of the function H can simulate the function call P(P) to a final state.
> >>>
> >>> So H / Ha is not a halt decider because it is answering the wrong question.
> >> Below I show that pattern that any expert of the x86 language can spot
> >> as specifying infinitely recursive simulation right below.
> >
> > And your pattern is incorrect as proved by UTM(Pa,Pa) halting, and as several people have explained to you.
> You know that my argument is irrefutable so you dishonestly change the
> subject as your fake rebuttal.

If that's so, why does Ha(Pa,Pa) not correctly answer whether Pa(Pa) halts as the halting problem requires it to do?

> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man
> I am referring to the sequence of instructions specified the correct x86
> emulation of the input to H(P,P) by H and you incorrectly refer to an
> entirely different sequence that would be correctly specified as
> Simulate(P,P).

It's the same sequence. You just don't want to admit it because you can't bear the though of being wrong after all this time.

The traces are the same up to the point where Ha aborts. Then if you manually trace past that point, you'll see that it's still the same all the way to the point where Pa halts.

>
> This is the last time that I respond to your dishonestly. I will
> continue to glance at your replies and not respond to any of them until
> you switch to the actual behavior specified the correct x86 emulation of
> the input to H(P,P) by H.

I noticed that you failed to explain why my description of your criteria 3 is wrong. That means you implicitly admit that it is in fact wrong. That also means that if you use it again to make your argument that you're explicitly lying.

On Wed, 27 Jul 2022 13:49:49 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/27/2022 1:40 PM, Mr Flibble wrote:
> > On Wed, 27 Jul 2022 10:51:48 -0700 (PDT)
> > Dennis Bush <dbush.mobile@gmail.com> wrote:
> >
> >> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
> >>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
> >>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
> >>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
> >>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> >>>>>>
> >>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
> >>>>>>>>
> >>>>>>> The input passed to the decider includes a near copy of the
> >>>>>>> decider itself. So if the decider works on the simulating
> >>>>>>> principle, then infinitely nested simulation is a property of
> >>>>>>> the system, and that's the way that a reasonably functional
> >>>>>>> simulating decider will fail.
> >>>>>>
> >>>>>> This sentence is not unlike stating that if the moon is made of
> >>>>>> cheese then halting is decidable. Or that a halt decider fails
> >>>>>> to be a halt decider it can fail by infinitely nested
> >>>>>> simulation.
> >>>>>>
> >>>>>> There are no halt deciders, simulating or otherwise. Nothing
> >>>>>> about them can be recursive or non-recursive.
> >>>>>>
> >>>>>>> (PO is aware of this and tries to code round it, but in fact
> >>>>>>> this cannot be done).
> >>>>>>
> >>>>>> He is not aware that there are no halt deciders, and I don't
> >>>>>> think anyone should be encouraging that misunderstanding.
> >>>>>>
> >>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
> >>>>>>> decider.
> >>>>>>
> >>>>>> He required H to an arbitrary denote a member of an empty set.
> >>>>>>
> >>>>> H(P,P) does correctly determine that its correct x86 emulation
> >>>>> of its input would never reach the C:"return" or x86:"ret"
> >>>>> instruction of this input because this input specifies
> >>>>> infinitely recursive simulation to H.
> >>>>
> >>>> The halting problem doesn't care that there is no implementation
> >>>> of the function H that can simulate the function P to a final
> >>>> state.
> >>>>
> >>>> The halting problem cares if Pa(Pa) halts, which it does.
> >>>>
> >>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
> >>>> returns 0, therefore Ha is not a halt decider.
> >>> 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
> >>> H(P,P) does correctly determine the halt status of the above
> >>> "pathological" input template.
> >>
> >> No, it determines that no implementation of the function H can
> >> simulate the function call P(P) to a final state.
> >
> > Not true, my SHD can as I have solved the problem of designing a
> > simulating halt decider that does not rely on recursion:
> >
> > https://github.com/i42output/halting-problem#readme
> >
> > /Flibble
> >
>
> You have a function that is called in infinite recursion return to
> its caller. This is like an actual infinite loop that halts on its
> own after three iterations.

Nonsense, my H can do whatever I want (returning) *within* the
simulation just as yours is doing whatever you want (aborting).

/Flibble

On 7/27/22 1:48 PM, olcott wrote:
> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>
>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>
>>>>> The input passed to the decider includes a near copy of the decider
>>>>> itself. So if the decider works on the simulating principle, then
>>>>> infinitely nested simulation is a property of the system, and that's
>>>>> the way that a reasonably functional simulating decider will fail.
>>>>
>>>> This sentence is not unlike stating that if the moon is made of cheese
>>>> then halting is decidable. Or that a halt decider fails to be a halt
>>>> decider it can fail by infinitely nested simulation.
>>>>
>>>> There are no halt deciders, simulating or otherwise. Nothing about them
>>>> can be recursive or non-recursive.
>>>>
>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>> cannot be done).
>>>>
>>>> He is not aware that there are no halt deciders, and I don't think
>>>> anyone should be encouraging that misunderstanding.
>>>>
>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>> decider.
>>>>
>>>> He required H to an arbitrary denote a member of an empty set.
>>>>
>>> H(P,P) does correctly determine that its correct x86 emulation of its
>>> input would never reach the C:"return" or x86:"ret" instruction of this
>>> input because this input specifies infinitely recursive simulation to H.
>>
>> The halting problem doesn't care that there is no implementation of
>> the function H that can simulate the function P to a final state.
>>
>> The halting problem cares if Pa(Pa) halts, which it does.
>>
>> If Ha was a halt decider, Ha(Pa,Pa) would return 1.  Ha(Pa,Pa) returns
>> 0, therefore Ha is not a halt decider.
>>
>
> 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
>
> H(P,P) does correctly determine the halt status of the above
> "pathological" input template.
>

No, it doesn't. Even YOU have agreed that P(P) will halt if H(P,P)
returns 0.

So, since H(P,P) must return 0 to be able to "correctly" do so, it must
not be correct.

You try to say that the input to H(P,P) behaves differently than P(P),
but that just says that either P is written wrong, as it used H(P,P) to
ask H about P(P), or H isn't actualy a pure function as required by the
requirements of a Decider.

On 7/27/22 2:08 PM, olcott wrote:
> On 7/27/2022 12:51 PM, Dennis Bush wrote:
>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>
>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>>
>>>>>>> The input passed to the decider includes a near copy of the decider
>>>>>>> itself. So if the decider works on the simulating principle, then
>>>>>>> infinitely nested simulation is a property of the system, and that's
>>>>>>> the way that a reasonably functional simulating decider will fail.
>>>>>>
>>>>>> This sentence is not unlike stating that if the moon is made of
>>>>>> cheese
>>>>>> then halting is decidable. Or that a halt decider fails to be a halt
>>>>>> decider it can fail by infinitely nested simulation.
>>>>>>
>>>>>> There are no halt deciders, simulating or otherwise. Nothing about
>>>>>> them
>>>>>> can be recursive or non-recursive.
>>>>>>
>>>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>>>> cannot be done).
>>>>>>
>>>>>> He is not aware that there are no halt deciders, and I don't think
>>>>>> anyone should be encouraging that misunderstanding.
>>>>>>
>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>>> decider.
>>>>>>
>>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>>
>>>>> H(P,P) does correctly determine that its correct x86 emulation of its
>>>>> input would never reach the C:"return" or x86:"ret" instruction of
>>>>> this
>>>>> input because this input specifies infinitely recursive simulation
>>>>> to H.
>>>>
>>>> The halting problem doesn't care that there is no implementation of
>>>> the function H that can simulate the function P to a final state.
>>>>
>>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>>
>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
>>>> returns 0, therefore Ha is not a halt decider.
>>>>
>>> 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
>>> H(P,P) does correctly determine the halt status of the above
>>> "pathological" input template.
>>
>> No, it determines that no implementation of the function H can
>> simulate the function call P(P) to a final state.
>>
>
> Because the correctly simulated input to H(P,P) specifies infinite
> recursion H cannot simulate its input to the final state of this input.

Nope, INVALID proof.

Been shown before. You are just prvoing your learning disability by
refusing to see it.

>
>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa) returns
>> 0, therefore Ha is not a halt decider.
>
> If we change the subject to some entirely different sequence of
> instructions like you just did then you commit the strawman deception.

Nope, YOU are looking at the wrong sequence of instructions.

H NEEDS to see the sequence in P(P), which has been PROVED to Halt if
H((P,P) returns 0. The only way that H can correctly simulate and see
something else is to see some other input, like it PRESUMES
(incorrectly) what H is.

>
> *straw man*
> An intentionally misrepresented proposition that is set up because it is
> easier to defeat than an opponent's real argument.
> https://www.lexico.com/en/definition/straw_man

Just what YOU do.

>
> The verified fact is that H(P,P) does correctly determine that the
> correct correct correct correct
> correct correct correct correct
> correct correct correct correct
> simulation of its input would never reach the C:"return" or x86:"ret"
> instruction of this input because this input species infinite recursion
> to H.
>

Nope, and being a two year old doesn't make it so.

H proves that H can't prove the correct answer, not that its answer is
correct.

You are just to ignorant to know what you are showing.

On 7/27/22 2:46 PM, olcott wrote:
> On 7/27/2022 1:19 PM, Dennis Bush wrote:
>> On Wednesday, July 27, 2022 at 2:08:36 PM UTC-4, olcott wrote:
>>> On 7/27/2022 12:51 PM, Dennis Bush wrote:
>>>> On Wednesday, July 27, 2022 at 1:48:10 PM UTC-4, olcott wrote:
>>>>> On 7/27/2022 12:14 PM, Dennis Bush wrote:
>>>>>> On Wednesday, July 27, 2022 at 1:05:33 PM UTC-4, olcott wrote:
>>>>>>> On 7/27/2022 11:41 AM, Ben Bacarisse wrote:
>>>>>>>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>>>>>>>
>>>>>>>>> On Monday, 25 July 2022 at 20:22:44 UTC+1, 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.
>>>>>>>>>>
>>>>>>>>> The input passed to the decider includes a near copy of the
>>>>>>>>> decider
>>>>>>>>> itself. So if the decider works on the simulating principle, then
>>>>>>>>> infinitely nested simulation is a property of the system, and
>>>>>>>>> that's
>>>>>>>>> the way that a reasonably functional simulating decider will fail.
>>>>>>>>
>>>>>>>> This sentence is not unlike stating that if the moon is made of
>>>>>>>> cheese
>>>>>>>> then halting is decidable. Or that a halt decider fails to be a
>>>>>>>> halt
>>>>>>>> decider it can fail by infinitely nested simulation.
>>>>>>>>
>>>>>>>> There are no halt deciders, simulating or otherwise. Nothing
>>>>>>>> about them
>>>>>>>> can be recursive or non-recursive.
>>>>>>>>
>>>>>>>>> (PO is aware of this and tries to code round it, but in fact this
>>>>>>>>> cannot be done).
>>>>>>>>
>>>>>>>> He is not aware that there are no halt deciders, and I don't think
>>>>>>>> anyone should be encouraging that misunderstanding.
>>>>>>>>
>>>>>>>>> However Linz's H_Hat doesn't require H to be a simulating halt
>>>>>>>>> decider.
>>>>>>>>
>>>>>>>> He required H to an arbitrary denote a member of an empty set.
>>>>>>>>
>>>>>>> H(P,P) does correctly determine that its correct x86 emulation of
>>>>>>> its
>>>>>>> input would never reach the C:"return" or x86:"ret" instruction
>>>>>>> of this
>>>>>>> input because this input specifies infinitely recursive
>>>>>>> simulation to H.
>>>>>>
>>>>>> The halting problem doesn't care that there is no implementation
>>>>>> of the function H that can simulate the function P to a final state.
>>>>>>
>>>>>> The halting problem cares if Pa(Pa) halts, which it does.
>>>>>>
>>>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
>>>>>> returns 0, therefore Ha is not a halt decider.
>>>>>>
>>>>> 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
>>>>> H(P,P) does correctly determine the halt status of the above
>>>>> "pathological" input template.
>>>>
>>>> No, it determines that no implementation of the function H can
>>>> simulate the function call P(P) to a final state.
>>>>
>>> Because the correctly simulated input to H(P,P) specifies infinite
>>> recursion H cannot simulate its input to the final state of this input.
>>
>> There is no infinite recursion.  You only think there is because no
>> implementation of the function H can simulate the function call P(P)
>> to a final state.
>>
>> A *complete* and correct simulation of the input to Ha(Pa,Pa) is
>> performed by UTM(Pa,Pa) which halts, demonstrating that Ha aborted too
>> soon.
>>
>>>> If Ha was a halt decider, Ha(Pa,Pa) would return 1. Ha(Pa,Pa)
>>>> returns 0, therefore Ha is not a halt decider.
>>> If we change the subject to some entirely different sequence of
>>> instructions like you just did then you commit the strawman deception.
>>
>> H has a fixed algorithm.  That algorithm is Ha.  P has a fixed
>> algorithm.  That algorithm is Pa.  It's the same set of instructions.
>>
>>>
>>> *straw man*
>>> An intentionally misrepresented proposition that is set up because it is
>>> easier to defeat than an opponent's real argument.
>>> https://www.lexico.com/en/definition/straw_man
>>>
>>> The verified fact is that H(P,P) does correctly determine that the
>>> correct correct correct correct
>>> correct correct correct correct
>>> correct correct correct correct
>>> simulation of its input would never reach the C:"return" or x86:"ret"
>>> instruction of this input because this input species infinite recursion
>>> to H.
>>
>> There is no infinite recursion.  You only think there is because no
>> implementation of the function H can simulate the function call P(P)
>> to a final state.
>>
>> So H / Ha is not a halt decider because it is answering the wrong
>> question.
>
> Below I show that pattern that any expert of the x86 language can spot
> as specifying infinitely recursive simulation right below.
>
> The correct x86 emulation of the input to H(P,P) by H would always cycle
> through its first seven instructions of P again and again until H aborts
> its simulation of P.
>
> *You must be clueless about the x86 language to not see this*
> *You must be clueless about the x86 language to not see this*
> *You must be clueless about the x86 language to not see this*
> *You must be clueless about the x86 language to not see this*
> *You must be clueless about the x86 language to not see this*

Nope, YOU doen't understand that to correctly emulate the program P you
need to correctly emulate the call to H.

Since H(P,P) has been shown to return 0, saying it is infinitely recurse
if just a LIE.

>
> Example 06:
> H correctly determines that P() never halts (prior version of halt decider)

So, Proof by example is a fallacy.

The fact you keep bringing this up just proves you don't understand even
the basic basics of logic.
>
> #include <stdint.h>
> #define u32 uint32_t
>
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
>   if (H(x, x))
>     HERE: goto HERE;
>   return;
> }
>
> int main()
> {
>   Output("Input_Halts = ", H(P, P));
> }
>
> _P()
> [00001352](01)  55              push ebp
> [00001353](02)  8bec            mov ebp,esp
> [00001355](03)  8b4508          mov eax,[ebp+08]
> [00001358](01)  50              push eax      // push P
> [00001359](03)  8b4d08          mov ecx,[ebp+08]
> [0000135c](01)  51              push ecx      // push P
> [0000135d](05)  e840feffff      call 000011a2 // call H
> [00001362](03)  83c408          add esp,+08
> [00001365](02)  85c0            test eax,eax
> [00001367](02)  7402            jz 0000136b
> [00001369](02)  ebfe            jmp 00001369
> [0000136b](01)  5d              pop ebp
> [0000136c](01)  c3              ret
> Size in bytes:(0027) [0000136c]
>
> _main()
> [00001372](01)  55              push ebp
> [00001373](02)  8bec            mov ebp,esp
> [00001375](05)  6852130000      push 00001352 // push P
> [0000137a](05)  6852130000      push 00001352 // push P
> [0000137f](05)  e81efeffff      call 000011a2 // call H
> [00001384](03)  83c408          add esp,+08
> [00001387](01)  50              push eax
> [00001388](05)  6823040000      push 00000423 // "Input_Halts = "
> [0000138d](05)  e8e0f0ffff      call 00000472 // call Output
> [00001392](03)  83c408          add esp,+08
> [00001395](02)  33c0            xor eax,eax
> [00001397](01)  5d              pop ebp
> [00001398](01)  c3              ret
> Size in bytes:(0039) [00001398]
>
>     machine   stack     stack     machine    assembly
>     address   address   data      code       language
>     ========  ========  ========  =========  =============
> ...[00001372][0010229e][00000000] 55         push ebp
> ...[00001373][0010229e][00000000] 8bec       mov ebp,esp
> ...[00001375][0010229a][00001352] 6852130000 push 00001352 // push P
> ...[0000137a][00102296][00001352] 6852130000 push 00001352 // push P
> ...[0000137f][00102292][00001384] e81efeffff call 000011a2 // call H

On 2022-07-27 18:46:17 +0000, olcott said:

> Below I show that pattern that any expert of the x86 language can spot
> as specifying infinitely recursive simulation right below.

...

> #include <stdint.h>
> #define u32 uint32_t
>
>
> #include <stdint.h>
> typedef void (*ptr)();
>
> void P(ptr x)
> {
> if (H(x, x))
> HERE: goto HERE;
> return;
> }
>
> int main()
> {
> Output("Input_Halts = ", H(P, P));
> }

That cannot be spotted as the full behaviour of H is not shown.

If the simulation by H is infinitely recursive then H never
returns and therefore H is not a halt decider.

If H always returns then it never performs an infinitely recursive
simulation and nothing in P specifies otherwise.

Mikko

On 7/28/2022 4:26 AM, Mikko wrote:
> On 2022-07-27 18:46:17 +0000, olcott said:
>
>> Below I show that pattern that any expert of the x86 language can spot
>> as specifying infinitely recursive simulation right below.
>
>  ...
>
>> #include <stdint.h>
>> #define u32 uint32_t
>>
>>
>> #include <stdint.h>
>> typedef void (*ptr)();
>>
>> void P(ptr x)
>> {
>>    if (H(x, x))
>>      HERE: goto HERE;
>>    return;
>> }
>>
>> int main()
>> {
>>    Output("Input_Halts = ", H(P, P));
>> }
>
> That cannot be spotted as the full behaviour of H is not shown.
>

The 237 pages of the behavior of H merely confirms that the simulated P
would never stop running unless H aborts its simulation of P and the
simulated P never reaches its "ret" instruction whether its simulation
has been aborted or not. Experts of the x86 language can see this
without needing to see these 237 pages.

> If the simulation by H is infinitely recursive then H never
> returns and therefore H is not a halt decider.
>

Every input that never stops running unless its simulation is aborted is
an input that specifies non-halting behavior. It can be seen from the
above code that the correctly simulated input to H(P,P) would never stop
running unless its simulation has been aborted.

> If H always returns then it never performs an infinitely recursive
> simulation and nothing in P specifies otherwise.
>
> Mikko
>

That same reasoning can be applied to this Infinite_Loop(), because H
aborts its simulation to report that Infinite_Loop() has an infinite
loop this causes Infinite_Loop() to stop running, thus according to your
faulty reasoning Infinite_Loop() is not an 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]

--
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 Thursday, July 28, 2022 at 10:52:58 AM UTC-4, olcott wrote:
> On 7/28/2022 4:26 AM, Mikko wrote:
> > On 2022-07-27 18:46:17 +0000, olcott said:
> >
> >> Below I show that pattern that any expert of the x86 language can spot
> >> as specifying infinitely recursive simulation right below.
> >
> > ...
> >
> >> #include <stdint.h>
> >> #define u32 uint32_t
> >>
> >>
> >> #include <stdint.h>
> >> typedef void (*ptr)();
> >>
> >> void P(ptr x)
> >> {
> >> if (H(x, x))
> >> HERE: goto HERE;
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> Output("Input_Halts = ", H(P, P));
> >> }
> >
> > That cannot be spotted as the full behaviour of H is not shown.
> >
> The 237 pages of the behavior of H merely confirms that the simulated P
> would never stop running unless H aborts its simulation of P and the
> simulated P never reaches its "ret" instruction whether its simulation
> has been aborted or not. Experts of the x86 language can see this
> without needing to see these 237 pages.

They confirm that there are conditional instructions between successive calls to H that can and do return in a correct and complete simulation. That's why you don't want to show them.

> > If the simulation by H is infinitely recursive then H never
> > returns and therefore H is not a halt decider.
> >
> Every input that never stops running unless its simulation is aborted is
> an input that specifies non-halting behavior. It can be seen from the
> above code that the correctly simulated input to H(P,P) would never stop
> running unless its simulation has been aborted.

So you're back to H(x,y) reporting if there exists an implementation of the function H that can simulate the function call x(y) to completion instead of reporting if the computation x(y) halts as it's required to.

> > If H always returns then it never performs an infinitely recursive
> > simulation and nothing in P specifies otherwise.
> >
> > Mikko
> >
> That same reasoning can be applied to this Infinite_Loop(), because H
> aborts its simulation to report that Infinite_Loop() has an infinite
> loop this causes Infinite_Loop() to stop running, thus according to your
> faulty reasoning Infinite_Loop() is not an infinite loop.

The difference is that directly running Infinite_Loop will not halt, while directly running P(P) will. And H(P,P) is required to report if the direct execution of P(P) halts, which it does not do.

On 7/28/2022 10:09 AM, Dennis Bush wrote:
> On Thursday, July 28, 2022 at 10:52:58 AM UTC-4, olcott wrote:
>> On 7/28/2022 4:26 AM, Mikko wrote:
>>> On 2022-07-27 18:46:17 +0000, olcott said:
>>>
>>>> Below I show that pattern that any expert of the x86 language can spot
>>>> as specifying infinitely recursive simulation right below.
>>>
>>> ...
>>>
>>>> #include <stdint.h>
>>>> #define u32 uint32_t
>>>>
>>>>
>>>> #include <stdint.h>
>>>> typedef void (*ptr)();
>>>>
>>>> void P(ptr x)
>>>> {
>>>> if (H(x, x))
>>>> HERE: goto HERE;
>>>> return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(P, P));
>>>> }
>>>
>>> That cannot be spotted as the full behaviour of H is not shown.
>>>
>> The 237 pages of the behavior of H merely confirms that the simulated P
>> would never stop running unless H aborts its simulation of P and the
>> simulated P never reaches its "ret" instruction whether its simulation
>> has been aborted or not. Experts of the x86 language can see this
>> without needing to see these 237 pages.
>
> They confirm that there are conditional instructions between successive calls to H that can and do return in a correct and complete simulation. That's why you don't want to show them.

So then you too are simply not bright enough to understand that a
function called in infinite recursion never returns to its caller.

--
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 Thursday, July 28, 2022 at 11:15:17 AM UTC-4, olcott wrote:
> On 7/28/2022 10:09 AM, Dennis Bush wrote:
> > On Thursday, July 28, 2022 at 10:52:58 AM UTC-4, olcott wrote:
> >> On 7/28/2022 4:26 AM, Mikko wrote:
> >>> On 2022-07-27 18:46:17 +0000, olcott said:
> >>>
> >>>> Below I show that pattern that any expert of the x86 language can spot
> >>>> as specifying infinitely recursive simulation right below.
> >>>
> >>> ...
> >>>
> >>>> #include <stdint.h>
> >>>> #define u32 uint32_t
> >>>>
> >>>>
> >>>> #include <stdint.h>
> >>>> typedef void (*ptr)();
> >>>>
> >>>> void P(ptr x)
> >>>> {
> >>>> if (H(x, x))
> >>>> HERE: goto HERE;
> >>>> return;
> >>>> }
> >>>>
> >>>> int main()
> >>>> {
> >>>> Output("Input_Halts = ", H(P, P));
> >>>> }
> >>>
> >>> That cannot be spotted as the full behaviour of H is not shown.
> >>>
> >> The 237 pages of the behavior of H merely confirms that the simulated P
> >> would never stop running unless H aborts its simulation of P and the
> >> simulated P never reaches its "ret" instruction whether its simulation
> >> has been aborted or not. Experts of the x86 language can see this
> >> without needing to see these 237 pages.
> >
> > They confirm that there are conditional instructions between successive calls to H that can and do return in a correct and complete simulation. That's why you don't want to show them.
> So then you too are simply not bright enough to understand that a
> function called in infinite recursion never returns to its caller.

There is no infinite recursion.

All instances of H(P,P) will return 0. H is unable to see that and aborts too soon. A correct and complete simulation of the input, i.e. UTM(P,P), proves that.

On 2022-07-28 14:52:54 +0000, olcott said:

>> If H always returns then it never performs an infinitely recursive
>> simulation and nothing in P specifies otherwise.
>>
>> Mikko
>>
>
> That same reasoning can be applied to this Infinite_Loop(), because H
> aborts its simulation to report that Infinite_Loop() has an infinite
> loop this causes Infinite_Loop() to stop running, thus according to
> your faulty reasoning Infinite_Loop() is not an infinite loop.
>
> void Infinite_Loop()
> {
> HERE: goto HERE;
> }

True, but in case of Infinite_Loop the same (and even a stronger)
conclusion can be reached with a simpler reasoning, as it it is
quite obvious that, whether H returns or not, there is no recursive
simulation in Infinite_Loop().

Mikko

On 7/28/2022 12:21 PM, Mikko wrote:
> On 2022-07-28 14:52:54 +0000, olcott said:
>
>>> If H always returns then it never performs an infinitely recursive
>>> simulation and nothing in P specifies otherwise.
>>>
>>> Mikko
>>>
>>
>> That same reasoning can be applied to this Infinite_Loop(), because H
>> aborts its simulation to report that Infinite_Loop() has an infinite
>> loop this causes Infinite_Loop() to stop running, thus according to
>> your faulty reasoning Infinite_Loop() is not an infinite loop.
>>
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>> }
>
> True, but in case of Infinite_Loop the same (and even a stronger)
> conclusion can be reached with a simpler reasoning, as it it is
> quite obvious that, whether H returns or not, there is no recursive
> simulation in Infinite_Loop().
>
> Mikko
>

(1) Infinitely Recursive simulation is one of three infinite behavior
patterns that H recognizes the other two are (2) infinite loop and (3)
infinite recursion.

H must abort its simulation to report each of these infinite behavior
patterns. It does so as soon as the behavior of the input has matches
one of these patterns.

Can you see that H correctly reports that Infinite_Loop() would never
stop running because Infinite_Loop() has an infinite loop?

Example 01:
H0 correctly determines that Infinite_Loop() never halts

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]

_main()
[00001192](01) 55 push ebp
[00001193](02) 8bec mov ebp,esp
[00001195](05) 6802110000 push 00001102
[0000119a](05) e8d3fbffff call 00000d72
[0000119f](03) 83c404 add esp,+04
[000011a2](01) 50 push eax
[000011a3](05) 68a3040000 push 000004a3
[000011a8](05) e845f3ffff call 000004f2
[000011ad](03) 83c408 add esp,+08
[000011b0](02) 33c0 xor eax,eax
[000011b2](01) 5d pop ebp
[000011b3](01) c3 ret
Size in bytes:(0034) [000011b3]

machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[00001192][00101ef8][00000000] 55 push ebp
[00001193][00101ef8][00000000] 8bec mov ebp,esp
[00001195][00101ef4][00001102] 6802110000 push 00001102
[0000119a][00101ef0][0000119f] e8d3fbffff call 00000d72

H0: Begin Simulation Execution Trace Stored at:211fac
[00001102][00211f9c][00211fa0] 55 push ebp
[00001103][00211f9c][00211fa0] 8bec mov ebp,esp
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
[00001105][00211f9c][00211fa0] ebfe jmp 00001105
H0: Infinite Loop Detected Simulation Stopped

if (current->Simplified_Opcode == JMP) // JMP
if (current->Decode_Target <= current->Address) // upward
if (traced->Address == current->Decode_Target) // to this address
if (Conditional_Branch_Count == 0) // no escape
return 1;

[0000119f][00101ef8][00000000] 83c404 add esp,+04
[000011a2][00101ef4][00000000] 50 push eax
[000011a3][00101ef0][000004a3] 68a3040000 push 000004a3
[000011a8][00101ef0][000004a3] e845f3ffff call 000004f2
Input_Halts = 0
[000011ad][00101ef8][00000000] 83c408 add esp,+08
[000011b0][00101ef8][00000000] 33c0 xor eax,eax
[000011b2][00101efc][00100000] 5d pop ebp
[000011b3][00101f00][00000004] c3 ret
Number of Instructions Executed(554) == 8 Pages

--
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/28/22 11:15 AM, olcott wrote:
> On 7/28/2022 10:09 AM, Dennis Bush wrote:
>> On Thursday, July 28, 2022 at 10:52:58 AM UTC-4, olcott wrote:
>>> On 7/28/2022 4:26 AM, Mikko wrote:
>>>> On 2022-07-27 18:46:17 +0000, olcott said:
>>>>
>>>>> Below I show that pattern that any expert of the x86 language can spot
>>>>> as specifying infinitely recursive simulation right below.
>>>>
>>>>   ...
>>>>
>>>>> #include <stdint.h>
>>>>> #define u32 uint32_t
>>>>>
>>>>>
>>>>> #include <stdint.h>
>>>>> typedef void (*ptr)();
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>     if (H(x, x))
>>>>>       HERE: goto HERE;
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", H(P, P));
>>>>> }
>>>>
>>>> That cannot be spotted as the full behaviour of H is not shown.
>>>>
>>> The 237 pages of the behavior of H merely confirms that the simulated P
>>> would never stop running unless H aborts its simulation of P and the
>>> simulated P never reaches its "ret" instruction whether its simulation
>>> has been aborted or not. Experts of the x86 language can see this
>>> without needing to see these 237 pages.
>>
>> They confirm that there are conditional instructions between
>> successive calls to H that can and do return in a correct and complete
>> simulation.  That's why you don't want to show them.
>
> So then you too are simply not bright enough to understand that a
> function called in infinite recursion never returns to its caller.
>
>

And your too dumb to realize that since H is supposed to be a decider,
it CAN'T be in the loop of an infinite recursion unless it fails to be a
decider.

YOU think of P calling a simulator.

If H is "just" a simulator, it fails to be a decider.

YOU need to decide which H you are talking about.

The H you have publishied DOES abort its simulation of P(P), and thus
this P(P) calling this H never does get into infinite recursion, it is
just that H INCORRECTLY simulates the behavior of H and thinks it does.

NOTE: your claim that it is correct, is shown to only be for the
instrucitons of the "C" function of P, NOT the full computation P(P),
and H is INCORRECT about the behavior of what a call H(P,P) does.

Your inability to see this just shows your incompetence to deal with
actual computatons or the ACTUAL behavior of computers.

On Tuesday, 26 July 2022 at 03:22:44 UTC+8, 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

olcott had studied the topic "refutation of the HP proof" for 18 years.
I think something is wrong if no one can make olcott believe the HP proof is
very solidly valid, and his proof is very bogus.

On 7/29/2022 8:18 AM, wij wrote:
> On Tuesday, 26 July 2022 at 03:22:44 UTC+8, 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
>
> olcott had studied the topic "refutation of the HP proof" for 18 years.
> I think something is wrong if no one can make olcott believe the HP proof is
> very solidly valid, and his proof is very bogus.

_P()
[00001352](01) 55 push ebp
[00001353](02) 8bec mov ebp,esp
[00001355](03) 8b4508 mov eax,[ebp+08]
[00001358](01) 50 push eax // push P
[00001359](03) 8b4d08 mov ecx,[ebp+08]
[0000135c](01) 51 push ecx // push P
[0000135d](05) e840feffff call 000011a2 // call H
[00001362](03) 83c408 add esp,+08
[00001365](02) 85c0 test eax,eax
[00001367](02) 7402 jz 0000136b
[00001369](02) ebfe jmp 00001369
[0000136b](01) 5d pop ebp
[0000136c](01) c3 ret
Size in bytes:(0027) [0000136c]

*Halt Deciding Principle* (the key element of all of my work)
Every simulating halt decider that correctly simulates its input until
it correctly predicts that this simulated input would never terminate
normally, (by reaching its final state) correctly rejects this input as
non-halting.

The above *Halt Deciding Principle* defeats the otherwise "impossible"
"pathological" input shown below:

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

H correctly determines that its correctly simulated input would never
reach the final state of this input: "ret" thus never halt even in an
infinite number of simulated steps.

--
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 Friday, 29 July 2022 at 23:20:42 UTC+8, olcott wrote:
> On 7/29/2022 8:18 AM, wij wrote:
> > On Tuesday, 26 July 2022 at 03:22:44 UTC+8, 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
> >
> > olcott had studied the topic "refutation of the HP proof" for 18 years.
> > I think something is wrong if no one can make olcott believe the HP proof is
> > very solidly valid, and his proof is very bogus.
> _P()
> [00001352](01) 55 push ebp
> [00001353](02) 8bec mov ebp,esp
> [00001355](03) 8b4508 mov eax,[ebp+08]
> [00001358](01) 50 push eax // push P
> [00001359](03) 8b4d08 mov ecx,[ebp+08]
> [0000135c](01) 51 push ecx // push P
> [0000135d](05) e840feffff call 000011a2 // call H
> [00001362](03) 83c408 add esp,+08
> [00001365](02) 85c0 test eax,eax
> [00001367](02) 7402 jz 0000136b
> [00001369](02) ebfe jmp 00001369
> [0000136b](01) 5d pop ebp
> [0000136c](01) c3 ret
> Size in bytes:(0027) [0000136c]
>
> *Halt Deciding Principle* (the key element of all of my work)
> Every simulating halt decider that correctly simulates its input until
> it correctly predicts that this simulated input would never terminate
> normally, (by reaching its final state) correctly rejects this input as
> non-halting.
>
> The above *Halt Deciding Principle* defeats the otherwise "impossible"
> "pathological" input shown below:
> 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
>
> H correctly determines that its correctly simulated input would never
> reach the final state of this input: "ret" thus never halt even in an
> infinite number of simulated steps.
> --
> Copyright 2022 Pete Olcott
>
> "Talent hits a target no one else can hit;
> Genius hits a target no one else can see."
> Arthur Schopenhauer

You said "H correctly determines that its correctly simulated input would never
reach the final state of this input ..."
So, the honest answer is: H is undecidable (never halts).
In Halt7.c, H detects certain machine codes makes H a non-pure function, lots
of problems caused by this 'criteria', to say the least.

On 7/29/2022 11:56 AM, wij wrote:
> On Friday, 29 July 2022 at 23:20:42 UTC+8, olcott wrote:
>> On 7/29/2022 8:18 AM, wij wrote:
>>> On Tuesday, 26 July 2022 at 03:22:44 UTC+8, 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
>>>
>>> olcott had studied the topic "refutation of the HP proof" for 18 years.
>>> I think something is wrong if no one can make olcott believe the HP proof is
>>> very solidly valid, and his proof is very bogus.
>> _P()
>> [00001352](01) 55 push ebp
>> [00001353](02) 8bec mov ebp,esp
>> [00001355](03) 8b4508 mov eax,[ebp+08]
>> [00001358](01) 50 push eax // push P
>> [00001359](03) 8b4d08 mov ecx,[ebp+08]
>> [0000135c](01) 51 push ecx // push P
>> [0000135d](05) e840feffff call 000011a2 // call H
>> [00001362](03) 83c408 add esp,+08
>> [00001365](02) 85c0 test eax,eax
>> [00001367](02) 7402 jz 0000136b
>> [00001369](02) ebfe jmp 00001369
>> [0000136b](01) 5d pop ebp
>> [0000136c](01) c3 ret
>> Size in bytes:(0027) [0000136c]
>>
>> *Halt Deciding Principle* (the key element of all of my work)
>> Every simulating halt decider that correctly simulates its input until
>> it correctly predicts that this simulated input would never terminate
>> normally, (by reaching its final state) correctly rejects this input as
>> non-halting.
>>
>> The above *Halt Deciding Principle* defeats the otherwise "impossible"
>> "pathological" input shown below:
>> 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
>>
>> H correctly determines that its correctly simulated input would never
>> reach the final state of this input: "ret" thus never halt even in an
>> infinite number of simulated steps.
>> --
>> Copyright 2022 Pete Olcott
>>
>> "Talent hits a target no one else can hit;
>> Genius hits a target no one else can see."
>> Arthur Schopenhauer
>
> You said "H correctly determines that its correctly simulated input would never
> reach the final state of this input ..."
> So, the honest answer is: H is undecidable (never halts).
No dumb bunny that it not what that means.

"H correctly determines that its correctly simulated input would never
reach the final state of this input ..."
because it is a freaking 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]

> In Halt7.c, H detects certain machine codes makes H a non-pure function, lots
> of problems caused by this 'criteria', to say the least.

*One thing at a time, first you must understand that this means*

"H correctly determines that its correctly simulated input would never
reach the final state of this input ..."

Mans that H correctly determine that its input is 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