On 8/20/22 3:46 PM, olcott wrote:
> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>
>> On 8/20/22 3:06 PM, olcott wrote:
>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>
>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>
>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>
>>>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>>>> been attempting to shill your simulating halting decider.  I find
>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>>>> has.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>>> mistake.
>>>>>>>>
>>>>>>>> First the problem this is al about:
>>>>>>>> In computation theory we can denote a program with X and its input
>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>>>> a finite number of steps, but another program X and/or input Y may
>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>> possible to create a program H that when given any program X with
>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>>
>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>
>>>>>>>> The classical proof that it is not possible is the idea that it is
>>>>>>>> always possible to create a program P that uses H, with itself as
>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>> language it would be something like:
>>>>>>>>
>>>>>>>> void P(ptr x)
>>>>>>>> {
>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>      if (Halt_Status)
>>>>>>>>        HERE: goto HERE;
>>>>>>>>      return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>> which would always halts with the correct answer, then it is clear
>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>>> finite number of steps.
>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>
>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>
>>>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>
>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>
>>>>>>>> Now the opinions diverge.
>>>>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>> must also be the correct answer when P actually calls the actual
>>>>>>>> aborting H.
>>>>>>>
>>>>>>> *You did a very good job summing this up*
>>>>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>>>>> correctly simulates its input that this input would reach the
>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>> determines that its correct simulation of its input would never
>>>>>>> reach the "return" instruction of P.
>>>>>>>
>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>
>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>
>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>>> then it is certain that this machine description specifies
>>>>>>> infinite behavior.
>>>>>>>
>>>>>>> In other words the SHD decider correctly predicts that its correct
>>>>>>> and complete simulation of its input would never reach the final
>>>>>>> state of this input.
>>>>>>>
>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>> void Infinite_Loop()
>>>>>>> {
>>>>>>>      HERE: goto HERE;
>>>>>>> }
>>>>>>
>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>     (void) H(x, x);
>>>>>>     return;
>>>>>> }
>>>>>>
>>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>>> always return a decision to its caller).
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>>
>>>>> This one uses my prior version of H named HH where the infinitely
>>>>> recursive simulation is easier to see.
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>     (void) HH(x, x);
>>>>>     return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>> }
>>>>>
>>>>> _Px()
>>>>> [000010b2](01)  55             push ebp
>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>> [000010b8](01)  50             push eax
>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>> [000010bc](01)  51             push ecx
>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>> [000010c2](03)  83c408         add esp,+08
>>>>> [000010c5](01)  5d             pop ebp
>>>>> [000010c6](01)  c3             ret
>>>>> Size in bytes:(0021) [000010c6]
>>>>>
>>>>> _main()
>>>>> [000010d2](01)  55             push ebp
>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>> [000010e4](03)  83c408         add esp,+08
>>>>> [000010e7](01)  50             push eax
>>>>> [000010e8](05)  6863040000     push 00000463
>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>> [000010f2](03)  83c408         add esp,+08
>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>> [000010f7](01)  5d             pop ebp
>>>>> [000010f8](01)  c3             ret
>>>>> Size in bytes:(0039) [000010f8]
>>>>>
>>>>>    machine   stack     stack     machine    assembly
>>>>>    address   address   data      code       language
>>>>>    ========  ========  ========  =========  =============
>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>> New slave_stack at:101c31
>>>>>
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:111c39
>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>> [000010b8][00111c21][000010b2] 50             push eax       // push
>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>> [000010bc][00111c1d][000010b2] 51             push ecx       // push
>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2  //
>>>>> call HH New slave_stack at:14c659
>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>> [000010b8][0015c649][000010b2] 50             push eax       // push
>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>> [000010bc][0015c645][000010b2] 51             push ecx       // push
>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2  //
>>>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>>>> Stopped*
>>>>>
>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>> machine address of Px().
>>>>> (2) With the same arguments to HH(Px,Px).
>>>>> (3) With no control flow instructions between the invocation of Px()
>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>> simulations.
>>>>>
>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>> Input_Halts = 0
>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>
>>>> All your trace is doing is confirming that H gets the answer wrong, Px
>>>> halts. Until you resolve this false positive you do not have a valid
>>>> SHD.
>>>>
>>>> /Flibble
>>>>
>>>
>>> void Px(void (*x)())
>>> {
>>>    (void) HH(x, x);
>>>    return;
>>> }
>>>
>>> int main()
>>> {
>>>    Output("Input_Halts = ", HH(Px, Px));
>>> }
>>>
>>> Because HH is a simulating halt decider (SHD) it continues to perform
>>> a pure x86 emulation of its input until it correctly matches a
>>> non-halting behavior pattern proving that the simulated input would
>>> never reach its own final state.
>>>
>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> *Until HH aborts its simulation*
>>>
>>> All those having sufficient software engineering technical competence
>>> can see this.
>>>
>>
>> And the correct and complete simulation of the input to HH(Px,Px) is
>>
>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>
>> *Until the SIMULATED HH from (a) abort ITS simulate.
>> (f) returns 0 to the simulated Px(Px) from (a)
>> (g) which returns, and thus Halts.
>>
>> Thus, the COMPLETE simulation of the input to HH, which we agree shows
>> the actual behavior of the input to HH, comes to a Halt
>>
>> The HH(Px,Px) returning 0 is INCORRECT.
>
>
> This sequence of instructions provides the correct and complete
> simulation of the input to H(P,P):
>
> void Px(void (*x)())
> {
>    (void) Simulate(x, x);
>    return;
> }
>
> You provide the pure simulation at the wrong point in the execution
> trace. In any case even in your incorrect execution trace the Px that HH
> simulates never reaches its own final state, thus never halts.
>
>
>

On 8/20/22 4:20 PM, olcott wrote:
> On 8/20/2022 3:00 PM, Fred. Zwarts wrote:
>> Op 20.aug..2022 om 17:23 schreef olcott:
>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>> Olcott, which of the following do you think is more likely?
>>>>>
>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>
>>>>> Which one is more likely hasn't changed for all the years you've been
>>>>> attempting to shill your simulating halting decider.  I find it
>>>>> amusing
>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>> decider that doesn't have the flaws your SHD has.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> I have been following these discussions for many months now. I have
>>>> a strong impression that there is little progress. It seems that
>>>> people are running in circles. I am not an expert in this field.
>>>> Maybe it helps if a non-expert tries to summarize the discussion.
>>>> Please, be patient when correcting me if I make any mistake.
>>>>
>>>> First the problem this is al about:
>>>> In computation theory we can denote a program with X and its input
>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>>> finite number of steps, but another program X and/or input Y may not
>>>> halt in a finite number of steps. The question is, is it possible to
>>>> create a program H that when given any program X with its input Y
>>>> can tell in a finite number of steps whether X(Y) halts or not? In
>>>> other words, will H(X,Y) always halt after a finite number of steps
>>>> with the correct answer for any X and Y?
>>>>
>>>> I hope that this is a correct formulation of the problem.
>>>>
>>>> The classical proof that it is not possible is the idea that it is
>>>> always possible to create a program P that uses H, with itself as
>>>> input, but behaves opposite to what H returns. In a C-like language
>>>> it would be something like:
>>>>
>>>> void P(ptr x)
>>>> {
>>>>    int Halt_Status = H(x, x);
>>>>    if (Halt_Status)
>>>>      HERE: goto HERE;
>>>>    return;
>>>> }
>>>>
>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>> which would always halts with the correct answer, then it is clear
>>>> that there would be a contradiction if we ask H about P with H(P,P).
>>>> Because there are only three possibilities:
>>>> 1. If H would return true (halting) in a finite number of steps,
>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>> finite number of steps.
>>>> 2. If H would return false (non-halting) in a finite number of
>>>> steps, then P returns immediately, so H returns a wrong result.
>>>> 3. If H does not return, then it does not return in a finite number
>>>> of steps, so it is not the H where the problem asked for.
>>>>
>>>> I think everybody agrees up to this point.
>>>>
>>>> Now Olcott has created a simulating aborting H, which, when given P
>>>> with input P [so H(P,P)], creates a trace of the execution and at
>>>> the point where P calls H, it uses the following logic: If H were
>>>> the hypothetical non-aborting H, then an infinite recursion would
>>>> happen at this point. Therefore, Olcott's simulating H aborts the
>>>> simulation and returns false (0).
>>>>
>>>> Does everybody still agree up to this point?
>>>>
>>>> Now the opinions diverge.
>>>> Olcott thinks that his H gives the correct answer that P would not
>>>> halt when P would call the hypothetical non-aborting H, so, it must
>>>> also be the correct answer when P actually calls the actual aborting H.
>>>>
>>>
>>> *You did a very good job summing this up* > The key nuance of
>>> divergence is that halting means that when H(P,P)
>>> correctly simulates its input that this input would reach the
>>> "return" instruction (final state) of P. H(P,P) correctly determines
>>> that its correct simulation of its input would never reach the
>>> "return" instruction of P.
>>>
>>
>> Thanks for the confirmation, because I was not completely sure about
>> my last sentence above. But I am glad that I understood you correctly
>> that your aborting H answers the question for P calling the
>> hypothetical non-aborting H.
>>
>> You derive the final answer (for P calling the actual aborting H)
>> indirectly from the first answer, because it cannot be answered
>> directly, as it would not reach the return instruction.
>>
>
> *Here is my newly revised clearer explanation*
>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.

CORRECTLY is the key, and that pattern needs to be a CORRECT PATTERN.

>
> *computation that halts* … the Turing machine will halt whenever it
> enters a final state. (Linz:1990:234)
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.

Nope, bad words,

The pattern is correct if when-so-ever matching this behavior pattern
proves that the correct and complete simulate of the input by a PURE
SIMULATOR would never reach the final state.

Note, your pattern even fails for your definition, as if the SHD has the
pattern in it, then it never actually does a correct and complete
simulation, so you can't "prove" what it does.

You don't get to look at P with a version of the SHD that doesn't have
the abort with a SHD that does have the abort and say that it passed the
test.

The P must use the SHD that decides it, which has the abort, which makes
the pattern incorrect.

FAIL.

>
> The above system equally applies to all non-halting inputs explicitly
> including the pathological input defined below:
>
>      *In computability theory, the halting problem is the problem*
>      of determining, from a description of an arbitrary computer
>      program and an input, whether the program will finish running,
>      or continue to run forever. Alan Turing proved in 1936 that a
>      general algorithm to solve the halting problem for all possible
>      program-input pairs cannot exist.
>
>      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
>
> *Linz, Peter 1990*. An Introduction to Formal Languages and Automata.
> Lexington/Toronto: D. C. Heath and Company. (317-320)
>
> *Two more inputs that are correctly decided using this same system*
>
> void Infinite_Loop()
> {
>   HERE: goto HERE;
> }
>
> void Infinite_Recursion(int N)
> {
>   Infinite_Recursion(N);
> }
>

On 8/20/2022 4:05 PM, Richard Damon wrote:
> On 8/20/22 3:46 PM, olcott wrote:
>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>
>>> On 8/20/22 3:06 PM, olcott wrote:
>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>
>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>
>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>
>>>>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>>>>> been attempting to shill your simulating halting decider.  I find
>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>>>>> has.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>>>> mistake.
>>>>>>>>>
>>>>>>>>> First the problem this is al about:
>>>>>>>>> In computation theory we can denote a program with X and its input
>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>>>>> a finite number of steps, but another program X and/or input Y may
>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>> possible to create a program H that when given any program X with
>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>>>
>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>
>>>>>>>>> The classical proof that it is not possible is the idea that it is
>>>>>>>>> always possible to create a program P that uses H, with itself as
>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>> language it would be something like:
>>>>>>>>>
>>>>>>>>> void P(ptr x)
>>>>>>>>> {
>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>      if (Halt_Status)
>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>      return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>>> which would always halts with the correct answer, then it is clear
>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>>>> finite number of steps.
>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>>
>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>
>>>>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>
>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>
>>>>>>>>> Now the opinions diverge.
>>>>>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>>> must also be the correct answer when P actually calls the actual
>>>>>>>>> aborting H.
>>>>>>>>
>>>>>>>> *You did a very good job summing this up*
>>>>>>>> The key nuance of divergence is that halting means that when H(P,P)
>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>> determines that its correct simulation of its input would never
>>>>>>>> reach the "return" instruction of P.
>>>>>>>>
>>>>>>>> *computation that halts* … the Turing machine will halt whenever it
>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>
>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and Automata.
>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>
>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>>>> then it is certain that this machine description specifies
>>>>>>>> infinite behavior.
>>>>>>>>
>>>>>>>> In other words the SHD decider correctly predicts that its correct
>>>>>>>> and complete simulation of its input would never reach the final
>>>>>>>> state of this input.
>>>>>>>>
>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>> void Infinite_Loop()
>>>>>>>> {
>>>>>>>>      HERE: goto HERE;
>>>>>>>> }
>>>>>>>
>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>     (void) H(x, x);
>>>>>>>     return;
>>>>>>> }
>>>>>>>
>>>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>>>> always return a decision to its caller).
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>>
>>>>>> This one uses my prior version of H named HH where the infinitely
>>>>>> recursive simulation is easier to see.
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>     (void) HH(x, x);
>>>>>>     return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>> }
>>>>>>
>>>>>> _Px()
>>>>>> [000010b2](01)  55             push ebp
>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>> [000010b8](01)  50             push eax
>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>> [000010bc](01)  51             push ecx
>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>> [000010c5](01)  5d             pop ebp
>>>>>> [000010c6](01)  c3             ret
>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>
>>>>>> _main()
>>>>>> [000010d2](01)  55             push ebp
>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>> [000010e7](01)  50             push eax
>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>> [000010f7](01)  5d             pop ebp
>>>>>> [000010f8](01)  c3             ret
>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>
>>>>>>    machine   stack     stack     machine    assembly
>>>>>>    address   address   data      code       language
>>>>>>    ========  ========  ========  =========  =============
>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>> New slave_stack at:101c31
>>>>>>
>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>> at:111c39
>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>> [000010b8][00111c21][000010b2] 50             push eax       // push
>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx       // push
>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>> call HH New slave_stack at:14c659
>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>> [000010b8][0015c649][000010b2] 50             push eax       // push
>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>> [000010bc][0015c645][000010b2] 51             push ecx       // push
>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>> Stopped*
>>>>>>
>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>> machine address of Px().
>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>> (3) With no control flow instructions between the invocation of Px()
>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>> simulations.
>>>>>>
>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>> Input_Halts = 0
>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>
>>>>> All your trace is doing is confirming that H gets the answer wrong, Px
>>>>> halts. Until you resolve this false positive you do not have a valid
>>>>> SHD.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>    (void) HH(x, x);
>>>>    return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>> }
>>>>
>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>> perform a pure x86 emulation of its input until it correctly matches
>>>> a non-halting behavior pattern proving that the simulated input
>>>> would never reach its own final state.
>>>>
>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> *Until HH aborts its simulation*
>>>>
>>>> All those having sufficient software engineering technical
>>>> competence can see this.
>>>>
>>>
>>> And the correct and complete simulation of the input to HH(Px,Px) is
>>>
>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>
>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>> (f) returns 0 to the simulated Px(Px) from (a)
>>> (g) which returns, and thus Halts.
>>>
>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>> shows the actual behavior of the input to HH, comes to a Halt
>>>
>>> The HH(Px,Px) returning 0 is INCORRECT.
>>
>>
>> This sequence of instructions provides the correct and complete
>> simulation of the input to H(P,P):
>>
>> void Px(void (*x)())
>> {
>>     (void) Simulate(x, x);
>>     return;
>> }
>>
>> You provide the pure simulation at the wrong point in the execution
>> trace. In any case even in your incorrect execution trace the Px that
>> HH simulates never reaches its own final state, thus never halts.
>>
>>
>>
>
> Nope, because you changed P!
>
> P MUST be
>
>
> void Px(void (*x)()) {
>    HH(x,x);
> }
>
> As that is the P that was defined.
>
> Then have main be:
>
> int main() {
>    // The original call to HH
>    Output("Input_Halts = ", HH(Px, Px));
>
>    // The test
>    Simulate(Px,Px);
>    Output("But Px(Px) Halts");
> }
>
> I.E just DO the correct and complete simulation of the input to HH.
>
> That is the plain meaning of the words.
>
> Youy keep on trying to change the P that is the input to H to "prove"
> your answer.
>
> THIS IS NOT ALLOWED, and shows that you are just a cheat.

