Deutsch English Français Italiano |
<xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!Xl.tags.giganews.com!local-3.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail NNTP-Posting-Date: Fri, 26 Jul 2024 03:35:11 +0000 Subject: Re: DDD correctly emulated by HHH is Correctly rejected as non-halting V2 ---woefully mistaken rebuttal Newsgroups: comp.theory References: <v6rg65$32o1o$3@dont-email.me> <v725d7$hlvg$1@dont-email.me> <aa7643b6d8c46d2c4dd5ef92ae3650afe114adbb@i2pn2.org> <v734ct$mjis$2@dont-email.me> <056325e336f81a50f4fb9e60f90934eaac823d22@i2pn2.org> <v73gk2$obtd$1@dont-email.me> <e2958e7ea04d53590c79b53bfb4bc9dff468772b@i2pn2.org> <v742r2$s48s$2@dont-email.me> <210383b2ee318f68a96d94aec314ee8b93f79b7f@i2pn2.org> <v75u22$19j7l$4@dont-email.me> <fde630817c49562bc765bdbc98e16a1582bcad53@i2pn2.org> <v78mda$1smtm$2@dont-email.me> <v7d5cl$2t3ja$1@dont-email.me> <v7ds0o$30pvh$3@dont-email.me> <v7fs29$3f4g7$1@dont-email.me> <v7gd17$3hlc2$2@dont-email.me> <v7ikn4$1jv5$1@dont-email.me> <v7j2pg$3o7r$3@dont-email.me> <v7l3di$idv1$1@dont-email.me> <v7lnrf$luh0$1@dont-email.me> <v7niqp$13ghd$1@dont-email.me> <v7obbn$17h8r$1@dont-email.me> <2eecnR6fa9XiWzz7nZ2dnZfqn_ednZ2d@brightview.co.uk> <v7tlin$2acgd$1@dont-email.me> <9KOcnbAqLvwnID_7nZ2dnZfqn_adnZ2d@brightview.co.uk> <v7us2g$2gvh6$1@dont-email.me> From: Mike Terry <news.dead.person.stones@darjeeling.plus.com> Date: Fri, 26 Jul 2024 04:35:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.17 MIME-Version: 1.0 In-Reply-To: <v7us2g$2gvh6$1@dont-email.me> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <xEydncDTQ97yhD77nZ2dnZfqnPGdnZ2d@brightview.co.uk> Lines: 296 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-HCxNJ/pg8hBl6SuC3p4t25mlPSVfAXbHBkzdrnrFVmUQtNHCOnxJRph77Kc4bAqcN4dilslicklXxM2!g5jw5hw7mpkJlwZ3RQKRtu9RXxD/ZhfUAfgBkKdZQEuYoPI5S7T+cWPtS04hYMaMv6lFSbyMSnPq!Qc8BmxTAewcrPFdipOr/sJqFQrE= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 15635 On 26/07/2024 01:53, olcott wrote: > On 7/25/2024 4:03 PM, Mike Terry wrote: >> On 25/07/2024 14:56, olcott wrote: >>> On 7/24/2024 10:29 PM, Mike Terry wrote: >>>> On 23/07/2024 14:31, olcott wrote: >>>>> On 7/23/2024 1:32 AM, 0 wrote: >>>>>> On 2024-07-22 13:46:21 +0000, olcott said: >>>>>> >>>>>>> On 7/22/2024 2:57 AM, Mikko wrote: >>>>>>>> On 2024-07-21 13:34:40 +0000, olcott said: >>>>>>>> >>>>>>>>> On 7/21/2024 4:34 AM, Mikko wrote: >>>>>>>>>> On 2024-07-20 13:11:03 +0000, olcott said: >>>>>>>>>> >>>>>>>>>>> On 7/20/2024 3:21 AM, Mikko wrote: >>>>>>>>>>>> On 2024-07-19 14:08:24 +0000, olcott said: >>>>>>>>>>>> >>>>>>>>>>>>> When we use your incorrect reasoning we would conclude >>>>>>>>>>>>> that Infinite_Loop() is not an infinite loop because it >>>>>>>>>>>>> only repeats until aborted and is aborted. >>>>>>>>>>>> >>>>>>>>>>>> You and your HHH can reason or at least conclude correctly about >>>>>>>>>>>> Infinite_Loop but not about DDD. Possibly because it prefers to >>>>>>>>>>>> say "no", which is correct about Infinte_loop but not about DDD. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Because this is true I don't understand how you are not simply lying* >>>>>>>>>>> int main >>>>>>>>>>> { >>>>>>>>>>> �� DDD(); >>>>>>>>>>> } >>>>>>>>>>> >>>>>>>>>>> Calls HHH(DDD) that must abort the emulation of its input >>>>>>>>>>> or {HHH, emulated DDD and executed DDD} never stop running. >>>>>>>>>> >>>>>>>>>> You are the lying one. >>>>>>>>>> >>>>>>>>>> If HHH(DDD) abrots its simulation and returns true it is correct as a >>>>>>>>>> halt decider for DDD really halts. >>>>>>>>>> >>>>>>>>> >>>>>>>>> (b) We know that a decider is not allowed to report on the behavior >>>>>>>>> computation that itself is contained within. >>>>>>>> >>>>>>>> No, we don't. There is no such prohibition. >>>>>>>> >>>>>>> >>>>>>> Turing machines never take actual Turing machines as inputs. >>>>>>> They only take finite strings as inputs and an actual executing >>>>>>> Turing machine is not itself a finite string. >>>>>> >>>>>> The definition of a Turing machine does not say that a Turing machine >>>>>> is not a finite string. It is an abstract mathematical object without >>>>>> a specification of its exact nature. It could be a set or a finite >>>>>> string. Its exact nature is not relevant to the theory of computation, >>>>>> which only cares about certain properties of Turing machines. >>>>>> >>>>>>> Therefore It is not allowed to report on its own behavior. >>>>>> >>>>>> Anyway, that does not follow. The theory of Turing machines does not >>>>>> prohibit anything. >>>>>> >>>>>>> Another different TM can take the TM description of this >>>>>>> machine and thus accurately report on its actual behavior. >>>>>> >>>>>> If a Turing machine can take a description of a TM as its input >>>>>> or as a part of its input it can also take its own description. >>>>>> Every Turing machine can be given its own description as input >>>>>> but a Turing machine may interprete it as something else. >>>>>> >>>>> In this case we have two x86utm machines that are identical >>>>> except that DDD calls HHH and DDD does not call HHH1. >>>>> >>>>> It is empirically proven that this changes their behavior >>>>> and the behavior of DDD. >>>>> >>>> >>>> You say a lot about things that are "empirically proven" and without exception they are never >>>> "proven" at all. >>>> >>> >>> It is empirically proven according to the semantics of the >>> x86 machine code of DDD that DDD correctly emulated by HHH >>> has different behavior than DDD correctly emulated by HHH1. >> >> Perhaps your actual code does behave differently! >> > > > OK great, we are making headway. > >> The questions are: >> a)� are HHH and HHH1 "identical copies", in the TM machine sense of incorporating >> ���� the algorithm of one TM inside another TM?� (As Linz incorporates H >> ���� inside H^, meaning that the behaviours of H and embedded_H MUST be identical for any >> ���� input.) >> ���� [You claim HHH and HHH1 /are/ proper copies, and yet give different results for >> ���� input (D), which is impossible.] > > They are identical in the that have identical x86 machine > code except for the x86 quirk that function calls are to > a relative rather than absolute address. So when HHH calls > the same function that HHH1 calls the machine code is not > the same.� The only other case where the machine code of > HHH1 and HHH is not identical is the way for slave instances > of HHH to pass its execution trace up to the master. The relative addressing is to be expected as a difference, and is fine provided the actual target is the same. [Which it seems to be...] The whole thing with the slave instances might well be where the bug lies! That would be slightly funny, as I pointed out that problem on some completely unrelated post, and this could be a follow-on issue where it has caused observable misbehavior in the code. (Needs a bit more investigation...) > > Although it seems that I have been correct all along about the > idea that slave instances can pass their execution trace up to > the master without breaking computability this is not the way > it has been actually encoded. > > Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk> > On 3/1/2024 12:41 PM, Mike Terry wrote: > > > > Obviously a simulator has access to the internal state > > (tape contents etc.) of the simulated machine. No problem there. > > >> b)� If the two behaviours HHH/HHH1 are indeed different, WHAT precisely is the coding >> ���� difference that accounts for that different behaviour?� (Like, with your H/H1 the >> ���� difference was that H used H's address as part of its algorithm, while H1 used H1's >> ���� address.) >> > > *I have said this about 500 times in the last three years* > DDD calls HHH(DDD) in recursive simulation and does > not call HHH1(DDD) in recursive simulation. You may have said it 500 times, but it doesn't answer my question! Look, here is a rough sketch of the two traces side by side just done by hand: [VIEW WITH FIXED FONT!!] HHH1 (DDD) HHH (DDD) ----------------------------------------------------------------- 1 main () main () 2 HHH1 (DDD) HHH (DDD) 4 Simulate (DDD) Simulate (DDD) 5 | DDD() | DDD() 6 | HHH (DDD) | HHH (DDD) 7 | Simulate (DDD) | Simulate (DDD) 8 | | DDD() | DDD() 9 | | HHH (DDD) | HHH (DDD) 10 | | Simulate (DDD) Abort 11 | | DDD() ret 0 12 | | HHH (DDD) ret 0 13 | Abort ========== REMAINDER OF ARTICLE TRUNCATED ==========