Deutsch English Français Italiano |
<vbri9h$3g2ju$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Mikko <mikko.levanto@iki.fi> Newsgroups: comp.theory Subject: Re: Indirect Reference Changes the Behavior of DDD() relative to DDD emulated by HHH --- Deception Date: Wed, 11 Sep 2024 10:53:21 +0300 Organization: - Lines: 142 Message-ID: <vbri9h$3g2ju$1@dont-email.me> References: <va104l$376ed$4@dont-email.me> <vaj1kd$2kvg9$1@dont-email.me> <eca21d905b57bb0b98172c573890b5c8cda91da8@i2pn2.org> <vakisq$302rl$3@dont-email.me> <vamjse$3d6eb$1@dont-email.me> <van2ni$3f6c0$1@dont-email.me> <vap9r5$3t411$1@dont-email.me> <vapv4l$3vumk$4@dont-email.me> <vashj9$grso$1@dont-email.me> <vav3iq$10jsm$4@dont-email.me> <vavc3b$11uqn$2@dont-email.me> <vavcf8$129qh$1@dont-email.me> <vavdv4$11uqn$6@dont-email.me> <vavfjq$12m8t$3@dont-email.me> <vb1gqf$1f566$1@dont-email.me> <vb4fd0$2s0uc$2@dont-email.me> <b393150191c6d78fc3033efb7c2fb993914ab53e@i2pn2.org> <vb9kao$3r9la$1@dont-email.me> <vbbvoc$9s9s$1@dont-email.me> <vbccr8$bdtb$5@dont-email.me> <vbeifo$om7b$5@dont-email.me> <vbep6r$punj$3@dont-email.me> <vbh9c8$1aru4$1@dont-email.me> <vbhm9k$1c7u5$13@dont-email.me> <vbjqhu$1sj3i$1@dont-email.me> <vbkai8$1u1js$6@dont-email.me> <vbkd8b$1v535$1@dont-email.me> <vbndvu$2g6vo$5@dont-email.me> <vbp23h$2skjj$1@dont-email.me> <vbpjlc$2vfau$7@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 11 Sep 2024 09:53:22 +0200 (CEST) Injection-Info: dont-email.me; posting-host="1b12f7c7333227c0655464d8aa448511"; logging-data="3672702"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0cEBplOIiZSz8KuLgZCnd" User-Agent: Unison/2.2 Cancel-Lock: sha1:PWLZLISu8vAONMhHt59r1PLrp90= Bytes: 7729 On 2024-09-10 14:04:28 +0000, olcott said: > On 9/10/2024 4:04 AM, Mikko wrote: >> On 2024-09-09 18:15:26 +0000, olcott said: >> >>> On 9/8/2024 9:44 AM, Mikko wrote: >>>> On 2024-09-08 13:58:32 +0000, olcott said: >>>> >>>>> On 9/8/2024 4:25 AM, Mikko wrote: >>>>>> On 2024-09-07 14:00:19 +0000, olcott said: >>>>>> >>>>>>> On 9/7/2024 5:19 AM, Fred. Zwarts wrote: >>>>>>>> Op 06.sep.2024 om 13:31 schreef olcott: >>>>>>>>> On 9/6/2024 4:36 AM, Fred. Zwarts wrote: >>>>>>>>>> Op 05.sep.2024 om 15:48 schreef olcott: >>>>>>>>>>> >>>>>>>>>>> HHH MUST ABORT AFTER SOME FIXED NUMBER OF RECURSIVE EMULATIONS >>>>>>>>>>> AND THE OUTERMOST HHH ALWAYS SEE ONE MORE THAN THE NEXT INNER ONE. >>>>>>>>>> >>>>>>>>>> And the outer one, when aborting after two cycles , misses the >>>>>>>>>> behaviour of the inner one in the next cycle, where the inner one would >>>>>>>>>> see the 'special condition', abort, return to DDD, which would halt as >>>>>>>>>> well. >>>>>>>>>> That HHH misses the last part of the behaviour of the program, does not >>>>>>>>>> change the fact that this is the behaviour that was coded in the program >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If we have an infinite chain of people each waiting for >>>>>>>>>>> the next one down the line to do something then that thing >>>>>>>>>>> is never done. >>>>>>>>>> >>>>>>>>>> The infinite chain exists only in your dream. In fact there are only >>>>>>>>>> two recursions, so never more that a chain of three HHH in the >>>>>>>>>> simulation. >>>>>>>>>> HHH is incorrect in assuming the there is an infinite chain, but this >>>>>>>>>> incorrect assumption makes that it aborts and halts. This applies both >>>>>>>>>> to the simulating and the simulated HHH. >>>>>>>>> >>>>>>>>> The way it is encoded now there are only two recursions. >>>>>>>>> >>>>>>>>> If we encode it as you suggest the outermost directly >>>>>>>>> executed HHH would wait for the first emulated HHH which >>>>>>>>> would wait for the second which would wait for third >>>>>>>>> on and on... >>>>>>>>> >>>>>>>> >>>>>>>> What is olcott's problem with English? >>>>>>>> If one way is incorrect, he thinks that it suggests that another way >>>>>>>> must be correct. >>>>>>>> I never suggested to change HHH, because there is *no* correct way to >>>>>>>> do it. Every HHH that simulates itself is incorrect. No matter what >>>>>>>> clever code it includes. >>>>>>> >>>>>>> You must be a brain dead moron. >>>>>>> As long as HHH emulates the sequence of instructions >>>>>>> it was provided then HHH is correct even if it catches >>>>>>> your computer on fire. >>>>>> >>>>>> That is right. The error only occurs when HHH no longer emulates the >>>>>> sequence of instructions it was provided. >>>>>> >>>>> >>>>> <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> >>>>> >>>>> The above refers to determining that *its input D* >>>>> "specifies a non-halting sequence of configurations" >>>>> When people change this to a *non-input D* they are >>>>> trying to get away with deception. >>>> >>>> We know except the only "people" that do so is you. >>>> >>> >>> _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] >>> >>> Try to show all of the details of how DDD emulated >>> by HHH ever reaches machine address 00002183 >> >> It is your emulator so you need to show what needs be shown. > > I am not making the false claim. > My claim in that 00002172, 00002173, 00002175, 0000217a > are emulated by the first executed emulator HHH then > HHH emulates itself emulating DDD and we get > 00002172, 00002173, 00002175, 0000217a... > > I proved this claim by showing the execution trace > https://www.liarparadox.org/HHH(DDD).pdf > > Disagreeing with verified facts seems to be a psychotic > break from reality to me. It is up to you to show otherwise. > >> For others it is sufficient to determine what HHH returns and >> whether DDD halts and compare the two. > > That is the fallacy of equivocation error. No, it is exactly the thing they consider sufficient. > The emulated HHH cannot possibly return and you > are trying to get away with lying about it by > changing to subject to a different HHH instance. Id you ara afaraid of a change of the subject then you should not change the subject. >>> Sequences of machine addressed when DDD is emulated by HHH >>> 00002172, 00002173, 00002175, 0000217a >>> which calls an emulated HHH(DDD). >>> >>> What are the next instructions of DDD emulated by the emulated HHH ? >> >> Here, too, it is your problem to show what needs be shown. >> For the rest of us it is sufficient to note what you have not proven. > > When DDD calls HHH(DDD) do I need to say that DDD does not > make a milkshake? DDD does not dance the jig? Only if someone asks. > Wouldn't someone that is not a liar say that when DDD calls > HHH(DDD) that HHH(DDD) would be invoked? I think someone that is not a liar has already said so. -- Mikko