On 8/20/22 4:04 PM, olcott wrote:
> On 8/20/2022 2:27 PM, Richard Damon wrote:
>>
>> On 8/20/22 3:00 PM, olcott wrote:
>>> On 8/20/2022 1:32 PM, Richard Damon wrote:
>>>> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>
>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>
>>>>>> Which one is more likely hasn't changed for all the years you've been
>>>>>> attempting to shill your simulating halting decider.  I find it
>>>>>> amusing
>>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> I have been following these discussions for many months now. I have
>>>>> a strong impression that there is little progress. It seems that
>>>>> people are running in circles. I am not an expert in this field.
>>>>> Maybe it helps if a non-expert tries to summarize the discussion.
>>>>> Please, be patient when correcting me if I make any mistake.
>>>>>
>>>>> First the problem this is al about:
>>>>> In computation theory we can denote a program with X and its input
>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in a
>>>>> finite number of steps, but another program X and/or input Y may
>>>>> not halt in a finite number of steps. The question is, is it
>>>>> possible to create a program H that when given any program X with
>>>>> its input Y can tell in a finite number of steps whether X(Y) halts
>>>>> or not? In other words, will H(X,Y) always halt after a finite
>>>>> number of steps with the correct answer for any X and Y?
>>>>>
>>>>> I hope that this is a correct formulation of the problem.
>>>>>
>>>>> The classical proof that it is not possible is the idea that it is
>>>>> always possible to create a program P that uses H, with itself as
>>>>> input, but behaves opposite to what H returns. In a C-like language
>>>>> it would be something like:
>>>>>
>>>>> void P(ptr x)
>>>>> {
>>>>>    int Halt_Status = H(x, x);
>>>>>    if (Halt_Status)
>>>>>      HERE: goto HERE;
>>>>>    return;
>>>>> }
>>>>>
>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>> which would always halts with the correct answer, then it is clear
>>>>> that there would be a contradiction if we ask H about P with
>>>>> H(P,P). Because there are only three possibilities:
>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>> finite number of steps.
>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>> 3. If H does not return, then it does not return in a finite number
>>>>> of steps, so it is not the H where the problem asked for.
>>>>>
>>>>> I think everybody agrees up to this point.
>>>>>
>>>>> Now Olcott has created a simulating aborting H, which, when given P
>>>>> with input P [so H(P,P)], creates a trace of the execution and at
>>>>> the point where P calls H, it uses the following logic: If H were
>>>>> the hypothetical non-aborting H, then an infinite recursion would
>>>>> happen at this point. Therefore, Olcott's simulating H aborts the
>>>>> simulation and returns false (0).
>>>>>
>>>>> Does everybody still agree up to this point?
>>>>>
>>>>> Now the opinions diverge.
>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>> halt when P would call the hypothetical non-aborting H, so, it must
>>>>> also be the correct answer when P actually calls the actual
>>>>> aborting H.
>>>>>
>>>>> Others have a different opinion and argue that P does not call the
>>>>> hypothetical non-aborting H, but the actual aborting H, which does
>>>>> not go in infinite recursion, but returns false in a finite number
>>>>> of steps. Therefore, H's result is wrong.
>>>>>
>>>>> Is this a correct summary of the disagreement? If not, please, tell
>>>>> me where the summary failed. Maybe we can then find the point of
>>>>> divergence of opinions easier.
>>>>>
>>>>
>>>> The key point is the conventional proof doesn't assume a
>>>> "Non-simulating" decider, but ANY decider, no matter how it
>>>> determines its answer.
>>>>
>>>> The key error of Olcott, is the mistaken idea that just because H
>>>> happens to be a simulating Halt Decider, it gets to change the
>>>> criteria that it needs to decide on, and rather than being does the
>>>> computation the input represents [that is M(x) for a call to H(M,x)
>>>> ], halt or never halt, but can we decide instead of on a did "H need
>>>> to abort its simulation" criteria, and that this "need" affect EVERY
>>>> COPY of H that exists in the world. (He confuses that last point by
>>>> mashing the code of the decided program and the decider into a
>>>> single program and having the decided program share code with the
>>>> decider instead of being an independent copy, as it would need to be
>>>> to actually implement as Turing Machines.
>>>>
>>>> Because of this, H is actually deciding on the wrong input, the H
>>>> that aborts is actually reporting the results of the input program P
>>>> built on the H that doesn't abort, which is a different input then
>>>> the input program P built on the H that does abort.
>>>
>>>
>>> It is common knowledge that the correct and complete simulation of a
>>> machine description always provides the actual behavior specified by
>>> this machine description.
>>
>> Right. COMPLETE.
>>
>> The H that answers non-halting does NOT do a COMPLETE simulation of
>> its input.
>>
>> If that input is given to a UTM equivalent, the COMPLETE simulation of
>> that input (which still calls H) will Halt.
>>
>> THUS, H was wrong.
>>
>>>
>>> That you and others reject this when it is applied to my simulating
>>> halt decider implicitly rejects the notion of a UTM. Since you and
>>> others do accept the notion of a UTM, I have just proven that your
>>> reasoning is incoherent and/or inconsistent.
>>
>> Becaue you have no H that answers non-Halting that also has a COMPLETE
>> simulation of its input that will not halt even after an unbounded
>> number of steps.
>>
>>>
>>> Whenever the simulating halt decider correctly predicts that its
>>> correct and complete simulation of its input would never reach the
>>> final state of this input, then the SHD is correct to reject its
>>> input as non-halting.
>>
>> FALSE.
>>
>> IF it doesn't actually DO a complete simulation, talking about what
>> the complete simulation it would do is MEANINGLESS.
>>
>> You H is answering about a different input then the one given to it.
>>
>>>
>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>> 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]
>>>
>>>
>>>
>>
>> Red Herring.
>>
>> Fallacy of Proof by Exampe.
>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>

On 8/20/22 5:01 PM, olcott wrote:
> On 8/20/2022 3:53 PM, Ben Bacarisse wrote:
>> "Fred. Zwarts" <F.Zwarts@KVI.nl> writes:
>>
>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>> Olcott, which of the following do you think is more likely?
>>>> 1) Olcott is correct and everybody else is wrong.
>>>> 2) Olcott is wrong and everybody else is correct.
>>>> Which one is more likely hasn't changed for all the years you've been
>>>> attempting to shill your simulating halting decider.  I find it amusing
>>>> that I came up with, in less than 24 hours, a simulating halting
>>>> decider that doesn't have the flaws your SHD has.
>>>> /Flibble
>>>>
>>>
>>> I have been following these discussions for many months now. I have a
>>> strong impression that there is little progress. It seems that people
>>> are running in circles. I am not an expert in this field. Maybe it
>>> helps if a non-expert tries to summarize the discussion. Please, be
>>> patient when correcting me if I make any mistake.
>>>
>>> First the problem this is al about: In computation theory we can
>>> denote a program with X and its input with Y, which together is
>>> denoted as X(Y). X(Y) may end (halt) in a finite number of steps, but
>>> another program X and/or input Y may not halt in a finite number of
>>> steps. The question is, is it possible to create a program H that when
>>> given any program X with its input Y can tell in a finite number of
>>> steps whether X(Y) halts or not? In other words, will H(X,Y) always
>>> halt after a finite number of steps with the correct answer for any X
>>> and Y?
>>>
>>> I hope that this is a correct formulation of the problem.
>>
>> Yes, that's a reasonable summary.  PO knows that no such H is possible
>> so he is just pushing two silly arguments: (a) that H(X,Y) == false for
>> at least one X and Y where X(Y) halts is correct, despite it being
>> clearly wrong; and (b) that even specifying that H(X,Y) must answer
>> about X(Y), rather than something else that he's made up, is wrong.
>>
>> Both objections are risible, yet that have managed to generate a lot of
>> posts!
>>
>> The fuel for all the debate comes from the fact that PO has wisely
>> abandoned talking about Turing machines because there was not enough
>> room for confusion.  After all, formal models of computation are
>> designed to facilitate clear and un-ambiguous proofs.
>>
>>> The classical proof that it is not possible is the idea that it is
>>> always possible to create a program P that uses H, with itself as
>>> input, but behaves opposite to what H returns. In a C-like language it
>>> would be something like:
>>>
>>> void P(ptr x)
>>> {
>>>    int Halt_Status = H(x, x);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return;
>>> }
>>>
>>> If there would be a hypothetical non-simulating non-aborting H, which
>>> would always halts with the correct answer, then it is clear that
>>> there would be a contradiction if we ask H about P with
>>> H(P,P). Because there are only three possibilities:
>>> 1. If H would return true (halting) in a finite number of steps, then
>>> P would start an endless loop, so H(P,P) does not halt in a finite
>>> number of steps.
>>> 2. If H would return false (non-halting) in a finite number of steps,
>>> then P returns immediately, so H returns a wrong result.
>>> 3. If H does not return, then it does not return in a finite number of
>>> steps, so it is not the H where the problem asked for.
>>>
>>> I think everybody agrees up to this point.
>>
>> No.  PO rejects the very definition of the problem he is pretending to
>> care about.  There is absolutely no dispute about the facts that (1)
>> H(P,P) == false and (2) P(P) halts.
>>
>> Every post in reply to PO should start and stop with that fact.  There
>> is nothing else to talk about.
>>
>>> Now Olcott has created a simulating aborting H, which, when given P
>>> with input P [so H(P,P)], creates a trace of the execution and at the
>>> point where P calls H, it uses the following logic: If H were the
>>> hypothetical non-aborting H, then an infinite recursion would happen
>>> at this point.  Therefore, Olcott's simulating H aborts the simulation
>>> and returns false (0).
>>>
>>> Does everybody still agree up to this point?
>>
>> That's his ruse, yes, but you should not be colluding with the idea that
>> what "would happen if" is in any way relevant to the halting problem.
>> He's been trying to sneak this trick past credulous readers for years in
>> many different disguises.  P(P) halts, but it wouldn't if... is not
>> maths but junk.  33 would be prime if it weren't divisible by 3 and 11.
>>
>>> Now the opinions diverge.
>>
>> They diverged long before this!  PO rejects the very idea that a halt
>> decider might tell up what we want to know: that H(X,Y) == false if, and
>> only if, X(Y) does not halt.
>>
>>> Olcott thinks that his H gives the correct answer that P would not
>>> halt when P would call the hypothetical non-aborting H, so, it must
>>> also be the correct answer when P actually calls the actual aborting
>>> H.
>>
>> He may think that.  I doubt his mind is that clear.  After years of
>> coming up with ever more obscure what to justify the wrong answer, he
>> has toughly confused himself.
>>
>>> Others have a different opinion and argue that P does not call the
>>> hypothetical non-aborting H, but the actual aborting H, which does not
>>> go in infinite recursion, but returns false in a finite number of
>>> steps. Therefore, H's result is wrong.
>>
>> Someone my think that but, as you can see from your definition of the
>> halting problem at the top of this post, H is wrong, not by virtue of
>> anything it does, but because it simply does not meet the definition of
>> a halt decider (even if it's only in this one instance).
>>
>>> Is this a correct summary of the disagreement? If not, please, tell me
>>> where the summary failed. Maybe we can then find the point of
>>> divergence of opinions easier.
>>
>> You won't even get PO to agree to your problem definition because he
>> does not dispute the fact (and we not have the source code to see for
>> ourselves) that H(P,P) == false even though P(P) halts.  These
>> undisputed facts should, in my opinion, be the start and end of every
>> reply to PO.
>>
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.
>
> That you and others reject this when it is applied to my simulating halt
> decider implicitly rejects the notion of a UTM. Since you and others do
> accept the notion of a UTM, I have just proven that your reasoning is
> incoherent and/or inconsistent.
>
>
> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

The error has been pointed out many times, but you have proved yourself
to be too dumb to understand it.

>
> When-so-ever a simulating halt decider (SHD) correctly performs a
> partial simulation of its input and the behavior of this partial
> simulation correctly matches a non-halting behavior pattern then the SHD
> halt decider can correctly report non-halting.
>
> A non-halting behavior pattern is correct when-so-ever matching this
> behavior pattern proves that the correct and complete simulation of the
> input by SHD would never reach the final state of this simulated input.
>
>
>

Since you definition of Halting doesn't match the Halting Problem, you
are just talking about POOP.

Halting is based on the ACTUAL EXECTUION of the machine, not by an
aborted simulation done by the SHD.

Sometimes it is right, but not in this case.

FAIL.

On 8/20/22 5:13 PM, olcott wrote:
> On 8/20/2022 4:05 PM, Richard Damon wrote:
>> On 8/20/22 3:46 PM, olcott wrote:
>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>
>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>
>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>
>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>
>>>>>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>>>>>> been attempting to shill your simulating halting decider.  I
>>>>>>>>>>> find
>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>>>>>> has.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>>>>> mistake.
>>>>>>>>>>
>>>>>>>>>> First the problem this is al about:
>>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>>> input
>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>>>>>> a finite number of steps, but another program X and/or input Y
>>>>>>>>>> may
>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>> possible to create a program H that when given any program X with
>>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>>>>
>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>
>>>>>>>>>> The classical proof that it is not possible is the idea that
>>>>>>>>>> it is
>>>>>>>>>> always possible to create a program P that uses H, with itself as
>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>> language it would be something like:
>>>>>>>>>>
>>>>>>>>>> void P(ptr x)
>>>>>>>>>> {
>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>      return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>>>> which would always halts with the correct answer, then it is
>>>>>>>>>> clear
>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>>>>> finite number of steps.
>>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>>>
>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>
>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>
>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>
>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>> Olcott thinks that his H gives the correct answer that P would
>>>>>>>>>> not
>>>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>>>> must also be the correct answer when P actually calls the actual
>>>>>>>>>> aborting H.
>>>>>>>>>
>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>> The key nuance of divergence is that halting means that when
>>>>>>>>> H(P,P)
>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>> determines that its correct simulation of its input would never
>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>
>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>> whenever it
>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>
>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>> Automata.
>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>
>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>> infinite behavior.
>>>>>>>>>
>>>>>>>>> In other words the SHD decider correctly predicts that its correct
>>>>>>>>> and complete simulation of its input would never reach the final
>>>>>>>>> state of this input.
>>>>>>>>>
>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>> void Infinite_Loop()
>>>>>>>>> {
>>>>>>>>>      HERE: goto HERE;
>>>>>>>>> }
>>>>>>>>
>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>     (void) H(x, x);
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>>>>> always return a decision to its caller).
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>>
>>>>>>> This one uses my prior version of H named HH where the infinitely
>>>>>>> recursive simulation is easier to see.
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>     (void) HH(x, x);
>>>>>>>     return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>> }
>>>>>>>
>>>>>>> _Px()
>>>>>>> [000010b2](01)  55             push ebp
>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>> [000010b8](01)  50             push eax
>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>> [000010bc](01)  51             push ecx
>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>> [000010c6](01)  c3             ret
>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000010d2](01)  55             push ebp
>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>> [000010e7](01)  50             push eax
>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>> [000010f8](01)  c3             ret
>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>
>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>    address   address   data      code       language
>>>>>>>    ========  ========  ========  =========  =============
>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>> New slave_stack at:101c31
>>>>>>>
>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>> at:111c39
>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>> [000010b8][00111c21][000010b2] 50             push eax       // push
>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx       // push
>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>> call HH New slave_stack at:14c659
>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>> [000010b8][0015c649][000010b2] 50             push eax       // push
>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx       // push
>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>> Stopped*
>>>>>>>
>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>>> machine address of Px().
>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>> (3) With no control flow instructions between the invocation of Px()
>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>> simulations.
>>>>>>>
>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>> Input_Halts = 0
>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>
>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>> wrong, Px
>>>>>> halts. Until you resolve this false positive you do not have a valid
>>>>>> SHD.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>    (void) HH(x, x);
>>>>>    return;
>>>>> }
>>>>>
>>>>> int main()
>>>>> {
>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>> }
>>>>>
>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>> perform a pure x86 emulation of its input until it correctly
>>>>> matches a non-halting behavior pattern proving that the simulated
>>>>> input would never reach its own final state.
>>>>>
>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> *Until HH aborts its simulation*
>>>>>
>>>>> All those having sufficient software engineering technical
>>>>> competence can see this.
>>>>>
>>>>
>>>> And the correct and complete simulation of the input to HH(Px,Px) is
>>>>
>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>
>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>> (g) which returns, and thus Halts.
>>>>
>>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>>> shows the actual behavior of the input to HH, comes to a Halt
>>>>
>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>
>>>
>>> This sequence of instructions provides the correct and complete
>>> simulation of the input to H(P,P):
>>>
>>> void Px(void (*x)())
>>> {
>>>     (void) Simulate(x, x);
>>>     return;
>>> }
>>>
>>> You provide the pure simulation at the wrong point in the execution
>>> trace. In any case even in your incorrect execution trace the Px that
>>> HH simulates never reaches its own final state, thus never halts.
>>>
>>>
>>>
>>
>> Nope, because you changed P!
>>
>> P MUST be
>>
>>
>> void Px(void (*x)()) {
>>     HH(x,x);
>> }
>>
>> As that is the P that was defined.
>>
>> Then have main be:
>>
>> int main() {
>>     // The original call to HH
>>     Output("Input_Halts = ", HH(Px, Px));
>>
>>     // The test
>>     Simulate(Px,Px);
>>     Output("But Px(Px) Halts");
>> }
>>
>> I.E just DO the correct and complete simulation of the input to HH.
>>
>> That is the plain meaning of the words.
>>
>> Youy keep on trying to change the P that is the input to H to "prove"
>> your answer.
>>
>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>
>
> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*

