Deutsch English Français Italiano |
<c949f7799a59ba8403d4a346c823114fb642ac34@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder2.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: The philosophy of computation reformulates existing ideas on a new basis --- Date: Wed, 30 Oct 2024 23:18:51 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <c949f7799a59ba8403d4a346c823114fb642ac34@i2pn2.org> References: <veoift$29dtl$2@dont-email.me> <vffk1i$33iat$1@dont-email.me> <vfgaev$36im7$5@dont-email.me> <vfi743$3kr1e$1@dont-email.me> <vfip3l$3ner2$2@dont-email.me> <1bc1ab08ec47bf818ddff1d4f63b542ceadd6985@i2pn2.org> <vfjokd$3su2f$1@dont-email.me> <vfk3jl$3kr0c$5@i2pn2.org> <vfk4lk$3ukdm$1@dont-email.me> <vfl8o9$3mnmt$5@i2pn2.org> <vfli1h$fj8s$1@dont-email.me> <vflue8$3nvp8$2@i2pn2.org> <vfmd8m$k2m7$1@dont-email.me> <bcd82d9f8a987d3884220c0df7b8f7204cb9de3e@i2pn2.org> <vfmueh$mqn9$1@dont-email.me> <ff039b922cabbb6d44f90aa71a52d8c2f446b6ab@i2pn2.org> <vfo95k$11qs1$1@dont-email.me> <vfp8c0$3tobi$2@i2pn2.org> <vfpcko$1837o$3@dont-email.me> <vfpish$3u885$2@i2pn2.org> <vfpjk2$1976k$1@dont-email.me> <086fc32f14bcc004466d3128b0fe585b27377399@i2pn2.org> <vfqsui$1jg6i$2@dont-email.me> <vft4om$44tc$2@i2pn2.org> <vft944$25aio$6@dont-email.me> <11408789ed30027f4bc9a743f353dfa9b4712109@i2pn2.org> <QU2dnTAfup30Rr_6nZ2dnZfqn_WdnZ2d@brightview.co.uk> <vfumog$2d1a7$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 31 Oct 2024 03:18:51 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="236349"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: <vfumog$2d1a7$1@dont-email.me> Content-Language: en-US Bytes: 7629 Lines: 136 On 10/30/24 9:33 PM, olcott wrote: > On 10/30/2024 8:20 PM, Mike Terry wrote: >> On 30/10/2024 23:35, Richard Damon wrote: >>> On 10/30/24 8:34 AM, olcott wrote: >>>> On 10/30/2024 6:19 AM, Richard Damon wrote: >>>>> On 10/29/24 10:54 AM, olcott wrote: >>>>>> On 10/29/2024 5:50 AM, Richard Damon wrote: >>>>>>> On 10/28/24 11:08 PM, olcott wrote: >>>>>>>> On 10/28/2024 9:56 PM, Richard Damon wrote: >>>>>>>>> On 10/28/24 9:09 PM, olcott wrote: >>>>>>>>>> On 10/28/2024 6:56 PM, Richard Damon wrote: >>>>>>>>>>> >>>>>>>>>>> It is IMPOSSIBLE to emulate DDD per the x86 semantics without >>>>>>>>>>> the code for HHH, so it needs to be part of the input. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> *You seemed to be a totally Jackass here* >>>>>>>>>> You are not that stupid >>>>>>>>>> You are not that ignorant >>>>>>>>>> and this is not your ADD >>>>>>>>>> >>>>>>>>>> _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] >>>>>>>>>> >>>>>>>>>> At machine address 0000217a HHH emulates itself emulating >>>>>>>>>> DDD without knowing that it is emulating itself. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Then how did it convert the call HHH into an emulation of DDD >>>>>>>>> again? >>>>>>>>> >>>>>>>> >>>>>>>> When HHH (unknowingly) emulates itself emulating DDD this >>>>>>>> emulated HHH is going to freaking emulate DDD. >>>>>>>> >>>>>>>> Did you think it was going to play poker? >>>>>>>> >>>>>>> >>>>>>> Which is what it would do, get stuck and fail to be a decider. It >>>>>>> might figure out that it is emulating an emulating decider, at >>>>>>> which point it knows that the decider might choose to abort its >>>>>>> conditional emulation to return, so it needs to emulate further. >>>>>>> >>>>>>> Only by recognizing itself, does it have grounds to say that if I >>>>>>> don't abort, it never will, and thus I am stuck, so I need to abort. >>>>>>> >>>>>> >>>>>> Counter-factual. This algorithm has no ability to KNOW ITS OWN CODE. >>>>>> https://github.com/plolcott/x86utm/blob/master/Halt7.c // page 801 >>>>>> >>>>>> *That people fail to agree with this and also fail to* >>>>>> *correctly point out any error seems to indicate dishonestly* >>>>>> *or lack of technical competence* >>>>>> >>>>>> DDD emulated by HHH according to the semantics of the x86 >>>>>> language cannot possibly reach its own "return" instruction >>>>>> whether or not any HHH ever aborts its emulation of DDD. >>>>>> >>>>>> I read, reread again and again to make sure that my understanding >>>>>> is correct. You seems to glance at a few words before spouting off >>>>>> a canned rebuttal that does not even apply to my words. >>>>>> >>>>> >>>>> >>>>> No, it knows its own code because it rule for "No conditional >>>>> branches" excludes that code. >>>>> >>>> >>>> It does not know its own code. It merely knows that the >>>> machine address that it is looking at belongs to the >>>> operating system. I simply don't have the fifty labor >>>> years that AProVE: Non-Termination Witnesses for C Programs, >>>> could spend on handling conditional branches. >>>> >>>> The stupid aspect on your part is that even knowing >>>> that its own code halts THIS HAS NOTHING TO DO WITH >>>> DDD REACHING TS OWN RETURN INSTRUCTION. >>>> >>>> >>> >>> No, HHH is NOT part of the "Operating System" so your claims are just >>> a lie, >> >> PO definitely has a deep-rooted problem with his thinking here. >> Comments in his code suggest he really does believe somehow that HHH >> counts as "OS code" which can be ignored! It's all over the place in >> the code... >> >> It reminds me as well of his "global" halt decider thinking which (as >> I understand it) was some scheme he had early on, where the equivalent >> of HHH really would have been part of x86utm.exe (arguably "the OS") >> rather than part of halt7.c. Thankfully that thinking was abandonned >> long ago, but when PO abandons some line of argument that's not an >> indication that he has understood his error - simply that he >> recognises that he's not getting anywhere [and has no prospect of >> getting anywhere] with that line of argument. >> >> >> Mike. >> > > *None of any of that matters for the current point* Of course ir matters. > > DDD emulated by HHH according to the semantics of the x86 > language cannot possibly reach its own "return" instruction > whether or not any HHH ever aborts its emulation of DDD. Which your HHH doesn't do, so that criteria means nothing, > > *We can't move on to any other point until we have this basis* > > > Right, so until you clarify that you are NOT working by the definitions of Computation Theory (and thus NOTHING you say applies to it, like to the Halting Problem) and then actually define what your words mean, starting with clarifying the equivocations pointed out, means you can't talk about any of the things you want to, because until you do that, you are just lying because you put yourself into the field, and keep on mentioning it, but don't want to be there. I suggest you may find that lake of fire to be your best option, as at least there you will be with others that agree with you. Sorry, but that is just the facts.