Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory,sci.logic Subject: Re: How Partial Simulations correctly determine non-halting ---Should I quit Richard at this point? Date: Sat, 8 Jun 2024 10:32:53 -0500 Organization: A noiseless patient Spider Lines: 141 Message-ID: References: <87h6eamkgf.fsf@bsb.me.uk> <_gWdnbwuZPJP2sL7nZ2dnZfqn_GdnZ2d@brightview.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 08 Jun 2024 17:32:54 +0200 (CEST) Injection-Info: dont-email.me; posting-host="99ea1b6838dd1404bad406fc122dbf0f"; logging-data="2806990"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX186t2Anh2qyF9SFOjKJURJW" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:yeJTkxwE6zeZPu/aIRByyRlBN9c= Content-Language: en-US In-Reply-To: Bytes: 6888 On 6/8/2024 10:15 AM, Richard Damon wrote: > On 6/8/24 11:07 AM, olcott wrote: >> On 6/8/2024 9:54 AM, Richard Damon wrote: >>> On 6/8/24 10:20 AM, olcott wrote: >>>> On 6/8/2024 9:10 AM, Richard Damon wrote: >>>>> >>>>> I HAVE pointed out what is missing, ANY set of truth-perserving >>>>> operations from the accepted facts (which will of course need to >>>>> name the fact they are working from) to your conclusion. >>>> >>>> The accepted facts are here >>>> (a) The x86 language >>>> (b) The notion of an x86 emulator >>>> >>>> {The proof that No DDD correctly emulated by any x86 >>>>   emulator H can possibly reach its own [00001df6] instruction} >>> >>> So, how do you show this claim? >>> >>> Do you have a tracing of the full INFINITE SET of possible Hs? >>> >>>> >>>> Is the set of possible execution traces of DDD correctly >>>> emulated by x86 emulator HH on the basis of the above >>>> accepted facts. >>>> >>>> Maybe you are just clueless about these technical details >>>> are are trying to hide this with pure bluster. >>>> >>>> _DDD() >>>> [00001de2] 55         push ebp >>>> [00001de3] 8bec       mov ebp,esp >>>> [00001de5] 8b4508     mov eax,[ebp+08] >>>> [00001de8] 50         push eax         ; push DD >>>> [00001de9] 8b4d08     mov ecx,[ebp+08] >>>> [00001dec] 51         push ecx         ; push DD >>>> [00001ded] e890f5ffff call 00001382    ; call HH >>>> [00001df2] 83c408     add esp,+08 >>>> [00001df5] 5d         pop ebp >>>> [00001df6] c3         ret >>>> Size in bytes:(0021) [00001df6] >>>> >>>> You keep disagreeing with the fact that DDD correctly >>>> emulated by x86 emulator HH only has one single correct >>>> execution trace of repeating the fist seven lines until >>>> out-of-memory error. >>>> >>> >>> But that is an INCORRECT trace per your definition, >>> >>> The call HH instruction MUST be simulated into HH because that IS the >>> behavior of the x86 instruction. >> >> Did I ever say that it is not? >> For the above DDD correctly emulated by x86 emulator HH >> the first seven instructions of DD keep repeating because >> DDD keeps calling HH(DDD,DDD) to emulate itself again and >> again until HH/DDD hits out-of-memory exception. > > So the x86 emulation of the code must go into HH(DDD,DDD) > It is pretty stupid to assume otherwise when HH is stipulated to be an x86 emulator. > The correct x86 emulation of the call to HH(DDD,DDD) will NEVER get to > the sequence of instrucitions starting at 00001DE2, as the code will > never jump there to just execute it. > Your are saying that incorrectly DDD correctly emulated by x86 emulator HH cannot possibly reach it own machine address of [00001df6]. > By your code, the simulator will "Debug Step" those instructions. > The underlying details of one HH are irrelevant when I reference an infinite set: {The proof that No DDD correctly emulated by any x86 emulator H any x86 emulator H any x86 emulator H any x86 emulator H any x86 emulator H any x86 emulator H can possibly reach its own [00001df6] instruction} > By a pure emulator, that would mean translating the machine code into > the operations it will perform, and then manipulating the virtual > register set being kept by the emulator. > libx86emu does that. > If your "simulation" is ACTUALLY being done using the debug step > hardware of the system (or simulating the actions of that hardware) then > the instruction are executed, but not in sequence as they have all the > steps of the debugger/tracing around them. > That is not how x86 emulators work. > So, your claim of what happens just shows you don't understand what the > program you are using actually is doing. > No it shows that you don't know how x86 emulators work. > That might explain why the trace you posted the other day wasn't > actually the trace you claimed it was. > We are only focusing on this one thread and zero deflection will be tolerated. >> >> This is the only post that I will reply to you on. >> I need you to stay focused on this one single point >> until you understand it. > > Is that a promise? I think you will break it. > When you proved to break out of your "stuck in rebuttal mode" nonsense and talked about closure I backed off this requirement for a while. *Even Ben admits that H does meet the Sipser criteria* On 10/14/2022 7:44 PM, Ben Bacarisse wrote: > I don't think that is the shell game. PO really /has/ an H > (it's trivial to do for this one case) that correctly determines > that P(P) *would* never stop running *unless* aborted. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer