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.