Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: Hypothetical possibilities --- Complete Proof Date: Fri, 2 Aug 2024 17:35:39 -0500 Organization: A noiseless patient Spider Lines: 305 Message-ID: References:

<9f3112e056ad6eebf35f940c34b802b46addcad4@i2pn2.org>

<-Vednah5VvbtwTD7nZ2dnZfqnPSdnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 03 Aug 2024 00:35:40 +0200 (CEST) Injection-Info: dont-email.me; posting-host="6697133516c971b81fd53169bb6a94ea"; logging-data="3202976"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f0e66fttXDd9s0CkN0HTk" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:VoixHgILjmBqnKGU0zixw6un2K8= Content-Language: en-US In-Reply-To: <-Vednah5VvbtwTD7nZ2dnZfqnPSdnZ2d@brightview.co.uk> Bytes: 15817 On 8/2/2024 5:23 PM, Mike Terry wrote: > On 02/08/2024 19:25, Richard Damon wrote: >> On 8/2/24 1:39 PM, Mike Terry wrote: >>> 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: >>>>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> 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().) >>> >>> It is implemented inside x86utm.exe (his COFF obj code runner), not >>> in the user code DDD/HHH/etc. in the obj file, and so we would not >>> expect to see any trace entries for its internals. When the op >>> concludes, rax has the address of the allocated memory, which is >>> consistent with how a normal function would have returned the address. >>> >>> You can say correctly that PO has not explained this, but then he >>> provided the full trace under protest, so it's understandable that he >>> has not previously explained everything in it. I'm surprised that >>> his response to your post was both to ignore the question and accuse >>> you of playing sadistic head games, as the question was perfectly >>> sensible. >>> >>> You can look up the 777 address in the listing at the start of the >>> trace and it's there along with a bunch of other routines which >>> appear to just return without doing anything - those are all PO's >>> primitive ops. If you feel a need to understand exactly what they >>> do, you'll need to check his source code! (Although for Allocate >>> there is no big surprise...) >>> >>> >>> So your observation isn't really a problem beyond not being properly >>> explained. An actual problem seen in his trace data is that the >>> simulation of DDD does not track the behaviour of the unsimulated >>> DDD. I.e. his simulation is incorrect. (PO knows about that but >>> claims it doesn't matter, although on other occasions he still claims >>> the simulation is correct.) >>> >>> >>> Mike. >>> >> >> But the bigger error that totally negates this trace is if you at >> where it begins, it is at program address 00002197, which just the >> page before is shown to be the address of _main. ========== REMAINDER OF ARTICLE TRUNCATED ==========