On 7/24/2022 12:02 AM, Skep Dick wrote:
> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>
>>> On 7/23/22 9:12 PM, olcott wrote:
>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>
>>>>>>>
>>>>>>> Not if it is a Halt Decider.
>>>>>>
>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>>
>>>>>
>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>
>>>>
>>>> If you keep changing the subject I will block you again.
>>>>
>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>> It has been conclusively proven that the correctly simulated
>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>> reach its "return" instruction.
>>>>
>>>>
>>>
>>> So, what do you think I don't understand or accept?
>> Just say that you honestly and sincerely totally accept that
>> every single word of my above paragraph is completely true.
>
> So you just want somebody to agree with you even when you are wrong?

Example 03 of my paper proves that I am correct.
Example 03 requires understanding of the x86 language.

The infinite recursive simulation detection criteria is an adaptation of
the infinite recursion criteria. Perhaps we should start with getting
people to understand the infinite recursion detection criteria first.

int H(ptr p, ptr i)
{ p(i);
}

void P(ptr x)
{ H(x, x);
return;
}

int main()
{ H(P,P);
}

If the execution trace of function P() called by function H() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no control flow instructions between the invocation of P() and
the call to H() from P().

Then the function call from P() to H() is infinitely recursive.
The exact same pattern applies when H() invokes simulate(p,i) with an
x86 emulator.

--
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/24/2022 5:45 AM, Richard Damon wrote:
> On 7/23/22 10:13 PM, olcott wrote:
>> On 7/23/2022 9:08 PM, Richard Damon wrote:
>>> On 7/23/22 9:40 PM, olcott wrote:
>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Not if it is a Halt Decider.
>>>>>>>>
>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>>
>>>>>>
>>>>>> If you keep changing the subject I will block you again.
>>>>>>
>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>>
>>>>>
>>>>> So, what do you think I don't understand or accept?
>>>>>
>>>>
>>>> Just say that every word of my above paragraph is completely true.
>>>>
>>>>
>>>
>>> Why, can't you understand polysylabic words?
>>>
>>> And, because of some of your use of adjectives, I don't belaive it to
>>> that extend.
>>>
>>> First, you haven't provided a "conclusive proof",
>>
>> In other words the conclusive proof in Example 03 is either over your
>> head or not explained well enough or some of both.
>>
>> *Halting problem proofs refuted on the basis of software engineering* ?
>>
>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>
>>
>
> Ah, here we get to the rub.
>
> You HAVEN'T proved that the input never Halts, because Halting refers to
> the behavior of the Machine. All you have proved is that H can never
> simulate its input to see that the input halts.
>
Here is a simpler example where H merely invokes its input.

int H(ptr p, ptr i)
{ p(i);
}

void P(ptr x)
{ H(x, x);
return;
}

int main()
{ H(P,P);
}

If the execution trace of function P() called by function H() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no control flow instructions between the invocation of P() and
the call to H() from P().

Then the function call from P() to H() is infinitely recursive.
The exact same pattern applies when H() invokes simulate(p,i) with an
x86 emulator.

--
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/24/2022 7:26 AM, Mikko wrote:
> On 2022-07-23 20:33:11 +0000, olcott said:
>
>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>> The trace proves no such thing. Here is a basic of the x86 question
>>> for you, what is the first instruction executed in P(P) that differs
>>> from the correct simulation of H(P,P)?
>>
>> _P()
>> [000013c6](01)  55         push ebp               // Save Base Pointer
>> register onto the stack
>> [000013c7](02)  8bec       mov ebp,esp            // Load Base Pointer
>> with Stack Pointer
>> [000013c9](01)  51         push ecx               // Save the value of
>> ecx on the stack
>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax with
>> argument to P
>> [000013cd](01)  50         push eax               // push 2nd argument
>> to H onto the stack
>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx with
>> with argument to P
>> [000013d1](01)  51         push ecx               // push 1st argument
>> to H onto the stack
>> [000013d2](05)  e82ffdffff call 00001106          // push return
>> address on the stack; call simulated H
>> [000013d7](03)  83c408     add esp,+08            // remove call
>> arguments from stack
>> [000013da](03)  8945fc     mov [ebp-04],eax       // load Halt_Status
>> with return value from H
>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>> Halt_Status to 0
>> [000013e1](02)  7402       jz 000013e5            // if Halt_Status ==
>> 0 goto 000013e5
>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>> [000013e5](02)  8be5       mov esp,ebp            // Load Stack
>> Pointer with Base Pointer
>> [000013e7](01)  5d         pop ebp                // Restore Base
>> Pointer value from stack
>> [000013e8](01)  c3         ret                    // return to caller
>> Size in bytes:(0035) [000013e8]
>>
>> The instruction at machine address 13d7
>
> Can you prove that 13d7 is the first differeing instruction?
> In particular, that the immediately preceding instruction is
> the same?
>
> Mikko
>

I have done this fifty times.If you are not an expert in the x86
language my correct proof will simply seem like gibberish.

--
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/24/2022 5:46 AM, Richard Damon wrote:
> On 7/24/22 1:02 AM, Skep Dick wrote:
>> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>
>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>
>>>>>>>>
>>>>>>>> Not if it is a Halt Decider.
>>>>>>>
>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>> reach its "return" instruction.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>
>>>>>
>>>>> If you keep changing the subject I will block you again.
>>>>>
>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>> It has been conclusively proven that the correctly simulated
>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>> reach its "return" instruction.
>>>>>
>>>>>
>>>>
>>>> So, what do you think I don't understand or accept?
>>> Just say that you honestly and sincerely totally accept that
>>> every single word of my above paragraph is completely true.
>>
>> So you just want somebody to agree with you even when you are wrong?
>
> Yep, that seems to be what he wants.

Simply failing to understand what I say is no actual rebuttal at all.

I have to explain the proof better. In the following H merely directly
executes its input and has no conditional logic. This is simple infinite
recursion.

*The goal here is to understand that the*
*infinite recursion detection criteria is correct*

I can build on the understanding of this proof to make my other proof
easier to understand.

int H(ptr p, ptr i)
{ p(i);
}

void P(ptr x)
{ H(x, x);
return;
}

int main()
{ H(P,P);
}

If the execution trace of function P() called by function H() shows:
(1) Function H() is called twice in sequence from the same machine
address of P().
(2) With the same parameters to H().
(3) With no control flow instructions between the invocation of P() and
the call to H() from P().

Then the function call from P() to H() is infinitely recursive.
The exact same pattern applies when H() invokes simulate(p,i) with an
x86 emulator.

--
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 Sun, 24 Jul 2022 09:51:44 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/24/2022 5:45 AM, Richard Damon wrote:
> > On 7/23/22 10:13 PM, olcott wrote:
> >> On 7/23/2022 9:08 PM, Richard Damon wrote:
> >>> On 7/23/22 9:40 PM, olcott wrote:
> >>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/23/22 9:12 PM, olcott wrote:
> >>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 8:41 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>>>>>
> >>>>>>>>>
> >>>>>>>>> Not if it is a Halt Decider.
> >>>>>>>>
> >>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>>>> It has been conclusively proven that the correctly simulated
> >>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>>>> reach its "return" instruction.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> So, that isn't the halt condition, so it doesn't matter.
> >>>>>>>
> >>>>>>
> >>>>>> If you keep changing the subject I will block you again.
> >>>>>>
> >>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>> It has been conclusively proven that the correctly simulated
> >>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>> reach its "return" instruction.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> So, what do you think I don't understand or accept?
> >>>>>
> >>>>
> >>>> Just say that every word of my above paragraph is completely
> >>>> true.
> >>>>
> >>>>
> >>>
> >>> Why, can't you understand polysylabic words?
> >>>
> >>> And, because of some of your use of adjectives, I don't belaive
> >>> it to that extend.
> >>>
> >>> First, you haven't provided a "conclusive proof",
> >>
> >> In other words the conclusive proof in Example 03 is either over
> >> your head or not explained well enough or some of both.
> >>
> >> *Halting problem proofs refuted on the basis of software
> >> engineering* ?
> >>
> >> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>
> >>
> >
> > Ah, here we get to the rub.
> >
> > You HAVEN'T proved that the input never Halts, because Halting
> > refers to the behavior of the Machine. All you have proved is that
> > H can never simulate its input to see that the input halts.
> >
> Here is a simpler example where H merely invokes its input.
>
> int H(ptr p, ptr i)
> {
> p(i);
> }
>
> void P(ptr x)
> {
> H(x, x);
> return;
> }
>
> int main()
> {
> H(P,P);
> }
>
> If the execution trace of function P() called by function H() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no control flow instructions between the invocation of P()
> and the call to H() from P().
>
> Then the function call from P() to H() is infinitely recursive.
> The exact same pattern applies when H() invokes simulate(p,i) with an
> x86 emulator.

