| Deutsch English Français Italiano |
|
<4f16f10230511406d85f943048f5bc43abb58862@i2pn2.org> View for Bookmarking (what is this?) Look up another Usenet article |
Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!panix!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: Richard Damon <richard@damon-family.org> Newsgroups: comp.theory Subject: Re: Computable Functions --- finite string transformation rules Date: Fri, 25 Apr 2025 21:55:13 -0400 Organization: i2pn2 (i2pn.org) Message-ID: <4f16f10230511406d85f943048f5bc43abb58862@i2pn2.org> References: <vsnchj$23nrb$2@dont-email.me> <vtmah8$2a90$2@dont-email.me> <vtmgen$gs48$1@dont-email.me> <c2ad5086dba36124c070173c3e3252967df2fab9@i2pn2.org> <vu8g3q$v0qa$1@dont-email.me> <vu8lse$vn9b$1@dont-email.me> <vu8og4$13jl5$7@dont-email.me> <6d9ae3ac08bbbe4407fc3612441fc2032f949a3d@i2pn2.org> <vub168$3clpn$2@dont-email.me> <7ac75991b443ba53d52960ddb1932524dea8e03f@i2pn2.org> <40b048f71fe2ed2a8ef11d2d587c765c8fcbc977@i2pn2.org> <vucrgq$148pf$1@dont-email.me> <vudkt8$1ona3$2@dont-email.me> <vudp39$1rhdn$1@dont-email.me> <vudrgb$20gck$1@dont-email.me> <vue2fb$27hl3$1@dont-email.me> <vue464$28iho$2@dont-email.me> <3fcc6700e2a832dbae42afd82a4e2cf3a9d85dee@i2pn2.org> <vueta8$31sno$1@dont-email.me> <vuettb$31h9n$1@dont-email.me> <vuf4gv$38ei5$1@dont-email.me> <vuftks$3tsjm$1@dont-email.me> <vugkee$it5g$1@dont-email.me> <vugks6$i5k4$1@dont-email.me> <vuglkb$it5g$3@dont-email.me> <bc2be0c83710704bcdf1454ec9832b9c6c7276d1@i2pn2.org> <vugti2$pke9$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 26 Apr 2025 02:01:56 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="1904724"; mail-complaints-to="usenet@i2pn2.org"; posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg"; User-Agent: Mozilla Thunderbird Content-Language: en-US X-Spam-Checker-Version: SpamAssassin 4.0.0 In-Reply-To: <vugti2$pke9$2@dont-email.me> On 4/25/25 5:07 PM, olcott wrote: > On 4/25/2025 2:07 PM, Richard Damon wrote: >> On 4/25/25 2:51 PM, olcott wrote: >>> On 4/25/2025 1:39 PM, dbush wrote: >>>> On 4/25/2025 2:31 PM, olcott wrote: >>>>> On 4/25/2025 7:02 AM, dbush wrote: >>>>>> On 4/25/2025 12:53 AM, olcott wrote: >>>>>>> On 4/24/2025 10:00 PM, dbush wrote: >>>>>>>> On 4/24/2025 10:50 PM, olcott wrote: >>>>>>>>> On 4/24/2025 6:07 PM, Richard Damon wrote: >>>>>>>>>> On 4/24/25 3:41 PM, olcott wrote: >>>>>>>>>>> On 4/24/2025 2:12 PM, Fred. Zwarts wrote: >>>>>>>>>>>> Op 24.apr.2025 om 19:13 schreef olcott: >>>>>>>>>>>>> >>>>>>>>>>>>> HHH correctly determines through mathematical induction that >>>>>>>>>>>>> DD emulated by HHH (according to the finite string >>>>>>>>>>>>> transformations >>>>>>>>>>>>> specified by the x86 language) cannot possibly reach its final >>>>>>>>>>>>> halt state in an infinite number of steps. >>>>>>>>>>> >>>>>>>>>>>> No, HHH has a bug which makes that it fails to see that >>>>>>>>>>>> there is only a finite recursion, >>>>>>>>>>> >>>>>>>>>>> *You are technically incompetent on this point* >>>>>>>>>>> When the finite string transformation rules of the >>>>>>>>>>> x86 language are applied to the input to HHH(DD) >>>>>>>>>>> THIS DD CANNOT POSSIBLY REACH ITS FINAL HALT STATE >>>>>>>>>>> not even after an infinite number of emulated steps. >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> When the defined finite string trasnsformation rules, thos of >>>>>>>>>> the x86 language, are applied to this input, completed with >>>>>>>>>> the definitions from Halt7.c as stipulated, we see that DD >>>>>>>>>> calls HHH(DD), that it will spend some time emulating DDm then >>>>>>>>>> it will >>>>>>>>> >>>>>>>>> Correctly determine that DD emulated by HHH can never possibly >>>>>>>>> reach its final halt state even after an infinite number of >>>>>>>>> steps are emulated. >>>>>>>> >>>>>>>> Category error. The fixed code of algorithm HHH, which is part >>>>>>>> of the input as you agreed, emulates for a fixed number of >>>>>>>> steps. Therefore there is no infinite number of steps emulated >>>>>>>> by algorithm HHH. >>>>>>>> >>>>>>> >>>>>>> You are flat out stupid about hypothetical possibilities. >>>>>>> Of every possible HHH/DD pair where DD calls HHH(DD) and >>>>>>> DD is emulated by HHH according to the finite string transformation >>>>>>> rules of the x86 language no DD ever reaches its own final halt >>>>>>> state. >>>>>>> >>>>>> >>>>>> In other words, you're hypothesizing changing the input. >>>>>> >>>>>> Changing the input, hypothetically or otherwise, is not allowed. >>>>>> >>>>>> >>>>> >>>>> I am only saying the ALL X are Y. >>>>> Only Trolls would have difficulty with this. >>>> >>>> No, you're saying that >>> >>> For every possible HHH/DD pair where HHH emulates 0 to ∞ >> >> But those don't exist, because HHH has been stipulated to be the ONE >> machine defined in Halt7.c >> > > > *It is really not that hard* > Many C programmers said they get this (two of them > with masters degrees in computer science) > > Is there any hypothetical HHH that emulates 0 to ∞ > steps of DD where DD reaches its final halt state? > No !!! > But none of them are allowed in your system, as you have already defined what HHH is. You aren't allowed to hypotosize somethint contradictory to a stipulation you have made. Sorry, you are just showing that you just don't know what you are talking about or how logic actually works. Yes, you can change your definition, and remove the fixed definition of Halt7.c (which you object strongly when I imply that you are doing) but then everything you said I had wrong is not right, and the input just isn't a program any more as it doesn't include the code for the decider, unless you add it back, but then you no longer have *A* input, but an infinite number of them, each given to just one machine, so your "induction" doesn't work except to prove that every one of those version is incorrect, and thus none are correct. Sorry, you have checkmated your system, and sunk it to the bottom of that lake of fire, where you will join it shortly.