On 8/20/2022 4:14 PM, Richard Damon wrote:
>
> On 8/20/22 4:04 PM, olcott wrote:
>> On 8/20/2022 2:27 PM, Richard Damon wrote:
>>>
>>> On 8/20/22 3:00 PM, olcott wrote:
>>>> On 8/20/2022 1:32 PM, Richard Damon wrote:
>>>>> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>
>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>
>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>> been
>>>>>>> attempting to shill your simulating halting decider.  I find it
>>>>>>> amusing
>>>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> I have been following these discussions for many months now. I
>>>>>> have a strong impression that there is little progress. It seems
>>>>>> that people are running in circles. I am not an expert in this
>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>> mistake.
>>>>>>
>>>>>> First the problem this is al about:
>>>>>> In computation theory we can denote a program with X and its input
>>>>>> with Y, which together is denoted as X(Y). X(Y) may end (halt) in
>>>>>> a finite number of steps, but another program X and/or input Y may
>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>> possible to create a program H that when given any program X with
>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>
>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>
>>>>>> The classical proof that it is not possible is the idea that it is
>>>>>> always possible to create a program P that uses H, with itself as
>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>> language it would be something like:
>>>>>>
>>>>>> void P(ptr x)
>>>>>> {
>>>>>>    int Halt_Status = H(x, x);
>>>>>>    if (Halt_Status)
>>>>>>      HERE: goto HERE;
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>> which would always halts with the correct answer, then it is clear
>>>>>> that there would be a contradiction if we ask H about P with
>>>>>> H(P,P). Because there are only three possibilities:
>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>> finite number of steps.
>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>
>>>>>> I think everybody agrees up to this point.
>>>>>>
>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>> aborts the simulation and returns false (0).
>>>>>>
>>>>>> Does everybody still agree up to this point?
>>>>>>
>>>>>> Now the opinions diverge.
>>>>>> Olcott thinks that his H gives the correct answer that P would not
>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>> must also be the correct answer when P actually calls the actual
>>>>>> aborting H.
>>>>>>
>>>>>> Others have a different opinion and argue that P does not call the
>>>>>> hypothetical non-aborting H, but the actual aborting H, which does
>>>>>> not go in infinite recursion, but returns false in a finite number
>>>>>> of steps. Therefore, H's result is wrong.
>>>>>>
>>>>>> Is this a correct summary of the disagreement? If not, please,
>>>>>> tell me where the summary failed. Maybe we can then find the point
>>>>>> of divergence of opinions easier.
>>>>>>
>>>>>
>>>>> The key point is the conventional proof doesn't assume a
>>>>> "Non-simulating" decider, but ANY decider, no matter how it
>>>>> determines its answer.
>>>>>
>>>>> The key error of Olcott, is the mistaken idea that just because H
>>>>> happens to be a simulating Halt Decider, it gets to change the
>>>>> criteria that it needs to decide on, and rather than being does the
>>>>> computation the input represents [that is M(x) for a call to H(M,x)
>>>>> ], halt or never halt, but can we decide instead of on a did "H
>>>>> need to abort its simulation" criteria, and that this "need" affect
>>>>> EVERY COPY of H that exists in the world. (He confuses that last
>>>>> point by mashing the code of the decided program and the decider
>>>>> into a single program and having the decided program share code
>>>>> with the decider instead of being an independent copy, as it would
>>>>> need to be to actually implement as Turing Machines.
>>>>>
>>>>> Because of this, H is actually deciding on the wrong input, the H
>>>>> that aborts is actually reporting the results of the input program
>>>>> P built on the H that doesn't abort, which is a different input
>>>>> then the input program P built on the H that does abort.
>>>>
>>>>
>>>> It is common knowledge that the correct and complete simulation of a
>>>> machine description always provides the actual behavior specified by
>>>> this machine description.
>>>
>>> Right. COMPLETE.
>>>
>>> The H that answers non-halting does NOT do a COMPLETE simulation of
>>> its input.
>>>
>>> If that input is given to a UTM equivalent, the COMPLETE simulation
>>> of that input (which still calls H) will Halt.
>>>
>>> THUS, H was wrong.
>>>
>>>>
>>>> That you and others reject this when it is applied to my simulating
>>>> halt decider implicitly rejects the notion of a UTM. Since you and
>>>> others do accept the notion of a UTM, I have just proven that your
>>>> reasoning is incoherent and/or inconsistent.
>>>
>>> Becaue you have no H that answers non-Halting that also has a
>>> COMPLETE simulation of its input that will not halt even after an
>>> unbounded number of steps.
>>>
>>>>
>>>> Whenever the simulating halt decider correctly predicts that its
>>>> correct and complete simulation of its input would never reach the
>>>> final state of this input, then the SHD is correct to reject its
>>>> input as non-halting.
>>>
>>> FALSE.
>>>
>>> IF it doesn't actually DO a complete simulation, talking about what
>>> the complete simulation it would do is MEANINGLESS.
>>>
>>> You H is answering about a different input then the one given to it.
>>>
>>>>
>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>> 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]
>>>>
>>>>
>>>>
>>>
>>> Red Herring.
>>>
>>> Fallacy of Proof by Exampe.
>>
>> When-so-ever a simulating halt decider (SHD) correctly performs a
>> partial simulation of its input and the behavior of this partial
>> simulation correctly matches a non-halting behavior pattern then the
>> SHD halt decider can correctly report non-halting.
>>
>
> Right
>
>> A non-halting behavior pattern is correct when-so-ever matching this
>> behavior pattern proves that the correct and complete simulation of
>> the input by SHD would never reach the final state of this simulated
>> input.
>>
>
> WRONG,
>

On 8/20/2022 4:18 PM, Richard Damon wrote:
>
> On 8/20/22 5:13 PM, olcott wrote:
>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>> On 8/20/22 3:46 PM, olcott wrote:
>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>
>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>
>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>
>>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>>> you've
>>>>>>>>>>>> been attempting to shill your simulating halting decider.  I
>>>>>>>>>>>> find
>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>> simulating halting decider that doesn't have the flaws your SHD
>>>>>>>>>>>> has.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>>>>>> mistake.
>>>>>>>>>>>
>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>>>> input
>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>> (halt) in
>>>>>>>>>>> a finite number of steps, but another program X and/or input
>>>>>>>>>>> Y may
>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>> possible to create a program H that when given any program X
>>>>>>>>>>> with
>>>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>>>>>
>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>
>>>>>>>>>>> The classical proof that it is not possible is the idea that
>>>>>>>>>>> it is
>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>> itself as
>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>
>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>> {
>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>      return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>>>>> which would always halts with the correct answer, then it is
>>>>>>>>>>> clear
>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>>>>>> finite number of steps.
>>>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>>>>>
>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>
>>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>>>> given
>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>
>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>
>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>> would not
>>>>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>>>>> must also be the correct answer when P actually calls the actual
>>>>>>>>>>> aborting H.
>>>>>>>>>>
>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>> The key nuance of divergence is that halting means that when
>>>>>>>>>> H(P,P)
>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>> determines that its correct simulation of its input would never
>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>
>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>> whenever it
>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>
>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>> Automata.
>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>
>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>> description correctly matches a correct infinite behavior pattern
>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>> infinite behavior.
>>>>>>>>>>
>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>> correct
>>>>>>>>>> and complete simulation of its input would never reach the final
>>>>>>>>>> state of this input.
>>>>>>>>>>
>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>> {
>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>     (void) H(x, x);
>>>>>>>>>     return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>>>>>> always return a decision to its caller).
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>>
>>>>>>>> This one uses my prior version of H named HH where the infinitely
>>>>>>>> recursive simulation is easier to see.
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>     (void) HH(x, x);
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _Px()
>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>
>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>    address   address   data      code       language
>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>> New slave_stack at:101c31
>>>>>>>>
>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>> at:111c39
>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax       //
>>>>>>>> push
>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx       //
>>>>>>>> push
>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax       //
>>>>>>>> push
>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx       //
>>>>>>>> push
>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected Simulation
>>>>>>>> Stopped*
>>>>>>>>
>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>>>> machine address of Px().
>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>> (3) With no control flow instructions between the invocation of
>>>>>>>> Px()
>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>> simulations.
>>>>>>>>
>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>> Input_Halts = 0
>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>
>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>> wrong, Px
>>>>>>> halts. Until you resolve this false positive you do not have a valid
>>>>>>> SHD.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>    (void) HH(x, x);
>>>>>>    return;
>>>>>> }
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>> }
>>>>>>
>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>> matches a non-halting behavior pattern proving that the simulated
>>>>>> input would never reach its own final state.
>>>>>>
>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> *Until HH aborts its simulation*
>>>>>>
>>>>>> All those having sufficient software engineering technical
>>>>>> competence can see this.
>>>>>>
>>>>>
>>>>> And the correct and complete simulation of the input to HH(Px,Px) is
>>>>>
>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>
>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>> (g) which returns, and thus Halts.
>>>>>
>>>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>>>> shows the actual behavior of the input to HH, comes to a Halt
>>>>>
>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>
>>>>
>>>> This sequence of instructions provides the correct and complete
>>>> simulation of the input to H(P,P):
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>     (void) Simulate(x, x);
>>>>     return;
>>>> }
>>>>
>>>> You provide the pure simulation at the wrong point in the execution
>>>> trace. In any case even in your incorrect execution trace the Px
>>>> that HH simulates never reaches its own final state, thus never halts.
>>>>
>>>>
>>>>
>>>
>>> Nope, because you changed P!
>>>
>>> P MUST be
>>>
>>>
>>> void Px(void (*x)()) {
>>>     HH(x,x);
>>> }
>>>
>>> As that is the P that was defined.
>>>
>>> Then have main be:
>>>
>>> int main() {
>>>     // The original call to HH
>>>     Output("Input_Halts = ", HH(Px, Px));
>>>
>>>     // The test
>>>     Simulate(Px,Px);
>>>     Output("But Px(Px) Halts");
>>> }
>>>
>>> I.E just DO the correct and complete simulation of the input to HH.
>>>
>>> That is the plain meaning of the words.
>>>
>>> Youy keep on trying to change the P that is the input to H to "prove"
>>> your answer.
>>>
>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>
>>
>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>
> I just did.
>
>> When-so-ever a simulating halt decider (SHD) correctly performs a
>> partial simulation of its input and the behavior of this partial
>> simulation correctly matches a non-halting behavior pattern then the
>> SHD halt decider can correctly report non-halting.
>>
>> A non-halting behavior pattern is correct when-so-ever matching this
>> behavior pattern proves that the correct and complete simulation of
>> the input by SHD would never reach the final state of this simulated
>> input.
>>
>>
>
> I just showed you the error which you didn't bother even trying to
> refute, which is just proof that you don't have a clue how to attempt
> because you understand you are wrong.
>
> You are just proving you are a pathological liar, or totally utterly
> incompetent and stupid.
>
> FAIL.

