Re: Hypothetical possibilities --- Complete Proof

On 2024-08-02 17:39:00 +0000, Mike Terry said:

On 02/08/2024 11:12, Mikko wrote:

On 2024-08-01 13:29:24 +0000, olcott said:
 

On 8/1/2024 8:12 AM, Fred. Zwarts wrote:

Op 01.aug.2024 om 14:20 schreef olcott:

On 8/1/2024 3:10 AM, Fred. Zwarts wrote:

Op 31.jul.2024 om 23:23 schreef olcott:

On 7/31/2024 3:01 PM, Fred. Zwarts wrote:

Op 31.jul.2024 om 17:14 schreef olcott:

On 7/31/2024 3:44 AM, Fred. Zwarts wrote:

Op 31.jul.2024 om 06:09 schreef olcott:

   machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[00002192][00103820][00000000] 55         push ebp
[00002193][00103820][00000000] 8bec       mov ebp,esp
[00002195][0010381c][00002172] 6872210000 push 00002172 ; push DDD
[0000219a][00103818][0000219f] e833f4ffff call 000015d2 ; call HHH(DDD)
New slave_stack at:1038c4
 We don't show any of HHH and show the execution trace of
of just DDD assuming that HHH is an x86 emulator.

 This assumption is incorrect if it means that HHH is an unconditional simulator that does not abort.

This algorithm is used by all the simulating termination analyzers:
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     *If simulating halt decider H correctly simulates its input D*
     *until H correctly determines that its simulated D would never*
     *stop running unless aborted* then
      H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

 So, Sipser only agreed to a correct simulation, not with an incorrect simulation that violates the semantics of the x86 language by skipping the last few instructions of a halting program.
 

 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 int main()
{
   HHH(DD);
}
 DD correctly emulated by HHH cannot possibly reach its own
second line. I switched to DDD correctly emulated by HHH

 But it has been proven that no such HHH exists that simulates itself correctly. So, talking about a correct simulation by HHH is vacuous word salad.
 

because only C experts understood the above example and we
never had any of those here.

 There are many C experts that looked at it, but you only got critic, because you keep hiding important properties of HHH, which made the conclusion impossible.

 The following is all that is needed for 100% complete proof
that HHH did emulate DDD correctly according to the semantics
of the x86 language and did emulate itself emulating DDD
according to these same semantics.

 You are repeating the same false claim with out any self-reflection. It has been pointed out that there are many errors in this proof.
Why repeating such errors?
 

 _DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
 Begin Local Halt Decider Simulation   Execution Trace Stored at:1138cc
[00002172][001138bc][001138c0] 55         push ebp      ; housekeeping
[00002173][001138bc][001138c0] 8bec       mov ebp,esp   ; housekeeping
[00002175][001138b8][00002172] 6872210000 push 00002172 ; push DDD
[0000217a][001138b4][0000217f] e853f4ffff call 000015d2 ; call HHH(DDD)

 The trace stops and hides what happens when 000015d2 is called.
Olcott is hiding the conditional branch instructions in the recursion.
 

 *Here is the full trace where nothing is hidden*
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

 On page 36 of that "trace"
   [0000128c][0010379f][00000018] e8e6f4ffff call 00000777
is not followed by the trace of 00000777. Instead the trace continues
with the next instruction after the return without any comment about
the omission. Meaning of 00000777 is not told.
 

 777 is the address of Allocate, which is one of PO's "primative ops" within his "computing model". (Similar to his DebugStep().)

Yes, it is a minor issue. However, he claims that there are not conditions
in the program simulated in the simulated simulation, and that means that
he must prove that all untraced functions always return as if the contained
no conditional execution. The x86 semantics do not rquire that a called
function returns. Even C semantics allows some cases of non-return.
--
Mikko