In this case P always halts so your H is incorrect to say it doesn't.
My simulating halt decider will get the answer correct in this case.

/Flibble

On 7/24/2022 9:49 AM, Mike Terry wrote:
> On 24/07/2022 13:26, Mikko wrote:
>> On 2022-07-23 20:33:11 +0000, olcott said:
>>
>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>> The trace proves no such thing. Here is a basic of the x86 question
>>>> for you, what is the first instruction executed in P(P) that differs
>>>> from the correct simulation of H(P,P)?
>>>
>>> _P()
>>> [000013c6](01)  55         push ebp               // Save Base
>>> Pointer register onto the stack
>>> [000013c7](02)  8bec       mov ebp,esp            // Load Base
>>> Pointer with Stack Pointer
>>> [000013c9](01)  51         push ecx               // Save the value
>>> of ecx on the stack
>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax with
>>> argument to P
>>> [000013cd](01)  50         push eax               // push 2nd
>>> argument to H onto the stack
>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx with
>>> with argument to P
>>> [000013d1](01)  51         push ecx               // push 1st
>>> argument to H onto the stack
>>> [000013d2](05)  e82ffdffff call 00001106          // push return
>>> address on the stack; call simulated H
>
> um, H here is not simulated, it's directly called by P.
>
>>> [000013d7](03)  83c408     add esp,+08            // remove call
>>> arguments from stack
>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load Halt_Status
>>> with return value from H
>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>> Halt_Status to 0
>>> [000013e1](02)  7402       jz 000013e5            // if Halt_Status
>>> == 0 goto 000013e5
>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>> [000013e5](02)  8be5       mov esp,ebp            // Load Stack
>>> Pointer with Base Pointer
>>> [000013e7](01)  5d         pop ebp                // Restore Base
>>> Pointer value from stack
>>> [000013e8](01)  c3         ret                    // return to caller
>>> Size in bytes:(0035) [000013e8]
>>>
>>> The instruction at machine address 13d7
>>
>> Can you prove that 13d7 is the first differeing instruction?
>> In particular, that the immediately preceding instruction is
>> the same?
>>
>> Mikko
>>
>
> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first
> call to H.  That is obviously not the last step of the computation, as
> we can see by looking at the trace of P(P) [native]:
>
> [Native P(P): summary of execution + simulations]
> P(P)
>     H(P,P)
>     [#SIMULATION...]
>     P(P)
>         H(P,P)
>     [#STOP SIMULATING]
>     H ret 0 [non-halting]
> P ret [P(P) halts]
>
> For "H simulating its input (P,P)" PO is just counting the lines above
> between "#SIMULATION..." and "#STOP SIMULATING":
>
> [H's simulation of P(P): summary of execution + simulations]
> P(P)
>     H(P,P)
> er that's it - Simulator has given up simulating!!
>
> Claiming the computations are "a different sequence of instructions" is
> completely misleading, as the sequence is exactly the same in both
> cases, other than H decides to give up simulating at an early point in
> the sequence,

That is not true. H correctly determines that its simulated P cannot
possibly ever reach machine address 13d7 even if H never stopped
simulating P.

_P()
[000013c6](01) 55 push ebp
[000013c7](02) 8bec mov ebp,esp
[000013c9](01) 51 push ecx
[000013ca](03) 8b4508 mov eax,[ebp+08]
[000013cd](01) 50 push eax
[000013ce](03) 8b4d08 mov ecx,[ebp+08]
[000013d1](01) 51 push ecx
[000013d2](05) e82ffdffff call 00001106
[000013d7](03) 83c408 add esp,+08
[000013da](03) 8945fc mov [ebp-04],eax
[000013dd](04) 837dfc00 cmp dword [ebp-04],+00
[000013e1](02) 7402 jz 000013e5
[000013e3](02) ebfe jmp 000013e3
[000013e5](02) 8be5 mov esp,ebp
[000013e7](01) 5d pop ebp
[000013e8](01) c3 ret
Size in bytes:(0035) [000013e8]

--
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 Sun, 24 Jul 2022 09:49:27 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/24/2022 12:02 AM, Skep Dick wrote:
> > On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
> >> On 7/23/2022 8:31 PM, Richard Damon wrote:
> >>>
> >>> On 7/23/22 9:12 PM, olcott wrote:
> >>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> >>>>> On 7/23/22 8:41 PM, olcott wrote:
> >>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>>>
> >>>>>>>
> >>>>>>> Not if it is a Halt Decider.
> >>>>>>
> >>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>> It has been conclusively proven that the correctly simulated
> >>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>> reach its "return" instruction.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> So, that isn't the halt condition, so it doesn't matter.
> >>>>>
> >>>>
> >>>> If you keep changing the subject I will block you again.
> >>>>
> >>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>> It has been conclusively proven that the correctly simulated
> >>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>> reach its "return" instruction.
> >>>>
> >>>>
> >>>
> >>> So, what do you think I don't understand or accept?
> >> Just say that you honestly and sincerely totally accept that
> >> every single word of my above paragraph is completely true.
> >
> > So you just want somebody to agree with you even when you are
> > wrong?
>
> Example 03 of my paper proves that I am correct.
> Example 03 requires understanding of the x86 language.
>
> The infinite recursive simulation detection criteria is an adaptation
> of the infinite recursion criteria. Perhaps we should start with
> getting people to understand the infinite recursion detection
> criteria first.
>
> int H(ptr p, ptr i)
> {
> p(i);
> }
>
> void P(ptr x)
> {
> H(x, x);
> return;
> }
>
> int main()
> {
> H(P,P);
> }
>
> If the execution trace of function P() called by function H() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no control flow instructions between the invocation of P()
> and the call to H() from P().
>
> Then the function call from P() to H() is infinitely recursive.
> The exact same pattern applies when H() invokes simulate(p,i) with an
> x86 emulator.

Nope, in this case P always halts so your H is giving an incorrect
answer.

/Flibble

On 7/24/2022 10:08 AM, Mr Flibble wrote:
> On Sun, 24 Jul 2022 09:51:44 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/24/2022 5:45 AM, Richard Damon wrote:
>>> On 7/23/22 10:13 PM, olcott wrote:
>>>> On 7/23/2022 9:08 PM, Richard Damon wrote:
>>>>> On 7/23/22 9:40 PM, olcott wrote:
>>>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not if it is a Halt Decider.
>>>>>>>>>>
>>>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>>>> reach its "return" instruction.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If you keep changing the subject I will block you again.
>>>>>>>>
>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, what do you think I don't understand or accept?
>>>>>>>
>>>>>>
>>>>>> Just say that every word of my above paragraph is completely
>>>>>> true.
>>>>>>
>>>>>>
>>>>>
>>>>> Why, can't you understand polysylabic words?
>>>>>
>>>>> And, because of some of your use of adjectives, I don't belaive
>>>>> it to that extend.
>>>>>
>>>>> First, you haven't provided a "conclusive proof",
>>>>
>>>> In other words the conclusive proof in Example 03 is either over
>>>> your head or not explained well enough or some of both.
>>>>
>>>> *Halting problem proofs refuted on the basis of software
>>>> engineering* ?
>>>>
>>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>>
>>>>
>>>
>>> Ah, here we get to the rub.
>>>
>>> You HAVEN'T proved that the input never Halts, because Halting
>>> refers to the behavior of the Machine. All you have proved is that
>>> H can never simulate its input to see that the input halts.
>>>
>> Here is a simpler example where H merely invokes its input.
>>
>> int H(ptr p, ptr i)
>> {
>> p(i);
>> }
>>
>> void P(ptr x)
>> {
>> H(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> H(P,P);
>> }
>>
>> If the execution trace of function P() called by function H() shows:
>> (1) Function H() is called twice in sequence from the same machine
>> address of P().
>> (2) With the same parameters to H().
>> (3) With no control flow instructions between the invocation of P()
>> and the call to H() from P().
>>
>> Then the function call from P() to H() is infinitely recursive.
>> The exact same pattern applies when H() invokes simulate(p,i) with an
>> x86 emulator.
>
> In this case P always halts

You have to pay attention to what I am actually saying
You have to pay attention to what I am actually saying
You have to pay attention to what I am actually saying
You have to pay attention to what I am actually saying

H merely invokes its input.
H merely invokes its input.
H merely invokes its input.
H merely invokes its input.

Thus P never halts
Thus P never halts
Thus P never halts
Thus P never halts

> so your H is incorrect to say it doesn't.
> My simulating halt decider will get the answer correct in this case.
>
> /Flibble
>

--
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 Sunday, July 24, 2022 at 11:08:31 AM UTC-4, olcott wrote:
> On 7/24/2022 9:49 AM, Mike Terry wrote:
> > On 24/07/2022 13:26, Mikko wrote:
> >> On 2022-07-23 20:33:11 +0000, olcott said:
> >>
> >>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>> The trace proves no such thing. Here is a basic of the x86 question
> >>>> for you, what is the first instruction executed in P(P) that differs
> >>>> from the correct simulation of H(P,P)?
> >>>
> >>> _P()
> >>> [000013c6](01) 55 push ebp // Save Base
> >>> Pointer register onto the stack
> >>> [000013c7](02) 8bec mov ebp,esp // Load Base
> >>> Pointer with Stack Pointer
> >>> [000013c9](01) 51 push ecx // Save the value
> >>> of ecx on the stack
> >>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with
> >>> argument to P
> >>> [000013cd](01) 50 push eax // push 2nd
> >>> argument to H onto the stack
> >>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with
> >>> with argument to P
> >>> [000013d1](01) 51 push ecx // push 1st
> >>> argument to H onto the stack
> >>> [000013d2](05) e82ffdffff call 00001106 // push return
> >>> address on the stack; call simulated H
> >
> > um, H here is not simulated, it's directly called by P.
> >
> >>> [000013d7](03) 83c408 add esp,+08 // remove call
> >>> arguments from stack
> >>> [000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status
> >>> with return value from H
> >>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
> >>> Halt_Status to 0
> >>> [000013e1](02) 7402 jz 000013e5 // if Halt_Status
> >>> == 0 goto 000013e5
> >>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
> >>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
> >>> Pointer with Base Pointer
> >>> [000013e7](01) 5d pop ebp // Restore Base
> >>> Pointer value from stack
> >>> [000013e8](01) c3 ret // return to caller
> >>> Size in bytes:(0035) [000013e8]
> >>>
> >>> The instruction at machine address 13d7
> >>
> >> Can you prove that 13d7 is the first differeing instruction?
> >> In particular, that the immediately preceding instruction is
> >> the same?
> >>
> >> Mikko
> >>
> >
> > In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first
> > call to H. That is obviously not the last step of the computation, as
> > we can see by looking at the trace of P(P) [native]:
> >
> > [Native P(P): summary of execution + simulations]
> > P(P)
> > H(P,P)
> > [#SIMULATION...]
> > P(P)
> > H(P,P)
> > [#STOP SIMULATING]
> > H ret 0 [non-halting]
> > P ret [P(P) halts]
> >
> > For "H simulating its input (P,P)" PO is just counting the lines above
> > between "#SIMULATION..." and "#STOP SIMULATING":
> >
> > [H's simulation of P(P): summary of execution + simulations]
> > P(P)
> > H(P,P)
> > er that's it - Simulator has given up simulating!!
> >
> > Claiming the computations are "a different sequence of instructions" is
> > completely misleading, as the sequence is exactly the same in both
> > cases, other than H decides to give up simulating at an early point in
> > the sequence,
> That is not true. H correctly determines that its simulated P cannot
> possibly ever reach machine address 13d7 even if H never stopped
> simulating P.

Remember, the halting problem is about algorithms, not functions. There is no "if H never stopped simulating" because the algorithm of H is fixed, i.e. Ha. So the above is actually saying:

That is not true. Ha correctly determines that its simulated Pa cannot
possibly ever reach machine address 13d7 even if Hn never stopped
simulating Pn.

See how ridiculous that sounds?

The function H can't be changed without changing what it is deciding on, so H / Ha is permanently fixed and immutable, as is P / Pa.

Ha(Pa,Pa)==0 is wrong because Pa(Pa) halts. Your infinite recursion criteria is flawed because it generates a false positive for Pa(Pa).

On Sunday, 24 July 2022 at 17:08:31 UTC+2, olcott wrote:
> That is not true. H correctly determines that its simulated P cannot
> possibly ever reach machine address 13d7 even if H never stopped
> simulating P.
> _P()
> [000013c6](01) 55 push ebp
> [000013c7](02) 8bec mov ebp,esp
> [000013c9](01) 51 push ecx
> [000013ca](03) 8b4508 mov eax,[ebp+08]
> [000013cd](01) 50 push eax
> [000013ce](03) 8b4d08 mov ecx,[ebp+08]
> [000013d1](01) 51 push ecx
> [000013d2](05) e82ffdffff call 00001106
> [000013d7](03) 83c408 add esp,+08
> [000013da](03) 8945fc mov [ebp-04],eax
> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00
> [000013e1](02) 7402 jz 000013e5
> [000013e3](02) ebfe jmp 000013e3
> [000013e5](02) 8be5 mov esp,ebp
> [000013e7](01) 5d pop ebp
> [000013e8](01) c3 ret

Of course the simulated P can reach 13d7.
Any execution which skips over 000013e3 (the infinite loop) would get to 13d7
When would we skip over 000013e3? When this test passes: [000013e1](02) 7402 jz 000013e5
When would that test pass? Whenever the zero-flag in the CPU is set.

https://en.wikipedia.org/wiki/Zero_flag

On 7/24/2022 10:17 AM, Dennis Bush wrote:
> On Sunday, July 24, 2022 at 11:08:31 AM UTC-4, olcott wrote:
>> On 7/24/2022 9:49 AM, Mike Terry wrote:
>>> On 24/07/2022 13:26, Mikko wrote:
>>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>>
>>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>>> The trace proves no such thing. Here is a basic of the x86 question
>>>>>> for you, what is the first instruction executed in P(P) that differs
>>>>>> from the correct simulation of H(P,P)?
>>>>>
>>>>> _P()
>>>>> [000013c6](01) 55 push ebp // Save Base
>>>>> Pointer register onto the stack
>>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
>>>>> Pointer with Stack Pointer
>>>>> [000013c9](01) 51 push ecx // Save the value
>>>>> of ecx on the stack
>>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with
>>>>> argument to P
>>>>> [000013cd](01) 50 push eax // push 2nd
>>>>> argument to H onto the stack
>>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with
>>>>> with argument to P
>>>>> [000013d1](01) 51 push ecx // push 1st
>>>>> argument to H onto the stack
>>>>> [000013d2](05) e82ffdffff call 00001106 // push return
>>>>> address on the stack; call simulated H
>>>
>>> um, H here is not simulated, it's directly called by P.
>>>
>>>>> [000013d7](03) 83c408 add esp,+08 // remove call
>>>>> arguments from stack
>>>>> [000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status
>>>>> with return value from H
>>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
>>>>> Halt_Status to 0
>>>>> [000013e1](02) 7402 jz 000013e5 // if Halt_Status
>>>>> == 0 goto 000013e5
>>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
>>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
>>>>> Pointer with Base Pointer
>>>>> [000013e7](01) 5d pop ebp // Restore Base
>>>>> Pointer value from stack
>>>>> [000013e8](01) c3 ret // return to caller
>>>>> Size in bytes:(0035) [000013e8]
>>>>>
>>>>> The instruction at machine address 13d7
>>>>
>>>> Can you prove that 13d7 is the first differeing instruction?
>>>> In particular, that the immediately preceding instruction is
>>>> the same?
>>>>
>>>> Mikko
>>>>
>>>
>>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first
>>> call to H. That is obviously not the last step of the computation, as
>>> we can see by looking at the trace of P(P) [native]:
>>>
>>> [Native P(P): summary of execution + simulations]
>>> P(P)
>>> H(P,P)
>>> [#SIMULATION...]
>>> P(P)
>>> H(P,P)
>>> [#STOP SIMULATING]
>>> H ret 0 [non-halting]
>>> P ret [P(P) halts]
>>>
>>> For "H simulating its input (P,P)" PO is just counting the lines above
>>> between "#SIMULATION..." and "#STOP SIMULATING":
>>>
>>> [H's simulation of P(P): summary of execution + simulations]
>>> P(P)
>>> H(P,P)
>>> er that's it - Simulator has given up simulating!!
>>>
>>> Claiming the computations are "a different sequence of instructions" is
>>> completely misleading, as the sequence is exactly the same in both
>>> cases, other than H decides to give up simulating at an early point in
>>> the sequence,
>> That is not true. H correctly determines that its simulated P cannot
>> possibly ever reach machine address 13d7 even if H never stopped
>> simulating P.
>
> Remember, the halting problem is about algorithms, not functions. There is no "if H never stopped simulating" because the algorithm of H is fixed,

None-the-less H does correctly determine that in the hypothetical case
where it never stopped simulating its input that its input would never
reach machine address 13d7.

The same process operates here:

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]

H correctly determines that if it never stopped simulating
Infinite_Loop() that Infinite_Loop() would never reach its machine
address 1108.

--
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 Sunday, 24 July 2022 at 16:49:36 UTC+2, olcott wrote:
> On 7/24/2022 12:02 AM, Skep Dick wrote:
> > On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
> >> On 7/23/2022 8:31 PM, Richard Damon wrote:
> >>>
> >>> On 7/23/22 9:12 PM, olcott wrote:
> >>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> >>>>> On 7/23/22 8:41 PM, olcott wrote:
> >>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>>>
> >>>>>>>
> >>>>>>> Not if it is a Halt Decider.
> >>>>>>
> >>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>> It has been conclusively proven that the correctly simulated
> >>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>> reach its "return" instruction.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> So, that isn't the halt condition, so it doesn't matter.
> >>>>>
> >>>>
> >>>> If you keep changing the subject I will block you again.
> >>>>
> >>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>> It has been conclusively proven that the correctly simulated
> >>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>> reach its "return" instruction.
> >>>>
> >>>>
> >>>
> >>> So, what do you think I don't understand or accept?
> >> Just say that you honestly and sincerely totally accept that
> >> every single word of my above paragraph is completely true.
> >
> > So you just want somebody to agree with you even when you are wrong?
> Example 03 of my paper proves that I am correct.
> Example 03 requires understanding of the x86 language.

The language is immaterial. A compiler doesn't change the semantics of your function - it only changes the syntax.
You are just confusing yourself over different representations of the same function.

On Sun, 24 Jul 2022 10:10:53 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/24/2022 10:08 AM, Mr Flibble wrote:
> > On Sun, 24 Jul 2022 09:51:44 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/24/2022 5:45 AM, Richard Damon wrote:
> >>> On 7/23/22 10:13 PM, olcott wrote:
> >>>> On 7/23/2022 9:08 PM, Richard Damon wrote:
> >>>>> On 7/23/22 9:40 PM, olcott wrote:
> >>>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
> >>>>>>>
> >>>>>>> On 7/23/22 9:12 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> >>>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
> >>>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Not if it is a Halt Decider.
> >>>>>>>>>>
> >>>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>>>>>> It has been conclusively proven that the correctly
> >>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> >>>>>>>>>> possibly reach its "return" instruction.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> So, that isn't the halt condition, so it doesn't matter.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> If you keep changing the subject I will block you again.
> >>>>>>>>
> >>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>>>> It has been conclusively proven that the correctly simulated
> >>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>>>> reach its "return" instruction.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> So, what do you think I don't understand or accept?
> >>>>>>>
> >>>>>>
> >>>>>> Just say that every word of my above paragraph is completely
> >>>>>> true.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> Why, can't you understand polysylabic words?
> >>>>>
> >>>>> And, because of some of your use of adjectives, I don't belaive
> >>>>> it to that extend.
> >>>>>
> >>>>> First, you haven't provided a "conclusive proof",
> >>>>
> >>>> In other words the conclusive proof in Example 03 is either over
> >>>> your head or not explained well enough or some of both.
> >>>>
> >>>> *Halting problem proofs refuted on the basis of software
> >>>> engineering* ?
> >>>>
> >>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> >>>>
> >>>>
> >>>
> >>> Ah, here we get to the rub.
> >>>
> >>> You HAVEN'T proved that the input never Halts, because Halting
> >>> refers to the behavior of the Machine. All you have proved is that
> >>> H can never simulate its input to see that the input halts.
> >>>
> >> Here is a simpler example where H merely invokes its input.
> >>
> >> int H(ptr p, ptr i)
> >> {
> >> p(i);
> >> }
> >>
> >> void P(ptr x)
> >> {
> >> H(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> H(P,P);
> >> }
> >>
> >> If the execution trace of function P() called by function H()
> >> shows: (1) Function H() is called twice in sequence from the same
> >> machine address of P().
> >> (2) With the same parameters to H().
> >> (3) With no control flow instructions between the invocation of P()
> >> and the call to H() from P().
> >>
> >> Then the function call from P() to H() is infinitely recursive.
> >> The exact same pattern applies when H() invokes simulate(p,i) with
> >> an x86 emulator.
> >
> > In this case P always halts
>
> You have to pay attention to what I am actually saying
> You have to pay attention to what I am actually saying
> You have to pay attention to what I am actually saying
> You have to pay attention to what I am actually saying
>
> H merely invokes its input.
> H merely invokes its input.
> H merely invokes its input.
> H merely invokes its input.
>
> Thus P never halts
> Thus P never halts
> Thus P never halts
> Thus P never halts

Nope, in this case P always halts so your H is incorrect to say it
doesn't. My simulating halt decider will get the answer correct in this
case.

/Flibble

On 7/24/2022 10:09 AM, Mr Flibble wrote:
> On Sun, 24 Jul 2022 09:49:27 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
>> On 7/24/2022 12:02 AM, Skep Dick wrote:
>>> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Not if it is a Halt Decider.
>>>>>>>>
>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>>
>>>>>>
>>>>>> If you keep changing the subject I will block you again.
>>>>>>
>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>>
>>>>>
>>>>> So, what do you think I don't understand or accept?
>>>> Just say that you honestly and sincerely totally accept that
>>>> every single word of my above paragraph is completely true.
>>>
>>> So you just want somebody to agree with you even when you are
>>> wrong?
>>
>> Example 03 of my paper proves that I am correct.
>> Example 03 requires understanding of the x86 language.
>>
>> The infinite recursive simulation detection criteria is an adaptation
>> of the infinite recursion criteria. Perhaps we should start with
>> getting people to understand the infinite recursion detection
>> criteria first.
>>
>> int H(ptr p, ptr i)
>> {
>> p(i);
>> }
>>
>> void P(ptr x)
>> {
>> H(x, x);
>> return;
>> }
>>
>> int main()
>> {
>> H(P,P);
>> }
>>
>> If the execution trace of function P() called by function H() shows:
>> (1) Function H() is called twice in sequence from the same machine
>> address of P().
>> (2) With the same parameters to H().
>> (3) With no control flow instructions between the invocation of P()
>> and the call to H() from P().
>>
>> Then the function call from P() to H() is infinitely recursive.
>> The exact same pattern applies when H() invokes simulate(p,i) with an
>> x86 emulator.
>
> Nope, in this case P always halts so your H is giving an incorrect
> answer.
>
> /Flibble
>

If you are saying that the above P always halts then your understanding
of C is woefully terrible. In the above case neither P nor H ever halt.

--
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 Sunday, July 24, 2022 at 11:36:53 AM UTC-4, olcott wrote:
> On 7/24/2022 10:17 AM, Dennis Bush wrote:
> > On Sunday, July 24, 2022 at 11:08:31 AM UTC-4, olcott wrote:
> >> On 7/24/2022 9:49 AM, Mike Terry wrote:
> >>> On 24/07/2022 13:26, Mikko wrote:
> >>>> On 2022-07-23 20:33:11 +0000, olcott said:
> >>>>
> >>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
> >>>>>> The trace proves no such thing. Here is a basic of the x86 question
> >>>>>> for you, what is the first instruction executed in P(P) that differs
> >>>>>> from the correct simulation of H(P,P)?
> >>>>>
> >>>>> _P()
> >>>>> [000013c6](01) 55 push ebp // Save Base
> >>>>> Pointer register onto the stack
> >>>>> [000013c7](02) 8bec mov ebp,esp // Load Base
> >>>>> Pointer with Stack Pointer
> >>>>> [000013c9](01) 51 push ecx // Save the value
> >>>>> of ecx on the stack
> >>>>> [000013ca](03) 8b4508 mov eax,[ebp+08] // Load eax with
> >>>>> argument to P
> >>>>> [000013cd](01) 50 push eax // push 2nd
> >>>>> argument to H onto the stack
> >>>>> [000013ce](03) 8b4d08 mov ecx,[ebp+08] // Load ecx with
> >>>>> with argument to P
> >>>>> [000013d1](01) 51 push ecx // push 1st
> >>>>> argument to H onto the stack
> >>>>> [000013d2](05) e82ffdffff call 00001106 // push return
> >>>>> address on the stack; call simulated H
> >>>
> >>> um, H here is not simulated, it's directly called by P.
> >>>
> >>>>> [000013d7](03) 83c408 add esp,+08 // remove call
> >>>>> arguments from stack
> >>>>> [000013da](03) 8945fc mov [ebp-04],eax // load Halt_Status
> >>>>> with return value from H
> >>>>> [000013dd](04) 837dfc00 cmp dword [ebp-04],+00 // compare
> >>>>> Halt_Status to 0
> >>>>> [000013e1](02) 7402 jz 000013e5 // if Halt_Status
> >>>>> == 0 goto 000013e5
> >>>>> [000013e3](02) ebfe jmp 000013e3 // goto 13e3
> >>>>> [000013e5](02) 8be5 mov esp,ebp // Load Stack
> >>>>> Pointer with Base Pointer
> >>>>> [000013e7](01) 5d pop ebp // Restore Base
> >>>>> Pointer value from stack
> >>>>> [000013e8](01) c3 ret // return to caller
> >>>>> Size in bytes:(0035) [000013e8]
> >>>>>
> >>>>> The instruction at machine address 13d7
> >>>>
> >>>> Can you prove that 13d7 is the first differeing instruction?
> >>>> In particular, that the immediately preceding instruction is
> >>>> the same?
> >>>>
> >>>> Mikko
> >>>>
> >>>
> >>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first
> >>> call to H. That is obviously not the last step of the computation, as
> >>> we can see by looking at the trace of P(P) [native]:
> >>>
> >>> [Native P(P): summary of execution + simulations]
> >>> P(P)
> >>> H(P,P)
> >>> [#SIMULATION...]
> >>> P(P)
> >>> H(P,P)
> >>> [#STOP SIMULATING]
> >>> H ret 0 [non-halting]
> >>> P ret [P(P) halts]
> >>>
> >>> For "H simulating its input (P,P)" PO is just counting the lines above
> >>> between "#SIMULATION..." and "#STOP SIMULATING":
> >>>
> >>> [H's simulation of P(P): summary of execution + simulations]
> >>> P(P)
> >>> H(P,P)
> >>> er that's it - Simulator has given up simulating!!
> >>>
> >>> Claiming the computations are "a different sequence of instructions" is
> >>> completely misleading, as the sequence is exactly the same in both
> >>> cases, other than H decides to give up simulating at an early point in
> >>> the sequence,
> >> That is not true. H correctly determines that its simulated P cannot
> >> possibly ever reach machine address 13d7 even if H never stopped
> >> simulating P.
> >
> > Remember, the halting problem is about algorithms, not functions. There is no "if H never stopped simulating" because the algorithm of H is fixed,
> None-the-less

No, not "none-the-less". Because your H decides on C functions, not algorithms, it has nothing to do with the halting problem.

The halting function maps Pa(Pa) to halting. Ha(Pa,Pa)==0 therefore Ha does not map the halting function and is not a halt decider.

On Sun, 24 Jul 2022 10:40:38 -0500
olcott <NoOne@NoWhere.com> wrote:

> On 7/24/2022 10:09 AM, Mr Flibble wrote:
> > On Sun, 24 Jul 2022 09:49:27 -0500
> > olcott <NoOne@NoWhere.com> wrote:
> >
> >> On 7/24/2022 12:02 AM, Skep Dick wrote:
> >>> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
> >>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
> >>>>>
> >>>>> On 7/23/22 9:12 PM, olcott wrote:
> >>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> >>>>>>> On 7/23/22 8:41 PM, olcott wrote:
> >>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> >>>>>>
> >>>>>>>>>
> >>>>>>>>> Not if it is a Halt Decider.
> >>>>>>>>
> >>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>>>> It has been conclusively proven that the correctly simulated
> >>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>>>> reach its "return" instruction.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> So, that isn't the halt condition, so it doesn't matter.
> >>>>>>>
> >>>>>>
> >>>>>> If you keep changing the subject I will block you again.
> >>>>>>
> >>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> >>>>>> It has been conclusively proven that the correctly simulated
> >>>>>> input to H(P,P) correctly simulated by H cannot possibly
> >>>>>> reach its "return" instruction.
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> So, what do you think I don't understand or accept?
> >>>> Just say that you honestly and sincerely totally accept that
> >>>> every single word of my above paragraph is completely true.
> >>>
> >>> So you just want somebody to agree with you even when you are
> >>> wrong?
> >>
> >> Example 03 of my paper proves that I am correct.
> >> Example 03 requires understanding of the x86 language.
> >>
> >> The infinite recursive simulation detection criteria is an
> >> adaptation of the infinite recursion criteria. Perhaps we should
> >> start with getting people to understand the infinite recursion
> >> detection criteria first.
> >>
> >> int H(ptr p, ptr i)
> >> {
> >> p(i);
> >> }
> >>
> >> void P(ptr x)
> >> {
> >> H(x, x);
> >> return;
> >> }
> >>
> >> int main()
> >> {
> >> H(P,P);
> >> }
> >>
> >> If the execution trace of function P() called by function H()
> >> shows: (1) Function H() is called twice in sequence from the same
> >> machine address of P().
> >> (2) With the same parameters to H().
> >> (3) With no control flow instructions between the invocation of P()
> >> and the call to H() from P().
> >>
> >> Then the function call from P() to H() is infinitely recursive.
> >> The exact same pattern applies when H() invokes simulate(p,i) with
> >> an x86 emulator.
> >
> > Nope, in this case P always halts so your H is giving an incorrect
> > answer.
> >
> > /Flibble
> >
>
> If you are saying that the above P always halts then your
> understanding of C is woefully terrible. In the above case neither P
> nor H ever halt.
>

Oh, I didn't spot your new definition of H. Yes obviously this is
infinitely recursive so H is invalid (for the same reason your real H
is) so I cannot see the point of your post.

/Flibble

On Sun, 24 Jul 2022 16:40:14 +0100
Mr Flibble <flibble@reddwarf.jmc.corp> wrote:

> On Sun, 24 Jul 2022 10:10:53 -0500
> olcott <NoOne@NoWhere.com> wrote:
>
> > On 7/24/2022 10:08 AM, Mr Flibble wrote:
> > > On Sun, 24 Jul 2022 09:51:44 -0500
> > > olcott <NoOne@NoWhere.com> wrote:
> > >
> > >> On 7/24/2022 5:45 AM, Richard Damon wrote:
> > >>> On 7/23/22 10:13 PM, olcott wrote:
> > >>>> On 7/23/2022 9:08 PM, Richard Damon wrote:
> > >>>>> On 7/23/22 9:40 PM, olcott wrote:
> > >>>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
> > >>>>>>>
> > >>>>>>> On 7/23/22 9:12 PM, olcott wrote:
> > >>>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> > >>>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
> > >>>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> > >>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Not if it is a Halt Decider.
> > >>>>>>>>>>
> > >>>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> > >>>>>>>>>> It has been conclusively proven that the correctly
> > >>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> > >>>>>>>>>> possibly reach its "return" instruction.
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> So, that isn't the halt condition, so it doesn't matter.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> If you keep changing the subject I will block you again.
> > >>>>>>>>
> > >>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> > >>>>>>>> It has been conclusively proven that the correctly
> > >>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> > >>>>>>>> possibly reach its "return" instruction.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> So, what do you think I don't understand or accept?
> > >>>>>>>
> > >>>>>>
> > >>>>>> Just say that every word of my above paragraph is completely
> > >>>>>> true.
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>> Why, can't you understand polysylabic words?
> > >>>>>
> > >>>>> And, because of some of your use of adjectives, I don't
> > >>>>> belaive it to that extend.
> > >>>>>
> > >>>>> First, you haven't provided a "conclusive proof",
> > >>>>
> > >>>> In other words the conclusive proof in Example 03 is either
> > >>>> over your head or not explained well enough or some of both.
> > >>>>
> > >>>> *Halting problem proofs refuted on the basis of software
> > >>>> engineering* ?
> > >>>>
> > >>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> > >>>>
> > >>>>
> > >>>
> > >>> Ah, here we get to the rub.
> > >>>
> > >>> You HAVEN'T proved that the input never Halts, because Halting
> > >>> refers to the behavior of the Machine. All you have proved is
> > >>> that H can never simulate its input to see that the input halts.
> > >>>
> > >> Here is a simpler example where H merely invokes its input.
> > >>
> > >> int H(ptr p, ptr i)
> > >> {
> > >> p(i);
> > >> }
> > >>
> > >> void P(ptr x)
> > >> {
> > >> H(x, x);
> > >> return;
> > >> }
> > >>
> > >> int main()
> > >> {
> > >> H(P,P);
> > >> }
> > >>
> > >> If the execution trace of function P() called by function H()
> > >> shows: (1) Function H() is called twice in sequence from the same
> > >> machine address of P().
> > >> (2) With the same parameters to H().
> > >> (3) With no control flow instructions between the invocation of
> > >> P() and the call to H() from P().
> > >>
> > >> Then the function call from P() to H() is infinitely recursive.
> > >> The exact same pattern applies when H() invokes simulate(p,i)
> > >> with an x86 emulator.
> > >
> > > In this case P always halts
> >
> > You have to pay attention to what I am actually saying
> > You have to pay attention to what I am actually saying
> > You have to pay attention to what I am actually saying
> > You have to pay attention to what I am actually saying
> >
> > H merely invokes its input.
> > H merely invokes its input.
> > H merely invokes its input.
> > H merely invokes its input.
> >
> > Thus P never halts
> > Thus P never halts
> > Thus P never halts
> > Thus P never halts
>
> Nope, in this case P always halts so your H is incorrect to say it
> doesn't. My simulating halt decider will get the answer correct in
> this case.

Ah yes, I didn't spot you explicit definition of H which is indeed
infinitely recursive so is just as incorrect as your actual H.

/Flibble

On Sunday, July 24, 2022 at 11:45:48 AM UTC-4, Mr Flibble wrote:
> On Sun, 24 Jul 2022 16:40:14 +0100
> Mr Flibble <fli...@reddwarf.jmc.corp> wrote:
>
> > On Sun, 24 Jul 2022 10:10:53 -0500
> > olcott <No...@NoWhere.com> wrote:
> >
> > > On 7/24/2022 10:08 AM, Mr Flibble wrote:
> > > > On Sun, 24 Jul 2022 09:51:44 -0500
> > > > olcott <No...@NoWhere.com> wrote:
> > > >
> > > >> On 7/24/2022 5:45 AM, Richard Damon wrote:
> > > >>> On 7/23/22 10:13 PM, olcott wrote:
> > > >>>> On 7/23/2022 9:08 PM, Richard Damon wrote:
> > > >>>>> On 7/23/22 9:40 PM, olcott wrote:
> > > >>>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
> > > >>>>>>>
> > > >>>>>>> On 7/23/22 9:12 PM, olcott wrote:
> > > >>>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
> > > >>>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
> > > >>>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
> > > >>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Not if it is a Halt Decider.
> > > >>>>>>>>>>
> > > >>>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> > > >>>>>>>>>> It has been conclusively proven that the correctly
> > > >>>>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> > > >>>>>>>>>> possibly reach its "return" instruction.
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> So, that isn't the halt condition, so it doesn't matter.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> If you keep changing the subject I will block you again.
> > > >>>>>>>>
> > > >>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
> > > >>>>>>>> It has been conclusively proven that the correctly
> > > >>>>>>>> simulated input to H(P,P) correctly simulated by H cannot
> > > >>>>>>>> possibly reach its "return" instruction.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> So, what do you think I don't understand or accept?
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> Just say that every word of my above paragraph is completely
> > > >>>>>> true.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>> Why, can't you understand polysylabic words?
> > > >>>>>
> > > >>>>> And, because of some of your use of adjectives, I don't
> > > >>>>> belaive it to that extend.
> > > >>>>>
> > > >>>>> First, you haven't provided a "conclusive proof",
> > > >>>>
> > > >>>> In other words the conclusive proof in Example 03 is either
> > > >>>> over your head or not explained well enough or some of both.
> > > >>>>
> > > >>>> *Halting problem proofs refuted on the basis of software
> > > >>>> engineering* ?
> > > >>>>
> > > >>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> Ah, here we get to the rub.
> > > >>>
> > > >>> You HAVEN'T proved that the input never Halts, because Halting
> > > >>> refers to the behavior of the Machine. All you have proved is
> > > >>> that H can never simulate its input to see that the input halts.
> > > >>>
> > > >> Here is a simpler example where H merely invokes its input.
> > > >>
> > > >> int H(ptr p, ptr i)
> > > >> {
> > > >> p(i);
> > > >> }
> > > >>
> > > >> void P(ptr x)
> > > >> {
> > > >> H(x, x);
> > > >> return;
> > > >> }
> > > >>
> > > >> int main()
> > > >> {
> > > >> H(P,P);
> > > >> }
> > > >>
> > > >> If the execution trace of function P() called by function H()
> > > >> shows: (1) Function H() is called twice in sequence from the same
> > > >> machine address of P().
> > > >> (2) With the same parameters to H().
> > > >> (3) With no control flow instructions between the invocation of
> > > >> P() and the call to H() from P().
> > > >>
> > > >> Then the function call from P() to H() is infinitely recursive.
> > > >> The exact same pattern applies when H() invokes simulate(p,i)
> > > >> with an x86 emulator.
> > > >
> > > > In this case P always halts
> > >
> > > You have to pay attention to what I am actually saying
> > > You have to pay attention to what I am actually saying
> > > You have to pay attention to what I am actually saying
> > > You have to pay attention to what I am actually saying
> > >
> > > H merely invokes its input.
> > > H merely invokes its input.
> > > H merely invokes its input.
> > > H merely invokes its input.
> > >
> > > Thus P never halts
> > > Thus P never halts
> > > Thus P never halts
> > > Thus P never halts
> >
> > Nope, in this case P always halts so your H is incorrect to say it
> > doesn't. My simulating halt decider will get the answer correct in
> > this case.
> Ah yes, I didn't spot you explicit definition of H which is indeed
> infinitely recursive so is just as incorrect as your actual H.
>
> /Flibble

That's part of his deception. He deceptively uses "H" to sometime mean Ha and sometimes mean Hn, and he deceptively uses "P" is sometimes mean Pa and sometimes mean Pn, and mixes them as it suits him.

On Sunday, 24 July 2022 at 17:43:02 UTC+2, Mr Flibble wrote:
> Oh, I didn't spot your new definition of H. Yes obviously this is
> infinitely recursive so H is invalid (for the same reason your real H
> is) so I cannot see the point of your post.

Recursion is just a design pattern - syntax, not semantics. Your level of ignorance is equivalent to Olcott's

Mathematically speaking f and g are the same function.

void f(){
return f();
}

void g(){
for (;;){};
}

On 7/24/22 10:51 AM, olcott wrote:
> On 7/24/2022 5:45 AM, Richard Damon wrote:
>> On 7/23/22 10:13 PM, olcott wrote:
>>> On 7/23/2022 9:08 PM, Richard Damon wrote:
>>>> On 7/23/22 9:40 PM, olcott wrote:
>>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not if it is a Halt Decider.
>>>>>>>>>
>>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>>> reach its "return" instruction.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>>>
>>>>>>>
>>>>>>> If you keep changing the subject I will block you again.
>>>>>>>
>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>> reach its "return" instruction.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, what do you think I don't understand or accept?
>>>>>>
>>>>>
>>>>> Just say that every word of my above paragraph is completely true.
>>>>>
>>>>>
>>>>
>>>> Why, can't you understand polysylabic words?
>>>>
>>>> And, because of some of your use of adjectives, I don't belaive it
>>>> to that extend.
>>>>
>>>> First, you haven't provided a "conclusive proof",
>>>
>>> In other words the conclusive proof in Example 03 is either over your
>>> head or not explained well enough or some of both.
>>>
>>> *Halting problem proofs refuted on the basis of software engineering* ?
>>>
>>> https://www.researchgate.net/publication/361701808_Halting_problem_proofs_refuted_on_the_basis_of_software_engineering
>>>
>>>
>>
>> Ah, here we get to the rub.
>>
>> You HAVEN'T proved that the input never Halts, because Halting refers
>> to the behavior of the Machine. All you have proved is that H can
>> never simulate its input to see that the input halts.
>>
> Here is a simpler example where H merely invokes its input.
>
> int H(ptr p, ptr i)
> {
>   p(i);
> }
>
> void P(ptr x)
> {
>   H(x, x);
>   return;
> }
>
> int main()
> {
>   H(P,P);
> }
>
> If the execution trace of function P() called by function H() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no control flow instructions between the invocation of P() and
> the call to H() from P().
>
> Then the function call from P() to H() is infinitely recursive.
> The exact same pattern applies when H() invokes simulate(p,i) with an
> x86 emulator.
>
>
>

Yes, and for H defined like that P(P) never Halts, but H(P,P) never
answers so fails to be a decider

This just points out your error.

Your H ASSUMES INCORRECTLY that it will behave this way in its
simulation of P so gets the wrong answer because of either bad logic or
bad simulation depending on what you want to call what H is doing with
the call to H.

Thus, your argument FAILS because of the error.

In a given example, you can only have ONE version of H, not two.

P needs to actually call the same H that is deciding or you haven't got
the required case, and H needs to treat that H as if it behaves just
like itself.

You are just proving you are talking out of both sides of your mouth and
are double minded.

On 7/24/22 11:01 AM, olcott wrote:
> On 7/24/2022 5:46 AM, Richard Damon wrote:
>> On 7/24/22 1:02 AM, Skep Dick wrote:
>>> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
>>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>>
>>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> Not if it is a Halt Decider.
>>>>>>>>
>>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>>> reach its "return" instruction.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>>
>>>>>>
>>>>>> If you keep changing the subject I will block you again.
>>>>>>
>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>> It has been conclusively proven that the correctly simulated
>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>> reach its "return" instruction.
>>>>>>
>>>>>>
>>>>>
>>>>> So, what do you think I don't understand or accept?
>>>> Just say that you honestly and sincerely totally accept that
>>>> every single word of my above paragraph is completely true.
>>>
>>> So you just want somebody to agree with you even when you are wrong?
>>
>> Yep, that seems to be what he wants.
>
> Simply failing to understand what I say is no actual rebuttal at all.
>
> I have to explain the proof better. In the following H merely directly
> executes its input and has no conditional logic. This is simple infinite
> recursion.
>
> *The goal here is to understand that the*
> *infinite recursion detection criteria is correct*

Which it isn't in the context of Halting.

Yes, mayebe it is correct for your POOP, but it isn't for Halting.

>
> I can build on the understanding of this proof to make my other proof
> easier to understand.
>
> int H(ptr p, ptr i)
> {
>   p(i);
> }
>
> void P(ptr x)
> {
>   H(x, x);
>   return;
> }
>
> int main()
> {
>   H(P,P);
> }
>
> If the execution trace of function P() called by function H() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no control flow instructions between the invocation of P() and
> the call to H() from P().

And (3) isn't correct if H is a conditional simulator. FAIL.

Your repeating this again and again shows that you are just stupid and
unable to understand what you are saying.

>
> Then the function call from P() to H() is infinitely recursive.
> The exact same pattern applies when H() invokes simulate(p,i) with an
> x86 emulator.
>
>

On 7/24/22 10:49 AM, olcott wrote:
> On 7/24/2022 12:02 AM, Skep Dick wrote:
>> On Sunday, 24 July 2022 at 04:01:45 UTC+2, olcott wrote:
>>> On 7/23/2022 8:31 PM, Richard Damon wrote:
>>>>
>>>> On 7/23/22 9:12 PM, olcott wrote:
>>>>> On 7/23/2022 8:10 PM, Richard Damon wrote:
>>>>>> On 7/23/22 8:41 PM, olcott wrote:
>>>>>>> On 7/23/2022 7:05 PM, Richard Damon wrote:
>>>>>
>>>>>>>>
>>>>>>>> Not if it is a Halt Decider.
>>>>>>>
>>>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>>>> It has been conclusively proven that the correctly simulated
>>>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>>>> reach its "return" instruction.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So, that isn't the halt condition, so it doesn't matter.
>>>>>>
>>>>>
>>>>> If you keep changing the subject I will block you again.
>>>>>
>>>>> *WE STAY FOCUSED ON THIS POINT UNTIL FULLY UNDERSTOOD*
>>>>> It has been conclusively proven that the correctly simulated
>>>>> input to H(P,P) correctly simulated by H cannot possibly
>>>>> reach its "return" instruction.
>>>>>
>>>>>
>>>>
>>>> So, what do you think I don't understand or accept?
>>> Just say that you honestly and sincerely totally accept that
>>> every single word of my above paragraph is completely true.
>>
>> So you just want somebody to agree with you even when you are wrong?
>
> Example 03 of my paper proves that I am correct.
> Example 03 requires understanding of the x86 language.
>
> The infinite recursive simulation detection criteria is an adaptation of
> the infinite recursion criteria. Perhaps we should start with getting
> people to understand the infinite recursion detection criteria first.
>
> int H(ptr p, ptr i)
> {
>   p(i);
> }
>
> void P(ptr x)
> {
>   H(x, x);
>   return;
> }
>
> int main()
> {
>   H(P,P);
> }
>
> If the execution trace of function P() called by function H() shows:
> (1) Function H() is called twice in sequence from the same machine
> address of P().
> (2) With the same parameters to H().
> (3) With no control flow instructions between the invocation of P() and
> the call to H() from P().
>
> Then the function call from P() to H() is infinitely recursive.
> The exact same pattern applies when H() invokes simulate(p,i) with an
> x86 emulator.
>

Rule (3) is incorrect, because it needs to actually look at BOTH P and H.

In this case, yes, because H isn't conditional, it works. But such an H
fails to answer so fails to be a decider.

Make H a decider, and your rule (3) is not correct, and you logic unsound.

You are just proving you are incapable of doing elementary logic and
seem to have a total learning block in this field.

On 7/24/22 11:08 AM, olcott wrote:
> On 7/24/2022 9:49 AM, Mike Terry wrote:
>> On 24/07/2022 13:26, Mikko wrote:
>>> On 2022-07-23 20:33:11 +0000, olcott said:
>>>
>>>> On 7/23/2022 3:23 PM, Richard Damon wrote:
>>>>> The trace proves no such thing. Here is a basic of the x86 question
>>>>> for you, what is the first instruction executed in P(P) that
>>>>> differs from the correct simulation of H(P,P)?
>>>>
>>>> _P()
>>>> [000013c6](01)  55         push ebp               // Save Base
>>>> Pointer register onto the stack
>>>> [000013c7](02)  8bec       mov ebp,esp            // Load Base
>>>> Pointer with Stack Pointer
>>>> [000013c9](01)  51         push ecx               // Save the value
>>>> of ecx on the stack
>>>> [000013ca](03)  8b4508     mov eax,[ebp+08]       // Load eax with
>>>> argument to P
>>>> [000013cd](01)  50         push eax               // push 2nd
>>>> argument to H onto the stack
>>>> [000013ce](03)  8b4d08     mov ecx,[ebp+08]       // Load ecx with
>>>> with argument to P
>>>> [000013d1](01)  51         push ecx               // push 1st
>>>> argument to H onto the stack
>>>> [000013d2](05)  e82ffdffff call 00001106          // push return
>>>> address on the stack; call simulated H
>>
>> um, H here is not simulated, it's directly called by P.
>>
>>>> [000013d7](03)  83c408     add esp,+08            // remove call
>>>> arguments from stack
>>>> [000013da](03)  8945fc     mov [ebp-04],eax       // load
>>>> Halt_Status with return value from H
>>>> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00 // compare
>>>> Halt_Status to 0
>>>> [000013e1](02)  7402       jz 000013e5            // if Halt_Status
>>>> == 0 goto 000013e5
>>>> [000013e3](02)  ebfe       jmp 000013e3           // goto 13e3
>>>> [000013e5](02)  8be5       mov esp,ebp            // Load Stack
>>>> Pointer with Base Pointer
>>>> [000013e7](01)  5d         pop ebp                // Restore Base
>>>> Pointer value from stack
>>>> [000013e8](01)  c3         ret                    // return to caller
>>>> Size in bytes:(0035) [000013e8]
>>>>
>>>> The instruction at machine address 13d7
>>>
>>> Can you prove that 13d7 is the first differeing instruction?
>>> In particular, that the immediately preceding instruction is
>>> the same?
>>>
>>> Mikko
>>>
>>
>> In H's simulation of P(P), H DECIDES TO STOP SIMULATING at the first
>> call to H.  That is obviously not the last step of the computation, as
>> we can see by looking at the trace of P(P) [native]:
>>
>> [Native P(P): summary of execution + simulations]
>> P(P)
>>      H(P,P)
>>      [#SIMULATION...]
>>      P(P)
>>          H(P,P)
>>      [#STOP SIMULATING]
>>      H ret 0 [non-halting]
>> P ret [P(P) halts]
>>
>> For "H simulating its input (P,P)" PO is just counting the lines above
>> between "#SIMULATION..." and "#STOP SIMULATING":
>>
>> [H's simulation of P(P): summary of execution + simulations]
>> P(P)
>>      H(P,P)
>> er that's it - Simulator has given up simulating!!
>>
>> Claiming the computations are "a different sequence of instructions"
>> is completely misleading, as the sequence is exactly the same in both
>> cases, other than H decides to give up simulating at an early point in
>> the sequence,
>
> That is not true. H correctly determines that its simulated P cannot
> possibly ever reach machine address 13d7 even if H never stopped
> simulating P.
>

But since H DOES abort its simulation, we can show that P(P) is
non-halting as is a correct and complete simulation of the input to
H(P,P) when we use a PROPER simulator (and keep P the same so it still
calls the H that is defined to abort its simulation).

This shows that H is incorrect as a Haltingg decider.

Maybe it is correct as a Olcott POOP decider, since H can't ever
simulate to that point, but no one really cares about your POOP.

It also shows that Peter Olcott doesn't understand what it meens to Halt
or what a Halting Decider actually is.

> _P()
> [000013c6](01)  55         push ebp
> [000013c7](02)  8bec       mov ebp,esp
> [000013c9](01)  51         push ecx
> [000013ca](03)  8b4508     mov eax,[ebp+08]
> [000013cd](01)  50         push eax
> [000013ce](03)  8b4d08     mov ecx,[ebp+08]
> [000013d1](01)  51         push ecx
> [000013d2](05)  e82ffdffff call 00001106
> [000013d7](03)  83c408     add esp,+08
> [000013da](03)  8945fc     mov [ebp-04],eax
> [000013dd](04)  837dfc00   cmp dword [ebp-04],+00
> [000013e1](02)  7402       jz 000013e5
> [000013e3](02)  ebfe       jmp 000013e3
> [000013e5](02)  8be5       mov esp,ebp
> [000013e7](01)  5d         pop ebp
> [000013e8](01)  c3         ret
> Size in bytes:(0035) [000013e8]
>
>