On 8/20/22 5:29 PM, olcott wrote:
> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>
>> On 8/20/22 5:13 PM, olcott wrote:
>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>
>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>>>> you've
>>>>>>>>>>>>> been attempting to shill your simulating halting decider.
>>>>>>>>>>>>> I find
>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws your
>>>>>>>>>>>>> SHD
>>>>>>>>>>>>> has.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>>>>> have a strong impression that there is little progress. It
>>>>>>>>>>>> seems
>>>>>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>>>>>>> mistake.
>>>>>>>>>>>>
>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>> In computation theory we can denote a program with X and its
>>>>>>>>>>>> input
>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>> (halt) in
>>>>>>>>>>>> a finite number of steps, but another program X and/or input
>>>>>>>>>>>> Y may
>>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>>> possible to create a program H that when given any program X
>>>>>>>>>>>> with
>>>>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>>>>> finite number of steps with the correct answer for any X and Y?
>>>>>>>>>>>>
>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>
>>>>>>>>>>>> The classical proof that it is not possible is the idea that
>>>>>>>>>>>> it is
>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>> itself as
>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>
>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>> {
>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>      return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>>>>>>> which would always halts with the correct answer, then it is
>>>>>>>>>>>> clear
>>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>>> steps,
>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not halt
>>>>>>>>>>>> in a
>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>>> number of steps, so it is not the H where the problem asked
>>>>>>>>>>>> for.
>>>>>>>>>>>>
>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>
>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>>>>> given
>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the execution
>>>>>>>>>>>> and
>>>>>>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>> recursion
>>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>
>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>
>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>> would not
>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>>>>>> must also be the correct answer when P actually calls the
>>>>>>>>>>>> actual
>>>>>>>>>>>> aborting H.
>>>>>>>>>>>
>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>> The key nuance of divergence is that halting means that when
>>>>>>>>>>> H(P,P)
>>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>> determines that its correct simulation of its input would never
>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>
>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>> whenever it
>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>
>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>> Automata.
>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>
>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>> pattern
>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>
>>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>>> correct
>>>>>>>>>>> and complete simulation of its input would never reach the final
>>>>>>>>>>> state of this input.
>>>>>>>>>>>
>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>> {
>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>     return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Px always halts if H returns to Px (and a valid halt decider must
>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This one uses my prior version of H named HH where the infinitely
>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>     return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> _Px()
>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>
>>>>>>>>> _main()
>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>
>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>    address   address   data      code       language
>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>
>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>> at:111c39
>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax       //
>>>>>>>>> push
>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx       //
>>>>>>>>> push
>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax       //
>>>>>>>>> push
>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx       //
>>>>>>>>> push
>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call 00000ca2  //
>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>> Simulation
>>>>>>>>> Stopped*
>>>>>>>>>
>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>>>>> machine address of Px().
>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>> (3) With no control flow instructions between the invocation of
>>>>>>>>> Px()
>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>> simulations.
>>>>>>>>>
>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>> Input_Halts = 0
>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>
>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>> wrong, Px
>>>>>>>> halts. Until you resolve this false positive you do not have a
>>>>>>>> valid
>>>>>>>> SHD.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>    (void) HH(x, x);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>> }
>>>>>>>
>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>> matches a non-halting behavior pattern proving that the simulated
>>>>>>> input would never reach its own final state.
>>>>>>>
>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> *Until HH aborts its simulation*
>>>>>>>
>>>>>>> All those having sufficient software engineering technical
>>>>>>> competence can see this.
>>>>>>>
>>>>>>
>>>>>> And the correct and complete simulation of the input to HH(Px,Px) is
>>>>>>
>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>
>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>> (g) which returns, and thus Halts.
>>>>>>
>>>>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>>>>> shows the actual behavior of the input to HH, comes to a Halt
>>>>>>
>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>
>>>>>
>>>>> This sequence of instructions provides the correct and complete
>>>>> simulation of the input to H(P,P):
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>>     (void) Simulate(x, x);
>>>>>     return;
>>>>> }
>>>>>
>>>>> You provide the pure simulation at the wrong point in the execution
>>>>> trace. In any case even in your incorrect execution trace the Px
>>>>> that HH simulates never reaches its own final state, thus never halts.
>>>>>
>>>>>
>>>>>
>>>>
>>>> Nope, because you changed P!
>>>>
>>>> P MUST be
>>>>
>>>>
>>>> void Px(void (*x)()) {
>>>>     HH(x,x);
>>>> }
>>>>
>>>> As that is the P that was defined.
>>>>
>>>> Then have main be:
>>>>
>>>> int main() {
>>>>     // The original call to HH
>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>
>>>>     // The test
>>>>     Simulate(Px,Px);
>>>>     Output("But Px(Px) Halts");
>>>> }
>>>>
>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>
>>>> That is the plain meaning of the words.
>>>>
>>>> Youy keep on trying to change the P that is the input to H to
>>>> "prove" your answer.
>>>>
>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>
>>>
>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>
>> I just did.
>>
>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>> partial simulation of its input and the behavior of this partial
>>> simulation correctly matches a non-halting behavior pattern then the
>>> SHD halt decider can correctly report non-halting.
>>>
>>> A non-halting behavior pattern is correct when-so-ever matching this
>>> behavior pattern proves that the correct and complete simulation of
>>> the input by SHD would never reach the final state of this simulated
>>> input.
>>>
>>>
>>
>> I just showed you the error which you didn't bother even trying to
>> refute, which is just proof that you don't have a clue how to attempt
>> because you understand you are wrong.
>>
>> You are just proving you are a pathological liar, or totally utterly
>> incompetent and stupid.
>>
>> FAIL.
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.

On 8/20/22 5:27 PM, olcott wrote:
> On 8/20/2022 4:14 PM, Richard Damon wrote:
>>
>> On 8/20/22 4:04 PM, olcott wrote:
>>> On 8/20/2022 2:27 PM, Richard Damon wrote:
>>>>
>>>> On 8/20/22 3:00 PM, olcott wrote:
>>>>> On 8/20/2022 1:32 PM, Richard Damon wrote:
>>>>>> On 8/20/22 11:01 AM, Fred. Zwarts wrote:
>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>
>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>
>>>>>>>> Which one is more likely hasn't changed for all the years you've
>>>>>>>> been
>>>>>>>> attempting to shill your simulating halting decider.  I find it
>>>>>>>> amusing
>>>>>>>> that I came up with, in less than 24 hours, a simulating halting
>>>>>>>> decider that doesn't have the flaws your SHD has.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> I have been following these discussions for many months now. I
>>>>>>> have a strong impression that there is little progress. It seems
>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>> discussion. Please, be patient when correcting me if I make any
>>>>>>> mistake.
>>>>>>>
>>>>>>> First the problem this is al about:
>>>>>>> In computation theory we can denote a program with X and its
>>>>>>> input with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>> (halt) in a finite number of steps, but another program X and/or
>>>>>>> input Y may not halt in a finite number of steps. The question
>>>>>>> is, is it possible to create a program H that when given any
>>>>>>> program X with its input Y can tell in a finite number of steps
>>>>>>> whether X(Y) halts or not? In other words, will H(X,Y) always
>>>>>>> halt after a finite number of steps with the correct answer for
>>>>>>> any X and Y?
>>>>>>>
>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>
>>>>>>> The classical proof that it is not possible is the idea that it
>>>>>>> is always possible to create a program P that uses H, with itself
>>>>>>> as input, but behaves opposite to what H returns. In a C-like
>>>>>>> language it would be something like:
>>>>>>>
>>>>>>> void P(ptr x)
>>>>>>> {
>>>>>>>    int Halt_Status = H(x, x);
>>>>>>>    if (Halt_Status)
>>>>>>>      HERE: goto HERE;
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> If there would be a hypothetical non-simulating non-aborting H,
>>>>>>> which would always halts with the correct answer, then it is
>>>>>>> clear that there would be a contradiction if we ask H about P
>>>>>>> with H(P,P). Because there are only three possibilities:
>>>>>>> 1. If H would return true (halting) in a finite number of steps,
>>>>>>> then P would start an endless loop, so H(P,P) does not halt in a
>>>>>>> finite number of steps.
>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>> steps, then P returns immediately, so H returns a wrong result.
>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>> number of steps, so it is not the H where the problem asked for.
>>>>>>>
>>>>>>> I think everybody agrees up to this point.
>>>>>>>
>>>>>>> Now Olcott has created a simulating aborting H, which, when given
>>>>>>> P with input P [so H(P,P)], creates a trace of the execution and
>>>>>>> at the point where P calls H, it uses the following logic: If H
>>>>>>> were the hypothetical non-aborting H, then an infinite recursion
>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>> aborts the simulation and returns false (0).
>>>>>>>
>>>>>>> Does everybody still agree up to this point?
>>>>>>>
>>>>>>> Now the opinions diverge.
>>>>>>> Olcott thinks that his H gives the correct answer that P would
>>>>>>> not halt when P would call the hypothetical non-aborting H, so,
>>>>>>> it must also be the correct answer when P actually calls the
>>>>>>> actual aborting H.
>>>>>>>
>>>>>>> Others have a different opinion and argue that P does not call
>>>>>>> the hypothetical non-aborting H, but the actual aborting H, which
>>>>>>> does not go in infinite recursion, but returns false in a finite
>>>>>>> number of steps. Therefore, H's result is wrong.
>>>>>>>
>>>>>>> Is this a correct summary of the disagreement? If not, please,
>>>>>>> tell me where the summary failed. Maybe we can then find the
>>>>>>> point of divergence of opinions easier.
>>>>>>>
>>>>>>
>>>>>> The key point is the conventional proof doesn't assume a
>>>>>> "Non-simulating" decider, but ANY decider, no matter how it
>>>>>> determines its answer.
>>>>>>
>>>>>> The key error of Olcott, is the mistaken idea that just because H
>>>>>> happens to be a simulating Halt Decider, it gets to change the
>>>>>> criteria that it needs to decide on, and rather than being does
>>>>>> the computation the input represents [that is M(x) for a call to
>>>>>> H(M,x) ], halt or never halt, but can we decide instead of on a
>>>>>> did "H need to abort its simulation" criteria, and that this
>>>>>> "need" affect EVERY COPY of H that exists in the world. (He
>>>>>> confuses that last point by mashing the code of the decided
>>>>>> program and the decider into a single program and having the
>>>>>> decided program share code with the decider instead of being an
>>>>>> independent copy, as it would need to be to actually implement as
>>>>>> Turing Machines.
>>>>>>
>>>>>> Because of this, H is actually deciding on the wrong input, the H
>>>>>> that aborts is actually reporting the results of the input program
>>>>>> P built on the H that doesn't abort, which is a different input
>>>>>> then the input program P built on the H that does abort.
>>>>>
>>>>>
>>>>> It is common knowledge that the correct and complete simulation of
>>>>> a machine description always provides the actual behavior specified
>>>>> by this machine description.
>>>>
>>>> Right. COMPLETE.
>>>>
>>>> The H that answers non-halting does NOT do a COMPLETE simulation of
>>>> its input.
>>>>
>>>> If that input is given to a UTM equivalent, the COMPLETE simulation
>>>> of that input (which still calls H) will Halt.
>>>>
>>>> THUS, H was wrong.
>>>>
>>>>>
>>>>> That you and others reject this when it is applied to my simulating
>>>>> halt decider implicitly rejects the notion of a UTM. Since you and
>>>>> others do accept the notion of a UTM, I have just proven that your
>>>>> reasoning is incoherent and/or inconsistent.
>>>>
>>>> Becaue you have no H that answers non-Halting that also has a
>>>> COMPLETE simulation of its input that will not halt even after an
>>>> unbounded number of steps.
>>>>
>>>>>
>>>>> Whenever the simulating halt decider correctly predicts that its
>>>>> correct and complete simulation of its input would never reach the
>>>>> final state of this input, then the SHD is correct to reject its
>>>>> input as non-halting.
>>>>
>>>> FALSE.
>>>>
>>>> IF it doesn't actually DO a complete simulation, talking about what
>>>> the complete simulation it would do is MEANINGLESS.
>>>>
>>>> You H is answering about a different input then the one given to it.
>>>>
>>>>>
>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>> 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]
>>>>>
>>>>>
>>>>>
>>>>
>>>> Red Herring.
>>>>
>>>> Fallacy of Proof by Exampe.
>>>
>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>> partial simulation of its input and the behavior of this partial
>>> simulation correctly matches a non-halting behavior pattern then the
>>> SHD halt decider can correctly report non-halting.
>>>
>>
>> Right
>>
>>> A non-halting behavior pattern is correct when-so-ever matching this
>>> behavior pattern proves that the correct and complete simulation of
>>> the input by SHD would never reach the final state of this simulated
>>> input.
>>>
>>
>> WRONG,
>>
>
> It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.

On 8/20/2022 3:18 PM, Richard Damon wrote:
>
> On 8/20/22 5:13 PM, olcott wrote:

<SNIP> garbage

> I just showed you the error which you didn't bother even trying to
> refute, which is just proof that you don't have a clue how to attempt
> because you understand you are wrong.
>
> You are just proving you are a pathological liar, or totally utterly
> incompetent and stupid.

Why don't you include "all of the above" in the above? It certainly
should be obvious after decades of this bullshit.
--
Jeff Barnett

On 8/20/2022 4:59 PM, Richard Damon wrote:
>
> On 8/20/22 5:29 PM, olcott wrote:
>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>
>>> On 8/20/22 5:13 PM, olcott wrote:
>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>>>>> you've
>>>>>>>>>>>>>> been attempting to shill your simulating halting decider.
>>>>>>>>>>>>>> I find
>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have been following these discussions for many months now. I
>>>>>>>>>>>>> have a strong impression that there is little progress. It
>>>>>>>>>>>>> seems
>>>>>>>>>>>>> that people are running in circles. I am not an expert in this
>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I make
>>>>>>>>>>>>> any
>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>
>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>> its input
>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>>>> possible to create a program H that when given any program
>>>>>>>>>>>>> X with
>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>> that it is
>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>> itself as
>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>      return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>> which would always halts with the correct answer, then it
>>>>>>>>>>>>> is clear
>>>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>>>> steps,
>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not halt
>>>>>>>>>>>>> in a
>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite number of
>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>> result.
>>>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>>>> number of steps, so it is not the H where the problem asked
>>>>>>>>>>>>> for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which, when
>>>>>>>>>>>>> given
>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>> execution and
>>>>>>>>>>>>> at the point where P calls H, it uses the following logic:
>>>>>>>>>>>>> If H
>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>> recursion
>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>> would not
>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H, so, it
>>>>>>>>>>>>> must also be the correct answer when P actually calls the
>>>>>>>>>>>>> actual
>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>
>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>> The key nuance of divergence is that halting means that when
>>>>>>>>>>>> H(P,P)
>>>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>> determines that its correct simulation of its input would never
>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>
>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>> whenever it
>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>
>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>> Automata.
>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>
>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>> pattern
>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>
>>>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>>>> correct
>>>>>>>>>>>> and complete simulation of its input would never reach the
>>>>>>>>>>>> final
>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>
>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>> {
>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>     return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt decider
>>>>>>>>>>> must
>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This one uses my prior version of H named HH where the infinitely
>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>     return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> _Px()
>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>
>>>>>>>>>> _main()
>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>
>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>
>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>> at:111c39
>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax
>>>>>>>>>> // push
>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx
>>>>>>>>>> // push
>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>> 00000ca2  //
>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax
>>>>>>>>>> // push
>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov ecx,[ebp+08]
>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx
>>>>>>>>>> // push
>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>> 00000ca2  //
>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>> Simulation
>>>>>>>>>> Stopped*
>>>>>>>>>>
>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>>>>>> machine address of Px().
>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>> (3) With no control flow instructions between the invocation
>>>>>>>>>> of Px()
>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>> simulations.
>>>>>>>>>>
>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>> Input_Halts = 0
>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>
>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>> wrong, Px
>>>>>>>>> halts. Until you resolve this false positive you do not have a
>>>>>>>>> valid
>>>>>>>>> SHD.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>    (void) HH(x, x);
>>>>>>>>    return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>> }
>>>>>>>>
>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>
>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>
>>>>>>>> All those having sufficient software engineering technical
>>>>>>>> competence can see this.
>>>>>>>>
>>>>>>>
>>>>>>> And the correct and complete simulation of the input to HH(Px,Px) is
>>>>>>>
>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>
>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>> (g) which returns, and thus Halts.
>>>>>>>
>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>>>>>> shows the actual behavior of the input to HH, comes to a Halt
>>>>>>>
>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>
>>>>>>
>>>>>> This sequence of instructions provides the correct and complete
>>>>>> simulation of the input to H(P,P):
>>>>>>
>>>>>> void Px(void (*x)())
>>>>>> {
>>>>>>     (void) Simulate(x, x);
>>>>>>     return;
>>>>>> }
>>>>>>
>>>>>> You provide the pure simulation at the wrong point in the
>>>>>> execution trace. In any case even in your incorrect execution
>>>>>> trace the Px that HH simulates never reaches its own final state,
>>>>>> thus never halts.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Nope, because you changed P!
>>>>>
>>>>> P MUST be
>>>>>
>>>>>
>>>>> void Px(void (*x)()) {
>>>>>     HH(x,x);
>>>>> }
>>>>>
>>>>> As that is the P that was defined.
>>>>>
>>>>> Then have main be:
>>>>>
>>>>> int main() {
>>>>>     // The original call to HH
>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>
>>>>>     // The test
>>>>>     Simulate(Px,Px);
>>>>>     Output("But Px(Px) Halts");
>>>>> }
>>>>>
>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>
>>>>> That is the plain meaning of the words.
>>>>>
>>>>> Youy keep on trying to change the P that is the input to H to
>>>>> "prove" your answer.
>>>>>
>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>
>>>>
>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>
>>> I just did.
>>>
>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>> partial simulation of its input and the behavior of this partial
>>>> simulation correctly matches a non-halting behavior pattern then the
>>>> SHD halt decider can correctly report non-halting.
>>>>
>>>> A non-halting behavior pattern is correct when-so-ever matching this
>>>> behavior pattern proves that the correct and complete simulation of
>>>> the input by SHD would never reach the final state of this simulated
>>>> input.
>>>>
>>>>
>>>
>>> I just showed you the error which you didn't bother even trying to
>>> refute, which is just proof that you don't have a clue how to attempt
>>> because you understand you are wrong.
>>>
>>> You are just proving you are a pathological liar, or totally utterly
>>> incompetent and stupid.
>>>
>>> FAIL.
>>
>> It is common knowledge that the correct and complete simulation of a
>> machine description always provides the actual behavior specified by
>> this machine description.
>
> Right
>
>>
>> Therefore the actual behavior of the actual input is what the behavior
>> of the input would be if the SHD performed a correct and complete
>> simulation of this input.
>>
>
> No. Because the SHD was defined to NOT do a complete simulation, but to
> abort it. The "SHD that does a complete simulation" is a different
> function than the one deciding, so it isn't the one that P is calling,
> so its behavior is irrelvent.
>
>
>> The fact that the simulated input would never reach its own final
>> state in the above case conclusively proves that this input specifies
>> a non-halting sequence of instructions.
>>
>
> Nope. Wrong Machine, The only machine that behaves that way doesn't answer.
>
> The fact that Simulate(Px,Px) does Halt for any HH that answers
> HH(Px,Px) proves that it is wrong to say non-halting.
>
> Simulate(Px,Px) is what you just references (if not by name) as the
> correct and complete simulation of the machine description that was
> given to HH.
>
>
> You keep on having two different functions that you call H (or HH) that
> you conflate in your logic.
>
> It doesn't matter what H/HH would have done if different, it matters
> what the P does that calls the H/HH that you do have.

On 8/20/22 6:33 PM, olcott wrote:
> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>
>> On 8/20/22 5:29 PM, olcott wrote:
>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>
>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the years
>>>>>>>>>>>>>>> you've
>>>>>>>>>>>>>>> been attempting to shill your simulating halting decider.
>>>>>>>>>>>>>>> I find
>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have been following these discussions for many months
>>>>>>>>>>>>>> now. I
>>>>>>>>>>>>>> have a strong impression that there is little progress. It
>>>>>>>>>>>>>> seems
>>>>>>>>>>>>>> that people are running in circles. I am not an expert in
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I
>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>>>>> possible to create a program H that when given any program
>>>>>>>>>>>>>> X with
>>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether X(Y)
>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt after a
>>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>>> that it is
>>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>>> itself as
>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>> which would always halts with the correct answer, then it
>>>>>>>>>>>>>> is clear
>>>>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>>>>> steps,
>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>>>>> halt in a
>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>>>>> number of steps, so it is not the H where the problem
>>>>>>>>>>>>>> asked for.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which,
>>>>>>>>>>>>>> when given
>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>> at the point where P calls H, it uses the following logic:
>>>>>>>>>>>>>> If H
>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>>> recursion
>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H,
>>>>>>>>>>>>>> so, it
>>>>>>>>>>>>>> must also be the correct answer when P actually calls the
>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>> The key nuance of divergence is that halting means that
>>>>>>>>>>>>> when H(P,P)
>>>>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>>> determines that its correct simulation of its input would
>>>>>>>>>>>>> never
>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>
>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>>> pattern
>>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>>>>> correct
>>>>>>>>>>>>> and complete simulation of its input would never reach the
>>>>>>>>>>>>> final
>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>     return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt decider
>>>>>>>>>>>> must
>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>> infinitely
>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>     return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> _Px()
>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>
>>>>>>>>>>> _main()
>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>
>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>
>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>>> at:111c39
>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax // push
>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx // push
>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax // push
>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx // push
>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>>> Simulation
>>>>>>>>>>> Stopped*
>>>>>>>>>>>
>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the same
>>>>>>>>>>> machine address of Px().
>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>> (3) With no control flow instructions between the invocation
>>>>>>>>>>> of Px()
>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>>> simulations.
>>>>>>>>>>>
>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>
>>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>>> wrong, Px
>>>>>>>>>> halts. Until you resolve this false positive you do not have a
>>>>>>>>>> valid
>>>>>>>>>> SHD.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>    return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> int main()
>>>>>>>>> {
>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>>
>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>
>>>>>>>>> All those having sufficient software engineering technical
>>>>>>>>> competence can see this.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>> HH(Px,Px) is
>>>>>>>>
>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>
>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>
>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we agree
>>>>>>>> shows the actual behavior of the input to HH, comes to a Halt
>>>>>>>>
>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>
>>>>>>>
>>>>>>> This sequence of instructions provides the correct and complete
>>>>>>> simulation of the input to H(P,P):
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>>     (void) Simulate(x, x);
>>>>>>>     return;
>>>>>>> }
>>>>>>>
>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>> execution trace. In any case even in your incorrect execution
>>>>>>> trace the Px that HH simulates never reaches its own final state,
>>>>>>> thus never halts.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nope, because you changed P!
>>>>>>
>>>>>> P MUST be
>>>>>>
>>>>>>
>>>>>> void Px(void (*x)()) {
>>>>>>     HH(x,x);
>>>>>> }
>>>>>>
>>>>>> As that is the P that was defined.
>>>>>>
>>>>>> Then have main be:
>>>>>>
>>>>>> int main() {
>>>>>>     // The original call to HH
>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>
>>>>>>     // The test
>>>>>>     Simulate(Px,Px);
>>>>>>     Output("But Px(Px) Halts");
>>>>>> }
>>>>>>
>>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>>
>>>>>> That is the plain meaning of the words.
>>>>>>
>>>>>> Youy keep on trying to change the P that is the input to H to
>>>>>> "prove" your answer.
>>>>>>
>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>
>>>>>
>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>>
>>>> I just did.
>>>>
>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>> partial simulation of its input and the behavior of this partial
>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>> the SHD halt decider can correctly report non-halting.
>>>>>
>>>>> A non-halting behavior pattern is correct when-so-ever matching
>>>>> this behavior pattern proves that the correct and complete
>>>>> simulation of the input by SHD would never reach the final state of
>>>>> this simulated input.
>>>>>
>>>>>
>>>>
>>>> I just showed you the error which you didn't bother even trying to
>>>> refute, which is just proof that you don't have a clue how to
>>>> attempt because you understand you are wrong.
>>>>
>>>> You are just proving you are a pathological liar, or totally utterly
>>>> incompetent and stupid.
>>>>
>>>> FAIL.
>>>
>>> It is common knowledge that the correct and complete simulation of a
>>> machine description always provides the actual behavior specified by
>>> this machine description.
>>
>> Right
>>
>>>
>>> Therefore the actual behavior of the actual input is what the
>>> behavior of the input would be if the SHD performed a correct and
>>> complete simulation of this input.
>>>
>>
>> No. Because the SHD was defined to NOT do a complete simulation, but
>> to abort it. The "SHD that does a complete simulation" is a different
>> function than the one deciding, so it isn't the one that P is calling,
>> so its behavior is irrelvent.
>>
>>
>>> The fact that the simulated input would never reach its own final
>>> state in the above case conclusively proves that this input specifies
>>> a non-halting sequence of instructions.
>>>
>>
>> Nope. Wrong Machine, The only machine that behaves that way doesn't
>> answer.
>>
>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>> HH(Px,Px) proves that it is wrong to say non-halting.
>>
>> Simulate(Px,Px) is what you just references (if not by name) as the
>> correct and complete simulation of the machine description that was
>> given to HH.
>>
>>
>> You keep on having two different functions that you call H (or HH)
>> that you conflate in your logic.
>>
>> It doesn't matter what H/HH would have done if different, it matters
>> what the P does that calls the H/HH that you do have.
>
> (1) It is common knowledge that the correct and complete simulation of a
> machine description always provides the actual behavior specified by
> this machine description.
>
> (2) Therefore the actual behavior of the actual input is what the
> behavior of the input would be if the SHD performed a correct and
> complete simulation of this input.
>

On 8/20/2022 5:59 PM, Richard Damon wrote:
> On 8/20/22 6:33 PM, olcott wrote:
>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>
>>> On 8/20/22 5:29 PM, olcott wrote:
>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the
>>>>>>>>>>>>>>>> years you've
>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have been following these discussions for many months
>>>>>>>>>>>>>>> now. I
>>>>>>>>>>>>>>> have a strong impression that there is little progress.
>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>> that people are running in circles. I am not an expert in
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I
>>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether
>>>>>>>>>>>>>>> X(Y)
>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt
>>>>>>>>>>>>>>> after a
>>>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>>>> that it is
>>>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>>>> itself as
>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>> which would always halts with the correct answer, then it
>>>>>>>>>>>>>>> is clear
>>>>>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>>>>>> steps,
>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>>>>>> halt in a
>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>>>>>> number of steps, so it is not the H where the problem
>>>>>>>>>>>>>>> asked for.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which,
>>>>>>>>>>>>>>> when given
>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>>>> recursion
>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H,
>>>>>>>>>>>>>>> so, it
>>>>>>>>>>>>>>> must also be the correct answer when P actually calls the
>>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>> The key nuance of divergence is that halting means that
>>>>>>>>>>>>>> when H(P,P)
>>>>>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>>>> determines that its correct simulation of its input would
>>>>>>>>>>>>>> never
>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>>>> pattern
>>>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> and complete simulation of its input would never reach the
>>>>>>>>>>>>>> final
>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>> decider must
>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>> infinitely
>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>     return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _Px()
>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>
>>>>>>>>>>>> _main()
>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>
>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>
>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>>>> at:111c39
>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax // push
>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx // push
>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax // push
>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx // push
>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>>>> Simulation
>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>
>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the
>>>>>>>>>>>> same
>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>> (3) With no control flow instructions between the invocation
>>>>>>>>>>>> of Px()
>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>>>> simulations.
>>>>>>>>>>>>
>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>
>>>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>>>> wrong, Px
>>>>>>>>>>> halts. Until you resolve this false positive you do not have
>>>>>>>>>>> a valid
>>>>>>>>>>> SHD.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>>>
>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>
>>>>>>>>>> All those having sufficient software engineering technical
>>>>>>>>>> competence can see this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>> HH(Px,Px) is
>>>>>>>>>
>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>
>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>
>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we
>>>>>>>>> agree shows the actual behavior of the input to HH, comes to a
>>>>>>>>> Halt
>>>>>>>>>
>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>
>>>>>>>>
>>>>>>>> This sequence of instructions provides the correct and complete
>>>>>>>> simulation of the input to H(P,P):
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>> execution trace. In any case even in your incorrect execution
>>>>>>>> trace the Px that HH simulates never reaches its own final
>>>>>>>> state, thus never halts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope, because you changed P!
>>>>>>>
>>>>>>> P MUST be
>>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)()) {
>>>>>>>     HH(x,x);
>>>>>>> }
>>>>>>>
>>>>>>> As that is the P that was defined.
>>>>>>>
>>>>>>> Then have main be:
>>>>>>>
>>>>>>> int main() {
>>>>>>>     // The original call to HH
>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>
>>>>>>>     // The test
>>>>>>>     Simulate(Px,Px);
>>>>>>>     Output("But Px(Px) Halts");
>>>>>>> }
>>>>>>>
>>>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>>>
>>>>>>> That is the plain meaning of the words.
>>>>>>>
>>>>>>> Youy keep on trying to change the P that is the input to H to
>>>>>>> "prove" your answer.
>>>>>>>
>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>
>>>>>>
>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>>>
>>>>> I just did.
>>>>>
>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>> partial simulation of its input and the behavior of this partial
>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>>
>>>>>> A non-halting behavior pattern is correct when-so-ever matching
>>>>>> this behavior pattern proves that the correct and complete
>>>>>> simulation of the input by SHD would never reach the final state
>>>>>> of this simulated input.
>>>>>>
>>>>>>
>>>>>
>>>>> I just showed you the error which you didn't bother even trying to
>>>>> refute, which is just proof that you don't have a clue how to
>>>>> attempt because you understand you are wrong.
>>>>>
>>>>> You are just proving you are a pathological liar, or totally
>>>>> utterly incompetent and stupid.
>>>>>
>>>>> FAIL.
>>>>
>>>> It is common knowledge that the correct and complete simulation of a
>>>> machine description always provides the actual behavior specified by
>>>> this machine description.
>>>
>>> Right
>>>
>>>>
>>>> Therefore the actual behavior of the actual input is what the
>>>> behavior of the input would be if the SHD performed a correct and
>>>> complete simulation of this input.
>>>>
>>>
>>> No. Because the SHD was defined to NOT do a complete simulation, but
>>> to abort it. The "SHD that does a complete simulation" is a different
>>> function than the one deciding, so it isn't the one that P is
>>> calling, so its behavior is irrelvent.
>>>
>>>
>>>> The fact that the simulated input would never reach its own final
>>>> state in the above case conclusively proves that this input
>>>> specifies a non-halting sequence of instructions.
>>>>
>>>
>>> Nope. Wrong Machine, The only machine that behaves that way doesn't
>>> answer.
>>>
>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>
>>> Simulate(Px,Px) is what you just references (if not by name) as the
>>> correct and complete simulation of the machine description that was
>>> given to HH.
>>>
>>>
>>> You keep on having two different functions that you call H (or HH)
>>> that you conflate in your logic.
>>>
>>> It doesn't matter what H/HH would have done if different, it matters
>>> what the P does that calls the H/HH that you do have.
>>
>> (1) It is common knowledge that the correct and complete simulation of
>> a machine description always provides the actual behavior specified by
>> this machine description.
>>
>> (2) Therefore the actual behavior of the actual input is what the
>> behavior of the input would be if the SHD performed a correct and
>> complete simulation of this input.
>>
>
> Nope. Proves you are an idiot. Because the SHD DOES abort it simulation,
> there is no "If it didn't" case to look at.
>
> What is the results of program X doing operation Y if program X never
> actually does operation Y.
>
> It is an ill defined condition.
>
>> (3) The fact that the simulated input would never reach its own final
>> state in the above case conclusively proves that this input specifies
>> a non-halting sequence of instructions.
>>
>> Because (1) is known to be true and (2) logically follows from (1) it
>> is impossible to correctly accept (1) and deny (2).
>>
>
> If you want to try to express your words in a correct formulation, you
> could do the following.
>
> H is defined to take THREE parameters:
>
> P the program to decide on,
> d the data for that program, and
> s a flag that forces the decider to be a pure simulator and not a decider.
>
>
> THen
>
> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run
> forever.
>
> P(x) is then defined to call H(x,x,0)
>
> And the H to decide it by the call H(P,P,0)
You are still doing the pure simulation at the wrong point in the
execution trace.

On 8/20/2022 5:59 PM, Richard Damon wrote:
> On 8/20/22 6:33 PM, olcott wrote:
>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>
>>> On 8/20/22 5:29 PM, olcott wrote:
>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>
>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>> Olcott, which of the following do you think is more likely?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the
>>>>>>>>>>>>>>>> years you've
>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have been following these discussions for many months
>>>>>>>>>>>>>>> now. I
>>>>>>>>>>>>>>> have a strong impression that there is little progress.
>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>> that people are running in circles. I am not an expert in
>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize the
>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I
>>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>>>> not halt in a finite number of steps. The question is, is it
>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether
>>>>>>>>>>>>>>> X(Y)
>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt
>>>>>>>>>>>>>>> after a
>>>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>>>> that it is
>>>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>>>> itself as
>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>> which would always halts with the correct answer, then it
>>>>>>>>>>>>>>> is clear
>>>>>>>>>>>>>>> that there would be a contradiction if we ask H about P with
>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number of
>>>>>>>>>>>>>>> steps,
>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>>>>>> halt in a
>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in a finite
>>>>>>>>>>>>>>> number of steps, so it is not the H where the problem
>>>>>>>>>>>>>>> asked for.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which,
>>>>>>>>>>>>>>> when given
>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>>>> recursion
>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's simulating H
>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H,
>>>>>>>>>>>>>>> so, it
>>>>>>>>>>>>>>> must also be the correct answer when P actually calls the
>>>>>>>>>>>>>>> actual
>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>> The key nuance of divergence is that halting means that
>>>>>>>>>>>>>> when H(P,P)
>>>>>>>>>>>>>> correctly simulates its input that this input would reach the
>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>>>> determines that its correct simulation of its input would
>>>>>>>>>>>>>> never
>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>>>> pattern
>>>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In other words the SHD decider correctly predicts that its
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> and complete simulation of its input would never reach the
>>>>>>>>>>>>>> final
>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>> decider must
>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>> infinitely
>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>
>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>     return;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> int main()
>>>>>>>>>>>> {
>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> _Px()
>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>
>>>>>>>>>>>> _main()
>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>
>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>
>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored
>>>>>>>>>>>> at:111c39
>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax // push
>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx // push
>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax // push
>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx // push
>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>>>> Simulation
>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>
>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the
>>>>>>>>>>>> same
>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>> (3) With no control flow instructions between the invocation
>>>>>>>>>>>> of Px()
>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>>>> simulations.
>>>>>>>>>>>>
>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>
>>>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>>>> wrong, Px
>>>>>>>>>>> halts. Until you resolve this false positive you do not have
>>>>>>>>>>> a valid
>>>>>>>>>>> SHD.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>> {
>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>    return;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> int main()
>>>>>>>>>> {
>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>>>
>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>
>>>>>>>>>> All those having sufficient software engineering technical
>>>>>>>>>> competence can see this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>> HH(Px,Px) is
>>>>>>>>>
>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>
>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>
>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we
>>>>>>>>> agree shows the actual behavior of the input to HH, comes to a
>>>>>>>>> Halt
>>>>>>>>>
>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>
>>>>>>>>
>>>>>>>> This sequence of instructions provides the correct and complete
>>>>>>>> simulation of the input to H(P,P):
>>>>>>>>
>>>>>>>> void Px(void (*x)())
>>>>>>>> {
>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>     return;
>>>>>>>> }
>>>>>>>>
>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>> execution trace. In any case even in your incorrect execution
>>>>>>>> trace the Px that HH simulates never reaches its own final
>>>>>>>> state, thus never halts.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope, because you changed P!
>>>>>>>
>>>>>>> P MUST be
>>>>>>>
>>>>>>>
>>>>>>> void Px(void (*x)()) {
>>>>>>>     HH(x,x);
>>>>>>> }
>>>>>>>
>>>>>>> As that is the P that was defined.
>>>>>>>
>>>>>>> Then have main be:
>>>>>>>
>>>>>>> int main() {
>>>>>>>     // The original call to HH
>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>
>>>>>>>     // The test
>>>>>>>     Simulate(Px,Px);
>>>>>>>     Output("But Px(Px) Halts");
>>>>>>> }
>>>>>>>
>>>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>>>
>>>>>>> That is the plain meaning of the words.
>>>>>>>
>>>>>>> Youy keep on trying to change the P that is the input to H to
>>>>>>> "prove" your answer.
>>>>>>>
>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>
>>>>>>
>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>>>
>>>>> I just did.
>>>>>
>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>> partial simulation of its input and the behavior of this partial
>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>>
>>>>>> A non-halting behavior pattern is correct when-so-ever matching
>>>>>> this behavior pattern proves that the correct and complete
>>>>>> simulation of the input by SHD would never reach the final state
>>>>>> of this simulated input.
>>>>>>
>>>>>>
>>>>>
>>>>> I just showed you the error which you didn't bother even trying to
>>>>> refute, which is just proof that you don't have a clue how to
>>>>> attempt because you understand you are wrong.
>>>>>
>>>>> You are just proving you are a pathological liar, or totally
>>>>> utterly incompetent and stupid.
>>>>>
>>>>> FAIL.
>>>>
>>>> It is common knowledge that the correct and complete simulation of a
>>>> machine description always provides the actual behavior specified by
>>>> this machine description.
>>>
>>> Right
>>>
>>>>
>>>> Therefore the actual behavior of the actual input is what the
>>>> behavior of the input would be if the SHD performed a correct and
>>>> complete simulation of this input.
>>>>
>>>
>>> No. Because the SHD was defined to NOT do a complete simulation, but
>>> to abort it. The "SHD that does a complete simulation" is a different
>>> function than the one deciding, so it isn't the one that P is
>>> calling, so its behavior is irrelvent.
>>>
>>>
>>>> The fact that the simulated input would never reach its own final
>>>> state in the above case conclusively proves that this input
>>>> specifies a non-halting sequence of instructions.
>>>>
>>>
>>> Nope. Wrong Machine, The only machine that behaves that way doesn't
>>> answer.
>>>
>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>
>>> Simulate(Px,Px) is what you just references (if not by name) as the
>>> correct and complete simulation of the machine description that was
>>> given to HH.
>>>
>>>
>>> You keep on having two different functions that you call H (or HH)
>>> that you conflate in your logic.
>>>
>>> It doesn't matter what H/HH would have done if different, it matters
>>> what the P does that calls the H/HH that you do have.
>>
>> (1) It is common knowledge that the correct and complete simulation of
>> a machine description always provides the actual behavior specified by
>> this machine description.
>>
>> (2) Therefore the actual behavior of the actual input is what the
>> behavior of the input would be if the SHD performed a correct and
>> complete simulation of this input.
>>
>
> Nope. Proves you are an idiot. Because the SHD DOES abort it simulation,
> there is no "If it didn't" case to look at.
>
> What is the results of program X doing operation Y if program X never
> actually does operation Y.
>
> It is an ill defined condition.
>
>> (3) The fact that the simulated input would never reach its own final
>> state in the above case conclusively proves that this input specifies
>> a non-halting sequence of instructions.
>>
>> Because (1) is known to be true and (2) logically follows from (1) it
>> is impossible to correctly accept (1) and deny (2).
>>
>
> If you want to try to express your words in a correct formulation, you
> could do the following.
>
> H is defined to take THREE parameters:
>
> P the program to decide on,
> d the data for that program, and
> s a flag that forces the decider to be a pure simulator and not a decider.
>
>
> THen
>
> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run
> forever.
>
> P(x) is then defined to call H(x,x,0)

On 8/20/22 7:10 PM, olcott wrote:
> On 8/20/2022 5:59 PM, Richard Damon wrote:
>> On 8/20/22 6:33 PM, olcott wrote:
>>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>>
>>>> On 8/20/22 5:29 PM, olcott wrote:
>>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>>> Olcott, which of the following do you think is more
>>>>>>>>>>>>>>>>> likely?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the
>>>>>>>>>>>>>>>>> years you've
>>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have been following these discussions for many months
>>>>>>>>>>>>>>>> now. I
>>>>>>>>>>>>>>>> have a strong impression that there is little progress.
>>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>>> that people are running in circles. I am not an expert
>>>>>>>>>>>>>>>> in this
>>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I
>>>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>>>>> not halt in a finite number of steps. The question is,
>>>>>>>>>>>>>>>> is it
>>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether
>>>>>>>>>>>>>>>> X(Y)
>>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt
>>>>>>>>>>>>>>>> after a
>>>>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>>>>> that it is
>>>>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>>>>> itself as
>>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>>> which would always halts with the correct answer, then
>>>>>>>>>>>>>>>> it is clear
>>>>>>>>>>>>>>>> that there would be a contradiction if we ask H about P
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number
>>>>>>>>>>>>>>>> of steps,
>>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>>>>>>> halt in a
>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in a
>>>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>>>> number of steps, so it is not the H where the problem
>>>>>>>>>>>>>>>> asked for.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which,
>>>>>>>>>>>>>>>> when given
>>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>>>>> recursion
>>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's
>>>>>>>>>>>>>>>> simulating H
>>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H,
>>>>>>>>>>>>>>>> so, it
>>>>>>>>>>>>>>>> must also be the correct answer when P actually calls
>>>>>>>>>>>>>>>> the actual
>>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>>> The key nuance of divergence is that halting means that
>>>>>>>>>>>>>>> when H(P,P)
>>>>>>>>>>>>>>> correctly simulates its input that this input would reach
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>>>>> determines that its correct simulation of its input would
>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>>>>> pattern
>>>>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In other words the SHD decider correctly predicts that
>>>>>>>>>>>>>>> its correct
>>>>>>>>>>>>>>> and complete simulation of its input would never reach
>>>>>>>>>>>>>>> the final
>>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>>> decider must
>>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>>> infinitely
>>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>>
>>>>>>>>>>>>> _main()
>>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>>
>>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>>
>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>> Stored at:111c39
>>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax // push
>>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx // push
>>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax // push
>>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx // push
>>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>>>>> Simulation
>>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>>
>>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>>> (3) With no control flow instructions between the
>>>>>>>>>>>>> invocation of Px()
>>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>>
>>>>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>>>>> wrong, Px
>>>>>>>>>>>> halts. Until you resolve this false positive you do not have
>>>>>>>>>>>> a valid
>>>>>>>>>>>> SHD.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>>>>
>>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>>
>>>>>>>>>>> All those having sufficient software engineering technical
>>>>>>>>>>> competence can see this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>> HH(Px,Px) is
>>>>>>>>>>
>>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>
>>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>>
>>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we
>>>>>>>>>> agree shows the actual behavior of the input to HH, comes to a
>>>>>>>>>> Halt
>>>>>>>>>>
>>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This sequence of instructions provides the correct and complete
>>>>>>>>> simulation of the input to H(P,P):
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>>     return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>>> execution trace. In any case even in your incorrect execution
>>>>>>>>> trace the Px that HH simulates never reaches its own final
>>>>>>>>> state, thus never halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, because you changed P!
>>>>>>>>
>>>>>>>> P MUST be
>>>>>>>>
>>>>>>>>
>>>>>>>> void Px(void (*x)()) {
>>>>>>>>     HH(x,x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> As that is the P that was defined.
>>>>>>>>
>>>>>>>> Then have main be:
>>>>>>>>
>>>>>>>> int main() {
>>>>>>>>     // The original call to HH
>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>
>>>>>>>>     // The test
>>>>>>>>     Simulate(Px,Px);
>>>>>>>>     Output("But Px(Px) Halts");
>>>>>>>> }
>>>>>>>>
>>>>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>>>>
>>>>>>>> That is the plain meaning of the words.
>>>>>>>>
>>>>>>>> Youy keep on trying to change the P that is the input to H to
>>>>>>>> "prove" your answer.
>>>>>>>>
>>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>>
>>>>>>>
>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>>>>
>>>>>> I just did.
>>>>>>
>>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>>> partial simulation of its input and the behavior of this partial
>>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>>>
>>>>>>> A non-halting behavior pattern is correct when-so-ever matching
>>>>>>> this behavior pattern proves that the correct and complete
>>>>>>> simulation of the input by SHD would never reach the final state
>>>>>>> of this simulated input.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I just showed you the error which you didn't bother even trying to
>>>>>> refute, which is just proof that you don't have a clue how to
>>>>>> attempt because you understand you are wrong.
>>>>>>
>>>>>> You are just proving you are a pathological liar, or totally
>>>>>> utterly incompetent and stupid.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> It is common knowledge that the correct and complete simulation of
>>>>> a machine description always provides the actual behavior specified
>>>>> by this machine description.
>>>>
>>>> Right
>>>>
>>>>>
>>>>> Therefore the actual behavior of the actual input is what the
>>>>> behavior of the input would be if the SHD performed a correct and
>>>>> complete simulation of this input.
>>>>>
>>>>
>>>> No. Because the SHD was defined to NOT do a complete simulation, but
>>>> to abort it. The "SHD that does a complete simulation" is a
>>>> different function than the one deciding, so it isn't the one that P
>>>> is calling, so its behavior is irrelvent.
>>>>
>>>>
>>>>> The fact that the simulated input would never reach its own final
>>>>> state in the above case conclusively proves that this input
>>>>> specifies a non-halting sequence of instructions.
>>>>>
>>>>
>>>> Nope. Wrong Machine, The only machine that behaves that way doesn't
>>>> answer.
>>>>
>>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>>
>>>> Simulate(Px,Px) is what you just references (if not by name) as the
>>>> correct and complete simulation of the machine description that was
>>>> given to HH.
>>>>
>>>>
>>>> You keep on having two different functions that you call H (or HH)
>>>> that you conflate in your logic.
>>>>
>>>> It doesn't matter what H/HH would have done if different, it matters
>>>> what the P does that calls the H/HH that you do have.
>>>
>>> (1) It is common knowledge that the correct and complete simulation
>>> of a machine description always provides the actual behavior
>>> specified by this machine description.
>>>
>>> (2) Therefore the actual behavior of the actual input is what the
>>> behavior of the input would be if the SHD performed a correct and
>>> complete simulation of this input.
>>>
>>
>> Nope. Proves you are an idiot. Because the SHD DOES abort it
>> simulation, there is no "If it didn't" case to look at.
>>
>> What is the results of program X doing operation Y if program X never
>> actually does operation Y.
>>
>> It is an ill defined condition.
>>
>>> (3) The fact that the simulated input would never reach its own final
>>> state in the above case conclusively proves that this input specifies
>>> a non-halting sequence of instructions.
>>>
>>> Because (1) is known to be true and (2) logically follows from (1) it
>>> is impossible to correctly accept (1) and deny (2).
>>>
>>
>> If you want to try to express your words in a correct formulation, you
>> could do the following.
>>
>> H is defined to take THREE parameters:
>>
>> P the program to decide on,
>> d the data for that program, and
>> s a flag that forces the decider to be a pure simulator and not a
>> decider.
>>
>>
>> THen
>>
>> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
>> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run
>> forever.
>>
>> P(x) is then defined to call H(x,x,0)
>>
>> And the H to decide it by the call H(P,P,0)
> You are still doing the pure simulation at the wrong point in the
> execution trace.
>
> x86utm Halt7.obj 1  // runs every instance of H as a pure simulator
> x86utm Halt7.obj 0  // runs every instance of H as a halt decider
>
>

On 8/20/22 7:28 PM, olcott wrote:
> On 8/20/2022 5:59 PM, Richard Damon wrote:
>> On 8/20/22 6:33 PM, olcott wrote:
>>> On 8/20/2022 4:59 PM, Richard Damon wrote:
>>>>
>>>> On 8/20/22 5:29 PM, olcott wrote:
>>>>> On 8/20/2022 4:18 PM, Richard Damon wrote:
>>>>>>
>>>>>> On 8/20/22 5:13 PM, olcott wrote:
>>>>>>> On 8/20/2022 4:05 PM, Richard Damon wrote:
>>>>>>>> On 8/20/22 3:46 PM, olcott wrote:
>>>>>>>>> On 8/20/2022 2:32 PM, Richard Damon wrote:
>>>>>>>>>>
>>>>>>>>>> On 8/20/22 3:06 PM, olcott wrote:
>>>>>>>>>>> On 8/20/2022 1:52 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 20 Aug 2022 13:50:15 -0500
>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 8/20/2022 1:32 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Sat, 20 Aug 2022 10:23:58 -0500
>>>>>>>>>>>>>> olcott <NoOne@NoWhere.com> wrote:
>>>>>>>>>>>>>>> On 8/20/2022 10:01 AM, Fred. Zwarts wrote:
>>>>>>>>>>>>>>>> Op 17.aug..2022 om 18:46 schreef Mr Flibble:
>>>>>>>>>>>>>>>>> Olcott, which of the following do you think is more
>>>>>>>>>>>>>>>>> likely?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 1) Olcott is correct and everybody else is wrong.
>>>>>>>>>>>>>>>>> 2) Olcott is wrong and everybody else is correct.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Which one is more likely hasn't changed for all the
>>>>>>>>>>>>>>>>> years you've
>>>>>>>>>>>>>>>>> been attempting to shill your simulating halting
>>>>>>>>>>>>>>>>> decider. I find
>>>>>>>>>>>>>>>>> it amusing that I came up with, in less than 24 hours, a
>>>>>>>>>>>>>>>>> simulating halting decider that doesn't have the flaws
>>>>>>>>>>>>>>>>> your SHD
>>>>>>>>>>>>>>>>> has.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have been following these discussions for many months
>>>>>>>>>>>>>>>> now. I
>>>>>>>>>>>>>>>> have a strong impression that there is little progress.
>>>>>>>>>>>>>>>> It seems
>>>>>>>>>>>>>>>> that people are running in circles. I am not an expert
>>>>>>>>>>>>>>>> in this
>>>>>>>>>>>>>>>> field. Maybe it helps if a non-expert tries to summarize
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> discussion. Please, be patient when correcting me if I
>>>>>>>>>>>>>>>> make any
>>>>>>>>>>>>>>>> mistake.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First the problem this is al about:
>>>>>>>>>>>>>>>> In computation theory we can denote a program with X and
>>>>>>>>>>>>>>>> its input
>>>>>>>>>>>>>>>> with Y, which together is denoted as X(Y). X(Y) may end
>>>>>>>>>>>>>>>> (halt) in
>>>>>>>>>>>>>>>> a finite number of steps, but another program X and/or
>>>>>>>>>>>>>>>> input Y may
>>>>>>>>>>>>>>>> not halt in a finite number of steps. The question is,
>>>>>>>>>>>>>>>> is it
>>>>>>>>>>>>>>>> possible to create a program H that when given any
>>>>>>>>>>>>>>>> program X with
>>>>>>>>>>>>>>>> its input Y can tell in a finite number of steps whether
>>>>>>>>>>>>>>>> X(Y)
>>>>>>>>>>>>>>>> halts or not? In other words, will H(X,Y) always halt
>>>>>>>>>>>>>>>> after a
>>>>>>>>>>>>>>>> finite number of steps with the correct answer for any X
>>>>>>>>>>>>>>>> and Y?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I hope that this is a correct formulation of the problem.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The classical proof that it is not possible is the idea
>>>>>>>>>>>>>>>> that it is
>>>>>>>>>>>>>>>> always possible to create a program P that uses H, with
>>>>>>>>>>>>>>>> itself as
>>>>>>>>>>>>>>>> input, but behaves opposite to what H returns. In a C-like
>>>>>>>>>>>>>>>> language it would be something like:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void P(ptr x)
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>      int Halt_Status = H(x, x);
>>>>>>>>>>>>>>>>      if (Halt_Status)
>>>>>>>>>>>>>>>>        HERE: goto HERE;
>>>>>>>>>>>>>>>>      return;
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If there would be a hypothetical non-simulating
>>>>>>>>>>>>>>>> non-aborting H,
>>>>>>>>>>>>>>>> which would always halts with the correct answer, then
>>>>>>>>>>>>>>>> it is clear
>>>>>>>>>>>>>>>> that there would be a contradiction if we ask H about P
>>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>>> H(P,P). Because there are only three possibilities:
>>>>>>>>>>>>>>>> 1. If H would return true (halting) in a finite number
>>>>>>>>>>>>>>>> of steps,
>>>>>>>>>>>>>>>> then P would start an endless loop, so H(P,P) does not
>>>>>>>>>>>>>>>> halt in a
>>>>>>>>>>>>>>>> finite number of steps.
>>>>>>>>>>>>>>>> 2. If H would return false (non-halting) in a finite
>>>>>>>>>>>>>>>> number of
>>>>>>>>>>>>>>>> steps, then P returns immediately, so H returns a wrong
>>>>>>>>>>>>>>>> result.
>>>>>>>>>>>>>>>> 3. If H does not return, then it does not return in a
>>>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>>>> number of steps, so it is not the H where the problem
>>>>>>>>>>>>>>>> asked for.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think everybody agrees up to this point.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now Olcott has created a simulating aborting H, which,
>>>>>>>>>>>>>>>> when given
>>>>>>>>>>>>>>>> P with input P [so H(P,P)], creates a trace of the
>>>>>>>>>>>>>>>> execution and
>>>>>>>>>>>>>>>> at the point where P calls H, it uses the following
>>>>>>>>>>>>>>>> logic: If H
>>>>>>>>>>>>>>>> were the hypothetical non-aborting H, then an infinite
>>>>>>>>>>>>>>>> recursion
>>>>>>>>>>>>>>>> would happen at this point. Therefore, Olcott's
>>>>>>>>>>>>>>>> simulating H
>>>>>>>>>>>>>>>> aborts the simulation and returns false (0).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Does everybody still agree up to this point?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Now the opinions diverge.
>>>>>>>>>>>>>>>> Olcott thinks that his H gives the correct answer that P
>>>>>>>>>>>>>>>> would not
>>>>>>>>>>>>>>>> halt when P would call the hypothetical non-aborting H,
>>>>>>>>>>>>>>>> so, it
>>>>>>>>>>>>>>>> must also be the correct answer when P actually calls
>>>>>>>>>>>>>>>> the actual
>>>>>>>>>>>>>>>> aborting H.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *You did a very good job summing this up*
>>>>>>>>>>>>>>> The key nuance of divergence is that halting means that
>>>>>>>>>>>>>>> when H(P,P)
>>>>>>>>>>>>>>> correctly simulates its input that this input would reach
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> "return" instruction (final state) of P. H(P,P) correctly
>>>>>>>>>>>>>>> determines that its correct simulation of its input would
>>>>>>>>>>>>>>> never
>>>>>>>>>>>>>>> reach the "return" instruction of P.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *computation that halts* … the Turing machine will halt
>>>>>>>>>>>>>>> whenever it
>>>>>>>>>>>>>>> enters a final state. (Linz:1990:234)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Linz, Peter 1990. An Introduction to Formal Languages and
>>>>>>>>>>>>>>> Automata.
>>>>>>>>>>>>>>> Lexington/Toronto: D. C. Heath and Company. (317-320)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When-so-ever the correct partial simulation of a machine
>>>>>>>>>>>>>>> description correctly matches a correct infinite behavior
>>>>>>>>>>>>>>> pattern
>>>>>>>>>>>>>>> then it is certain that this machine description specifies
>>>>>>>>>>>>>>> infinite behavior.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In other words the SHD decider correctly predicts that
>>>>>>>>>>>>>>> its correct
>>>>>>>>>>>>>>> and complete simulation of its input would never reach
>>>>>>>>>>>>>>> the final
>>>>>>>>>>>>>>> state of this input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *HERE IS THE SIMPLEST CASE OF THAT*
>>>>>>>>>>>>>>> void Infinite_Loop()
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>      HERE: goto HERE;
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And here is a case where your H gets the answer wrong:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>     (void) H(x, x);
>>>>>>>>>>>>>>     return;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Px always halts if H returns to Px (and a valid halt
>>>>>>>>>>>>>> decider must
>>>>>>>>>>>>>> always return a decision to its caller).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This one uses my prior version of H named HH where the
>>>>>>>>>>>>> infinitely
>>>>>>>>>>>>> recursive simulation is easier to see.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     (void) HH(x, x);
>>>>>>>>>>>>>     return;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> int main()
>>>>>>>>>>>>> {
>>>>>>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> _Px()
>>>>>>>>>>>>> [000010b2](01)  55             push ebp
>>>>>>>>>>>>> [000010b3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5](03)  8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8](01)  50             push eax
>>>>>>>>>>>>> [000010b9](03)  8b4d08         mov ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc](01)  51             push ecx
>>>>>>>>>>>>> [000010bd](05)  e8e0fbffff     call 00000ca2
>>>>>>>>>>>>> [000010c2](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010c5](01)  5d             pop ebp
>>>>>>>>>>>>> [000010c6](01)  c3             ret
>>>>>>>>>>>>> Size in bytes:(0021) [000010c6]
>>>>>>>>>>>>>
>>>>>>>>>>>>> _main()
>>>>>>>>>>>>> [000010d2](01)  55             push ebp
>>>>>>>>>>>>> [000010d3](02)  8bec           mov ebp,esp
>>>>>>>>>>>>> [000010d5](05)  68b2100000     push 000010b2
>>>>>>>>>>>>> [000010da](05)  68b2100000     push 000010b2
>>>>>>>>>>>>> [000010df](05)  e8befbffff     call 00000ca2
>>>>>>>>>>>>> [000010e4](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010e7](01)  50             push eax
>>>>>>>>>>>>> [000010e8](05)  6863040000     push 00000463
>>>>>>>>>>>>> [000010ed](05)  e890f3ffff     call 00000482
>>>>>>>>>>>>> [000010f2](03)  83c408         add esp,+08
>>>>>>>>>>>>> [000010f5](02)  33c0           xor eax,eax
>>>>>>>>>>>>> [000010f7](01)  5d             pop ebp
>>>>>>>>>>>>> [000010f8](01)  c3             ret
>>>>>>>>>>>>> Size in bytes:(0039) [000010f8]
>>>>>>>>>>>>>
>>>>>>>>>>>>>    machine   stack     stack     machine    assembly
>>>>>>>>>>>>>    address   address   data      code       language
>>>>>>>>>>>>>    ========  ========  ========  =========  =============
>>>>>>>>>>>>> [000010d2][00101b8d][00000000] 55             push ebp
>>>>>>>>>>>>> [000010d3][00101b8d][00000000] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010d5][00101b89][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>>> [000010da][00101b85][000010b2] 68b2100000     push 000010b2
>>>>>>>>>>>>> [000010df][00101b81][000010e4] e8befbffff     call 00000ca2
>>>>>>>>>>>>> New slave_stack at:101c31
>>>>>>>>>>>>>
>>>>>>>>>>>>> Begin Local Halt Decider Simulation   Execution Trace
>>>>>>>>>>>>> Stored at:111c39
>>>>>>>>>>>>> [000010b2][00111c25][00111c29] 55             push ebp
>>>>>>>>>>>>> [000010b3][00111c25][00111c29] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5][00111c25][00111c29] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8][00111c21][000010b2] 50             push eax // push
>>>>>>>>>>>>> Px [000010b9][00111c21][000010b2] 8b4d08         mov
>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc][00111c1d][000010b2] 51             push ecx // push
>>>>>>>>>>>>> Px [000010bd][00111c19][000010c2] e8e0fbffff     call
>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>> call HH New slave_stack at:14c659
>>>>>>>>>>>>> [000010b2][0015c64d][0015c651] 55             push ebp
>>>>>>>>>>>>> [000010b3][0015c64d][0015c651] 8bec           mov ebp,esp
>>>>>>>>>>>>> [000010b5][0015c64d][0015c651] 8b4508         mov eax,[ebp+08]
>>>>>>>>>>>>> [000010b8][0015c649][000010b2] 50             push eax // push
>>>>>>>>>>>>> Px [000010b9][0015c649][000010b2] 8b4d08         mov
>>>>>>>>>>>>> ecx,[ebp+08]
>>>>>>>>>>>>> [000010bc][0015c645][000010b2] 51             push ecx // push
>>>>>>>>>>>>> Px [000010bd][0015c641][000010c2] e8e0fbffff     call
>>>>>>>>>>>>> 00000ca2  //
>>>>>>>>>>>>> call HH *Local Halt Decider: Infinite Recursion Detected
>>>>>>>>>>>>> Simulation
>>>>>>>>>>>>> Stopped*
>>>>>>>>>>>>>
>>>>>>>>>>>>> *When HH(Px,Px) simulates its input it sees that*
>>>>>>>>>>>>> (1) Function HH(Px,Px) is called twice in sequence from the
>>>>>>>>>>>>> same
>>>>>>>>>>>>> machine address of Px().
>>>>>>>>>>>>> (2) With the same arguments to HH(Px,Px).
>>>>>>>>>>>>> (3) With no control flow instructions between the
>>>>>>>>>>>>> invocation of Px()
>>>>>>>>>>>>> and its call to HH(Px,Px) that could possibly escape repeated
>>>>>>>>>>>>> simulations.
>>>>>>>>>>>>>
>>>>>>>>>>>>> [000010e4][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>> [000010e7][00101b89][00000000] 50             push eax
>>>>>>>>>>>>> [000010e8][00101b85][00000463] 6863040000     push 00000463
>>>>>>>>>>>>> [000010ed][00101b85][00000463] e890f3ffff     call 00000482
>>>>>>>>>>>>> Input_Halts = 0
>>>>>>>>>>>>> [000010f2][00101b8d][00000000] 83c408         add esp,+08
>>>>>>>>>>>>> [000010f5][00101b8d][00000000] 33c0           xor eax,eax
>>>>>>>>>>>>> [000010f7][00101b91][00000018] 5d             pop ebp
>>>>>>>>>>>>> [000010f8][00101b95][00000000] c3             ret
>>>>>>>>>>>>> Number of Instructions Executed(15322) == 229 Pages
>>>>>>>>>>>>
>>>>>>>>>>>> All your trace is doing is confirming that H gets the answer
>>>>>>>>>>>> wrong, Px
>>>>>>>>>>>> halts. Until you resolve this false positive you do not have
>>>>>>>>>>>> a valid
>>>>>>>>>>>> SHD.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void Px(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>>    (void) HH(x, x);
>>>>>>>>>>>    return;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> int main()
>>>>>>>>>>> {
>>>>>>>>>>>    Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Because HH is a simulating halt decider (SHD) it continues to
>>>>>>>>>>> perform a pure x86 emulation of its input until it correctly
>>>>>>>>>>> matches a non-halting behavior pattern proving that the
>>>>>>>>>>> simulated input would never reach its own final state.
>>>>>>>>>>>
>>>>>>>>>>> (a) HH(Px,Px) simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>> *Until HH aborts its simulation*
>>>>>>>>>>>
>>>>>>>>>>> All those having sufficient software engineering technical
>>>>>>>>>>> competence can see this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> And the correct and complete simulation of the input to
>>>>>>>>>> HH(Px,Px) is
>>>>>>>>>>
>>>>>>>>>> (a) Simulate Px(Px) that calls a sumulated HH(Px,Px)
>>>>>>>>>> (b) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (c) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (d) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>> (e) that simulates Px(Px) that calls a simulated HH(Px,Px)
>>>>>>>>>>
>>>>>>>>>> *Until the SIMULATED HH from (a) abort ITS simulate.
>>>>>>>>>> (f) returns 0 to the simulated Px(Px) from (a)
>>>>>>>>>> (g) which returns, and thus Halts.
>>>>>>>>>>
>>>>>>>>>> Thus, the COMPLETE simulation of the input to HH, which we
>>>>>>>>>> agree shows the actual behavior of the input to HH, comes to a
>>>>>>>>>> Halt
>>>>>>>>>>
>>>>>>>>>> The HH(Px,Px) returning 0 is INCORRECT.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This sequence of instructions provides the correct and complete
>>>>>>>>> simulation of the input to H(P,P):
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>>     (void) Simulate(x, x);
>>>>>>>>>     return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> You provide the pure simulation at the wrong point in the
>>>>>>>>> execution trace. In any case even in your incorrect execution
>>>>>>>>> trace the Px that HH simulates never reaches its own final
>>>>>>>>> state, thus never halts.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, because you changed P!
>>>>>>>>
>>>>>>>> P MUST be
>>>>>>>>
>>>>>>>>
>>>>>>>> void Px(void (*x)()) {
>>>>>>>>     HH(x,x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> As that is the P that was defined.
>>>>>>>>
>>>>>>>> Then have main be:
>>>>>>>>
>>>>>>>> int main() {
>>>>>>>>     // The original call to HH
>>>>>>>>     Output("Input_Halts = ", HH(Px, Px));
>>>>>>>>
>>>>>>>>     // The test
>>>>>>>>     Simulate(Px,Px);
>>>>>>>>     Output("But Px(Px) Halts");
>>>>>>>> }
>>>>>>>>
>>>>>>>> I.E just DO the correct and complete simulation of the input to HH.
>>>>>>>>
>>>>>>>> That is the plain meaning of the words.
>>>>>>>>
>>>>>>>> Youy keep on trying to change the P that is the input to H to
>>>>>>>> "prove" your answer.
>>>>>>>>
>>>>>>>> THIS IS NOT ALLOWED, and shows that you are just a cheat.
>>>>>>>
>>>>>>>
>>>>>>> *NO ONE CAN POINT OUT AN ERROR WITH THIS BECAUSE THERE IS NO ERROR*
>>>>>>
>>>>>> I just did.
>>>>>>
>>>>>>> When-so-ever a simulating halt decider (SHD) correctly performs a
>>>>>>> partial simulation of its input and the behavior of this partial
>>>>>>> simulation correctly matches a non-halting behavior pattern then
>>>>>>> the SHD halt decider can correctly report non-halting.
>>>>>>>
>>>>>>> A non-halting behavior pattern is correct when-so-ever matching
>>>>>>> this behavior pattern proves that the correct and complete
>>>>>>> simulation of the input by SHD would never reach the final state
>>>>>>> of this simulated input.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I just showed you the error which you didn't bother even trying to
>>>>>> refute, which is just proof that you don't have a clue how to
>>>>>> attempt because you understand you are wrong.
>>>>>>
>>>>>> You are just proving you are a pathological liar, or totally
>>>>>> utterly incompetent and stupid.
>>>>>>
>>>>>> FAIL.
>>>>>
>>>>> It is common knowledge that the correct and complete simulation of
>>>>> a machine description always provides the actual behavior specified
>>>>> by this machine description.
>>>>
>>>> Right
>>>>
>>>>>
>>>>> Therefore the actual behavior of the actual input is what the
>>>>> behavior of the input would be if the SHD performed a correct and
>>>>> complete simulation of this input.
>>>>>
>>>>
>>>> No. Because the SHD was defined to NOT do a complete simulation, but
>>>> to abort it. The "SHD that does a complete simulation" is a
>>>> different function than the one deciding, so it isn't the one that P
>>>> is calling, so its behavior is irrelvent.
>>>>
>>>>
>>>>> The fact that the simulated input would never reach its own final
>>>>> state in the above case conclusively proves that this input
>>>>> specifies a non-halting sequence of instructions.
>>>>>
>>>>
>>>> Nope. Wrong Machine, The only machine that behaves that way doesn't
>>>> answer.
>>>>
>>>> The fact that Simulate(Px,Px) does Halt for any HH that answers
>>>> HH(Px,Px) proves that it is wrong to say non-halting.
>>>>
>>>> Simulate(Px,Px) is what you just references (if not by name) as the
>>>> correct and complete simulation of the machine description that was
>>>> given to HH.
>>>>
>>>>
>>>> You keep on having two different functions that you call H (or HH)
>>>> that you conflate in your logic.
>>>>
>>>> It doesn't matter what H/HH would have done if different, it matters
>>>> what the P does that calls the H/HH that you do have.
>>>
>>> (1) It is common knowledge that the correct and complete simulation
>>> of a machine description always provides the actual behavior
>>> specified by this machine description.
>>>
>>> (2) Therefore the actual behavior of the actual input is what the
>>> behavior of the input would be if the SHD performed a correct and
>>> complete simulation of this input.
>>>
>>
>> Nope. Proves you are an idiot. Because the SHD DOES abort it
>> simulation, there is no "If it didn't" case to look at.
>>
>> What is the results of program X doing operation Y if program X never
>> actually does operation Y.
>>
>> It is an ill defined condition.
>>
>>> (3) The fact that the simulated input would never reach its own final
>>> state in the above case conclusively proves that this input specifies
>>> a non-halting sequence of instructions.
>>>
>>> Because (1) is known to be true and (2) logically follows from (1) it
>>> is impossible to correctly accept (1) and deny (2).
>>>
>>
>> If you want to try to express your words in a correct formulation, you
>> could do the following.
>>
>> H is defined to take THREE parameters:
>>
>> P the program to decide on,
>> d the data for that program, and
>> s a flag that forces the decider to be a pure simulator and not a
>> decider.
>>
>>
>> THen
>>
>> H(P,d,0) is correct to return 1 if H(P,d,1) Halts, and
>> H(P,d,0) is correct to return 0 if H(P,d,1) will never halt but run
>> forever.
>>
>> P(x) is then defined to call H(x,x,0)
>
> *We could prove my point another way too*
>
> The simulating halt decider writes a 1 or a 0 to a specific tape
> location that is initialized to blank. It does this as soon as it
> correctly detects that its complete simulation would never stop running.
>
> HERE IS THE KEY DIFFERENCE:
> H continues to perform this complete simulation, thus never stops
> running. Because it has reported this it is correct.
>
> The assumption that H must stop to report its decision is refuted.